Understanding the 2019 Capital One Attack

As we head into the last month of 2020, we’re taking a quick break this week and reprinting one of K2’s original posts that we released back in January of 2020.  This blog post was originally published here.

On July 19, 2019, an attacker gained unauthorized access to hosted Capital One servers in Amazon Web Services (AWS) and stole personal information about individuals who had applied for Capital One credit cards.  In this blog article, we will review how this attack was able to take place, and what could have been done to prevent such attacks in the first place.

The attack was extremely sophisticated and its success required deep knowledge of both how the AWS infrastructure functions and of a vulnerability in the ModSecurity Web Application Firewall (WAF).

First, a vulnerability in the WAF allowed a “Server Side Request Forgery” (SSRF) attack where the attacker manipulates a vulnerable web server to make new http requests on its behalf to access resources that the attacker should not have direct access to. The resource in this case was the AWS metadata service.

The AWS metadata service is a crucial part of the AWS infrastructure that allows services to obtain temporary credentials. The metadata service runs as part of the hypervisor and provides temporary Identity and Access Management (IAM) credentials via a simple http request. The advantage of having the metadata service is that it securely authenticates access to AWS services, without the complexity of real IAM keys. Since the connectivity to the metadata service is local there is no additional authentication required.  By launching the SSRF attack on the WAF the attacker was able to connect to the metadata service and obtain credentials the metadata service would provide to the WAF.

Sponsorships Available

Sponsorships Available

Sponsorships Available

Second, the access controls were improperly configured and gave the WAF access to resources that it should not have. One of these resources was the personal information of individuals who had applied for the Capital One credit card. This allowed the attacker to use the obtained credentials to access PII (Personally Identifiable Information) of the individuals.

Third, the misappropriated temporary credentials could be used from any Amazon virtual private cloud (VPC). Therefore, the attacker was able to use the stolen credentials to directly gain access to private and confidential resources. If the use of these credentials had been limited to VPCs owned by Capital One, the attack could have been prevented.  The attacker would not have been able to use the stolen credentials to gain unauthorized access to Capital One data. Unfortunately, VPCs can be brought up and torn down frequently and the imposition of checking credentials to VPC association would be difficult and likely impact the performance of the cloud infrastructure.

Prevention of an attack of this type, is typically the responsibility of the security solution, i.e. the WAF, to protect against SSRF attacks that are increasingly common. Unfortunately, these types of attacks are extremely hard to detect for WAFs because they have no visibility or context into how a URL or IP address in the incoming HTTP request will be used by the web application.

Further, the WAF may not necessarily be deployed in-line to monitor the outbound HTTP requests made by the web application. Many SaaS companies offer some form of web hook product which makes an http request on behalf of the user and cannot be easily differentiated from an SSRF attack. These factors expose the fundamental limitations faced by WAFs in trying to defend against SSRF attacks. A robust, modern defense against SSRF attacks needs to incorporate validation of how the web application itself processes the incoming and outgoing web requests. Today’s web application security solution needs to have application execution validation to correctly determine if an incoming HTTP request is resulting in an SSRF attack or if it is a legitimate action of the application.  WAFs are coming up short in providing this type of detection and defense.

If you’re relying on a WAF to secure your web infrastructure, you should evaluate K2 Cyber Security’s next generation workload protection platform, offering application execution validation as part of our security offering.  K2’s easy to deploy non-invasive agent installs in minutes and uses a deterministic technique of Optimized Control Flow Integrity (OCFI) to automatically create a DNA map of each application at runtime, which is used to determine that your application is executing correctly, offering extremely accurate attack detection that eliminates false alerts.

If you’re looking for an application security solution that meets today’s needs for security, with true zero-day attack detection and no false alerts, you can request a demo or follow up from our sales team.