WebApp 101

WebApps 101: Server-Side Request Forgery (SSRF) and PortSwigger Academy Lab Examples

Note: Majority of the content here was ripped directly from PortSwigger.net.

Table of Contents:

  • What is Server-Side Request Forgery?
  • What is the impact of these attacks?
    • SSRF attacks against the server itself
    • SSRF attacks against other back-end systems
  • Finding Attack Surface for SSRF
    • What do we look for?
    • Where do we look?
    • Commonly chained exploits
  • Basic Bypass Techniques
    • Bypassing black-list based defenses
    • Bypassing white-list based defenses
  • Exploitation Examples
    • Example 1: Basic SSRF against the local server
    • Example 2: Basic SSRF against another back-end system
    • Example 3: SSRF with blacklist-based input filter
    • Example 4: SSRF with whitelist-based input filter
    • Example 5: SSRF with filter bypass via open redirection vulnerability
    • Example 6: Exploiting XXE to perform SSRF attacks

What is Server-Side Request Forgery?

SSRF is a vulnerability that allows attackers to induce a web server to make an HTTP request that they control. Typically, this would allow the attacker to see things that they wouldn’t otherwise be able to see. For example, having the webserver make a request back to itself or to another device on the internal network it is connected to make allow attackers to extract information that isn’t publicly available.


What is the impact of these attacks?

It is common for infrastructure to be configured to trust other devices within the same internal network, or to trust devices that are managed by the same organization and their trusted third-parties. Because of this, SSRF may allow attackers to bypass authentication restrictions, location or IP-based restrictions, and more.

SSRF attacks against the server itself

In these type of attacks, the attacker will induce a HTTP request to make the webserver issue a request back to its own local loopback interface (oftentimes 127.0.0.1 or localhost). This could be beneficial if restrictions are configured within parts of the webapp that are only visible when you’re accessing them locally from the webserver itself. For example, say there is an admin panel that isn’t visible to external users, but is visible to users who access it from the webserver itself. Issuing a request like this may allow an attacker to gain unauthorized access.

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

stockApi=http://localhost/admin

Why does this work? There are a number of reasons why a webserver may implicitly trust requests made by itself.

  • Admins may rely on front-end load balancers or web application firewalls to implement access control checks BEFORE the request hits the webserver. When a connection is made back to the server itself, the check is bypassed.
  • For disaster recovery purposes, applications may allow admin access without logging in for any users coming from the local machine.
  • The administrative interface might be listening on a different port number than the main application, which may make it not directly reachable from the outside.

SSRF attacks against other back-end systems

It is common for internal systems to be less protected than external systems on the internet. Because of this, compromising an externally facing system with a SSRF vulnerability may allow you to interact with other devices on the internal network that trust that webserver when communicated to from INSIDE the network on non-routable private IP addresses. In many cases, internal back-end systems contain sensitive functionality that can be accessed without authentication by anyone who is able to interact with the systems.

For example, lets say there is an administrative interface at the back-end URL https://192.168.0.68/admin. Here, an attacker can exploit the SSRF vulnerability to access the administrative interface by submitting the following request.

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

stockApi=http://192.168.0.68/admin

Finding Attack Surface for SSRF

Knowing about the vulnerability is great, but how do we actually hunt for it? Where do we look? What other vulnerabilities are commonly chained? Let’s answer those questions.

What do we look for?

Full URLS in Requests. This is the easiest to spot, as you will typically see the HTTP/HTTPS handlers in the request.

Partial URLs in Requests. Sometimes an application will only place a hostname or part of a URL path into the request parameters. The value submitted is then incorporated server-side into a full URL that gets requested. These may be harder to spot, and harder to exploit, because you do not have control of the entire URL that gets requested.

URLs within data formats. Some applications transmit data in formats whose specification allows the inclusion of URLs that might get requested by the data parser for the format. For example, an application that accepts and parses XML code may be vulnerable to XXE Injection, and in turn be vulnerable to SSRF via XXE.

Where do we look?

SSRF vulnerabilities are commonly found in the following:

  • Anytime an application makes a call to an API.
  • Look in URLs or Parameters that issue requests to HTTP/HTTPS handlers.

Commonly chained exploits

  • Open Redirects may help cause more impact to an SSRF vulnerability. See lab example below.
  • When the application parses XML code, XXE Injection may be utilized to cause an SSRF. See lab example below.

Basic Bypass Techniques

It is common for applications to implement defenses the prevent exploitation of SSRF attacks. This section will explain various defenses and provide some bypass techniques to try.

Bypassing black-list based defenses. Some applications will block input containing hostnames like 127.0.0.1, localhost, or sensitive URLs like /admin. To circumvent the filter, you can use these techniques.

  • Using an alternative IP representation of 127.0.0.1, such as 2130706433, 017700000001, or 127.1.
  • Registering your own domain name that resolves to 127.0.0.1. You can use spoofed.burpcollaborator.net for this purpose.
  • Obfuscating blocked strings using URL encoding or case variation.

Bypassing white-list based defenses. Some applications will only allow input that matches, begins with, or contains a whitelist of permitted values. The following can be used to circumvent this filter.

  • You can embed credentials in a URL before the hostname, using the @ character. For example: https://expected-host@evil-host.
  • You can use the # character to indicate a URL fragment. For example: https://evil-host#expected-host.
  • You can leverage the DNS naming hierarchy to place required input into a fully-qualified DNS name that you control. For example: https://expected-host.evil-host.
  • You can URL-encode characters to confuse the URL-parsing code. This is particularly useful if the code that implements the filter handles URL-encoded characters differently than the code that performs the back-end HTTP request.
  • You can add a period (.) to the URL within the parameter. If the Regex used for whitelisting is misconfigured, this could bypass the restriction.
  • You can use combinations of these techniques together.

While watching Nahamsec’s stream, he tried bypassing using the following when he had a parameter that looked like this: stockAPI=http://localhost/admin/delete?username=carlos

 · http://%2f%2flocalhost%2fadmin%2fdelete?username=carlos
 · http://%2f%2flocalhost/login/../%2fadmin%2fdelete?username=carlos
 · http://%2f%2flocalhost/x/../%2fadmin%2fdelete?username=carlos
 · https://%2f%2flocalhost/login/../%2fadmin%2fdelete?username=carlos
 · http://%2f%2flocalhost/////admin%2fdelete?username=carlos
 · http://localhost/ADMIN/delete?username=carlos
 · http://localhost/AdMiN/delete?username=carlos 

Exploitation Examples

Example 1: Basic SSRF against the local server

In this example, browsing to the /admin directory returns an error stating that its only available locally from the server, or for signed in administrators.

However, a SSRF vulnerability exists within the “Check Stock” functionality of the website. Checking the stock of an item will issue a request that talks to a back-end API, which you can see in the following request.

Modifying the StockAPI parameter allows us to issue a request from the webserver, to itself, and delete a user from the admin panel.


