We often think that a firewall restrictive enough protects the access to non-open services. We also believe that only a compromise machine can give access to the internal network. We are indeed wrong, and that’s what we are going to see with a web application vulnerability: The Server-Side Request Forgery, or SSRF.
What is an SSRF?
From a vulnerable web application, an SSRF makes possible to interact with the server, in order to extract files and to find its other active services. But there is more. It is also possible to scan the internal network to cartography IP and open ports.
But Where does the Breach Come From?
The general idea is the following: If a functionality allows to interact with external resources (for example, uploading a picture to the application or redirection towards a page), then the attacker may try to send a request to the server in a way that the researched resource is internal to the server (files, services, resources available only in localhost) or to its network.
Let’s look for example at the following functionality, which allows a user to change its profile picture:
We notice two things: on the one hand, the url parameter is not controlled before it is used in file_get_contents($url), and on the other, content is written (echo $content;) while a redirection occurs.
This functionality is therefore vulnerable to SSRF. Here are some possible exploitations:
- Access to an apache functionality of the server (unexposed):
http://vaadata.test/ssrf.php?url=http://localhost/server-status - Access to a web service of the server (unexposed):
http://vaadata.test/ssrf.php?url=http://localhost:8080 - Access to a file of the server (LFI: Local File Inclusion):
http://vaadata.test/ssrf.php?url=file:///etc/passwd - Access to a web server of the internal network:
http://vaadata.test/ssrf.php?url=http://10.0.0.15/ - Router interface router: http://vaadata.test/ssrf.php?url=http://10.0.0.1/
We can see here that the SSRF vulnerability gives potentially many possibilities for an attacker. In fact, here are only example applying to our test server, but many other exploitations could be done according to each case: XML External Entity (XXE), Cross-Site Scripting (XSS), command injection, etc.
In our above example, it is the function file_get_contents that opens the breach. However, other functions (here PHP) can also be the source of the breach. The most classics are:
- file_get_contents()
- fopen()
- fread()
- fsockopen()
- curl_exec()
This SSRF vulnerability is, of course, not confined to PHP, and the same principle can be found with each web technology.
Various Kinds of SSRF
We saw a particular type of SSRF, as the content of the loaded resource is returned by the server (echo $content;). For this reason, it is called Content-Based. This type of SSRF is potentially the most dangerous, as it permits to extract data quickly.
In other cases, only direct or indirect clues allow to deduce information about the server or the internal network:
- Boolean-Based: the answer of the server is different whether the resource exists or not
- Error-Based: an error, HTTP (404 or 500) for example, indicates whether the resource exists or not
- Time-Based: in cases the answer of the server remains the same whether the resource exists or not, the responding time can vary significantly.
With those three kinds of clues, and even if no data is extracted, it is still possible to map the existing resources on the server and in the internal network.
Remediation
Rules about resources to load are indispensable.
As for every vulnerability needing a control over parameters sent by the client, using a blacklist is NOT recommended, because there will always be a way to bypass this filter. Prefer a whitelist, i.e. authorising only explicit resources and refusing everything else. It will be needed then to define:
- Authorised DNS name and/or IP addresses
- Without localhost and 0.0.1, this will prevent the access to files/services of the server.
- Illegitimate access to the internal network will be prevented.
- Authorised protocols
- The use of file://, sftp://, will be then prevented.
In this following article, we show that it exists many ways to bypass filters by using URLs, and we present a tool to exploit more easily SSRF.
