SBN

Developing Like A Pentester – (And How To Reproduce Any Vulnerability)

Reproducing the vulnerabilities documented in a pentest report is a common engineering pain point. But aligning developer skills with the tooling used during the pentest can help confirm issues faster, and deploy fixes faster.

The Tools Of The Trade

BurpSuite (or “Burp”) is the industry standard framework for performing professional application penetration tests. For developers, there are a few key features that greatly improve on standard browser debuggers:

  • Clearly view raw requests/response pairs.  
  • Replay (and modify) requests.  
  • Intercept (and modify) requests.

Installing BurpSuite

Burp has a free community edition that contains all the key features above. This can be downloaded here: https://portswigger.net/burp/releases

Burp download

How it Works

Burp is “MITM proxy” and thus can inspect all HTTP and Websocket traffic. A browser must be configured to use the local proxy (127.0.0.1:8080) and trust Burps root Certificate Authority certificate. Fortunately, Burp includes a pre-configured Chrome binary:

Navigate to ProxyInterceptOpen Browser to open the browser.

Open Burp's Browser

Once you open the browser, you can navigate and authenticate to your application. By default, “Intercept” is toggled on, and you will probably want toggle that off:

Burp toggle intercept

Trusting the Root Certificate

Burp needs to proxy TLS connections and must be able to inspect SSL. If you see certificate errors with the pre-configured browser, you should install Burp’s CA certificate at the system level.

When Burp is running, a web interface is available at http://burp from the configured browser.

Burp web interface

On Windows you can follow the following steps to trust the certificate:

1 Click CA Certificate and download the cacert.der certificate.   2 Double-click the der file and click Install Certificate   3 Select Current User   4 Select Place all certificates in the following store   5 Select Trusted Root Certification Authorities

Reproducing Common Pentest Vulnerabilities

Now let’s look at some real world examples of vulnerabilities we can test for. These examples highlight workflows that can be used to confirm and test for a great deal of pentesting test cases.

Are Session Tokens Invalidated After Logoff?

When a user logs out of an application, the session token should be terminated. A common vulnerability exists when the token is only cleared from the browser, and not actually invalidated by the application. To test for this we can do the following:

  1. Login to the application and generate a request that proves we’re authenticated. Below a request retrieving chart data will work great.

View authenticated request

  1. Send the request to ‘Repeater’

In ProxyHTTP History we can right click on any request and send its contents to repeater:

Burp send to repeater

  1. Click Logout to end the session

Click Logout

  1. Return to the repeater tab, and send the previously used request.

Burp repeating pentest request

Now we can see the session token cannot be replayed and is now terminated on the server side. Had we seen that we can still use the request to access the API, the vulnerability would be considered still open.

Modify a Request “on the fly”

In many situations it will be difficult to simply replay a previous request. In cases of file uploads, single-use CSRF tokens, and other complex requests, it is easier to use a browser to make each new request.

By using Burp’s Intercept, we can tell Burp to hold all requests before sending them to the server. We can then modify, forward, or drop all requests as we please.

Reproducing Cross-site Scripting (XSS) Vulnerabilities

Scenario: Our super secure app uses JavaScript to prevent users from entering bad characters. But the pentest team told us they still found XSS in a form field.

When trying to reproduce this with a browser, our security controls worked! How could this be?

Client side security controls

As it turns out, client-side security controls are fundamentally flawed; users ultimately have full control of client-side JavaScript. To bypass these controls, a pentester can use the form as it was intended, but enable Burp’s Intercept. When this feature is on, all requests are halted here so we can edit and forward or drop before they are sent on.

In the example below, we populated the form with safe characters, but injected the dangerous payload here:

Exploit XSS with Intercept

Miscellaneous Raw Requests

By now you should have the tools and skills to reproduce any vulnerability which is reasonably documented on an application pentest report. Remember that as long as you have a raw request, you can cut and paste this into Repeater. Just remember to update the actual network hostname of the application:

Burp raw request

Other Common Pentest Issues

VulnerabilityTest Method
Session Cookies Not Marked Secure  Observe response headers after authentication
Insufficient Cache Controls  Observe headers on pages containing sensitive data.
Username EnumerationLogin valid use/invalid password – send response to comparer. Login invalid user – send response to comparer.

Helping Teammates with Curl Commands

Your teammates may not adopt Burp, but you can still help them. Burp allows any request from your proxy history to be copied as a curl command. Just right click anywhere you see a request displayed and Copy as curl command.

Burp copy as curl

You can see this in your clipboard:

curl -i -s -k -X $'POST'     -H $'Host: staging.example.com' -H $'Connection: close' -H $'Content-Length: 36' -H $'Accept: */*'     --data-binary $'username=<script>alert(1)</script>'     $'https://staging.example.com/api/settings'

Conclusion

These methods should give you the ability to quickly generate any request you need and modify them just as a pentester would.


*** This is a Security Bloggers Network syndicated blog from Blog – Virtue Security authored by Elliott. Read the original post at: https://www.virtuesecurity.com/developing-like-a-pentester/