A Server-Side Request Forgery attack (SSRF) is a security vulnerability in which a hacker tricks a server into accessing unintended resources on his behalf.
An SSRF attack can lead to sensitive information being leaked or the attacker gaining control of other systems. If they succeed to make the server establish connections to random external systems, threat actors will be able to read or update internal resources.
The attackers may then be able to read server configuration information like AWS metadata, connect to internal services like HTTP-enabled databases, or send post requests to internal services that are should not be exposed.
The HTTP protocol is not the only support for SSRF. The first request is usually made using HTTP, but if it is the app that makes the second request, then other protocols: FTP, SMB, SMTP, etc., and schemes: file:/, phar:/, gopher:/, data:/, dict:/, etc. might be used too.
How Does a Server-Side Request Forgery Attack Work?
During a server-side request forgery attack, the server is tricked into making HTTP requests to internal resources or other servers on behalf of the attacker.
This is done by crafting a custom-made URL that the server will access and then return the result to the attacker. In the process, it exposes sensitive information or allows the hacker to access the resources. Simply put, the server’s trust in the client’s request enables the threat actor to bypass security measures and access protected resources.
How does a Server-Side Request Forgery attack work
What`s at Risk If You Fall Victim to an SSRF attack?
Internal network resources – by performing a server-side request forgery attack, threat actors may gain access to internal network resources such as databases and private IP addresses.
Remote systems – if they succeed in gaining access to other servers, which is possible through an SSRF attack, hackers will also be able to launch further attacks.
Local files – the attacker could use this kind of attack to access sensitive files stored on the server, such as configuration files or sensitive user data.
Third-party services – third-party services can also be accessed, such as APIs.
Authentication credentials – unfortunately, SSRFs can also be used to retrieve authentication credentials, such as passwords or API keys, and use them for further attacks.
DoS attack on the network’s internal servers – By using SSRF threat actors could flood the internal servers with traffic and crash the internal servers.
Server-Side Request Forgery Attack Types:
Depending on the server’s response to the initial request, there are three types of SSRF attacks.
In this instance, the original request returns no information about the target service. The adversary will give a URL, but he will not receive any data from it. He will have to use a vulnerability detection tool to check if the server is vulnerable. This can be achieved by determining it to make DNS or HTTP queries to a server he already controls.
Unlike the blind SSRF, the semi-blind instance does return some information, so the adversary gains access to some data, but not the entire lot. An error message and metadata about a request, like response times, are some examples. While this kind of result is enough to validate the vulnerability it doesn`t expose any sensitive data.
The most harmful of all is usually the non-blind SSRF, as data from an arbitrary URL can be exfiltrated and sent to the threat actors who made the query. The non-blind SSRF enables hackers access to information that will help them launch other attacks.
Use URL encoding to properly encode and decode user inputs, reducing the risk of malicious URLs being processed by the server.
Segment internal networks from external networks. Use a separate network segment, with restricted access, for the server so it stays isolated from sensitive internal resources. Hackers will have a harder job trying to access internal systems by launching an SSRF attack.
Regularly perform security assessments to identify and remediate vulnerabilities, including SSRF vulnerabilities.
Make sure all software is updated, including servers, so that any known vulnerabilities are patched in time.
Educate employees on the SSRF attack risks and ways of avoiding them.
Antivirus is no longer enough to keep an organization’s systems secure.
Heimdal® DNS Security Solution
Is our next gen proactive DNS-Layer security that stops unknown
threats before they reach your endpoints.
Machine learning powered scans for all incoming online traffic;
Stops data breaches before sensitive info can be exposed to the outside;
Advanced DNS, HTTP and HTTPS filtering for all your endpoints;
Protection against data leakage, APTs, ransomware and exploits;
Practicing prevention is always wiser, and more convenient, than waiting for the threat actors to make the first move. By developing and implementing our innovatory Heimdal solutions we help organizations protect their servers and networks against SSRF attacks and other harmful actions.
With 96% accuracy in predicting future threats, our solution enables you to spot any malicious URLs that could mess up your system.
The DarkLayer Guard 2-way traffic filtering engine included in Heimdal`s Threat Prevention – Endpoint solution offers professional white/blacklisting, which is one of the largely recommended security measures against SSRF attacks.
DarkLayer Guard helps your team block unwanted network communication to reduce Zero Hour exploits, Ransomware C&C’s, next-gen attacks, and data leakages.
By using the intelligence that it gains when blocking threats at the DNS, HTTP, and HTTPS level, DarkLayer Guard empowers you to stop active attacks and also speed up the forensic process. It tracks down and helps reinforce against potential threats any vulnerable endpoints your organization may have.
Although this kind of attack is not as common as others, SSRF vulnerabilities remain a risk factor even for experienced brands.
Not later than last year, cyber researchers discovered four of Microsoft Azure`s Services were vulnerable to full server-side request forgery (SSRF) attacks.
Fortunately, in that instance, the security issues were patched in a timely manner, but obviously it is not always the case. Prevention remains the smartest aproach in tackling DNS server and network security.
Livia Gyongyoși is a Communications and PR Officer within Heimdal®, passionate about cybersecurity. Always interested in being up to date with the latest news regarding this domain, Livia's goal is to keep others informed about best practices and solutions that help avoid cyberattacks.