Example 2: Basic SSRF against another back-end system

In this example, there is a device on the internal network that allows unauthenticated access to the admin interface. Since we can’t access this device externally, we’ll need to leverage the SSRF vulnerability on the externally facing webserver to communicate with it. To begin, we know that the internal network uses the following internal network scheme: 192.168.0.0/24. Armed with this knowledge, we’ll start by making a webrequest that looks like this.

We can actually leverage this vulnerability to scan the internal network for other devices. To automate this, we’ll send this request to Burp Intruder.

  • Click “Clear §”, change the stockApi parameter to http://192.168.0.1:8080/admin then highlight the final octet of the IP address (the number 1), click “Add §”.
  • Switch to the Payloads tab, change the payload type to Numbers, and enter 1, 255, and 1 in the “From” and “To” and “Step” boxes respectively.
  • Click “Start attack”.

After some time, the attack should reveal that an address on the LAN returned a 200 OK.

Throw that request into Repeater, and update the parameter to include instructions for deleting a user to complete the challenge.


Example 3: SSRF with blacklist-based input filter

In this example, there are two protections that we need to bypass.

  • First, we have to bypass the protections that prevent 127.0.0.1 or localhost. To do so, we’ll sent a request to 127.1 and confirm that we receive a response.

Second, the word “admin” is blacklisted. To get around this, we can URL-encode a character in the word, such as the ‘a’. This will encode to %61. However, this is blocked as well, so we can then encode the % sign in %61. This is referred to as “Double URL Encoding”. When ‘a’ is double URL Encoded, this would be represented as %2561. Issuing the following request also returns a 200 OK, confirming we’ve bypassed the filter.

Finally, we can issue the request to delete the user.


Example 4: SSRF with whitelist-based input filter

In this example, there are a handful of bypasses we’ll need to implement.

First, we’ll try and issue a request to localhost. We find that the returned response tells us “stock.weliketoshop.net” must be included in the request.

Knowing we’ll have to include that text in the request, we test to see if the application will accept embedded credentials by adding username@ to our request. Doing so returns a different response, as if the webserver attempted to connect to “username”.

This is great, but it’s pointless if we don’t have a way to indicate a URL fragment. We can usually utilize the # sign for this, but the application rejects requests that contain that character. To get around this, we’ll Double URL Encode the # sign so that it is represented by %2523. Notice how now the request goes through.

Finally, we can replace “username” with localhost, and see that the response returns a webpage! By appending /admin/delete?username=carlos, we can issue a request that deletes the Carlos user.


Example 5: SSRF with filter bypass via open redirection vulnerability

In this example, we have an application that contains a SSRF along with an Open Redirection. By chaining these two together, we’re able to force the webserver to issue a request that deletes an user from within the admin panel.

To begin, we’ll find the open redirect vulnerability. This is present within the “Next Product” option. Click that returns a URL that looks like the following:

https//web-security-academy.net/product/nextProduct?currentProductId=1&path=/product?productId=2

We find that anything placed into the above path parameter will get redirected. For example, the following URL would redirect to google.com

https//web-security-academy.net/product/nextProduct?currentProductId=1&path=http://google.com

Knowing this, we can place our SSRF payload within the path parameter of the open redirect.

/product/nextProduct?path=http://192.168.0.12:8080/admin/delete?username=carlos

Then we can abuse the SSRF to force the webserver to issue the request. Doing so will delete the Carlos user.


Example 6: Exploiting XXE to perform SSRF attacks

In this example, we have a web application that parses XML input and returns any unexpected values in the response. Because of this, we can inject an XXE that issues a SSRF on our behalf, which leads to exposed EC2 credentials.

To begin, we’ll capture the “Check Stock” request and Insert the following external entity definition in between the XML declaration and the stockCheck element:

<!DOCTYPE test [ <!ENTITY xxe SYSTEM "http://169.254.169.254/"> ]>

Then replace the productId number with a reference to the external entity: &xxe;

The response should contain “Invalid product ID:” followed by the response from the metadata endpoint, which will initially be a folder name. Iteratively update the URL in the DTD to explore the API until you reach /latest/meta-data/iam/security-credentials/admin. This should return JSON containing the SecretAccessKey.

WebApp 101

WebApps 101: Information Disclosure Vulnerabilities and PortSwigger Lab Examples

Note: Majority of the content here was ripped directly from PortSwigger.net.

Table of Contents:

  • What is information disclosure?
  • What are some examples of information disclosure?
  • How to prevent information disclosure vulnerabilities
  • Practical Lab Examples
    • Example A: Information disclosure in error messages
    • Example B: Information disclosure on debug page (using comments)
    • Example C: Source code disclosure via backup files
    • Example D: Authentication bypass via information disclosure

What is information disclosure?

Information disclosure, also known as information leakage, is when a website unintentionally reveals sensitive information to its users. Depending on the context, websites may leak all kinds of information to a potential attacker, including:

  • Data about other users, such as usernames or financial information
  • Sensitive commercial or business data
  • Technical details about the website and its infrastructure

The dangers of leaking sensitive user or business data are fairly obvious, but disclosing technical information can sometimes be just as serious. Although some of this information will be of limited use, it can potentially be a starting point for exposing an additional attack surface, which may contain other interesting vulnerabilities. The knowledge that you are able to gather could even provide the missing piece of the puzzle when trying to construct complex, high-severity attacks.

Occasionally, sensitive information might be carelessly leaked to users who are simply browsing the website in a normal fashion. More commonly, however, an attacker needs to elicit the information disclosure by interacting with the website in unexpected or malicious ways. They will then carefully study the website’s responses to try and identify interesting behavior.


What are some examples of information disclosure?

Some basic examples of information disclosure are as follows:

  • Revealing the names of hidden directories, their structure, and their contents via a robots.txt file or directory listing
  • Providing access to source code files via temporary backups
  • Explicitly mentioning database table or column names in error messages
  • Unnecessarily exposing highly sensitive information, such as credit card details
  • Hard-coding API keys, IP addresses, database credentials, and so on in the source code
  • Hinting at the existence or absence of resources, usernames, and so on via subtle differences in application behavior

How to prevent information disclosure vulnerabilities

Preventing information disclosure completely is tricky due to the huge variety of ways in which it can occur. However, there are some general best practices that you can follow to minimize the risk of these kinds of vulnerability creeping into your own websites.

  • Make sure that everyone involved in producing the website is fully aware of what information is considered sensitive. Sometimes seemingly harmless information can be much more useful to an attacker than people realize. Highlighting these dangers can help make sure that sensitive information is handled more securely in general by your organization.
  • Audit any code for potential information disclosure as part of your QA or build processes. It should be relatively easy to automate some of the associated tasks, such as stripping developer comments.
  • Use generic error messages as much as possible. Don’t provide attackers with clues about application behavior unnecessarily.
  • Double-check that any debugging or diagnostic features are disabled in the production environment.
  • Make sure you fully understand the configuration settings, and security implications, of any third-party technology that you implement. Take the time to investigate and disable any features and settings that you don’t actually need.

