Cloud Spotlight: SSRF and IMDS
Last updated
Last updated
In this module, we'll explore how SSRF attacks can target cloud Instance Metadata Services (IMDS). While SSRF can affect any web app, it's especially important when used against cloud targets.
Web servers often take user input to make their own web requests. For example, if a user uploads an image link for a profile picture, the server will request the image. If an attacker changes the input to make the server send unwanted HTTP requests, it could lead to a Server-Side Request Forgery (SSRF) attack. This may allow attackers to access sensitive information, like cloud authentication tokens, through the Instance Metadata service.
In an SSRF attack, a web client sends a request to a server (e.g., asking for a page like /user with a profile image). The server processes the request and tells the web client where to find the image. The client then makes a second request to get the image from another server. This normal process can be exploited in SSRF attacks.
Sometimes, the server requests a resource for the web client. For example, if a user asks for a page with a profile image, the server fetches the image from another server and sends it back to the user, instead of giving the user a link to get the image themselves.
Web servers often handle requests like converting user content to PDF or transferring data between cloud platforms. If the server doesn't check the input properly, it can be vulnerable to attacks.
In this example, instead of just giving a file name (like "me.jpg"), the server request uses the full URL of the file. The server still works the same way: it fetches the image and sends it back to the client.
Then the attacker changes the URL parameter to file:///etc/shadow. The server then fetches the local /etc/shadow file, exposing sensitive information.
When an attacker can trick a server into making a request to another server, it's called a Server-Side Request Forgery (SSRF) attack. These vulnerabilities are common, even on well-known sites.
Let’s look at how an attacker could find and use an SSRF flaw by checking out the login page for Falsimentis Corporation. This page lets users switch login sources like Facebook, Twitter, and Microsoft (Live.com). When a user selects a different login option, the provider’s logo appears. The URL has two parts: f and logo.
The logo parameter's value shows a URL that uses a CDN to get the Twitter logo. If an attacker sees a URL in a parameter sent to a server, it might be an SSRF vulnerability that needs checking.
Changing the logo link from a Twitter URL to a local file reference (file://) requests the /etc/hosts file and shows a broken image on the login page. This could indicate an SSRF vulnerability, which can be checked with cURL.
We changed the logo link in the browser to a file:// URI, which broke the image. Using cURL, a tool by Daniel Stenberg, we made a similar request. The cURL output showed an SSRF vulnerability because the server exposed the /etc/hosts file.
Although SSRF doesn’t let attackers list files, they can request other important files like /etc/passwd and /var/log/auth.log to gather more information. Next, we'll see how this SSRF issue affects cloud assets.
When exploiting an SSRF vulnerability, attackers aim to access protected files to gain passwords or hashes. For Linux, they often target the /etc/shadow file. However, in cloud systems with minimal setups, this file may not be present. In the example, a modified cURL command attempts to access /etc/shadow, but the server responds with a zero-length content.
The attacker isn't sure if the zero-length response means the /etc/shadow file is protected or missing, but it's a hint to try other cloud-based attacks.
The Instance Metadata Service (IMDS) is a tool used by cloud providers to give developers information about their cloud environment. It helps developers see things like resource availability, network settings, and permissions so they can make better decisions on how their application should work.
The web app uses the URL http://169.254.169.254 to access the IMDS service on the virtual server. For instance, the admin might start a cloud instance with instructions or data, like CSV files, for the app.
IMDS helps configure cloud assets flexibly without changing the instance or VM. However, it might reveal sensitive info, like database connection details or passwords, if not handled carefully.
In this case, the base64 token is used to access a service. An attacker might exploit this by making a special HTTP request to get sensitive info from the IMDS service, which can be vulnerable to SSRF attacks.
AWS IMDSv1 can leak sensitive data due to an SSRF vulnerability. It can expose IAM access keys, secrets, and tokens if the instance provides this information.
In the example, we use a modified cURL command to get the cloud instance role name by changing the logo parameter to the IMDSv1 endpoint. The first request finds the role name, aws-elasticbeanstalk-ec2-role. Adding this role name to the second cURL request gets the security credentials (access key ID, secret key, and token). The ; echo part makes the output clearer.
The attacker can add the stolen credentials to their AWS keychain with AWS-CLI, then use them to access the server and any other privileges of the EBS instance.
Once the AWS CLI profile is set up, the attacker can test the credentials with commands like get-user (output adjusted for space).
IMDS credential disclosure is a problem with many cloud services like AWS, DigitalOcean, and Alibaba Cloud. Some providers, like AWS with IMDSv2, now require special authentication or headers to access this data.
In an SSRF attack, the attacker can't change request headers—only the URL. By needing a custom header to access the IMDS service, the cloud provider ensures that only legitimate requests can reach it, blocking SSRF attacks.
GCP VMs use a similar approach to Azure but with a different header (output is shortened for space).
AWS instances can use IMDSv2 for better security, but it's not on by default to stay compatible with older instances, leaving many vulnerable to data leaks.
In an SSRF attack, attackers usually care less about OS files, especially in cloud environments where files like /etc/shadow might not exist or be useful. Instead, they focus on finding application-specific files that could reveal sensitive information like database connection strings. They research the application framework, sometimes testing it in their own lab, to figure out where credentials might be stored before exploiting the vulnerable instance.
In cloud setups, everything often runs as root, so if a vulnerable process is running as root, attackers get those same root privileges. This makes file permissions useless for protecting sensitive files.
Credentials are often set as environment variables for security. However, attackers can still access them through the /proc file system or the /etc/environment file if exposed.
To protect against SSRF and IMDS attacks, first understand the inputs your application handles. For instance, user input can be more complex than just URL parameters. Look out for any system input that could make server-side requests. An example is the Lyft SSRF vulnerability, where a PDF generation feature and an XSS bug let an attacker access Lyft's credentials through SSRF and IMDSv1.
Use logging to spot misuse of systems, like checking web server logs for SSRF attacks or cloud provider logs for credential misuse. For example, in AWS SSRF attacks, temporary credentials might be exposed. Monitor AWS CloudWatch logs for signs of these credentials being used outside the cloud instance, which might indicate a breach. For AWS, enforce IMDSv2 to help protect against SSRF attacks, though it won't stop all types of attacks.
We studied Server-Side Request Forgery (SSRF) and Instance Metadata Service (IMDS) attacks. In these attacks, an attacker tricks a web server into making requests to local resources or cloud metadata by manipulating HTTP requests. If the attacker can control the URL the server requests, they might access local files or cloud credentials. They can exploit this by changing URLs to local file paths, like file:///etc/hosts, and retrieving sensitive data from the system.
If a cloud system is weak against an SSRF attack, it can also be vulnerable to another attack through IMDS. IMDS gives info about the cloud instance and is accessed via http://169.254.169.254. Some cloud providers like Azure and Google Cloud are protected from SSRF attacks on IMDS. AWS has IMDSv2 for better protection, but many still use the older IMDSv1, which is vulnerable. Other providers like Digital Ocean and Alibaba might also be at risk. To protect against these attacks, monitor logs for unusual activity, use IMDSv2 if possible, and limit web server privileges.
In this lab, we will evaluate the intern.falsimentis.com server, leveraging a Server-Side Request Forgery (SSRF) attack to gain access to Instance Metadata Service (IMDS) data.
Let's browse to the target site at intern.falsimentis.com and spend sometime exploring the target site.
Let's click the Apply link at the top of the site to go to the application form.
Next, we'll look into the published work sample input field for a potential SSRF vulnerability.
To keep exploring the vulnerability, we need to add a URL when we submit the form. Let's open a new terminal in Slingshot Linux, then go to the ~/labs/www directory, and list the files there.
Let's start a local web server using python3 to deliver the image file to the remote site.
We can use the Python http.server module to share the circuit board image online at the URL http://10.10.75.1/circuitboard.jpg using the Slingshot Linux IP address.
Let's complete the Falsimentis intern application form. For the Published Work Sample, we'll enter the URL http://10.10.75.1/circuitboard.jpg.
After we submit the form, the server will send a response like the one.
The response page shows the browser displaying a circuit board image, which suggests a potential SSRF vulnerability. To confirm, let's check the web server logs to see if intern.falsimentis.com accessed the image. Switch to the terminal where the Python web server is running and review the logs for details.
This output shows an HTTP GET request where the Falsimentis server asks the attacker for the "circuitboard.jpg" image from 172.30.0.24. The server responds with an HTTP 200 message. Since the server both requests and displays the image in the "Submission Accepted" page, it confirms the system is vulnerable to SSRF attacks.
Next, we'll assess the risk of the SSRF vulnerability to the Falsimentis server.
On the submission page, the server shows the circuit board image to confirm it loaded correctly. To exploit the SSRF vulnerability, let's find the URL of the Falsimentis server's response. We'll go back to the submission page in Firefox, right-click the circuit board image, and choose "Open Image in New Tab."
The server created a local copy of the circuit board image on intern.falsimentis.com as Fares.jpg.
We saw the server show the circuit board image on the submission page. We'll use the cURL command line tool. Let's open a terminal, type curl, and paste the URL.
In this example, cURL warns that the requested file is a binary (an image) and won't display it on the screen.
Next, we'll use the SSRF vulnerability to extract data from the server. We'll try to access the /etc/passwd file. Let's enter file:///etc/passwd.
The confirmation page might show either a working circuit board image or a broken one, as Firefox can be inconsistent with cached images. Let's go back to the terminal and run the previous cURL command again.
cURL shows the contents of /etc/passwd instead of giving a warning about binary data on the screen.
Attacker submits form with file:///etc/passwd as the URL to retrieve.
Server performs an HTTP GET request for file:///etc/passwd, saves as images/Drew.jpg.
Attacker requests images/Drew.jpg from the server; cURL displays file contents as ASCII.
Next, we'll use the SSRF vulnerability to try to access other resources, specifically the /etc/shadow file.
We'll see that the submission confirmation looks different, lacking the boxes and images. Let's go back to the terminal and run the previous cURL command again to check the result.
The empty cURL command shows that the SSRF attack failed because of permission issues. The web server can read the /etc/passwd file, but we can't access files needing root access. However, we can read files available to all users, like /etc/passwd, and files owned by the web server, including the web app's source code.
Let's repeat the SSRF attack to access the source code of the /var/www/html/index.html file, which contains the main content of the Falsimentis internal website.
Question: What is the embedded username and password in the web page application source?
Let's go back to the terminal and run cURL command again to check the result.
Answer: intern:geDgECURnQjuymuGKHoC
Many cloud systems have limited or no access to /etc/shadow files, but SSRF vulnerabilities offer a new attack path: accessing the Instance Metadata Service (IMDS). By reaching the virtual IMDS server at http://169.254.169.254, attackers can sometimes get cloud server details, including credentials used to launch the server.
Let's go back to Firefox, we'll enter anything in the name field, and change the work sample URL to request the IMDS server page at http://169.254.169.254.
Let's check the cURL command output.
Let's repeat the process by accessing the URL http://169.254.169.254/latest/meta-data/iam/info to get information about the AWS IAM configuration.
The IAM info request gives JSON output. We can add the --silent option to the cURL request to hide the progress indicator, then use jq to get a well-formatted, color-coded version of the output.
In this output, the InstanceProfileArn field shows the Amazon Resource Name for the cloud instance and the deployment role name.
With SSRF access to the IMDS server and knowing the deploy role name, we can request the IMDS endpoint at http://169.254.169.254/latest/meta-data/iam/security-credentials/falsimentis-deploy-role/.
We can see that we get the access key and secret access key.
Web server logs can help detect attacks like SSRF and IMDS. We can use Elastic Stack or grep to search for relevant keywords and find suspicious events.
The logs from intern.falsimentis.com are stored in /home/sec504/labs/ssrf/log. Let's go to that folder and use various attack-related keywords to find the relevant log entries. We'll review the logs to understand how IMDS and SSRF attacks are recorded.
First, let's display the contents of the error.log.
At the start of this log entry, there's a message saying the attempt to access /etc/shadow failed due to permission denial. This message relates to PHP web apps, showing the server logged the failed attempt
Next, let's use grep to look for some keywords in the access.log file.
Here’s the original request showing the real form submission with the remote URL for the circuit board image. Now, let's run the grep command again, but this time look for the keyword "file."
This command creates multiple log entries that show a "file" prefix instead of "http" or "https," suggesting a possible SSRF attack. The log also shows a 200 response code, meaning the request was successful, and a response size of 2663 bytes, indicating that the attacker received some data.
Finally, let's search the logs for the 169.254.169.254 keyword.
The log shows attempts to access the IMDS server, along with the URL, which will help us understand what information the attacker got in the SSRF/IMDS attack.
