SSRF — Exploitation 02
Successful Cyberattacks often start at the “Network Perimeter”.
Now that we have covered the basics of SSRFs, let’s learn to exploit them! If you aren’t fimiliar with SSRFs or need to refresh, here’s the first part of the series about SSRF.
Hello, This is Anmol. This article is about different techniques to exploit SSRF. I hope after reading this article you all can understand and able to manipulate and exploit many service for the SSRF vulnerability.
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 fingerprinting internal services;
- Accessing Confidential information(like: important API Keys)
- Pulling Instance Metadata
- Bypass Access Controls
- Accessing Root Access (RCE on the webservers)
Network Scanning
First, SSRFs can be used to scan the network for other reachable machines. This is done be feeding the vulnerable endpoints with a range of Internal IP Addresses and see if the server responds differently for each address.Using the difference 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 the valid host on the network, while 10.0.0.2 is not.
Port Scanning and Service Fingerprinting
SSRFs can also be used to port scan a network machines and reveal services runing on these machines. Open ports provide a pretty good indicator of services running on the machines, as service have default ports that they run on, and port scan leads you to ports to inspect manually for any type of hidden service. This helps you to plan for the further attacks on the services.
For example, When you send a request to port 80 on an internal service (like 10.0.0.1:80), and if 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, 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
This is my personally favourite. Amazon Elastic Compute Cloud (Amazon EC2) is a service that allows businessman to run application in the public. 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 can reveal sis often extremely sensitive and could potentially allows an attacker to escalate SSRFs to serious info leaks and even can enables an attacker to manipulate the service and get an RCE (Remote Code Execution).
Querying AWS EC2 Metadata
These endpoints reveal information such as API Keys, AWS S3 tokens, and passwords.
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 becausee most endpoints accesible through APIv1 can be accessed via the APIv1 beta1 endpoints instead. And APIv1 beta1 does not have the same header requirements.
Here’s some critical pieces of the information to go after first:
http://metadata.google.internal/compute#Metadata/v1beta1/instance/service-accounts/default/tokens : returns the access token of the 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. Here’s a list of other cloud metadata services and things you can try.
Using What We’ve Got
Now using what you’ve found by scanning the network, identifying services and pulling instance metadatas, you can now try pull these of:
Bypass Access Control
Some internl services might only control access based on IP addresses or internal headers. It might be possible to bypass access controls of the 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 are able to find AWS S3 keys, go through the company’s private S3 buckets and see if you have access to those.
Execute Code (RCE)
You can use the info gathered to turn SSRF into RCE. For example, if you found admin credentials that give to write privileges, try upload a shell then listen and try to gain a reverse shell, Or if you have found an unsecured admin panel then try to find that are there any features and enables you to execute scripts? Better yet, maybe you can log in as root/administrator?
Blind SSRFs
Blind SSRFs are SSRFs where you don’t get a response or error back from the target server.
The Exploitation of blind is often limited to network mapping, port scanning and service discovery. Since you can’t extract information directly from the server, exploitation of blind SSRFs relies heavily on deduction. Utilizing HTTP status code 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 in an HTTP status code of 200 (Status code for “OK”)
https://subdomain.example.com/webhook?url=10.0.0.1
While the following request result in an HTTP status code of 500 (Status code for “Internal Server Error”)
https://subdomain.example.com/webhook?url=10.0.0.2
We can deduce that 10.0.0.1 is the address pf a valid host on the network, while 10.0.0.2 is not.
Port scanning with the blind ssrf work the same way.
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 an the key is to look for differences in behavior instead of the specific signatures describe above.
To Study more about Blind SSRF and their exploitation, Go Here.
Thanks for reading this article. Hope now that you have learned the basics of exploiting the SSRF Vulnerability.
HAPPY HACKING!
Until then;
WAKE EAT HACK REPEAT 🔥
From Infosec Writeups: A lot is coming up in the Infosec every day that it’s hard to keep up with. Join our weekly newsletter to get all the latest Infosec trends in the form of 5 articles, 4 Threads, 3 videos, 2 Github Repos and tools, and 1 job alert for FREE!
