Capital One, the second largest auto finance company in the United States, operates a Responsible Disclosure Program where researchers can disclose potential vulnerabilities via email. In mid-July, the company received the email below with a link to leaked information on Paige A. Thompson’s GitHub account.

capital one

The link contained huge amounts of credit card application data, social security numbers, bank account numbers, and a file with the code used to leak this information. From the complaint against Thompson, we can guess how the attack happened and learn what Capital One, one of the largest Amazon AWS customers, could have done to block the attack.

Background on Amazon AWS to Provide Context

Amazon AWS provides virtual machines that companies can use to store and run internal applications or web servers, and buckets where companies can store and manage data. Each virtual machine can be given a Role which identifies its permissions over the different services Amazon provides. When a machine wants to access an Amazon AWS service, it requests a security token from a “magic” IP address which it can then use to connect to AWS services. (Notice that Amazon does not log this action on CloudTrail.)

Here’s How It Happened (Details of the Capital One Breach)

The attacker attempted to access Capital One’s data on or around March 12, 2019 from a TOR endpoint and through the VPN company IPredator. The code file from Thompson’s GitHub contained the IP address for a specific server used to steal the credentials of a role, WAF-Role. (WAF stands for Web Application Firewall, an application that protects web applications from common exploits such as SQL Injection and Cross-Site-Scripting).

It’s important to keep in mind that one of the classic methods for compromising a servers’ role is by exploiting a Server-Side-Request-Forgery vulnerability. This allows the attacker to forge a request by the server to, for example, http://169.254.169.254/latest/meta-data/iam/security-credentials/, providing temporary credentials to the machine’s role.

Nearly two weeks later on March 22nd, the WAF-Role listed all of Capital One’s buckets and downloaded the credit card application data from one of them. According to Capital One, this role does not usually invoke the ListBuckets action, and this was the only time it accessed these files. It happened again on April 21st, only this time the information was posted on Thompson’s GitHub. On June 26th, the attacker posted a list of files he claims to be possessing, connecting Capital One, WAF-Role and another role, WAF-Web role, to himself.

With all of that background and context in mind, here are five tips for cloud security that could have prevented the Capital One data leak from happening in the first place:

  1. Know Your Infrastructure. Know which users can access what and why. Capital One’s WAF-Role had permissions to access credit card application data. Maybe the WAF-Role requires access to list the names of all Capital One’s buckets; but does the web application firewall need access to download a bucket containing private customer information?
  2. Apply a Principle of Least Privilege Model.  Permissions should be delegated over roles with each having access only to the resources it needs. Be sure to keep an eye out for overly-powerful users and any strange or new behaviour in your organization, just like you would in an on-premises environment.
  3. Separate Your Resources. The cloud gives you virtually unlimited storage space all over the world. Use it. But just like you would not have your proxy server on the same machine as your database and your codebase on-premise (I sure hope you don’t). Capital One should not hold both WAF and private customer information in the same bucket. It also shouldn’t have WAF and credit card web applications run from the same server with both justifying its role to own permissions for that bucket.
  4. Manage All Entities in Your Organization. Capital One, as one of the largest users of AWS, developed Cloud Custodian, a rules engine for managing public cloud accounts and resources. This product should have been used to alert someone at Capital One to the suspicious activity made by WAF-Role. Maybe it was actively given permissions by Thompson. In another possible scenario, the commands could have been run from inside the server. Nevertheless, WAF-Role accessed files which it should not have from an external IP and not one inside Amazon.
  5. Keep Your Infrastructure Up To Date. Amazon offers a WAF solution which integrates with CloudFront and blocks suspicious requests before they reach your servers. In Capital One’s case, Thompson had the public IP address of a server, so he did not pass through CloudFront at all. Using this service would have stopped Thompson from gaining the public address of the server and may have blocked his requests. Amazon keeps updating and building better security products for its customers to use. Companies working with AWS should always stay up to date with Amazon’s newest technologies and security recommendations to prevent cyber attacks.

Public cloud has undoubtedly been a great enabler for business, but it’s also created a number of blind spots and serious security challenges. The number of services and applications has - and continues to - increase exponentially, making access logic, permission sets, resources, capabilities and risks much more difficult to manage. Authorization is not a nice-to-have capability, it’s an imperative — and over-provisioned identities should be carefully inspected and eradicated. Identities permissions and access must be well defined and carefully verified in order to prevent such incidents. Otherwise, the results can be catastrophic and, in many cases, irreversible.