While hacking on a private program, I was manually testing the main website and noticed that I wasn’t seeing all the available functions due to the limitations of my account level.
As usual, I logged in and navigated the website using Burp Suite. While reviewing the HTTP history, one request caught my eye. It was a GET request to the /accounts endpoint that returned the following data in the request’s response.
{“customerFeatures”:[1,2,3,4,5]….
Curious, I decided to modify these values to see if any changes would reflect in the user interface (UI).
I needed to identify the values the server was expecting without guessing and refreshing the UI repeatedly. During my exploration, I discovered that another request to the /flags endpoint provided the information I needed. The productFeatures below had the feature (id) and description of the feature. I navigated the application and noticed I didn’t have access to the SSO (Single Sign-On) product feature. This was id (88) on the response for the request to /flags.
”productFeatures”:[{“id”:88,”name”:”Single Sign On (SSO)”,”description”:”Allows SAML based authentication.”,”upgradeLabel”:”to Allow SSO login.”…
I went back to the request response that returned the customerFeatures and included this value:
{“customerFeatures”:[1,2,3,4,5,88]…
The browser accepted the change without additional validation, and an SSO configuration page appeared in the application’s settings. This feature allowed an administrator to retrieve metadata URL configurations, detailing information about the Identity Provider (IDP). Since this feature enabled third-party domains to be contacted, it seemed like a prime target for testing SSRF vulnerabilities.
(If you’re unfamiliar with SAML and the concepts of IDP and SP, check out this link.)
What is SSRF ?
According to PortSwigger:
“Server-side request forgery is a web security vulnerability that allows an attacker to cause the server-side application to make requests to an unintended location.”
In essence, SSRF allows attackers to make a web application reach out to internal resources, potentially bypassing external controls like firewalls and network security measures. Traffic between internal resources is often allowed, and defenders might overlook proper segmentation between applications.
Exploiting SSRF
Using the Chrome plugin Wappalyzer, I identified that the site was hosted on AWS. Wappalyzer is useful for identifying technologies running on web servers. I knew if I found a feature vulnerable to ssrf I would try a common technique to retrieve AWS metadata information.
I found the SSO configuration endpoint and saw I would be able to provide a URL to retrieve the SAML metadata file from my Identity Provider. I first used the burp collaborator link in the URL field to see if I received a callback to Burp. When I checked, I indeed saw the website reached out to Burp Collaborator. I inserted the AWS metadata URL and sent the request, intercepting it with Burp Suite.
Although the website UI reported an error, the response in Burp contained the following:
This response included various categories of data that could be queried for more information on AWS. To learn more about the data that can be retrieved, check out this link.
Next, I sent a request to http://169.254.169.254/latest/meta-data/iam/security-credentials/ to retrieve the role name.
After obtaining the role name, I sent another request to get the AWS credentials. The response included the following AWS AKIA EC2 Key.
Post-Exploitation and Submission
I performed further enumeration using Enumerate-IAM to explore additional exploit paths. Eventually, I submitted the report and received a $2,000 reward from the program.
Although I offered to provide further impact, the triager said it was unnecessary. If they had been interested, I would have used Pacu for AWS Identity enumeration. Pacu is a powerful tool that, when provided with an access key like the one above, can generate an impersonate link that allows you to log into the AWS account as that user. Depending on the authorization level, this could enable actions such as downloading entire AWS S3 Buckets. Learn more about pacu here at this link.
ASIA VS AKIA
AKIA: Access key IDs beginning with AKIA are long-term credentials for an IAM user or the AWS account root user.
ASIA: Access key IDs beginning with ASIA are temporary credentials created using AWS STS operations.
Remediation
This website was using Instance Metadata Service Version 1 (IMDSv1). This exploitation wouldn’t have been possible if the site had been using IMDSv2. Starting in mid-2024, newly released Amazon EC2 instance types will use IMDSv2 by default. For more information on this change and how it enhances AWS metadata protection, read this article.
When I see features in a web application that allow interaction with external URLS, I immediately suspect that the web application might not be handling URLs correctly and may allow for SSRF.
For a deeper dive into SSRF vulnerabilities, visit PortSwigger’s guide.
Thanks for checking out the article!