Practical Lab Examples

Example A: Information disclosure in error messages

In this example, we have an eCommerce site that uses Product IDs to track its products. When you select a project, the URL presents ?productID=1 as a parameter. By modifying your request to use a non-valid number, we’re able to trigger an error message that leaks the Apache version.


Example B: Information disclosure on debug page (using comments)

In this example, we’re able to leverage Burp Suite to crawl the site and look for comments in the source code. One of the comments hint at a directory present at /cgi-bin/phpinfo.php. Browsing to this allows us to enumerate a wealth of information about the website.

To automate hunting for comments, you can use Burp:

  1. Navigate to Target and select Site Map.
  2. Right click the correct target, select Engagement Tools, and select Find Comments.

Example C: Source code disclosure via backup files

In this example, robots.txt shows us a /backup directory. That directory allows for listing to anybody, so we’re able to see a backup file in .bak format. Viewing the contents of this file reveals a hardcoded credential in plain text.

Always check robots.txt and source code!


Example D: Authentication bypass via information disclosure

In this example, we try to access the admin interface at /admin. However, browsing to this page returns an error stating that it is only accessible when accessing it locally.

To debug this a bit, we decide to intercept the default GET /admin request, and change it to a TRACE /admin request. Doing so shows us that the webserver adds an additional header that contains our IP address.

Assuming this is what is used to determine whether or not we’re locally accessing the page, we will append our own value for this header to every request we make to the server. To automate this, we can use Burp Suite:

  1. Navigate to Proxy and select Options.
  2. Find the Match and Replace section and click Add.
  3. Leave the Match blank, but enter the following into Replace: X-Custom-IP-Authorization: 127.0.0.1

Now reissuing the GET /admin request bypasses the local IP address restriction, which we were only able to determine because of the information disclosure.


WebApp 101

WebApps 101: HTTP Host Header Attacks and PortSwigger Academy Lab Examples

Note: Majority of the content here was ripped directly from PortSwigger.net.

Table of Contents:

  • What is an HTTP Host Header?
  • What Are Host Header Injection Attacks?
  • How Do We Test for Attacks?
    • Checking for flawed validation
      • Insert the payload within the port field
      • Provide arbitrary domain name containing the whitelisted domain name
    • Sending ambiguous requests to bypass front-end systems.
      • Inserting duplicate Host headers
      • Supply an absolute URL
      • Add line wrapping via space character
    • Additional Technique: Inject Host Override Headers
    • Additional Technique: Brute-Forcing Virtual Hosts
  • Exploitation Examples
    • Example 1A: Basic password reset poisoning (Uses Host Header)
    • Example 1B: Password reset poisoning via middleware (Uses X-Forwarded-Host Header)
    • Example 1C: Password reset poisoning via dangling markup (Uses Arbitrary Port Within Host Header)
    • Example 2: Web cache poisoning via ambiguous requests (Uses X-Cache Header)
    • Example 3: Host header authentication bypass (Changing Host Header to localhost)

What is an HTTP Host Header?

The HTTP Host header is mandatory, and specifies the domain name that the client wants to access. Modifying this header may allow you to view various webpages against the same server, if that server is configured to respond to multiple virtual hosts. In addition to virtual host routing, the Host header is important for a load-balancer or third-party intermediary (think CloudFlare) to know where to route traffic once the request comes in and is processed.

For example, a user browsing to a website at http://example.com/page-1 will issue a request that looks like the following:

GET /page-1 HTTP/1.1
Host: example.com

Example.com may resolve to an IP address that many other domain-names respond to. Because of this, multiple domain names may be sent to the same webserver or resource, and that resource needs to be able to know where to send traffic. This is done by looking at the Host header.


What Are Host Header Injection Attacks?

When a payload is injected directly into the Host header of a HTTP Request, this is referred to as a Host Header Injection Attack. If the webserver fails to validate or escape the Host Header properly, this could lead to harmful server-side behavior.

As the Host header is in fact user controllable, this practice can lead to a number of issues. If the input is not properly escaped or validated, the Host header is a potential vector for exploiting a range of other vulnerabilities, most notably:

  • Web cache poisoning
  • Business logic flaws in specific functionality
  • Routing-based SSRF
  • Classic server-side vulnerabilities, such as SQL injection

How Do We Test for Attacks?

The process for testing this is very simple. Just intercept the Request in Burp, and modify the Host header to an arbitrary value. The webserver will likely respond in one of two ways:

  1. The page you intended to test will display. This typically occurs when the site you’re testing is configured as the webserver’s default or fallback option when a improper Host header is provided.
  2. The server returns an error. This is more common, especially in cases when multiple websites are being hosted by the same webserver or front-end.

Checking for flawed validation

Instead of returning a “Invalid Host Header” response, you may find that your request is blocked as a security measure. This doesn’t mean that the server isn’t vulnerable, but you do need to try and understand how the server parses the host header. The following contains a list of possible bypass techniques:

Insert the payload within the port field. The domain name may be checked, but the port number may not be.

GET /example HTTP/1.1
Host: vulnerable-website.com:bad-stuff-here

Provide arbitrary domain name containing the whitelisted domain name. Validation may be checking simple to see if the target domain is present in the response. By registering an arbitrary domain name that ends with the same sequence of characters as a whitelisted one, you may be able to bypass defenses.

GET /example HTTP/1.1
Host: notvulnerable-website.com

Sending ambiguous requests to bypass front-end systems.

In cases were a load balancer or CDN is in place acting as the front-end server, we may be able to bypass security checks on the front-end server using one request, but have the application process the request on the back-end differently. For example, the following bypass techniques can be deployed.

Inserting duplicate Host headers. This is particularly useful when your request is processed by multiple webservers (such as a load-balancer or CDN). Different systems may handle the request differently, giving one header precedence over the other one, which can effectively override its value. let’s say the front-end gives precedence to the first instance of the header, but the back-end prefers the final instance. Given this scenario, you could use the first header to ensure that your request is routed to the intended target and use the second header to pass your payload into the server-side code.

GET /example HTTP/1.1
Host: vulnerable-website.com
Host: bad-stuff-here

Supply an absolute URL. Officially, the request line should be given precedence when routing the request, but this isn’t always the case in practice. You may be able to exploit the same behavior mentioned above by issuing a request similar to the one below.

GET https://vulnerable-website.com/ HTTP/1.1
Host: bad-stuff-here

Note: Don’t forget to modify the protocol from http to https and vice versa to see the behavior.

Add line wrapping via space character. Sometimes adding a space character to the Host header may interpret the indented header as a wrapped line. This may cause the app to treat it as the preceding header’s value. This is especially helpful if the website blocks requests that contains multiple Host headers, as it may not register the indented Host header as an additional one.

