Server-Side Request Forgery (SSRF) in Request Data module

[prernaadev01]

Impact

An attacker able to create policies can port scan and fetch web content from the application’s internal network and from services listening locally on the application server. It may be possible to exfiltrate sensitive information or exploit insecure services that are only exposed internally. The impact of this issue is heightened by the lack of authentication between the internal microservices (see finding "Missing Authentication between Microservices"). The exploitation of this issue was reduced as it would require a policy that allows to set arbitrary parameters, or a registry user in the system.

Description

The policies contain a server module, Request Data, that allows to perform an external query through HTTP, allowing to set the URL, method, body, and HTTP Headers of the request. This module could be abused by attackers to perform requests to internal servers, a risk that is heightened by the lack of authentication between microservices (see finding "Missing Authentication between Microservices") and by the fact that the source code is public and requests to internal services can be obtained from the source code.
In a Server Side Request Forgery (SSRF) attack, the attacker abuses functionality on the server to read or modify resources internal to the application’s network infrastructure. The attacker can supply or modify a URL which the code running on the server will fetch or submit data to. Depending on context surrounding the vulnerability, the attacker may be able to read server configuration data, access HTTP-enabled databases, port-scan the internal network, or even communicate with non-HTTP services.
If the application is hosted on AWS servers where AWS provides a metadata service that reveals IAM credentials for the server. A SSRF attack could be used to retrieve these credentials which could then be used to compromise the AWS environment.

Recommendation

If the functionality is important enough to keep despite the risk, then all URLs should be requested through a secure proxy server. This is a significant effort, and to be secure the proxy must ensure that:

1. The URL does not resolve to a private or local IP address 2. Redirects are not followed
2. Only HTTP(S) protocol schemes are supported
   Additionally, the application server should define and enforce rate limits to discourage abuse of the functionality as a web scanner.
   If the application is hosted on AWS servers, enforce usage of AWS “Instance Metadata Service Version 2” with token usage required. This is a new AWS metadata API which severely curtails the ability of attackers to abuse SSRF to access the AWS metadata API. However, this will not prevent attacks against other internal services.

Location

• Request Data Module