Server Side Request Forgery Vulnerability (SSRF), occurs when an external threat ( A Hacker, Pentester, or Bug Hunter), is able to trick the server side of an organization, to make request into internal resources and perform prohibited actions.
Usually, these internal resources, are prohibited from public access, and should only be accessible to authorized administrators who have successfully logged in to the administrative side (Dashboard) of the organization web application.
LET’S EXPLAIN THIS:
Internal organizations resources are considered accessible only via local access (internally). For example, “database (phpMyAdmin)” trying to access this publicly from the web-browser via the public internet would be forbidden and of course trigger a message that resources can’t be accessed from the web-browser (except you are logged into the webserver, which is then considered a local access, when or if these resources are requested from the webserver itself i.e. admin panel of the webserver).
However, the database is required by the website (which sits on the public internet), to perform actions such as verifying and login authorized users to the website or retrieving requested data from the database. In other to achieve such, a communication between the web-application and internal server, is required.
So How Does The Communication Between The Public Web Application and Internal Server Works?
The firewall is configured to understand the web application IP address (web-application IP address is whit[e]listed), and when a user sends a request such as search or tries to get information about a product, the web application communicates to the database.
Since the firewall is configured to accept communication from the website’s IP address, the requested information is then redirected to the internal resources in this case the database which sits locally (127.0.0.1 or any internal IP address), and the request made such as searched terms, or verifying user’s login credentials is then successfully retrieved or performed.
HOW IS SERVER SIDE REQUEST FORGERY (SSRF) HACKED OR EXPLOITED?
Configuration errors such as improper filter implementation by the websecurity-administrator, could result in these internal resources exploited by an unauthorized persons and of course perform CRUD operations such as DELETING records, or retrieving resources from the organizations database.
With tools like Burpsuite, a threat actor can intercept a request, and understand how the request is being made. If the request points to or redirects to an organization internal resources to retrieve requested information, the threat actor could then further try actions such as repeating the request with additional path provided like “admin” to access the admin dashboard using the burpsuite tool or the “file:///etc/passwd” payload to retrieve password information in the database.
If such actions are successful, the threat actor is said to have performed a successful SSRF vulnerability attack.
There are numerous forms by which SSRF vulnerabilities attack are exploited. A few of them are:
- SSRF attack on the server.
- Against other backend systems (Internal Servers).
- SSRF based on blackl[i]st inputs (by using alternative IP representation) etc.
While SSRF is briefly explained, it is complex than this article portrays. Also, SSRF attacks are dependent on the type of service the targeted organization offers.
Performing DDOS Attack Using SSRF:
When an organization provides services similar to that of a social network site, such as the sharing of links or blog post as article, e.g. “LinkedIn, or X that allows the sharing of articles”, if the social network site which offers these services is vulnerable to Server Side Request Forgery (SSRF), a threat actor could use the social network site to redirect traffic to another victim server.
How is This Done?
Due to the social network site being vulnerable to SSRF, the vulnerable social network site will make a series of API calls requesting these blogpost links shared and redirecting the responses to the victim server provided by the threat actor (Malicious Hacker), during the time the request was made.
These traffic request made on behalf of the victim by the attacker, through the social network site vulnerable to SSRF, then overwhelms the victim server with these traffic response (API calls made to the various blog links shared), which then results into a DDOS (Distributed Denial of Service) attack on the victim server.
HOW TO PREVENT SSRF ATTACK:
There are numerous ways to prevent SSRF attacks depending on the nature or type of SSRF attacks being explained. However, based on this article two suggestive mitigation for SSRF attacks includes:
Validating requests from URLS:
- By ensuring that all requests made contained valid URLs, and not IP request. If a tool such as Burpsuite is used to repeat a request, and these request are observed to contain IP addresses in them e.g. 127.0.0.1, 192.168.x.x , such request should be denied.
- All requests coming from the public internet should be upgraded from a less secure communication (http) to a more secure communication (https), with valid certificates.
Although these can serve as mitigative steps, it is also important to note that DNS records pointing to localhost or internal IP addresses can be setup by an advance threat actor, which is why it is very important not to rely solely on validating URL request.
Response to Outgoing HTTP calls:
Ensure all responses to request coming into the organization internal resources (server), are coming from authenticated user with rights to do so. If an authenticated user is not an administrator, they shouldn’t be able to append the “/admin” payload to access the admin dashboard, even thou they are authenticated.
If the user making this request is also not an authenticated user, they shouldn’t be able to use the “/admin” payload to access the admin dashboard.
So, for example if a threat actor tries to search resources, and then intercepts these request using burpsuite, as long as they are not authenticated as user or an administrator, whatever modifications, or payload they inject irrespective of even encoding such payloads and replaying this request to the server, the request should be rejected.
NOTE:
We used administrator here, as we do limit all internal request to administrator. If we don’t, the threat actor could establish an account as a normal user, login into the account, and from there launch all forms of SSRF attack, on the webserver.
Creating a Blocklist of Domains For the Social Network site kind of services:
A list containing the organizations domains that should not make a request to organization’s internal resources should be maintained. When the threat actor tries to use these domains to launch SSRF attacks, the request should be blocked. This should be implemented in the server configuration files or Database.
While the Topic SSRF, can be a broad subject matter, we believe with this article, you have come to have a quick summary of what SSRF attacks are, or all about. Thanks for the read.
Put your comments below in the comment section on your thoughts about this.
Find this article and information helpful? Show some love and support “Click-Here”
