For those diving deep into cybersecurity and penetration testing, understanding the complexities and nuances of different vulnerabilities is crucial. One such vulnerability that’s seen a rise in prominence due to the widespread adoption of microservices is the Server-Side Request Forgery (SSRF). Let’s dive into the specifics of SSRF and discuss how to protect against it.
What is SSRF Vulnerability?
Server-Side Request Forgery (SSRF) is a type of vulnerability that allows an attacker to force a server to perform requests on their behalf. This typically occurs when an attacker can control the URL which a web application will access, but without the ability to see the resulting response. Essentially, SSRF enables the attacker to target services that are internal to the server’s network, exploiting functionalities that can fetch URLs.
The Rise of Microservices and SSRF
Microservices architecture is an architectural style that structures an application as a collection of services that are highly maintainable, testable, loosely coupled, independently deployable, and precisely focused.
However, as organizations embrace microservices:
- Increased Inter-service Communication: With more services communicating with each other, the surface for SSRF attacks becomes broader. Each service-to-service communication is a potential target for an attacker.
- Network Policies are Overlooked: With the rapid adoption of microservices, often the underlying network policies governing the communication between these services are not properly configured or simply overlooked.
- Misconfigured Cloud Services: In a microservices environment, it’s common to use cloud-native services like AWS S3 buckets or Azure Blob Storage. These are prime targets for SSRF attacks, especially if not correctly configured.
How to discover SSRF Vulnerabilities in a Penetration test
Start by identifying functionalities within the application that interact with external services, such as image upload features, URL fetchers, or integrations with other web applications. Use a proxy tool like Burp Suite to manipulate the requests and point to different internal IPs or services. It is highly recommended to use Burp Suite’s Collaborator for testing whether or not a request has reached to an external site.
Monitor the responses to identify unexpected behavior or unintended exposure of internal services. It’s also beneficial to test with various URL schemas like file://, dict://, sftp://, and others to see if the application tries to fetch data from them. Automated scanners can aid in this discovery, but remember, a manual approach often uncovers nuances that automated tools might miss.
For example, consider the following HTTP Post request that, for the sake of this example grabs photos from some internal address.
POST /fetchPhoto HTTP/2
Host: victim.com
Cookie: session=v2_2371676cb303f91b9de00f08270ebfbd
Content-Length: 35
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/115.0.0.0 Safari/537.36
Content-Type: application/x-www-form-urlencoded
Accept: */*
address=/internal/photo.jpgThis first question that should come to your mind as a penetration tester is “what happens if I replace the value of ‘address’ with some internal or external address?‘ So you should probably start with a payload that can cause the web server to access a resource you can control. In the following example, I replaced the address with a Burp Collaborator address
POST /fetchPhoto HTTP/2
Host: victim.com
Cookie: session=v2_2371676cb303f91b9de00f08270ebfbd
Content-Length: 35
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/115.0.0.0 Safari/537.36
Content-Type: application/x-www-form-urlencoded
Accept: */*
address=https://9isu4d4a1pzbwdbeqa0031zbp2vtjk79.oastify.comIf you see an HTTP request reaching your site (or collaborator in this example), then the site might be vulnerable and if you’re lucky you might be able to quickly leak some secrets like an OAuth 2.0 Access Token.
If you suspect that a certain functionality does indeed reach out to external resources, but has some input validation that prevents you from reaching out to you domain, then you should attempt various URL Format Bypass attacks like described here.
Preventing SSRF Attacks
Protecting against SSRF attacks requires both understanding the vulnerability and taking steps to mitigate its risk. Here are some recommended methods:
- Whitelist URLs: If your application needs to fetch external URLs, ensure that you maintain a whitelist of approved URLs and deny any requests outside of this list.
- Block Private IPs: Configure your application to deny requests to private IP addresses or specific ports that might be used by back-end services. This will prevent an attacker from targeting internal network services.
- Upgrade Libraries and Dependencies: Ensure all your third-party software, libraries, and dependencies are up-to-date, as they might contain patches for known SSRF vulnerabilities such as this vulnerability in the famous request http client library.
- Use a Web Application Firewall (WAF): A WAF can help detect and block SSRF attacks by inspecting HTTP requests before they reach your application.
- Regular Security Audits: Regularly review and audit your infrastructure and applications for potential security holes. Automated tools can help, but consider also engaging penetration testers and bug bounty hunters for more thorough checks.
- Educate Development Teams: Often, vulnerabilities arise from a lack of understanding. Make sure your development team is aware of SSRF vulnerabilities, their implications, and how to write code securely.
In Conclusion
While the rise of microservices has certainly streamlined various aspects of application development and deployment, it has also brought forth new challenges in the realm of cybersecurity. SSRF is a glaring example of such challenges. However, with the right measures in place, businesses can harness the power of microservices without compromising their security posture.