GET /example HTTP/1.1
 Host: bad-stuff-here
Host: vulnerable-website.com

Additional Technique: Inject Host Override Headers

If we can’t override the Host Header using one of the above mentioned techniques, perhaps we can inject our payload into a header that will override it for us. For example, that could be one of the following:

  • X-Host
  • X-Forwarded-Server
  • X-HTTP-Host-Override
  • Forwarded
GET /example HTTP/1.1
Host: vulnerable-website.com
X-Forwarded-Host: bad-stuff-here

Additional Technique: Brute-Forcing Virtual Hosts

Companies sometimes make the mistake of hosting publicly accessible websites and private, internal sites on the same server. Servers typically have both a public and a private IP address. As the internal hostname may resolve to the private IP address, this scenario can’t always be detected simply by looking at DNS records.

In some cases, the internal site might not even have a public DNS record associated with it. Nonetheless, an attacker can typically access any virtual host on any server that they have access to, provided they can guess the hostnames. If they have discovered a hidden domain name through other means, such as information disclosure, they could simply request this directly. Otherwise, they can use tools like Burp Intruder to brute-force virtual hosts using a simple wordlist of candidate subdomains.


Exploitation Examples

So we’ve used the techniques mentioned above and have identified that a website is vulnerable to a Host Header Injection attack. How do we actually exploit this, and what is the impact? These examples will help you answer those questions.

Example 1A: Basic password reset poisoning (Uses Host Header)

To begin, we start by sending a password reset request for our own account. This is received in our email and we observe that the reset link contains a unique token that is used to issue the reset request.

If we issue another password reset request, but this type modify the Host header to a domain that we control (nope.com), the page returns a success 200 message.

Heading over to our email, we see that the password reset link is generated for https://nope.com.

Armed with this knowledge, we can craft our malicious request by submitting a password reset, but modifying the Host Header to point to a domain that we control.

Once the link that is sent to Carlos gets clicked, it should issue a request to our malicious domain. The request should include Carlos’ valid password reset token.

Now that we have his token, we can reset Carlos’ password by issuing the proper POST request.


Example 1B: Password reset poisoning via middleware (Uses X-Forwarded-Host Header)

This example is basically the same as the above, except modifying the Host Header returns an error. Instead, we can inject our own X-Forwarded-Host header that contains an arbitrary domain.

Which then generates an email containing a password reset token attached to a domain that we can control.

So again, we update the X-Forwarded-Host Header within a new password reset request, but we’ll point it to a domain that we actually control and modify the user to be Carlos.

This will generate an email containing a link. Once that link is clicked by Carlos, a password reset request is sent to our domain that contains the token we need.

Throwing that into Burp allows us to reset Carlos’ password.


Example 1C: Password reset poisoning via dangling markup (Uses Arbitrary Port Within Host Header)

In this example, a valid password reset request will send an email containing a new password.

We find that modifying the domain within the Host Header within our request returns an error, but modifying the port does not return an error.

Heading back to our mailbox, we can confirm that the arbitrary value we added to the port number is injected into the email message that gets sent – But we have to analyze this either by viewing the source code of the page, the response directly in Burp, or the Raw email message. Viewing the email raw is the easiest.

Armed with these details, we can analyze the message and see that we have an injection point that is reflected inside a link as an unescaped, single-quoted string. We’ll issue another password reset request, but this time we’ll do it for Carlos and use the port to break out of the string and inject a dangling-markup payload pointing to our exploit server.

The result is a mangled email being sent to the victim, but the AV is used to scan the link that we injected. This issues a GET request to our exploit server that contains the victims newly generated password.


Example 2: Web cache poisoning via ambiguous requests (Uses X-Cache Header)

In this example, we find that caching is in use by observing the “X-CACHE” Header. In addition to this, we find that we’re able to inject an arbitrary domain within a Javascript tag by adding a 2nd Host Header to our request. Combining these two items could allow us to run Javascript that we control in the browser of any victim that is served our cached webpage.

To begin, we notice that a simple GET request to the root of the site returns a 200 OK that isn’t cached.

However, sending a 2nd request to the same page quickly does confirm that caching is in use.

To request a unique page each time, we’ll just add a fake parameter to our request that we can increment when we don’t wish to retrieve a cached page. For example, I’ll add ?cb=1234 to the request.

Now let’s increment this value one more time, and see what happens when we try to inject a 2nd Host Header that contains an arbitrary domain. We see that the returned response was not cached, and the 2nd Host Header we provided was reflected into a Javascript Script tag.

We find that removing the 2nd Host Header and issuing a 2nd request to the same page will return our injected payload in the response, as long as the returned response is cached.

To get malicious with this, let’s create our own Javascript file on our exploit server. We’ll need to make sure that it contains the same file name/path as provided in the response from the webserver. That path is /resources/js/tracking.js.

With our payload crafted, make note of the URL that it lives at. Next, let’s go back into Burp and increment our ?cb param again. Before submitting the request, make sure to also include a 2nd Host Header that points to domain hosting your .js payload.

Quickly, we’ll remove the 2nd Host Header from our request to confirm the returned Response is cached and still contains our injected Payload.

Finally, we can simulate a user browsing to the malicious page and triggering the Javascript.

To solve the lab, remove the ?cb parameter and reissue the requests so that the Javascript payload will pop when a victim accesses the Home Page.


Example 3: Host header authentication bypass (Changing Host Header to localhost)

In this example, we find that an admin panel is available at /admin, but the page won’t load unless you’re accessing it locally.

However, intercepting the request and adjusting the Host Header to localhost bypasses this requirement.

And now we can delete users.


Example 4: Routing-based SSRF

This example requires access to Burp Pro. Will update this post once I have access to this tool.

Tips & Tricks

How to Route Public Python Exploit Code Through Burp Suite

When you come across public exploit code written in Python, it is sometimes easiest to just route the exploit through Burpsuite so you can understand what it’s doing — especially in cases where the code interacts with web applications.

To do this, we can simple add some code that instructs the script to use a proxy.


First, make sure that the Requests module is already being called by the script. Check for the following line of code:
import requests

As long as that is present, we can add a Proxy variable at the top of the exploit, but after the Requests module is imported. If the application uses HTTPS instead of HTTP, then you’d want to use https in the below line.
proxies = {'http': 'http://127.0.0.1:8080'}

Next, we need to look through the code for any .get or .post requests and add the following to the end of it.
, proxies=proxies

For example, let’s say you have a line of code that looks like this:
s.get(SERVER_URL, verify=False)

You will want to modify it so that it looks like this:
s.get(SERVER_URL, verify=False, proxies=proxies)

Just make sure to do this throughout the entire exploit. The easiest way to find them all may be to search for “requests” and look for any time a .get or .post is added to that.

Now you can spin up Burp Intercept and run the exploit! This will allow you to interact with the exploit through Burp and gives you much more visibility into the requests being made.

