About
New category named Server-Side Request Forgery or SSFR.
Description
OWASP SSRF when abbreviated, it is a variety of cyber-attack wherein the skilled hacker takes the advantage of the pre-existed vulnerability, present on a server, and uses it against the server. Depending upon the intent of the hacker, an attacker uses SSRF to temper mission-critical server data (stored or passing by) by inserting a corrupted code/link.
SSRF flaws occur whenever a web application is fetching a remote resource without validating the user-supplied URL. It allows an attacker to coerce the application to send a crafted request to an unexpected destination, even when protected by a firewall, VPN, or another type of network access control list (ACL).
As modern web applications provide end-users with convenient features, fetching a URL becomes a common scenario. As a result, the incidence of SSRF is increasing. Also, the severity of SSRF is becoming higher due to cloud services and the complexity of architectures.
Reference here.
Potential impact
If ignored for a long time, the SSRF attack can cause hassles beyond once it and expectations. The key impacts are as follows:
Attackers can use a compromised server as an IP scanner or port to gather the information from front and back-end systems
If internal protocols like Gopher are enabled on targeted servers then hackers can easily make a path for further reconnaissance possibilities
A successful SSRF cyber-attack permits threat actors to find out the hidden IP addresses that are running at the back of reverse proxy
By creating a possibility for XCE, SSRF creates a base for multiple cyber troubles as malware, viruses, ransomware, and other sorts of ill-intended components can be introduced.
Reference here.
Prevention
From Network layer
Segment remote resource access functionality in separate networks to reduce the impact of SSRF
Enforce “deny by default” firewall policies or network access control rules to block all but essential intranet traffic. Hints: ~ Establish an ownership and a lifecycle for firewall rules based on applications. ~ Log all accepted and blocked network flows on firewalls (see A09:2021-Security Logging and Monitoring Failures).
From Application layer:
Sanitize and validate all client-supplied input data
Enforce the URL schema, port, and destination with a positive allow list
Do not send raw responses to clients
Disable HTTP redirections
Be aware of the URL consistency to avoid attacks such as DNS rebinding and “time of check, time of use” (TOCTOU) race conditions
Do not mitigate SSRF via the use of a deny list or regular expression. Attackers have payload lists, tools, and skills to bypass deny lists.
Reference here.
Common examples
Example #1: Port scan internal servers
If the network architecture is unsegmented, attackers can map internal networks and determine whether ports on internal servers are open or closed based on connection results or elapsed time to connect or deny SSRF payload connections
Example #2: Sensitive data exposure
Attackers can access local files or internal services to obtain sensitive information, such as file:///etc/passwd</span> and http://localhost:28017/.
Example 3: Access metadata storage of cloud services
Most cloud providers have a metadata store, such as http://169. 254. 169. 254/. An attacker can read the metadata to obtain sensitive information.
Example 4: Compromise internal services
An attacker can abuse internal services to carry out further attacks such as remote code execution (RCE) or denial of service (DoS).
Reference here.
Cases
In 2019, CapitalOne fell victim to an SSRF attack. It remains one of the most well-known successful SSRF attacks today and it led to the leaking of over 100 million customer records. The attack was successful because of a mix of poor security practices and the presence of bugs within its infrastructure.
The CapitalOne site was hosted on Amazon’s AWS platform in which an SSRF vulnerability was present. The vulnerability allowed the attacker to obtain AWS credentials by using the application server itself, as AWS enables the application to obtain its own metadata. Once the attacker had secured the credentials, they could funnel the stolen data using AWS management tools, such as the command-line interface (CLI) and E3 storage.
A notable point about this attack is that the web application firewall (WAF) failed to identify and block the attack. We don’t know whether the attacker used a WAF bypass or if it was turned off. Couple that with the fact that the access credentials were too permissive, and you had the perfect conditions for a successful SSRF attack.
Reference here.
____________________________________________________________________________________________
References:
Last updated