Skip to content

Month: December 2019

Lab Write-up: Exploiting XXE to perform SSRF attacks

Published by Bobby Lin on December 17, 2019

In this post, you will see how an XML external entity attack can be exploited to perform a SSRF. The lab can be found in this link (https://portswigger.net/web-security/xxe/lab-exploiting-xxe-to-perform-ssrf).

In the lab description, it was mentioned that the app server is running on AWS’s EC2 instance. To retrieve metadata about the server, you will need to inject an external entity to call this url:
http://169.254.169.254/

The next thing to take note is to notice the XML payload is being posted to the server. Below is the screenshot:

If you try to change the Product ID value to a random string, you can see that the response is showing the random string back. This means that you can inject the metadata to Product ID to retrieve the information.

Notice when we change to product ID to ‘testing123’, the value will be reflected back.

You will need to inject the below external entity into the XML payload:

The response will return ‘latest’. But what the hell is that? It took me a while to figure out that this is a folder name.

You see now that the URL is ‘http://169.254.169.254/latest’, the value ‘metadata’ is returned.

Eventually, when you keep appending the folder name to the URL, you will see the AWS EC2 metadata.


Lab Write-up: SSRF with filter bypass via open redirection vulnerability

Published by Bobby Lin on December 15, 2019

This is a writeup on one of the SSRF labs by Portswigger.
https://portswigger.net/web-security/ssrf/lab-ssrf-filter-bypass-via-open-redirection

You can try to produce intentional errors by providing unicode values. This cause the stock check server to return some error message. From below screenshot, we can see that the url is actually:
http://localhost:80/product/stock/check?productId=1%26storeId=12

Another thing you can play around is to decode the payload and send the request. Notice the response is returning “Missing parameter”. This is because you need to encode the ‘&’ character. Probably there is some sort of blacklist filter. Let’s learn to double encode to bypass the filter.

Another observation we can make is to look at the source code. We can see there is an open redirect in the “Next product” function. So the keyword for redirection might be ‘path’?
https://acfe1fda1fa0f12e80181f3300d500a8.web-security-academy.net/product/nextProduct?currentProductId=4&path=/product?productId=5

First attempt, we try to see if the stock check url has any open redirect. It turns out that it just return the stock value without performing any redirection. You can try other keywords like view / url / path etc. and still it will not redirect. So this doesn’t work.

Second attempt, we take the url payload from ‘Next Product’:

/product/nextProduct?currentProductId=4&path=/product?productId=5

Replace the current path value with the admin url ‘http://192.168.0.12:8080/admin’. The below screenshot shows that the redirection is successfully and we can see some of the admin functions appearing.

Now, you can exploit the SSRF vulnerability by sending a delete request using the admin URL.

Usage of Double Encoding

Published by Bobby Lin on December 15, 2019

Double Encoding is an attack technique that can be used to bypass certain blacklisting-filter mechanism. Suppose an application is trying to blacklist the ‘#’ character in an user-provided URL. First, the web application have to decode the user-provided URL (in case the attacker tries to encode the ‘#’ character.

Below is a pseudo-code example of a blacklisting function:

function blacklist_filter(url):
decoded_url = url_decode(url)
if '#' is in decoded_url: 
throw error
else: return decoded_url

But it turns out that the attacker can perform the encoding twice in order to bypass the blacklisting filter.

First Encoding: '#'  -> %23
Second Encoding: %23 -> %2523
function blacklist_filter(url = 'www.example.com%2523'):
decoded_url = url_decode(url) // decoded_url equals to  www.example.com%23 
if '#' is in decoded_url: 
throw error
else: return decoded_url

To improve this blacklisting method, the application can try to search for both the ‘#’ character and the encoded value ‘%23’ before using the decoded_url. As a result, the blacklist of the ‘#’ character as well as its encoded form will be prevented from being used in the URL.

function improved_blacklist_filter(url = 'www.example.com%2523'):
decoded_url = url_decode(url) // decoded_url equals to  www.example.com%23 
if '#' or ' %23' is in decoded_url: 
throw error
else: return decoded_url

You can use this blogpost to as a tip for solving the Web Security Academy Lab:
https://portswigger.net/web-security/ssrf/lab-ssrf-with-whitelist-filter

Resources:

  • Chapter 1, Mastering Modern Web Penetration Testing
  • https://www.owasp.org/index.php/Double_Encoding
  • https://en.wikipedia.org/wiki/Double_encoding