WebApp 101

Business Logic Flaws/Vulnerabilities and PortSwigger Lab Examples

The term “Business Logic” can be misleading, but in the context of web application security and bug bounties, a Business Logic Vulnerability is when an attacker is able to make a website or application perform an action that was never intended by the developers. For example, a eCommerce website may allow you to perform a transaction, without actually going through the intended shopping cart sequence. This could potentially lead to invalided input supplied during the transaction process and cause unwanted outcomes.

Another term for these vulnerabilities is “Logic Flaws”. Since logic flaws typically require a human element for thinking about what the web application can do, and how we can make it do things that aren’t intended, they make for a great vulnerability category to hunt for, since vulnerability scanners typically won’t find these type of bugs.

Table of Contents:

  • Example A: Excessive trust in client-side controls:
  • Example B: 2FA Broken Logic
  • Example C: High-Level Logic Vulnerability
  • Example D: Low-Level Logic Flaw
  • Example E: Inconsistent Handling of Exceptional Input
  • Example F: Inconsistent Security Controls
  • Example G: Weak Isolation on Dual-Use Endpoint
  • Example H: Password Reset Broken Logic
  • Example I: 2FA Simple Bypass
  • Example J: Insufficient Workflow Validation
  • Example K: Authentication Bypass via Flawed State Machine
  • Example L: Flawed Enforcement of Business Rules
  • Example M: Infinite Money Logic Flaw

PortSwigger Labs

Example A: Excessive Trust in Client-Side Controls

In this example, we have a eCommerce website that sells a jacket for over $1,000. When the item is added to the cart, the price is also sent in the request. We can intercept this request and adjust the price of the item ourselves using Burp Suite.


Example B: 2FA Broken Logic

In this example, we have a web application that utilizes 2FA. We notice by observing the requests after signing in that in addition to sending our username/password, a 2nd request is sent that will request a 2FA code to be generated for whatever user is supplied in the “verify” parameter.

If we sign in with our own account (since we know valid credentials to it), we can then modify the request so that the verification code is generated for a different account by replacing “wiener” with our target, “carlos”.

With a verification code generated for Carlos, let’s enter an invalid 2FA code that is pending for our login and capture the request in Burp Suite. With the request captured, let’s send it to Repeater where we will modify the “verify” parameter to “carlos” and then set the “mfa-code” parameter to our payload.

Using a simple wordlist that contains four digit numbers, we’re able to brute force Carlos’ MFA code.

And then show the response in the browser to get logged in as Carlos.


Example C: High-Level Logic Vulnerability

In this example, we have another eCommerce site with multiple products for sale. This time however, the price is hardcoded with the ProductID in the request. Adding the expensive jacket will make the total in our cart over $1,000.

However, we can also intercept a request that adds another item in the cart. Since this item costs $80, we can use Burp to add -15 items, which cuts the price down for us.

Now our cart total is only $48.50.


Example D: Low-Level Logic Flaw

In this example, we’re working with the same eCommerce website. However, our previous attacks don’t work. This time, we’re going to attempt to add so many items to the cart that the “Total Price” overflows. Most programming languages can’t hold integers over 2.147b in value. In this particular case, adding enough items to the cart will cause the Total Price to overflow and start incrementing in negative values instead.

Burp Suite can easily perform this for us. If we intercept a request that is adding 99 items to the cart, we can then send it to Intruder. Instead of specify a payload, we’ll clear the payloads and set our payload type to a “Null payload”. This will essentially allow us to repeat our same request in bulk a certain, or infinite, number of times.

We can see by doing so, we have now added a ton of items to the cart, and cause the Total Price to return a negative value.

Now we just need to modify the cart in the right way so that the total price fits to a value between $0-100 since we have store credit of that amount. At that point, we can place the order.


Example E: Inconsistent Handling of Exceptional Input

In this example, we have a login page as well as the ability to register an account. Any account registered with the @dontwannacry.com domain will automatically be assigned administrator rights. However, since we do not have access to a valid @dontwannacry.com email account, we must exploit a misconfiguration.

We find that while we’re able to insert more than 256 characters when creating an email account, the application will truncate the remaining characters when signing up for an account. For example, we could enter the following email address when registering: ONHknIt7C0NCfRqaybvtktQpiS2BflyVTzAiGeC0yfOyIVN4wBGHFc9LXCsMIKGj7LfV2pmFbLyj73orVyWnSQcQKJHPG8zl2STXKoSLjccYVWf5rVB64aVkMlYlOppQBG8svfEE1nb3bOnenhF2fECssVypADOlJGQIuUUvrGCINMUY0agnw8tegZqDxep2XszBk501BgBdkY8om7jpXIERAoPvKHqs9aq5bFattacker@dontwannacry.com.ac9a1f1f1e15a857801bf5e2013f00e5.web-security-academy.net

As long as we own the domain dontwannacry.com.ac9a1f1f1e15a857801bf5e2013f00e5.web-security-academy.net, we should be able to receive the email message to verify the account. However, logging in reveals that only the first 256 characters are kept. This changes our email address to an @dontwannacry.com address, therefor tricking the system into giving us admin rights.


Example F: Inconsistent Security Controls

This one is simple. We have a login page and the ability to register an account. Any account registered with an @dontwannacry.com address will be assigned admin rights. We can’t register an account directly with this email because there is an email verification step upon initial registration, however, the web app does not require email verification to update your email address afterwards.

Once logged in using an email you do control, you can simply change your email to an @dontwannacry.com address using the “My Account” page.


Example G: Weak Isolation on Dual-Use Endpoint

In this example, we have a web app that allows for user accounts. When we’re logged in as a low level user, there is a feature for updating our password, but the client requires that we provide our current password before the new one will take. However, we notice that intercepting the request and deleting the “&current-password” parameter will allow us to change the password without knowing the current with.

We also notice that we can reset the password for any given user by providing the username of the desired account within the &username parameter.


Example H: Password Reset Broken Logic

In this example, we’re able to request a password reset for our own account to generate a valid reset token. However, the web app does not appear to perform checks against the token to ensure its validity. We find that when the token is removed, we’re able to reset a password for any user account by updating the “username” parameter.

With the token values removed, we can then adjust the username parameter to reflect the account we wish to reset. This now allows us to sign in using carlos:password as our credentials.


Example I: 2FA Simple Bypass

In this example, we know the password to two accounts both of which are secured with 2FA.

  • Our account: wiener:peter
  • Vitim account: carlos:montoya

Since we have access to Wiener’s mailbox, we can sign in from start to finish, receive the 2FA code, and see that we’re redirected to /my-account upon successful login.

With this knowledge, we can bypass the 2FA prompt by signing into Carlo’s account with the password and then browsing straight to /my-account when asked to enter the 2FA code.


Example J: Insufficient Workflow Validation

