Exploiting SSRF
And how I got your company secrets.
Now that we got the basics of SSRFs down, let’s learn to exploit them! If you aren’t familiar with SSRFs or need a refresher, here’s the first part of the series about SSRF.
So what exactly can a hacker do with an SSRF vulnerability? Well, that usually depends on the internal services found on the network. Today, we’ll talk about a few common ways to exploit the vulnerability once you’ve found one. Let’s dive right in!
I found an SSRF! What now?
SSRF vulnerabilities can be used to:
- Scan the network for hosts,
- Port scan internal machines and fingerprint internal services,
- collect instance metadata,
- bypass access controls,
- leak confidential data,
- and even execute code on reachable machines.
Network Scanning
First, SSRFs can be used to scan the network for other reachable machines. This is done by feeding the vulnerable endpoint with a range of internal IP addresses and see if the server responds differently for each address. Using the differences in server behavior, we can gather info about the network structure.
For example, when you request:
https://public.example.com/upload_profile_from_url.php?url=10.0.0.1
The server responds with:
Error: cannot upload image: http-server-header: Apache/2.2.8 (Ubuntu) DAV/2
And when you request:
https://public.example.com/upload_profile_from_url.php?url=10.0.0.2
The server responds with:
Error: cannot upload image: Connection Failed
We can deduce that 10.0.0.1 is the address of a valid host on the network, while 10.0.0.2 is not.
Port Scanning and Service Fingerprinting
SSRF can also be used to port scan network machines and reveal services running on these machines. Open ports provide a pretty good indicator of services running on the machine, as services have default ports that they run on, and port scan results point you to ports to inspect manually. This will help you plan further attacks tailored to the services found.
Provide the vulnerable endpoint with different ports of identified internal machines and determine if there is a difference in server behavior between ports. It’s the same process as scanning for hosts, except this time, you’re switching out port numbers. (Port numbers range from 0 to 65535.)
For example, when you send a request to port 80 on an internal server (eg. 10.0.0.1:80), the server responds with:
Error: cannot upload image: http-server-header: Apache/2.2.8 (Ubuntu) DAV/2
And when you send a request to port 11 on the same server (eg. 10.0.0.1:11), the server responds with this:
Error: cannot upload image: Connection Failed
We can deduce that port 80 is open on the server, while port 11 is not.
Pulling Instance Metadata
Amazon Elastic Compute Cloud (Amazon EC2) is a service that allows businesses to run applications in the public cloud. It has a service called ”Instance Metadata”. This enables EC2 instances to access an API that returns data about the instance itself (on the address 169.254.169.254). An instance metadata API service similar to that of EC2’s is also available on Google Cloud. These API endpoints are accessible by default unless they are specifically blocked or disabled by network admins. The information these services reveal is often extremely sensitive and could potentially allow attackers to escalate SSRFs to serious info leaks and RCE (Remote Code Execution).
Querying AWS EC2 Metadata
If a company is hosting its infrastructure on Amazon EC2, you can query various instance metadata about the host using the endpoints at
http://169.254.169.254/latest/meta-data/
These endpoints reveal information such as API keys, AWS S3 tokens, and passwords. Here is the complete documentation from Amazon.
Here are a few especially useful ones to go after first:
- <http://169.254.169.254/latest/meta-data/> returns the list of available metadata that you can query.
- <http://169.254.169.254/latest/meta-data/local-hostname/> returns the internal hostname used by the host.
- <http://169.254.169.254/latest/meta-data/iam/security-credentials/ROLE_NAME> returns the security credentials of that role.
- <http://169.254.169.254/latest/dynamic/instance-identity/document> reveals the private IP address of the current instance.
- <http://169.254.169.254/latest/user-data/> returns user data on the current instance.
Querying Google Cloud Metadata
If the company uses Google Cloud, you could try to query Google Instance Metadata API instead.
Google implements some additional security measures for their API endpoints — Querying Google Cloud Metadata APIv1 requires special headers:
"Metadata-Flavor: Google" or "X-Google-Metadata-Request: True"
But this protection can be easily bypassed because most endpoints accessible through APIv1 can be accessed via the API v1beta1 endpoints instead. And API v1beta1 does not have the same header requirements. Here’s the full documentation of the API from Google.
Here are a few critical pieces of information to go after first:
- <http://metadata.google.internal/computeMetadata/v1beta1/instance/service-accounts/default/token> returns the access token of the default account on the instance.
- <http://metadata.google.internal/computeMetadata/v1beta1/project/attributes/ssh-key> returns public SSH keys that can connect to other instances in this project.
Amazon and Google aren’t the only web services that provide metadata APIs. However, these two have quite a large market share so chances are the company that you are testing is on one of these platforms. If not, here’s a list of other cloud metadata services and things you can try.
Using What You’ve Got
Now using what you’ve found by scanning the network, identifying services and pulling instance metadata, you can try to pull these off:
Bypass access controls:
Some internal services might only control access based on IP addresses or internal headers. It might be possible to bypass access controls to sensitive functionalities just by sending the request from a trusted machine.
Leak confidential information:
If you’re able to find credentials using the SSRF, you can then use those credentials to access confidential information stored on the network. For example, if you were able to find AWS S3 keys, go through the company’s private S3 buckets and see if you have access to those.
Execute code:
You can use the info you gathered to turn SSRF into RCE. For example, if you found admin credentials that give you write privileges, try uploading a shell. Or if you found an unsecured admin panel, are there any features that allow the execution of scripts? Better yet, maybe you can log in as root?
Blind SSRFs
Blind SSRFs are SSRFs where you don’t get a response or error message back from the target server.
The exploitation of blind SSRFs is often limited to network mapping, port scanning, and service discovery. Since you can’t extract information directly from the target server, exploitation of blind SSRFs relies heavily on deduction. Utilizing HTTP status codes and server response times, we can achieve similar results as regular SSRF.
Network and Port Scanning using HTTP status codes
For example, when you feed the following request results in an HTTP status code of 200 (Status code for “OK”).
https://public.example.com/webhook?url=10.0.0.1
While the following request results in an HTTP status code of 500 (Status code for “Internal Server Error”).
https://public.example.com/webhook?url=10.0.0.2
We can deduce that 10.0.0.1 is the address of a valid host on the network, while 10.0.0.2 is not.
Port scanning with blind SSRF works the same way. If the server returns a 200 status code for some ports and 500 for others, the ports that yield a 200 status code might be the open ports on the machine.
Network and Port Scanning using Server response times
If the server is not returning any useful information in the form of status codes, all is not lost. You might still be able to figure out the network structure by examining how long the server is taking to respond to your request.
If the server is taking much longer to respond for some addresses, it might indicate that those network addresses are unrouted, or are hidden behind a firewall. On the other hand, unusually short response times may also indicate unrouted address, if the request is dropped by the router immediately. If the server is taking much longer to respond for some ports, it might indicate that those ports are closed.
Check out this graph published by @jobert on the Hackerone Blog. It provides a good overview of how a network would behave.
When performing any kind of network or port scanning, it is important to remember that vulnerable machines behave differently, and the key is to look for differences in behavior instead of the specific signatures described above.
Leaking Info to External Servers
The target machine might also leak sensitive information in outbound requests, such as internal IPs, headers, and version numbers of the software used. Try to provide the vulnerable endpoint with the address of a server you own and see what you can extract from the incoming request!
Conclusion
SSRF is a vulnerability that is full of potential. Here’s a link to the SSRF Bible. It discusses many more methods of exploiting SSRFs. In future posts, we will discuss real-life examples of how master hackers have utilized SSRF to own company networks!
Happy Hacking!
Next time, we’ll talk about how to bypass common SSRF protection mechanisms used by companies.