Server-Side Request Forgery in Cloud

With the increasing adoption of cloud computing services, the security of cloud environments has become a significant concern. One of the most common and dangerous vulnerabilities that can be exploited in cloud environments is Server-Side Request Forgery (SSRF). 

In this blog, we will discuss the basics of SSRF. We will also discuss how it can be exploited in cloud environments, its impacts, and remediation techniques.

What is SSRF?

Server-Side Request Forgery (SSRF) is a type of vulnerability that allows an attacker to send requests from a vulnerable web application. 

An SSRF attack occurs when an attacker can control the destination of a request sent by a vulnerable application. 

In other words, the attacker can manipulate the request. It could be in a way that it can help to communicate with internal or external systems. These systems are not intended to be accessed by the application.

Exploiting SSRF in Cloud Environments

Server-Side Request Forgery attacks in cloud environments can be even more dangerous as the attacker can access the sensitive data and resources of the entire cloud infrastructure. Cloud environments usually involve multiple instances and servers running different services and applications. An attacker with an SSRF vulnerability can access them all. 

For example, an attacker can exploit an SSRF vulnerability in a cloud-based web application that sends requests to a backend server. 

The attacker can manipulate the request and redirect it to the internal IP address of a database server or a cloud storage bucket not intended to be accessed by the application. 

This can result in data theft, corruption, or even complete control of the cloud infrastructure.

Pulling Instance Metadata

Amazon Elastic Compute Cloud is a service that allows businesses to run applications in the public cloud. It has a service called Instance Metadata. 

This enables EC2 instances to access an API that returns data about the instance itself (on the address 169.254.169.254). 

An instance metadata API service similar to that of EC2 is also available on Google Cloud. These API endpoints are accessible by default unless they are specifically blocked or disabled by network admins. 

The information these services reveal is often extremely sensitive and could potentially allow attackers to escalate SSRFs to serious info leaks and RCE (Remote Code Execution).

Querying AWS EC2 Metadata

If a company is hosting its infrastructure on Amazon EC2, you can query various instance metadata about the host using the endpoints at  http://169.254.169.254/latest/meta-data/. 

These endpoints reveal information such as API keys, AWS S3 tokens, and passwords.

Here are a few especially useful ones to go after first:

• http://169.254.169.254/latest/meta-data/ – returns the list of available metadata that you can query.
  
• http://169.254.169.254/latest/meta-data/local-hostname/ – returns the internal hostname used by the host.
  
• http://169.254.169.254/latest/meta-data/iam/security-credentials/ROLE_NAME – returns the security credentials of that role.
  
• http://169.254.169.254/latest/dynamic/instance-identity/document – reveals the private IP address of the current instance.

• http://169.254.169.254/latest/user-data/ – returns user data on the current instance.

Querying Google Cloud Metadata

If the company uses Google Cloud, you could try to query Google Instance Metadata API instead.

Google implements some additional security measures for their API endpoints — Querying Google Cloud Metadata APIv1 requires special headers:

“Metadata-Flavor: Google” or “X-Google-Metadata-Request: True”

But this protection is an easy bypass because most endpoints accessible through APIv1. It has easy access via the API v1beta1 endpoints instead. And API v1beta1 does not have the same header requirements. 

Here are a few critical pieces of information to go after first:

• http://metadata.google.internal/computeMetadata/v1beta1/instance/service-accounts/default/token – returns the access token of the default account on the instance.

• http://metadata.google.internal/computeMetadata/v1beta1/project/attributes/ssh-key – returns public SSH keys that can connect to other instances in this project.

Amazon and Google aren’t the only web services that provide metadata APIs. However, these two have quite a large market share, so chances are the company that you are testing is on one of these platforms. 

If not, https://gist.github.com/BuffaloWill/fa96693af67e3a3dd3fb is a list of other cloud metadata services and things you can try.

Impact of SSRF on Cloud Environments

The impact of an Server-Side Request Forgery attack in a cloud environment can be severe. An attacker with an SSRF vulnerability can access and exploit the resources and data of the entire cloud infrastructure. 

Some of the possible impacts of an SSRF attack in a cloud environment are as follows.

1. Data Theft: An attacker can steal sensitive data from cloud storage buckets or databases not intended to be accessed by the application.
    
2. Data Corruption: An attacker can manipulate the data stored in cloud storage buckets or databases by sending malicious requests.
   
3. Resource Exhaustion: An attacker can send many requests to a targeted internal or external system, resulting in resource exhaustion and downtime.
   
4. Complete Control: An attacker can take complete control of the cloud infrastructure by exploiting an SSRF vulnerability in a critical component of the cloud environment.

Remediation Techniques to counter Server-Side Request Forgery attacks

Here are some of the remediation techniques to prevent SSRF attacks in cloud environments:

1. Input Validation: The first and most crucial step is to validate user input to ensure that it does not contain any malicious content. It means we cannot use special characters in an Server-Side Request Forgery attack. Developers can use a whitelist approach and allow URLs that are authentic for access by the application.
   
2. Restricting Network Access: Network access should be restricted to only the necessary resources, and external access should be blocked wherever possible. Firewalls and network access controls can restrict network access.
   
3. Access Control: Implement access controls to ensure that only authorize users have access to critical resources in the cloud infrastructure. This includes implementing role-based access control and using strong authentication mechanisms.
   
4. Patch Management: Perform regular patch management to ensure that all software and services running in the cloud environment are up-to-date and do not contain any known vulnerabilities.

Recap – Server-Side Request Forgery

SSRF is a severe vulnerability that can be particularly dangerous in cloud environments. Attackers can use this vulnerability to gain access to sensitive data, execute arbitrary code, and launch other attacks that can compromise the security of the entire system. 

But with the right remediation techniques, you do not need to worry. As discussed, there are various remediation techniques to mitigate the risk of Server-Side Request Forgery attacks. 

If you’re looking for a comprehensive solution to secure your web applications, SecureLayer7 can help. With our cutting-edge web application security solutions, you can protect your systems from all types of cyber threats.Get in touch with us today to learn more!