In this example, we want to purchase a super expensive item that costs $1,000, but only have $100 in store credit to use. We notice that ordering an item that we can afford (meaning less than $100) will issue a GET request that looks like this.

GET /cart/order-confirmation?order-confirmed=true HTTP/1.1

Armed with this knowledge, we can simply add the more expensive item to the cart and then use Burp Repeater to reissue that GET request. Doing so allows us to successfully place an order with bypassing the checkout process that collects payment.


Example K: Authentication Bypass via Flawed State Machine

In this example, we have valid login credentials for a non-admin user. However, the login process sends the user through a couple of pages. It looks like this.

  1. The user logs in by issuing a POST request to /login. We will forward this request.

2) Next, the web application will issue a GET request to /role-selector. This is a page that allows the user to select which role they want to interact with the web application with, based on which roles they’re allowed to use. However, we want to bypass this test to see what role is supplied by default, so we’ll drop this request.

3. At this point, we’ll manually browse back to the home page of the application, which shows us that we now have access to the admin panel! This proves that the default role is administrator.


Example L: Flawed Enforcement of Business Rules

In this example, we have an eCommerce site with discount codes. There are two codes that we can use on the page, but the intention of the developers was to only allow each code to be used a single time.

  • SIGNUP30 – Takes 30% off your order.
  • NEWCUST5 – Takes $5 off your order.

When trying to use the same discount code multiple times, the site will return an error.

However, we found that alternating between the two codes will bypass this control and allow us to use each coupon an unlimited number of times. Using Repeater, it is easy to send multiple requests and modify the coupon code being used for each.

Eventually the price is reduced to $0 as we’ve applied so many discounts.


Example M: Infinite Money Logic Flaw

In this example, we find that we’re able to utilize a 30% off coupon code to purchase a giftcard worth $10. Because there are no limits to the number of times we can place an order with this code, we can place multiple orders and make $3 off of each transaction.

To do this, we’ll configure a Burp Suite macro that will add the gift card to our cart, apply the coupon, check out, retrieve the gift card code, apply it to our account, and then use that money to repeat the process.

Since Portswigger does a better job at explaining how to set up the Macro than I could, the below is copied directly from their website. The process will create a Macro that runs each time we submit any request to the site. Once that is configured, we’ll utilize Repeater to automate the process of sending multiple null requests to the site to trigger the macro.

  1. Go to “Project options” > “Sessions”. In the “Session handling rules” panel, click “Add”. The “Session handling rule editor” dialog opens.
  2. In the dialog, go to the “Scope” tab. Under “URL Scope”, select “Include all URLs”.
  3. Go back to the “Details” tab. Under “Rule actions”, click “Add” > “Run a macro”. Under “Select macro”, click “Add” again to open the Macro Recorder.
  4. Select the following sequence of requests. Then, click “OK”. The Macro Editor opens.
    POST /cart
    POST /cart/coupon
    POST /cart/checkout
    GET /cart/order-confirmation?order-confirmed=true
    POST /gift-card
  5. In the list of requests, select GET /cart/order-confirmation?order-confirmed=true. Click “Configure item”. In the dialog that opens, click “Add” to create a custom parameter. Name the parameter gift-card and highlight the gift card code at the bottom of the response. Click “OK” twice to go back to the Macro Editor.
  6. Select the POST /gift-card request and click “Configure item” again. In the “Parameter handling” section, use the drop-down menus to specify that the gift-card parameter should be derived from the prior response (response 4). Click “OK”.
  7. In the Macro Editor, click “Test macro”. Look at the response to GET /cart/order-confirmation?order-confirmation=true and note the gift card code that was generated. Look at the POST /gift-card request. Make sure that the gift-card parameter matches and confirm that it received a 302 response. Keep clicking “OK” until you get back to the main Burp window.
  8. Send the GET /my-account request to Burp Intruder. Use the “Sniper” attack type and clear the default payload positions.
  9. On the “Payloads” tab, select the payload type “Null payloads”. Under “Payload options”, choose to generate 412 payloads. On the “Options” tab, set the thread count to 1. Start the attack.
  10. When the attack finishes, you will have enough store credit to buy the jacket and solve the lab.

Hacking Tutorial, WebApp 101

Exploiting Cross Site Request Forgery (CSRF) & Bypassing Defenses

Wondering what Cross Site Request Forgery is? Go check out my previous post on this topic at Let’s Talk Basics About Cross Site Request Forgery (CSRF).

Ready to learn more about how to exploit it? You’re in the right place. The concepts and examples shown in this post were taken from PortSwigger’s WebSecurity Academy.

Table of Contents

  • What areas in a webapp do you look to exploit with CSRF?
  • What are some basic bypass techniques?
  • What about some more advanced bypass techniques?
    • Tokens Tied to Non-Session Cookie
    • “Double Submit” CSRF Token method.
    • Referer Validation Dependent on Present Referer Header
    • Referer Validation Only Checks if Domain Name is Present

What areas in a webapp do you look to exploit with CSRF?

Anywhere there might be a PUT request on the back-end. You are able to exploit this with a GET request as well, but the odds of finding this in the wild are very small as most devs know better by now.

  • Check the account page and see if a password change/reset might be vulnerable.
  • Perhaps a place where you can input your own email to send a recovery link?
  • Then I start looking for input fields to input XSS as they are sometimes chainable. For example, if an admin can post on a message board, but nobody else can, perhaps we can use XSRF to post a XSS payload on the message board for us.

What are some basic bypass techniques?

Since most mitigation techniques have to do with placing a unique token, bypassing this token requirement may be simple if they do not implement good validation on the other side.

  • What happens if we delete the value within the token parameter?
  • What happens if we delete the entire parameter including the value?
  • What happens if we replace the existing token with one of a different value that has the same length?
  • What happens if we convert our POST request into a GET request?Some applications correctly validate the token when the request uses the POST method but skip the validation when the GET method is used.

Basic Exploit Code:

When there are no defenses in play, or one of the defense methods listed above, it is relatively easy to exploit CSRF using a simple HTML template. Obviously you’ll want to replace the placeholders with the accurate values. Host this code up on your exploit server and wait for the victim to browse to the page:

<form method="$method" action="$url">
     <input type="hidden" name="$param1name" value="$param1value">
</form>
<script>
      document.forms[0].submit();
</script> 

What about some more advanced bypass techniques?

I get it, you’re over the basics and you’re up against a target that has some more difficult protections in place. Let’s up our game a bit, shall we?

Bypassing CSRF Protections: Tokens Tied to Non-Session Cookie

Some applications tie the CSRF token to a cookie, but not to the same cookie that is used to track sessions. This can easily occur when an application employs two different frameworks, one for session handling and one for CSRF protection, which are not integrated together.

This situation is harder to exploit but is still vulnerable. If the web site contains any behavior that allows an attacker to set a cookie in a victim’s browser, then an attack is possible. The attacker can log in to the application using their own account, obtain a valid token and associated cookie, leverage the cookie-setting behavior to place their cookie into the victim’s browser, and feed their token to the victim in their CSRF attack.

