Making pentesting sexy ossams - BSidesQuebec2013

330 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
330
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
9
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Making pentesting sexy ossams - BSidesQuebec2013

  1. 1. Making PenTesting Analysis Sexy! OSSAMS Adrien de Beaupré Intru-Shun.ca Inc. SANS Internet Storm Center Handler BsidesQuebec, 01 June 2013 ©2013 Intru-Shun.ca Inc.
  2. 2. About me • • • • • • • 32+, 22+, 12+ years Contributor to OSSTMM 3 Contributor to Hacking Exposed, Linux 3rd Ed Contributor to SANS Incident Handling Guide Contributor to SANS 401 Security Essentials SANS Instructor 503, 504, 542, 560, 642, 660 ZAP, Nikto, Watcher and other OS projects 01/0/2012 ©2013 Intru-Shun.ca Inc. 2
  3. 3. Agenda • • • • • • • • Definitions Methodology Workflow Reporting Problems Solutions Demo Conclusion ©2013 Intru-Shun.ca Inc. 3
  4. 4. Definitions • Vulnerability - flaw or weakness in a system that can be exploited. • Security audit - assess the adequacy of controls and evaluate compliance. • Vulnerability assessment - description and analysis of vulnerabilities in a system. • Penetration testing - circumvent the security features of a system. ©2013 Intru-Shun.ca Inc. 4
  5. 5. Penetration Testing • Requires methodology AND creativity. • Requires performing a vulnerability assessment correctly first. • Finding alternate means to access functionality or data. • Finding alternate functionality. • Should be goal oriented. • There is no such thing as cheating in a pentest. ©2013 Intru-Shun.ca Inc. 5
  6. 6. Testing • Every test consists of a stimulus and response, and monitoring to verify the response, or lack thereof. • Testing consists of modules. • Each module has an input and an output. • You must monitor closely for responses. • Testing must be appropriate to the target. • Testing is of limited value if nothing is fixed. ©2013 Intru-Shun.ca Inc. 6
  7. 7. Methodology • • • • • • • • Logistics and Planning Open Source Information Gathering Reconnaissance Identification / Enumeration Research Vulnerability Identification Validation / Exploitation Reporting ©2013 Intru-Shun.ca Inc. 7
  8. 8. Open Source Info • Purpose: gathering information on the target organization, typically from the Internet. • Inputs: organization name, URL, IP addresses or ranges, industry or organization type. • Outputs: URLs, IP addresses or ranges, email addresses, ‘buzz’, technologies used, resumes, names, host names… • Data types: text, graphics, statistics… ©2013 Intru-Shun.ca Inc. 8
  9. 9. Reconnaissance • Purpose: determine which systems are live and map the network/technology. • Inputs: URLs, IP addresses or ranges. • Outputs: Whois, DNS, IP addresses or host names of systems which are likely to be live… • Tools: Ping, Nmap, Ike-scan, Fierce Doman Scanner, traceroute, ICMP… • Data types: text files, XML files… ©2013 Intru-Shun.ca Inc. 9
  10. 10. Identification / Enumeration • Purpose: enumerate the systems that are live, determine open ports, listening services, map applications, operating systems, and versions. • Inputs: systems known to be live/available. • Outputs: ports, services, OS, versions, patches. • Tools: Nmap, Amap, Ike-scan, Nessus… • Data types: text files, XML files… ©2013 Intru-Shun.ca Inc. 10
  11. 11. Research Purpose: list all potential vulnerabilities. Inputs: technologies in use. Outputs: list of potential vulnerabilities. Tools: vulnerability databases, search engines… • Data types: text files, XML files, databases… • • • • ©2013 Intru-Shun.ca Inc. 11
  12. 12. Vulnerability Identification • Purpose: identify known or unknown vulnerabilities in the identified technologies. • Inputs: IP addresses, ports, services, applications. • Outputs: listing of potential vulnerabilities. • Tools: scanners such as Nessus, NexPose, Burp, W3AF, ZAP… • Data types: text files, XML files, databases… ©2013 Intru-Shun.ca Inc. 12
  13. 13. Validation / Exploitation • Purpose: assign a confidence value and validate potential vulnerabilities. Have FUN!! • Inputs: listing of all potential vulnerabilities. • Outputs: listing of validated vulnerabilities and confidence rating values. • Tools: penetration testing (Metasploit, Core Impact, Canvas…), manual validation, fuzzers… • Outputs: text files, graphics, XML files, database entries, databases... ©2013 Intru-Shun.ca Inc. 13
  14. 14. Penetration! • Pillaging. • Identification of previously unknown vulnerabilities through fuzzing. • Post exploitation and pivoting. • The best hack is just logging in... • Tools: brain power • Outputs: text files, graphics, XML files, database entries, databases... BOOTY!!! ©2013 Intru-Shun.ca Inc. 14
  15. 15. Reporting • Purpose: assign risk and priority ratings to confirmed vulnerabilities. • Inputs: list of validated vulnerabilities. • Outputs: analysis results. • Tools: people brain power. • Outputs: text files, database entries, documents... • Wordsmithing. ©2013 Intru-Shun.ca Inc. 15
  16. 16. Why Automate? Laziness ☺. Consistent results over time. Allows for scheduling and trending. Streamlined and more efficient. Engineering a process that can be run and maintained by an operational group. • Allows the test team to concentrate on the areas that are not automated. • • • • • ©2013 Intru-Shun.ca Inc. 16
  17. 17. Requirements • • • • • • • • • Process – follow consistent repeatable methodology. Scriptable – typically Linux CLI tools. Tool – result that can be parsed. Database – for correlation and reporting. Correlated – multiple sources of data. Analyzed – intelligent human analysis. Mitigation – how to respond, recommendations. Metrics – quantitative, measurable, trends. Severity – rating system. ©2013 Intru-Shun.ca Inc. 17
  18. 18. Workflow • Methodology is broken down into modules. • Output from one is the input to the next. • Unfortunately most tools do not follow the methodology flow precisely, or may not allow for data extraction between modules. • Which means that either we must run each tool multiple times with different configurations, or different tools for each module. ©2013 Intru-Shun.ca Inc. 18
  19. 19. Workflow Output from module > database import Database queries > inputs to next module Reporting module > ticketing Tickets > vulnerability management and mitigation • Close the loop back to the test team process • Re-test where necessary • • • • ©2013 Intru-Shun.ca Inc. 19
  20. 20. Problem • Individual tools do not always follow a methodology and do not always allow for sufficiently granular control. • No one tool can perform all modules. • Methodology requires use of multiple tools. • Each tool may have a different output format or use a proprietary database. • Correlation and analysis can be time consuming. ©2013 Intru-Shun.ca Inc. 20
  21. 21. What is Missing • Security Assessments collect a lot of data, but don’t always correlate the data. • To properly identify risk and threats, correlation of collected data is necessary. • Correlation between different tools is essential! • Marking false positives, adding manual findings, and annotating is also required. • Current systems – Extremely Expensive. ©2013 Intru-Shun.ca Inc. 21
  22. 22. Solutions • Single unified and normalized database schema for all security assessment tools. • Obviously requires that such a schema exist! • Requires a parser for each tool we use. • This allows us to create an abstract layer between the tools and the common database, while still allowing us to enforce the methodology regardless of the tools used. ©2013 Intru-Shun.ca Inc. 22
  23. 23. OSSAMS • Open Source Security Assessment Management System www.ossams.com • A framework for security assessors to correlate and analyze risk to information systems. • Streamlines the assessment reporting process. • A modular process that builds on past assessments. ©2013 Intru-Shun.ca Inc. 23
  24. 24. Database Design • One of the key aspects of OSSAMS is the database design. • It is capable of having any number of tool outputs as an input. • Currently using MySQL on Linux with Python, PowerShell, or Perl scripts to parse outputs. • A front-end will be designed in addition to CLI. • It is flexible, extensible, and Open Source. ©2013 Intru-Shun.ca Inc. 24
  25. 25. 19/07/2011 Intru-Shun.ca Inc. 25
  26. 26. Tooloutput • For every tool there are outputs. An output file, typically an XML file, will describe what the tool has discovered from the target domain, subnet, system, host, or application). • Tooloutputnumber - Primary Key, autoincrement. Projectname, Projectid, Toolname, Filename, Filedate, Tooldate , Version, OSSAMSversion, Scanner , Inputtimestamp. ©2013 Intru-Shun.ca Inc. 26
  27. 27. Configuration • For every TOOLOUTPUT it may contain configuration information about the tool. Its primary key is Configurationnumber, which is an auto-increment. • Configurationtype, Configurationoptionname, Configurationoptionvalue, Configurationnumber. ©2013 Intru-Shun.ca Inc. 27
  28. 28. Domain • A grouping of systems, subnets, CIDR ranges, or non-contiguous but related IP addresses will be considered a domain. DNS and Sctive Directory domains fir here as well. Primary key is Domainnumber which is auto-increment. • Domainname, Domaintype, Domainnumber, Domainnotes, Domainaddresses. ©2013 Intru-Shun.ca Inc. 28
  29. 29. Groups • A domain or a host may have none, one, or more user groups. Its primary key is Groupnumber, which is an auto-increment. • Groupproperty, Groupvalue, Groupname, Groupnumber, Groupnotes, Groupprivilege, Groupmembers. ©2013 Intru-Shun.ca Inc. 29
  30. 30. Hosts • A toolout may describe none, one, or more hosts (computers or network devices). Its primary key is Hostnumber, which is an autoincrement. • Domainnumber, Hostproperty, Hostvalue, ipv4, ipv6, Hostname, Hostnumber, Hostptr, Whois, Recon, Reconreason, Hostcriticality, Macaddress, Macvendor, Hostnotes, Hostos, Osgen, Osfamily. ©2013 Intru-Shun.ca Inc. 30
  31. 31. Users • A Domain, application, or a host may have none, one, or more users. Its primary key is Usernumber, which is an auto-increment. • Userproperty, Uservalue, Username, Usernumber, Domainnumber, Groupnumber, Hostnumber, Passwordhash, Password, Userprivilege, Usernotes. ©2013 Intru-Shun.ca Inc. 31
  32. 32. Ports • A host may have none, one, or more ports open. This table contains information about ports (open, filtered, or closed). Its primary key is Portnumber, which is an autoincrement. • Protocol, Portnumber, Portstate, Reason, Portbanner, Portversion, Portname, Service, Method, Confidence, Portvalue. ©2013 Intru-Shun.ca Inc. 32
  33. 33. Vulnerabilities • A host, port, or application may have none, one, or more vulnerabilities associated with it. Its primary key is Vulnerabilitynumber, which is an autoincrement. • Vulnerabilityid, Vulnerabilityseverity, Vulnerabilityrisk, Vulnerabilityconf, Falsepositive, Vulnerabilityname, Vulnerabilitydescription, Vulnerabilitysolution, Vulnerabilitydetails, Vulnerabilityextra, Vulnerabilityvalidation, Vulnerabilitynotes, Vulnerabilityattribute, Vulnerabilityvalue, Vulnerabilityuri, Httprequest, Httpresponse, Httpparam. ©2013 Intru-Shun.ca Inc. 33
  34. 34. Refs • A vulnerability may have none, one, or more references associated with it. A reference can be a link to a web site, a database entry (such as SecurityFous bid, OSVDB, Secunia, CVE, CCE, CWE, …). • Vulnerabilitynumber, Referencenumber, Referencetype - Type reference (URI, OSVDB, CVE…), Referencevalue – Value of the reference. ©2013 Intru-Shun.ca Inc. 34
  35. 35. Booty • Booty may have been taken from a Domain, User, Host, Application, or other assorted places the pentester finds stuff ☺ • Domainnumber, Hostnumber, Bootyproperty, Bootyvalue, Bootynumber, Bootynotes. ©2013 Intru-Shun.ca Inc. 35
  36. 36. Scripts • Flow: – Scanning scripts – Import scripts – Query scripts – Analysis with brainpower – Iterative process – Reporting scripts ©2013 Intru-Shun.ca Inc. 36
  37. 37. Parsing Scripts • • • • • • • • Main function Read configuration function Database access function Read a list of files Read a directory of files Parsing XML, HML, or text file function Insert function Return ©2013 Intru-Shun.ca Inc. 37
  38. 38. Supported tools • Completed: – acunetix, burp, grendel, nessus, netsparker, nexpose community, nikto, nmap, ratproxy, retina community, skipfish, sslscan, w3af, wapiti, watcher, websecurify, zap. • Roadmap: – appscan, arachni, core impact, fierce, httprint, iss, languard, metasploit, ncircle, nexpose, n-stalker, ntospider, openvas, proxystrike, retina, saint, sandcat, webcruiser, webinspect, wsfuzzer… ©2013 Intru-Shun.ca Inc. 38
  39. 39. Demo • A brief demo of the parsing script and database use. • Also briefly discuss the roadmap for OSSAMS: – – – – – – – – Finalize the database design and scripts. Reporting templates. Query database for module tool input. OSSTMM RAVs. OWASP. Other methodologies/frameworks. Work on tool data interchange format. Get more people involved!! ©2013 Intru-Shun.ca Inc. 39
  40. 40. Code • Currently living at: handlers.dshield.org/adebeaupre/ossams-parser.tgz And www.ossams.com • Requires: – Python > 2.5; – Python-mysqldb; and – Lxml. ©2013 Intru-Shun.ca Inc. 40
  41. 41. Conclusions • The key is not running the scanners, but analysis, methodology, correlation, documentation, and problem solving. • Organizations can automate security testing and reporting processes, particularly consultants and enterprises. • The key is analysis and database utilization. • These can be built using Free / Open Source Software tools and/or commercial offerings. • Should be done with proper planning, tools, methodology, processes, and expertise. ©2013 Intru-Shun.ca Inc. 41
  42. 42. QUESTIONS? ADRIEN@INTRU-SHUN.CA @ADRIENDB THANK YOU! ©2013 Intru-Shun.ca Inc. 42

×