In the wild encounters: From Random SSRF to LFI & AWS Takeover

This blog post discusses a Server-Side Request Forgery (SSRF) vulnerability that was escalated to Local File Inclusion (LFI). Successful exploitation of this vulnerability exposed sensitive access keys and private tokens, allowing access to connected AWS instances. In fact, my research revealed that this vulnerability could potentially compromise the integrity, availability, and confidentiality of the website and over 20+ AWS instances that are not necessarily directly connected to it but are definitely within the scope.

It is vital for organizations to understand the potential risks and impacts of vulnerabilities like this, as well as the measures that can be taken to prevent them.

First of all, what is SSRF?

A Server-Side Request Forgery (SSRF) attack involves an attacker abusing server functionality to access or modify resources. The attacker targets an application that supports data imports from URLs or allows them to read data from URLs.

‍

SSRF (Server Side Request Forgery)

While researching some of the parameters within the site's infrastructure, one parameter has attracted my attention. Playing with this parameter, I could access internal information by using different protocol schemes and dig deeper into the infrastructure in order to understand the effect that an attacker could have if this issue is exploited.

An SSRF vulnerability was detected under an endpoint which does not validate the "url" parameter input.

An attacker can insert a URL of his choice, and therefore, can interact with the internal network utilizing different protocols.

Here is an example for a PoC with the SSH protocol:

• http://www.REDACTED.com/?url=http://localhost:22
• This grabs the internal SSH banner from the host:

• SSH-2.0-OpenSSH_8.0

SSRF to LFI (Local File Inclusion)

The SSRF vulnerability was successfully escalated to LFI utilizing the file:// protocol.

Here is an example for a PoC with the file protocol:

• http://www.REDACTED.com/?url=file:///etc/passwd
• The results in internal file read, exposing the content of the passwd file.
  There are several different users under a known web directory (/var/www/html/), which could indicate that several sites are running on the instance.

‍

SSRF to AWS Access Keys‍

The SSRF vulnerability was successfully escalated to extract AWS access keys and private tokens.

This allows the attacker control over various AWS instances with read \ write privileges to multiple cloud environment assets of the organization.

Here is an example for a PoC revealing AWS keys in plaintext:

• http://www.REDACTED.com/?url=http://169.254.169.254/REDACTED/meta-data/iam/security-credentials/REDACTED
• The output is damning:

• "Code" : "Success",
  "Type" : "AWS-REDACTED",
  "AccessKeyId" : "REDACTED",
  "SecretAccessKey" : "REDACTED",
  "Token" : "REDACTED",
  "Expiration" : "REDACTED"

‍

‍

Threat actors can use the AWS credentials to control the instances, view or edit sensitive information, and plan further sophisticated attacks. They could inflict a high amount of damage, only limited largely by their own goals.

For example, they could steal and manipulate confidential data and expand to other devices via lateral movement while staying dormant in order to extract more sensitive information, all the while mapping the compromised network in order to execute a ransomware attack on the compromised cloud infrastructure and the sites connected to it.

The damage can be both operational and reputational, leading to both very public and very severe repercussions.

Always remember:

• Sanitize all user supplied input.
• Restrict redirection and external communication to specific domains and ip addresses via whitelisting.
• Deploy appropriate monitoring capabilities in order to alert upon unauthorized access to sensitive content.

‍