How Paige Adele Thompson Hacked Capital One Using A SSRF Attack

by Sunny Hoi

Introduction

Capital One had deployed a misconfigured open-source Web Application Firewall (WAF) called ModSecurity together with the open-source Apache Web Server to provide application security protections against various vulnerabilities (OWASP ModSecurity Core Rule Set, CRS) that hackers usually employ to compromise web applications.

The misconfigured WAF was deployed to protect activities hosted in the cloud with Amazon Web Services (AWS).

The Web Application Firewall’s misconfiguration permitted the hacker to deceive the firewall into relaying requests to a central back-end resource on the Amazon Web Services platform. Such resource is referred to as a metadata service which is responsible for delivering transient information to a cloud server, comprising current credentials transmitted from a security service to access any resource in the cloud to which that specific server possesses access.

Capital One’s misconfigured WAF was allocated excessive permissions. For instance, it was permitted to enumerate all of the files in any buckets of data and to read each of the file’s contents.

Paige Adele Thompson exploited a vulnerability called Server Side Request Forgery (SSRF) whereby the server (Capital One’s misconfigured WAF) may be deceived into executing commands that it should never have been allowed to execute, such as those that permit it to communicate to the metadata service.

Thompson was able to obtain data from 30 different organizations.

In this tutorial, we will illustrate how a hacker can replicate the hacking of Capital One, in the way that Thompson did.


Before proceeding further, we presume that you are acquainted with various notions like WAF, EC2, IAM, SSRF, and Security Group.

You should already have an account registered with Amazon Web Services. The free tier should suffice.


1. Make A Security Group. We will want to open port 80 for HTTP (Hypertext Transfer Protocol) and Port 22 for SSH (Secure Shell).

2. Make an Ubuntu EC2 (Amazon Elastic Compute Cloud) instance of t2.micro and login using PuTTy (A free SSH and Telnet client for Windows).

3. Make an IAM role (Role4EC2-S3RO) accompanying the AmazonS3ReadOnlyAccess policy and allocate the policy to the aforementioned Ubuntu EC2 instance.

Note that an IAM role serves as an IAM identity that you may create in your account that holds particular permissions. An IAM role is reminiscent of an IAM user, in the sense that represents an AWS identity with permission policies that establish what the identity can and cannot accomplish in AWS. Nevertheless, as opposed to being peculiarly linked to one individual, a role is designed to be presumable by anybody who requires it.

Next, we will want to attach a policy with very restricted privileges like S3 RO or something different, behind which there lacks critical data.

4. Test the subsequent cURL command in the Ubuntu EC2 instance to acquire the IAM Role credentials by means of EC2 Metadata Service.

5. In Ubuntu, we’ll want to install Ruby and Sinatra on the Ubuntu EC2 instance:

The final command will take a couple of minutes to execute.

6. Make the server.rb file with the following content on the Ubuntu EC2 instance:

In this way, we are making a web server. The server will proceed to grab an URL as a request, opens the same and transmits the URL content as the response.

7. Obtain the Private IP of the Ubuntu EC2 instance. Deploy the following command and run it in the Ubuntu EC2 instance:

As we can see, this will initiate the webserver employing the Ruby program.

8. Execute the subsequent command in the Ubuntu EC2 instance:

Evidently, we’ll want to replace “replacewithpublicIPofUbuntuEC2instance” with the Ubuntu EC2 instance’s Public IP address.

We can clearly see that the security credentials of the role are affixed to the Ubuntu EC2 instance.

9. We can proceed by opening the following URL address in a browser from any system to obtain the IAM Role’s security credentials to show in the browser:

Once again, we’ll want to replace “replacewithpublicIPofUbuntuEC2instance” with the Ubuntu EC2 instance’s Public IP address.

Like earlier, we can observe that the security credentials of the role are affixed to the Ubuntu EC2 instance.

Hence, we can perceive how Capital One and other companies got hacked through SSRF vulnerability. After the hacker obtained the security credentials, the subsequent steps would be to deploy the AWS CLI (Command Line Interface) or SDK (Software Development Kit) to acquire data from S3.

10. Ensure that you stop the EC2 instance and remove the role.

How To Mitigate SSRF Vulnerabilities

1. Render modifications to the Ubuntu EC2 Instance to obstruct the calls to 169.254.169.254:

2. Incorporating additional identifying information in any request transmitted to the metadata service. Google has already integrated such implementations into its cloud hosting platform.

3. Inserting a WAF rule to discover the “169.254.169.254” string and block could have prevented this attack.

4. Conduct application code review for the Server-Side Request Forgery vulnerabilities and carry out proper validation of the inputs.

Conclusion

Fixing these sorts of security problems requires tons of specialized knowledge and experience that are associated with operating a service inside AWS. SSRF attacks do not typically appear on any critical configuration guide.

The operator ought to understand how EC2 functions, grasp Amazon’s Identity and Access Management (IAM) system and be able to authenticate with different AWS services.

Plenty of individuals deploying AWS will interface with heaps of AWS services and create software that organizes and automates new services. Numerous people depend on Amazon Web Services, and one significant issue is that it requires enormous specialized knowledge that is difficult to grasp and tough to get right.

Related Posts