• whoami
• Overview
• Testing Methodologies
• Soft Skills
• Why Go Beyond Automated Testing
• Finding Unknown Stuff
• Vulnerability Exploitation
• Reporting and Automation
• Useful Training and Talks

• Security Geek
• Pentester @ BreakPoint Labs (@0xcc_labs)
• Co-Founder and Security Researcher at Primal Security (@PrimalSec)
• Certification Junkie (OSCE, OSCP, etc.)
• Loves Python, CTF Challenges, Pentesting, and Hiking/Camping

• I am not a master of all things...but I have acquired a particular set of skills...

• Goal: Share my experience with external security assessments


• Motivation: How many of you have heard this a lot?
• "Is the scan done?"
• "Can you scan us?"
• Quick Note: Automated vs. Manual Testing in the context of this talk
• Automated testing: kicking off a vulnerability scanner (Nessus, Burp Pro's scanner, Acunetix, WebInspect, etc.)
• Manual Testing: will be everything else you do beyond the scope of a vulnerability scan

• Having an established testing methodology is an important first step before you jump into conducting a pentest.

• You do not need to marry a methodology.



• There are several great methodologies out there:
• The Pentesting Execution Standard (PTES)
• OWASP Testing Guide (OTG) 4.0
• The Web App Hacker's Handbook Task Checklist


• An important point is that your methodology should include both Automated and Manual testing.

• The DHS National Cybersecurity Assessment and Technical Services (NCATS) organization recently released a report on vulnerability findings.

• According to the DHS report, 67% of high impact vulnerabilities required manual testing to enumerate.

• Burp: Right-Click -> Send to Repeater or Request in Browser

• Hopefully you are convinced that just running a scan isn't the best solution.

• The rest of this presentation will demonstrate some things I do beyond an automated tool to help me find cool stuff.

• What technology is in use?
• Ensure you properly map the application.
• Enumerate all technology features (File upload, Auth, Comments, etc.).
• Enumerate all areas of user input "Injection Points".
• Can you figure what is being done with your input?
• Is your input being presented on the screen? -> XSS.
• Is your input calling on stored data? -> SQLi.
• Does your 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.

Given the the following parameters, what would you attempt to do?

• http://example-site.com/index.php?redirect=/contact/contact-us.php
• http://example-site.com/index.php?file=/app/load.php
• http://example-site.com/index.php?name=bob
• http://example-site.com/index.php?search=starwars
• http://example-site.com/index.php?sql=SELECT * FROM USERS

If a customer gives me a list of targets I normally encourage them to let me see what I can pull out. They are normally quite surprised and unaware of what they have exposed.

How do you tackle large /8's, /16's, how do you even build out this footprint starting with a company name?

• Shodan + Censys.io
• Domain + IP Research
• Masscan + Nmap
• Whatweb + Wapalayzer
• Google, Bing, etc.
• OSINT: Company Mergers + acquisitions

• Great tool for helping to automate reconnaissance written by Tim Tomes.
• Jason Haddix wrote a script to automate several modules: enumall.sh

• EyeWitness is a tool that takes in URLs and creates a report with server headers + Screen shot of web GUI.
• Extremely useful when facing a large number of systems

• Offensive Security's Masscan Web GUI is a great way to get a quick visual of services enumerated with Masscan.

• Requesting an application URL by IP might give back drastically different content vs. the domain name.
• Keep this in mind, you could have several different applications living on the same IP.
• Pointing an automated tool to "http://ip/" may miss a lot of stuff vs. "http://ip/thisIswhereTheAppIs/"

Can you deploy the technology in a VM and test?

If you have access to source code you can enumerate vulnerabilities more efficiently.

• Unlinked content can be a gold mine of interesting functionality.
• Ensure you test for unlinked directories, files, and parameters.
• Useful wordlists for brute force content discovery:
• FuzzDB and Raft Lists
• Burp Suite's Built-in Lists
• SecLists
• My Github
• Robots Disallowed
• Tools: Dirbuster, Papator, Burp's Intruder, Burp's content discovery feature.

• Enumerating the technology and version in use can go a long way with finding vulnerabilities (Google + Exploit-db).
• What do I know about the technology and how can I find out more information?

• FuzzDB, Raft Lists, and SecLists provide great lists for custom fuzzing.
• As you start to get an understanding of how your input is being leveraged you can target your fuzzing.
• Burp Suite Pro's Intruder is my goto tool for web application fuzzing.

Very common finding with web application penetration testing.

Often combines several vulnerabilities:

• Username enumeration (Low) +
• Lack of Anti-Automation Controls (Low) +
• Lack of Password Complexity Requirements (Low) =
• Account Compromise (Critical)

• Password Reset Features "Email address not in database."
• Login Error Messages "Invalid Username"
• Timing for Login Attempts: Valid user = 0.4 secs, invalid user = 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

Pull the authentication request up in Burp's Repeater and try a few times.

If you see no sign of automation controls send to Intruder for more aggressive testing.

• No account lockout
• No/Weak CAPTCHA
• Main login form may use good controls, but other resources do not.
• Two factor authentication is required on main login form, but not API
• Mobile Interface?

We as humans are bad at passwords:

• Password the same as username...
• Variations of "password": "p@ssw0rd", "password11", etc.
• Month+Year, Season+Year: winter2016, july2015, etc.
• Company Name + year
• Keyboard Walks - PW Generator: "!QAZ2wsx", "123QWEasd", etc.

Lots of wordlists out there, consider making a targeted wordlist using CeWL.

Research the targeted user's interests and build lists around those interests.

Automated tools do this poorly. They commonly will point out file upload functionality and make it an informational finding.

You should leverage a proxy and look at all the details associated with the file upload:

• Can you determine where the file is stored?
• What controls are in place (file extension, file type, etc.)?
• Can you modify the content-type header?
• Can you add code to a legit file and have it run?
• Things like changing case could bypass filters.

Insecure file uploads -> RCE, Web Shells, XSS, etc.

Contact Us, and Feedback forms are commonly vulnerable to SMTP

How excited would you be if the app allowed you to send email as the CEO?

     POST /contact/contactus.php HTTP/1.1
     Host: www.target-site.com
     User-Agent: Mozilla/5.0
     Connection: Keep-alive
     Content-Type: application/x-www-form
     Content-Length 106

     name=Stephanie&email=your-input@domain.com&siteAdmin=webmaster@target-site.com
     &subject=Contact+Us&message=test

     

Lots of ways to do this: XSS, Open Redirect, New Domain, etc.

• Step 1: Register a domain that closely matches the target organization: breakpoint-labs.com vs. breakpoint-lab.com


• Step 2: Social Engineering Toolkit (SET) -> clone site


• Step 3: Figure out payload(s): Credential Grabber, Unicorn PowerShell HTA, Java, BeEF Hook, CSRF, Malicious Doc, etc.


• Step 4: Send Email modeled off the companies previous communications (HR, Taxes, Pay, etc.) - Check out Gophish open source phishing framework.

     From: kren@breakpoint-lab.com
     To: lhudson@breakpoint-labs.com; [other-employees]
     Subject: 2015 Tax Information

     Hey Guys,

     Please login to the employee portal for important information about 
     2015 taxes: https://www.breakpoint-lab.com/employee-login.php

     Thanks,
     Kylo Ren
     Human Resources
     Breakpoint Labs
     

• File inclusion vulnerabilities can lead to code execution "php include()".
• Sometimes they are just limited file inclusion "php echo()".
• File inclusion can lead to code execution via LFI or RFI.
• LFI's normally require you to get your input somewhere on disk then include that resource.
• RFI's are normally easier to exploit as you can point them to an external resource containing your code.

Enumerate an unlinked resource "debug.php" that gives an HTTP 200 OK and blank screen. This is where most automated tools stop.

Parameters are fuzzed in an attempt to enumerate inputs "page=" gives back a different response "Failed opening 'test' for inclusion".

Attempt to point the page parameter to local and remote resources and attempt to execute code on the server.

PHP was running as SYSTEM on the vulnerable application. An attacker could dump password hashes and pivot throughout the organization with admin privileges.

Something might be vulnerable, but take some work to successfully exploit

Many try to exploit stuff and throw complex payloads. When I am working on exploiting something, I try to use very simple payloads at first and then work my way to something more complex.

Webshell Example: Some simple examples, more here

        <?php system($_GET['d']);?>
        

        <% eval request("d") %>
        

• Recent pentest I found a WordPress server
• Could access the login panel - Brute Force is in!
• wpscan found some stuff to play with:
• Avada Theme with Revslider
• Paid Memberships Pro Path Traversal (PHP echo())
• Photo Gallery <=1.2.7 - Unauthenticated Blind SQLi

• Brute Force: Had a valid username, but very slow :(

• Paid Memberships Pro Path Traversal: Worked! Sweet LFI (Grabbed wp-config.php)
• Via PHP echo() so no code execution :(

• Replicated WP/Plugin in lab environment
• MSF Module worked in lab, caused no impact to system
• Needed to have a valid Photo gallery ID, so I had to dig around on the site to find it
• Attempted MSF module and it failed :(
• Dug through pcap and saw RSTs from server shortly after SQLi string

• Figured out how to replicate with sqlmap:

        ~$ sqlmap -u “[target_URL]” -p “order_by” --random-agent  
           --tamper=between --dbms=mysql --level=5 --risk=3
        

• Attempted on the application and still blocked, hmmm....
• I added in a "--delay=4" which delayed my SQLi requests by 4 seconds (bypassing the WAF).

• 4 second delay per request, so I am back to this....

• Result? Took a long time, but led to full compromise.
• Lots of places I could have stopped. It is always easier to say something isn't vulnerable.

• I could upload a webshell using fileupload.php (client-side MIME type check).


• Developer fixes the issue with server side checks and names the resource: fileupload2.php.


• How would you go about testing this?

• I thought "Hmm, I wonder if fileupload.php is still accessible...."