A server-side request forgery (SSRF) hole, a web application vulnerability that redirects an attacker’s requests to the internal network or localhost behind the firewall, could have an impact on organizations in the industrial, technology, and media sectors, researchers said.
SSRF poses a threat to cloud services due to the use of the metadata API that allows applications to access the underlying cloud infrastructure’s information such as configurations, logs, and credentials, said Jay Chen of Palo Alto Network’s Unit 42 in a post.
Although the metadata API can only be accessed locally, the SSRF vulnerability makes it accessible from the Internet. This type of vulnerability also bypasses the container sandbox protection. SSRF opens the door for internal network reconnaissance, lateral movement, and even remote code execution.
An application in a container, by default, can directly access the metadata API on its host, enabling a special way of container escape. To understand the severity of the problem, Unit 42 researchers took a closer look at the Jira SSRF vulnerability (CVE-2019-8451) and studied its impact on six public cloud service providers (CSPs).
Unit 42’s vulnerability scanner found:
• More than 7,000 Jira instances exposed to the Internet in public clouds
• 45 percent of the 7,000+ Jira instances (3,152) are vulnerable to this CVE (not patched or updated)
• 56 percent of the 3,152 vulnerable hosts (1,779) leak cloud infrastructure metadata
NVD shows this CVE was first introduced in v7.6, but Unit 42 discovered the issue affects versions back to v4.3 (March 2011) as opposed to v7.6 (Nov. 2017). The leaked metadata ranges from internal network configuration to source code and credentials.
SSRF is a web application vulnerability that redirects malicious requests to resources restricted to the server. Attackers circumvent the firewall by tricking the vulnerable application to forward the malicious request to arbitrary domains, including the internal network and localhost.
The most common type of SSRF request is HTTP(s), but other valid uniform resource identifier (URI) schemes such as host file system (file:////), dictionary service (dict://), and redis service (redis://) are all possible, Chen said in the post. Attackers can access any target that has a trust relationship with the vulnerable server as long as the application supports the URI scheme. They can reach the target and it does not require additional authentication.
SSRF vulnerability’s roots lie in the lack of proper input sanitization. To fix the issue, developers should strictly validate the format and pattern of the user input before passing it to the application logic.
For system administrators who only install and manage web applications, Unit 42 offered some suggested preventive protections include:
• Domain whitelisting: Most of the applications only need to initiate communications with a handful of domains such as database or API gateways. Enforcing a whitelist of domains that an application is allowed to communicate with can significantly reduce the services that attackers can target.
• Zero-trust network: An application should never trust another application just because they are in the same internal network. SSRF will fail if the targeted services require authentication. Authentication and authorization should be implemented on every application.
• Web Application Firewall (WAF): WAF can detect abnormal patterns or malicious content in Http requests. However, WAF depends on the rules created for known vulnerabilities or attacks with obvious patterns, e.g., SQL injection or XSS. A Zero Day vulnerability may still bypass the WAF.
• Patch and update: Patching and updating applications frequently are the easiest and most effective ways to prevent any vulnerability. It is, however, limited to the support from the vendors. An end-of-life application may never receive an update.
Cloud users should take preventive actions to reduce the risk of metadata leak by:
• Enabling CSP metadata API protection: Some CSPs provide configurable options to secure metadata API. GCP users can disable the legacy metadata API versions and enforces the Http header requirement. DigitalOcean users can disable the metadata API service at the cloud-config script.
• Blocking metadata IP: Firewall rules can be created inside VMs to block the IP of the metadata API completely. A more granular firewall rule can also be created to allow only specific applications or users to access the metadata API.
• Metadata proxy: Open-source tools such as metadataproxy and aws-metadata-proxy create a layer above the native metadata API and offer granular control to applications that need to access the metadata.
• Least privilege IAM: IAM role is attached to a VM to allow applications on the VM to access other cloud services. It is critical to restrict the IAM privileges to only the services that the applications need. The least-privilege practice minimizes the impact in case a credential is compromised.
SSRF by itself may not be a severe vulnerability, but when coupled with the metadata API and misconfiguration in cloud infrastructure, SSRF opens the door to other attack vectors.
Sensitive metadata such as credentials and network architecture may be leaked, and internal services such as database and storage could be exposed. In the worst case, the entire cloud infrastructure could be compromised.
Unit 42’s research used only the Jira vulnerability CVE-2019-8451 as an example to show the impact of SSRF to cloud infrastructure, but there are hundreds of other applications with known SSRF vulnerabilities that can all be exploited in the cloud.