Beyond Automated Testing - RVAsec 2016
Download as PPT, PDF2 likes727 views
The document by Andrew McNicol and Zack Meyers outlines strategies to enhance external security assessments beyond automated testing. It emphasizes the importance of manual testing methodologies, reconnaissance, and effective reporting while providing practical examples and resources for security professionals. The authors highlight the significance of understanding client goals, establishing clear communication, and offering remediation support after assessments.
Beyond Automated Testing - RVAsec 2016
- 1. Beyond Automated Testing By: Andrew McNicol & Zack Meyers
- 2. Agenda ~$ whoami Overview How to Go Beyond a Scan Testing Methodologies Soft Skills Planning Organization Reconnaissance Mapping Automated Testing Manual Testing Examples Useful Resources Reporting Remediation Support Useful Trainings and Links
- 3. ~$ whoami Andrew McNicol (@primalsec) Zack Meyers (@b3armunch) We are Security Geeks Red Team @BreakPoint Labs (@0xcc_labs) Bloggers/Podcasters @Primal Security (@primalsec) Certification Junkies (OSCE, OSCP, GWAPT, GPEN etc.) Python, CTFs, Learning, long walks on the beach ( @AnnapolisSec)
- 4. Overview Goal: To share our experiences with external security assessments Motivation: Mostly frustration… How many of you have heard this? Is the scan done? Can you scan us? Automated Testing: Running a vulnerability scanner Manual Testing: Everything else you do beyond the scope of the scan According to a recent DHS report, 67% of high impact vulnerabilities required manual testing to enumerate
- 5. How to Go Beyond a Scan 1. Mindset: Fail 1000s of times and Continue Trying 2. Recon + Mapping: Find Systems + Content Others Have Missed 3. Automated Testing: Run the appropriate tool for the job 4. Manual Testing: Identify, Understand, and Fuzz all Areas of Input Research all Version Specific Vulnerabilities Combine Findings, Remove False Positives, and Abuse Features 1. Reporting: Highlight Business Impact
- 6. Testing Methodologies A solid methodology helps from a technical and business perspective You do not need to marry a methodology during your engagements Create checklists and templates to guide assessment process Several great methodologies exist: Pentesting Execution Standard (PTES) OWASP Testing Guide (OTG) 4.0 Web Application Hackers Handbook Task Checklist Good methodologies should include Automated and Manual testing
- 7. Our Methodology (High Level) Planning and Scoping Reconnaissance Mapping Automated Testing Manual Testing Reporting Remediation Support
- 8. Soft Skills Be confident and know that you will fail 1000s of times before you succeed…
- 9. Planning Understanding your customers Goals Establish the scope “What” Establish the Rules of Engagement (ROE) “How” Setup communication channels and timeframe “Who and When” Do not get caught up in terms: “Pentest” means different things to different people Figure out what is most important to the business Confidentiality, Availability, or Integrity?
- 12. Reconnaissance Goal: Given a company name, how can you map their footprint? IP/Domain Research (Dig, whois, Google, etc.) System Enumeration (Shodan, Censys.io, Masscan, Nmap) Subdomain Enumeration (Google, Recon-ng, crt.sh, fierce.pl, etc.) Tech Stack Enumeration (Whatweb, Wappalyzer, EyeWitness) OSINT (emails, names, mergers, acquisitions, etc.)
- 13. System Enumeration Shodan + Censys.io (3rd Party Gathered) Masscan -> Nmap (Active Probing)
- 14. Subdomain Enumeration Google, Shodan, crt.sh, Recon-ng, fierce.pl Jason Haddix wrote a script: enumall.sh for Recon-ng
- 15. Tech Stack Enumeration Whatweb, Wappalyzer, EyeWitness
- 16. OSINT Customer Already Compromised? Usernames, YouTube, Social Media, etc. Posting on stack overflow, GitHub, Pastebin? Can you find source code online?
- 17. Mapping 17
- 18. Map Your App Mapping your App is key before kicking off automated testing Spider: enumerates linked content Brute Force techniques to enumerate unlinked content Do not judge a system by its IP: 1 IP could have several domains living on it http://ip-addr/ may get you very little and http://ip-addr/unlinked-dir/ may store the application http://ip-addr/ vs. http://domain-name/ (Virtual Hosting?)
- 19. Spidering
- 20. Unlinked Content Enumeration Use Burps Intruder and it’s methods (Sniper, Cluster Bomb, etc.) Use Burp Pros Discover Content feature to expand your Site Map Use Commonly known lists from tools like Dirbuster Web Services (?wsdl, wsdler, SoapUI, etc.) SecLists: collection of content (Passwords, Resources, etc.) Source: https://github.com/danielmiessler/SecLists
- 22. Automated Testing This is where you’d actually click the “scan” button #SavesTime Run the right tool for the job! Few things to keep in mind about Automated Testing: Can miss stuff Can break stuff Can take a long time Can have false positives
- 24. Manual Testing: Questions For us manual testing is about four (4) main things: 1. Identify all areas of user input (Injection Points) and fuzz 2. Identify all features and abuse them like an attacker 3. Find the systems and content that others have missed 4. Continue to ask yourself “What happens if I try this?”
- 25. Manual Testing: Questions (Cont.) Is your input being presented on the screen? -> XSS Is your input calling on stored data? -> SQLi Does input generate an action to an external service? -> SSRF Does your input call on a local or remote file? -> File Inclusion Does your input end up on the file system? -> File Upload Does your input cause another page to load? -> Redirect Vulns Can we enumerate email addresses? -> Phishing Targets
- 26. Custom Input Fuzzing FuzzDB, Raft Lists, and SecLists provide great lists for fuzzing Understand how your input is being used to target fuzzing (XSS, SQLi, LFI, etc.) Burp Suite Pro’s Intruder is our go to tool for web application fuzzing
- 27. Manual Testing Examples We plan to walk through a few examples to demonstrate some manual testing techniques
- 28. Ex 1: Feature Abuse Contact Us and Feedback forms are commonly vulnerable to SMTP Injection How excited would you be?
- 29. Ex 1: Feature Abuse (Cont.) We can control the ‘siteAdmin’ & ‘subject’ parameters
- 30. Ex 2: Combine Several Findings Very common finding with web application testing Combines several vulnerabilities that automated tools may find but don’t put together or exploit: - Username enumeration (Low) + - Lack of Automation Controls (Low) + - Lack of Password Complexity Reqs (Low) = - Account Compromise (Critical)
- 31. Ex 2: Username Enumeration Password Reset Feature “Email address not found” Login Error Message “Invalid Username” Timing for login Attempts: Valid = 0.4 secs Invalid = 15 secs User Registration “Username already exists” Various error messages, and HTML source Contact Us Features “Which Admin do you want to contact?” Google Hacking and OSINT Document Metadata Sometimes the application tells you
- 32. Ex 2: Automation Controls Pull the auth request up in Burp’s Repeater and try it a few times No sign of automation controls? -> Burp Intruder - No account lockout - Non-existent or Weak CAPTCHA - Main login is strong, but others? (Mobile Interface, API, etc.)
- 33. Ex 2: Weak Passwords We as humans are bad at passwords…here are some tricks: - Password the same as username - Variations of “password”: “p@ssw0rd”… - Month+Year, Season+Year: winter2015… - Company Name + year - Keyboard Walks – PW Generator: “!QAZ2wsx” Lots of wordlists out there, consider making a targeted wordlist using CeWL Research the targeted user’s interests and build lists around those interests
- 34. Ex 3: Proxy -> FW Bypass Let’s say you stumble upon a resource called ‘proxy.ashx’ You append a “?” to the end with URL to follow (proxy.ashx? https://google.com) This resource then loaded Google’s HTML content while remaining at our target domain… so what should be do with our open redirect? Spear Phishing Users: By appending a malicious link to the resource we could distribute malware to unsuspecting victims Firewall Bypass and Scanning: The application can be used to make arbitrary TCP connections to any system(s) (Internal and External). We could potentially bypass firewall restrictions to access other systems internal to their network
- 35. Ex 3: Proxy -> FW Bypass (Cont.) We leveraged a quick Python script to automate this Firewall Bypass task of identifying and making connections to system on the internal network - /proxy.ashx?http://192.168.1.200 -> 200 OK (Lets Take a Look!)
- 36. Ex 4: File Inclusion to Shell • File Inclusion vulns can lead to code execution “php include()” • Sometimes they are limited to just file inclusion “php echo()” • LFIs normally require you to get your input on disk then include the affected resource (log poisoning) • RFIs are normally easier to exploit as you can point them to an external resource containing your code
- 37. Ex 4: File Inclusion to RCE: Step 1 • Unlinked resource “debug.php”- HTTP 200 OK and blank screen
- 38. Ex 4: File Inclusion to RCE: Step 2 • Parameters are fuzzed to enumerate inputs. "page=test" gives back a different response "Failed opening 'test' for inclusion”
- 39. Ex 4: File Inclusion to RCE: Step 3 • Attempt to execute code: 1.php = <?php system(‘id’);?>
- 40. Ex 4: File Inclusion to RCE: Step 4 • IN REAL LIFE: The web service was running as SYSTEM!
- 41. Ex 5: Email Spoofing Overview The Perception: – People often think SPAM filters and their own wit will allow them to never be tricked into opening a malicious email or an attachment. The Reality: – Emails can be spoofed often easily due to a lack of several key defenses not being put into place (SPF, DKIM, DMARC) for Mail servers. The Statistics: – According to the recent Verizon 2016 DBIR report “In roughly 636,000 sanctioned phishing emails, we captured whether the email was reported. Approximately 3% of targeted individuals alerted management of a possible phishing email.”
- 42. Ex 5: Email Spoofing (Cont.)
- 43. Ex 5: Email Spoofing (Cont.) • Here is what the email looks like:
- 44. Ex 5: Email Spoofing (Cont.) • It does not have to be from the same domain either:
- 45. Ex 5: Email Spoofing (Cont.) • Outlook client – you can model the name of the target orgs Help Desk. Email below is sent from a Gmail account:
- 46. Ex 5: Email Spoofing (Cont.) • Google Apps for Work – Has little security setup and without SPF/DKIM DNS TXT records you can essentially use their domain to phish/send email • The previous email examples abused Google Apps for Work to spoof emails – very reliable technique • Solution? Configure SPF/DKIM/DMARC TXT records with your provider • Very few people configure these in our experience
- 47. Reporting 47
- 48. Reporting • We leverage Markdown for custom reporting, which uses an HTML-esque format. Common Findings Database - Check it out • Some customers also enjoy having a spreadsheet of findings in addition to the report. • Find out the format your customer prefers/needs.
- 49. Reporting (Cont.) Depending on your Rules of Engagement (ROE), consider this: •If you find a vulnerability or flaw within a system and you do exploit it then include an exploitation section with to your finding. •If you find a vulnerability or flaw within a system and you could exploit it then include an attacker scenario section within your finding Also: •Pics or it didn’t happen (always include screenshots!) •Include detailed steps taken to identify the vulnerability if done via manual testing (OSINT, fuzzing, dirbuster, etc.) •Include a high level summary for each finding to appeal to managers before going too deep into the technical details
- 50. Offer Remediation Testing • Offering remediation support to your customers after delivering the report is like kicking the extra point after winning the game scoring touchdown • Re-evaluating findings once they are deemed mitigated or resolved • When possible, provide additional remediation recommendations and countermeasures beyond what’s state in the report • Can lead to additional testing and a stronger relationship with the customer
- 51. Useful Trainings & Links • Free Training: Cybrary • CTFs: Vulnhub, Past CTF Writeups, Pentester Lab • Training: Offensive Security, GWAPT • Book: Web Application Hackers Handbook • Book: Black Hat Python • Talk: How to Shot Web - Jason Haddix • Talk: How to be an InfoSec Geek - Primal Security • Talk: File in the hole! - Soroush Dalili • Talk: Exploiting Deserialization Vulnerabilities in Java • Talk: Polyglot Payloads in Practice - Marcus Niemietz • Talk: Running Away From Security - Micah Hoffman • Github Resource: Security Lists For Fun & Profit