Proof of Concept:

In our example, we have two different user accounts to sign in with. We’ll first log in as the username Wiener and issue a “Change Email” request. Let’s take a look at a legitimate request first and observe that the webserver responds with a 302 message.

Notice how modifying the session cookie will return an Unauthorized error, indicating that we’ve been signed out.

However, modifying the csrfKey cookie returns a “Invalid CSRF Token” message. This suggests that the csrfKey cookie may not be strictly tied to the session.

To prove our theory, let’s spin up a incognito window and sign in with a 2nd user account. Let’s issue a legitimate “Change Email” request, but lets swap the csrfKey cookie and csrf parameter from the first account to the second account.

We see that the request went through with a successful 302 response. If proper validation was in place, the csrfKey cookie would be tied to the session cookie, causing this example to be rejected. But because it isn’t, this means we can generate a valid CSRF cookie/param pair, and then pass those to our victim’s session during the attack.

Exploit Code:

To exploit this vulnerability, we need to be able to inject both a cookie that we control, along with a parameter. The parameter is easy, since we can just issue that as part of our CSRF request. The cookie is more challenging, because we need a way to inject a csrfKey cookie with a value that we control into the victim’s browser. Luckily for us, our example site’s search feature allows us to inject cookies. How do we know? When we perform a search, we see that the response sets a cookie named “LastSearchTerm”, which contains the value of our last search term.

Note: Notice how the above screenshot also shows the search feature has no CSRF protections. If it had, we wouldn’t be able to inject cookies using this method.

Now we can create a URL that contains the following. Notice how when URL decoded, it clearly sets a cookie named “csrfKey” with whatever value we choose.

/?search=test%0d%0aSet-Cookie:%20csrfKey=your-key

The full payload looks like this. Line 5 includes our cookie injection that will create a csrf cookie with a valid value that pairs with the csrf parameter in Line 3.

<form method="POST" action="https://ac1a1faf1f72be7c80d80d67002b00c9.web-security-academy.net/email/change-email">
     <input type="hidden" name="email" value="hacked@hax.com">
     <input type="hidden" name="csrf" value="AtwwO8ZSKpgUrBEkqBMIieJrCACVavFz">
</form>
 <img src="https://ac1a1faf1f72be7c80d80d67002b00c9.web-security-academy.net/?search=test%0d%0aSet-Cookie:%20csrfKey=65EfxxiuOkDcp12bXTGK9eAMzxfGFasr " onerror="document.forms[0].submit()"> 

Bypassing CSRF Protections: “Double Submit” CSRF Token method.

Some applications do not maintain any server-side record of tokens that have been issued, but instead duplicate each token within a cookie and a request parameter. When the subsequent request is validated, the application simply verifies that the token submitted in the request parameter matches the value submitted in the cookie. This is sometimes called the “double submit” defense against CSRF, and is advocated because it is simple to implement and avoids the need for any server-side state.

Example of vulnerable request:

POST /email/change HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 68
Cookie: session=1DQGdzYbOJQzLP7460tfyiv3do7MjyPw; csrf=R8ov2YBfTYmzFyjit8o2hKBuoIjXXVpa

csrf=R8ov2YBfTYmzFyjit8o2hKBuoIjXXVpa&email=wiener@normal-user.com

In the above request, it’s important to notice how the csrf session token matches the csrf parameter. When a “double submit” vulnerability exists, we simply need to inject a cookie that matches whatever csrf parameter we’re going to forge as well.

Exploit code:

In our example, the search feature on the vulnerable website allows the ability for us to inject a cookie of our choosing within the victim’s browser. Line 5 shows us injecting a csrf cookie with a value of fake. Line 3 shows us also forging a request with paramater csrf containing a matching value of fake.

<form method="POST" action="https://acb31f821e84332a809da51f00d200ce.web-security-academy.net/email/change-email">
     <input type="hidden" name="email" value="hax@hacked.com">
     <input type="hidden" name="csrf" value="fake">
</form>
<img src=" https://acb31f821e84332a809da51f00d200ce.web-security-academy.net/?search=test%0d%0aSet-Cookie:%20csrf=fake " onerror="document.forms[0].submit();"/> 


The end result is we’re able to update the users email to be hax@hacked.com by bypassing the “double submit” CSRF mitigation technique.


Bypassing CSRF Protections: Referer Validation Dependent on Present Referer Header

Aside from defenses that employ CSRF tokens, some applications make use of the HTTP Referer header to attempt to defend against CSRF attacks, normally by verifying that the request originated from the application’s own domain. Some applications validate the Referer header when it is present in requests but skip the validation if the header is omitted. What were to happen if we were to delete the referer header from the request?

Proof of concept:

In the following example, the “Change Email” forum validates the Referer header when present to ensure the request originated from the same domain. This is what a legitimate request looks like.

Notice how the validation kicks in and will reject the request when we modify the Referer header to originate from a different domain, such as fake.com.

However, deleting the Referer header in its entirety allows the request to go through.

Exploit code:

Line 4 includes the bypass to strip out the Referer header from our request.

<form method="POST" action="https://ac891f331edd33ed8007ab8500750000.web-security-academy.net/email/change-email">
     <input type="hidden" name="email" value="hacked@hax.com">
</form>
     <meta name="referrer" content="no-referrer"> 

Bypassing CSRF Protections: Referer Validation Only Checks if Domain Name is Present

Some applications validate the Referer header in a naive way that can be bypassed. For example, if the application simply validates that the Referer contains its own domain name, then the attacker can place the required value elsewhere in the URL.

Proof of concept:

Like before, we see that a legitimate request from the website returns a valid 302 response.

Also like before, modifying the Referer header to contain a domain name that differs from the legitimate one will force the server to reject the request.

However, we’re able to get a successful 302 response by simply adding web-security-academy.net as a subdomain to fake.com.

Exploit Code:

Line 5 contains the piece that allows us to modify what URL and Referer the response comes from.

<form method="POST" action="https://acc01f071ff796db8098277e00a00038.web-security-academy.net/email/change-email">
     <input type="hidden" name="email" value="hacked@hax.com">
</form>
<script>
      history.pushState("", "", "/?https://acc01f071ff796db8098277e00a00038.web-security-academy.net.fake.com/email") 
      document.forms[0].submit();
</script> 

Tips & Tricks

Setting Up BurpSuite

Once Burp loads up, there are a few things we need to configure to make our lives easier. This guide intends to serve as a list of steps that I like to do after a fresh install of Burp Suite.

  • Installing Java to Launch Burp via CLI
  • Installing and Configuring FoxyProxy
  • Disabling Firefox’s Captive Portal
  • Installing the Burp’s Certificate in Firefox
  • Installing Common Extensions
  • Installing Jython for Python Extensions

