Server-side request forgery is an attack in which an attacker can force a vulnerable server to trigger malicious requests to third-party servers and or to internal resources. This vulnerability can then be leveraged to launch specific attacks such as a cross-site port attack, service enumeration, and various other attacks.
This ability makes server-side request forgery potentially dangerous because a vulnerable server can be leveraged as a proxy and can attack other public resources and local infrastructure.
Some common vulnerabilities related to server-side request forgery:
- URL redirection
- Remote file inclusion
- SQL injection
- Frame injection
- Link injection
- XML external entity
What can an attacker do using this vulnerability?
An attacker who has identified this vulnerability can leverage it for further attacks, including:
- Port-scan internal hosts on the intranet protected by the firewall.
- Attack internal applications.
- Access local web server files using the file handler “file:///c:/windows/system32/.”
- Enumerate services.
Attackers can use other options such as mailto://, gopher://, etc. But these depend on how the request is handled by the server and the parser.
Port scanning
Server-side request forgery can take advantage of port scanning.
Scanning local interface:
GET /Vulnerablepage.php? VulnParameter=http://127.0.0.1:80
GET /Vulnerablepage.php? VulnParameter=http://127.0.0.1:443
GET /Vulnerablepage.php? VulnParameter=http://127.0.0.1:21
Based upon the difference in responses, attackers can infer open and closed ports. Similarly, one can scan other resources.
This process can also be automated with Burp’s Intruder feature by setting the payload position as:
GET /Vulnerablepage.php?VulnParameter=http://127.0.0.1:§§ HTTP/1.1
Next set the “payload set” as “numbers,” “ports” from “0-65535,” and start the attack. Remember to uncheck payload encoding.
Testing server-side request forgery
Normally any input field that accepts a URL is an ideal candidate for this attack. However, we have seen that applications with random parameters from which nothing can be inferred were also vulnerable to this attack. Thus it is always a good practice to check for this vulnerability on suspicious parameters because we do not know how the parameters are handled by the server.
Creating a proof of concept
The following steps will help a penetration tester develop a proof of concept.
- Identity a potential input field in the application to test this vulnerability.
- Start Netcat on a server (with server name “servertest,” for example) with the following command
- (nc –l –v port no)
- Once the server is running, enter the following payload in the vulnerable input http://servertest:portno/testSSRF
- Use a unique directory such as /testSSRF to ensure that the request is triggered from our vulnerable server.
- If the server is vulnerable, it will establish the connection and the Netcat listener will display the details about the connection as shown in the following screen capture.
Tools
Burp’s collaborator feature comes in very handy when testing this vulnerability. It can help initially identify this issue, which can then be manually verified by the preceding technique.
The collaborator sends payloads to the affected application that are crafted to initiate connections with the collaborator server. Burp then continuously monitors the collaborator server to ensure if any request has initiated a connection.
Recommendations
- Do not trust user data, and perform data validation.
- Harden application servers, and ensure that unnecessary ports and services are not open and running.
- Implement a whitelist policy for allowed hosts and services.
References
https://portswigger.net/burp/help/collaborator.html
http://www.riyazwalikar.com/2012/11/cross-site-port-attacks-xspa-part-1.html
https://docs.google.com/document/d/1v1TkWZtrhzRLy0bYXBcdLUedXGb9njTNIJXa3u9akHM/edit#
The post Server-Side Request Forgery Takes Advantage of Vulnerable App Servers appeared first on McAfee.