A Server-Side Request Forgery attack 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. Data leakage and authorization credentials exposure are among the possible results of an SSRF attack. 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. What`s at Risk If You Fall Victim to an SSRF attack? Authentication credentials - unfortunately, SSRFs can also be used to retrieve authentication credentials, such as passwords or API keys, and use them for further attacks. Depending on the server's response to the initial request, there are three types of SSRF attacks. Blind SSRF. 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. Semi-Blind SSRF. 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. Non-Blind SSRF. 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. 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. Wrapping Up. 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 attacks. 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. If you liked this article, follow us on LinkedIn, Twitter, Facebook, Youtube, and Instagram for more cybersecurity news and topics. If you liked this post, you will enjoy our newsletter. Get cybersecurity updates you'll actually want to read directly in your inbox.
This Cyber News was published on heimdalsecurity.com. Publication date: Thu, 02 Feb 2023 09:56:02 +0000