Installing Java to Launch Burp via CLI

It is preferable to launch the Burp JAR file from the command line, as this gives you more control over its execution, in particular the amount of memory that your computer assigns to Burp.

In order to do this, you must first have Java installed. At time of writing, I found that Burp works best with Java 14.0.2, which you can download from https://www.oracle.com/java/technologies/javase/jdk14-archive-downloads.html.

Once installed, you can check if Java is present in your PATH by running java -version. If you get an error like the one in the screenshot, continue on.

Adjust your PATH environment variable to include the path to the Java executable.

C:\Program Files\Java\jdk-14.0.2\bin

Your version should now display when running the same command mentioned earlier.

Finally, you can now launch Burp from the command line. The following will launch Burp with 4 GB of RAM allocated.

Java -jar -Xmx4g "C:\Program Files\BurpSuitePro\burpsuite_pro.jar"


Installing and Configuring FoxyProxy

First, to make our lives easier, let’s install the Firefox add-in for FoxyProxy.

With the add-in installed, let’s head into the Options.

Now we can Add a new entry.

Let’s create the New Entry with the following.

Title: Burp
Proxy IP: 127.0.0.1
Port: 8080

Click Save.

With this in place, we can easily route traffic in/out of Burp without having to dive deep into Firefox’s settings.


Installing the Burp’s Certificate in Firefox

Now that we have the proxy configured, we’ll want to import Burp’s certificate so that we do not receive certificate errors while browsing the internet.

Let’s start by routing our traffic through our proxy and navigating to the following URL.

http://burpsuite/

Now we can click on CA Certificate to download the necessary der file.

With the cert file saved, lets head into Preferences and click on Options.

Head over to the Privacy settings, find the Certificates section, and click on View Certificates.

In the Certificate Manager window, find the Authorities tab. Then, select Import.

Browse to the .der file you downloaded earlier.

Enable Trust this CA to identify websites, and then click OK.


Disabling Firefox’s Captive Portal

With Firefox’s default configuration, you will see a lot of requests to http://detectportal.firefox.com.

To get rid of this, let’s head over to about:config and click Accept the Risk and Continue.

Search for network.captive-portal-service, and set the value to False.


Installing Common Extensions

To install an extension, head over to the Extender tab of Burp Suite, and then select BApp Store.

Installing an extension is as easy as finding the one you want, and clicking Install. Here’s a list of my must-haves.

  • Autorize
  • Logger++
  • Param Miner
  • Upload Scanner
  • OpenAPI Parser
  • Wsdler
  • 403 Directory Bypasser

Installing Jython for Python Extensions

Any extension written in Python will require us to to set up Jython. For example, clicking into the Autorize extension will display an option to Download Jython.

You’ll want to download the Jython Standalone.

Once downloaded, I like to place the file into my C:\ drive at the following location.

C:\Burp\Extensions

Head back over to Burp Suite and select the Extender tab. Go into Options, and select Select File.

Then browse to and select the JAR file.

You should now have the option to Install Python-based extensions.

Hacking Tutorial

How To Route Tools (Gobuster) Through a BurpSuite Proxy

There are times where you will need to troubleshoot or route your tools through a proxy in order to get the result you need. This post will serve as a general guide for configuring BurpSuite as a proxy so you can route tools through it easily, and troubleshoot things as needed.

In this specific example, we showcase how to route Gobuster through Burpsuite so we can analyze traffic.

Table of Contents:

  • Identifying the Problem
  • Configuring Proxy in BurpSuite
  • Testing the Proxy

Identifying the Problem

On HackTheBox, there is a box called Node where you can’t use Gobuster for enumeration. When you’re able to analyze requests through a tool like Burpsuite, you can identify this early on and save a ton of time by dodging a rabbit hole.

Note: This is NOT a write-up on Node. We will not be resolving the problem of enumerating Node using Gobuster, but instead will simply use Node as an example for this blog post.

Node lives at 10.10.10.58, and has a webserver listening on port 3000. Let’s start by browsing to that webpage to see what we get once we’re connected to the HackTheBox VPN.

http://10.10.10.58:3000

Anytime I see a webpage, I always like to start Gobuster to try and enumerate any directories that may be living under the hood. Let’s give that a shot.

gobuster dir -u http://10.10.10.58:3000 -w /usr/share/dirbuster/wordlists/directory-list-2.3-medium.txt

Very quickly we get a response back that states “Error: the server returns a status code that matches the provided options for non existing urls. http://10.10.10.58:3000/febbf4ec-069f-4b87-a671-a07ses, specify the ‘–wildcard’ switch

Specifying the --wildcard switch as it suggests in this case will just cause every page to report back with a 200 status code. Not very helpful.

gobuster dir -u http://10.10.10.58:3000 -w /usr/share/dirbuster/wordlists/directory-list-2.3-medium.txt --wildcard


Configuring Proxy in BurpSuite

Let’s spin up BurpSuite and navigate to the Proxy tab. Let’s then go into Options, and Add a new proxy listener.

In the Binding tab, enter a Port that you’d like to use. In this case, I’ll just use 8081.

Click on the Request Handling tab. Fill out as needed.

Redirect to host: Enter the host that you wish to send traffic to. I’ll be sending my traffic to 10.10.10.58
Redirect to port: Enter the port that the host is listening on. In my case, it will be 3000.
Force use of TLS: That is not necessary in my example, but it may be a requirement for you depending on your use-case.
Support Invisible Proxying: N/A

Click OK.

The add listener screen should close, and you should be taken to the Proxy Listeners table with a new entry shown. Make sure that your new listener is Running.


Testing the Proxy

Now, let’s open a browser and see what happens when we browse to localhost on the port we specified earlier.

http://localhost:8081

Great! We know our proxy is working and we’re able to route traffic through BurpSuite. Let’s do the same, but with Gobuster this time.

gobuster dir -u http://localhost:8081 -w /usr/share/dirbuster/wordlists/directory-list-2.3-medium.txt

We notice that we are still getting the same error message. Let’s see if we can analyze this traffic within BurpSuite and identify why. Let’s head back into Burp and select the Proxy tab. Turn Intercept On.

Let’s run the same Gobuster command again. You’ll notice the tool will spin up, but then appear to hang.

gobuster dir -u http://localhost:8081 -w /usr/share/dirbuster/wordlists/directory-list-2.3-medium.txt

Heading back to Burp, we have a chance to modify the request if we desire. I will go ahead and click Forward. You may need to click it a few times if multiple requests are being sent.

Gobuster still reports the same error as before, but now we have a chance to go into the HTTP History within Burp. From here, we can review the Response received from the webserver and have a chance to troubleshoot.

This proves that we are routing fully through Burp, and now have a chance to utilize some of its features while running our tools.


That’s it for this post! Again, the goal was to learn how to route tools through BurpSuite so that you can leverage all of its features. Let me know if this is at all helpful, or if there is more that you’d like me to add.