Capital One Hack

Capital One Financial Corporation is a bank holding company specializing in credit cards, auto loans,
banking and savings accounts headquartered in McLean, Virginia. Capital One is ranked 10th on the
list of largest banks in the United States by assets.

With 100 million customers affected, it ranks as one of the largest data breaches to date. Capital
One now joins a long list of companies that have fallen victim to risks that are inherent to AWS and
other cloud security platforms.

At some point between March 12, 2019 and July 17, 2019, an unauthorized user accessed data
stored in AWS S3 buckets belonging to Capital One. The unauthorized user exfiltrated the data and
stored it on GitHub under their real name, Paige Thompson, as well as boasting about the data theft
in a Slack channel and on twitter using the pseudonym “erratic”.

About 140,000 Social Security numbers and 80,000 linked bank account numbers were exposed.

Someone previously unknown to Capital One became aware of the data theft, either through the
online boasting or GitHub upload. They sent an email to the responsible disclosure email address at
Capital One.

Technical Details of the Capital One Breach

Based on the latest information from charging documents and media outlets in this still-developing
story we now believe that the data breach occurred because of a misconfigured AWS service
allowing server-side request forgery.

The charging documents break it down into 3 steps:

1. The attacker used some method to obtain AWS keys for an IAM role called “*****-WAF-
Role” (the full role name is redacted in the charging documents)
2. The attacker used the stolen AWS keys to list S3 buckets that were accessible to that role.
3. The attacker used the AWS CLI S3 “sync” command to recursively copy data from the
“*****-WAF-Role” accessible buckets to some other location.

During our AWS penetration tests, we often see these kinds of misconfigurations.

The “Shared Responsibility Model” is a framework used by AWS to explain the division of
responsibility for security between AWS and users of the platform. This framework dictates that
AWS is responsible for the “Security of the Cloud”, while the user is responsible for the “Security in
the Cloud”.

The bank might have used a weak type of encryption or failed to properly store decryption keys,
allowing a hacker to access data.

AWS’s responsibilities, or the “Security of the Cloud”, include the infrastructure of the cloud
platform, for example the hardware the runs in the data centers. The user’s responsibilities, or the
“Security in the Cloud”, include the security of their applications that run on top of the cloud
infrastructure.

1|Page
It is often assumed that cloud platforms are simply secure and full responsibility falls on the provider
of the platform. This is a critical misunderstanding that Rhino Security Labs researchers see again
and again during penetration tests.

To be clear, we are not speculating that Capital One misunderstood the Shared Responsibility Model.
In fact, the Capital One team is well-known for being leaders in Cloud Security. The point that we’re
trying to make is that if a top-notch team like Capital One can fall victim to simple configuration
mistakes, anyone can. Because these simple configuration mistakes are so easy to make, it’s
important that users understand exactly what they are responsible for in AWS.

Once aware of this, Capital One conducted an investigation, determined that there had, in fact, been
a breach, and alerted the FBI. In the early hours of July 29th, “erratic” was arrested in their home in
Seattle and is being held at a Federal Facility in SeaTac, Washington, charged with “computer fraud
and abuse”.

According to a source with direct knowledge of the breach investigation, the problem stemmed in
part from a misconfigured open-source Web Application Firewall (WAF) that Capital One was using
as part of its operations hosted in the cloud with Amazon Web Services (AWS).

Known as “ModSecurity,” this WAF is deployed along with the open-source Apache Web server to
provide protections against several classes of vulnerabilities that attackers most commonly use to
compromise the security of Web-based applications.

The misconfiguration of the WAF allowed the intruder to trick the firewall into relaying requests to a
key back-end resource on the AWS platform. This resource, known as the “metadata” service, is
responsible for handing out temporary information to a cloud server, including current credentials
sent from a security service to access any resource in the cloud to which that server has access.

In AWS, exactly what those credentials can be used for hinges on the permissions assigned to the
resource that is requesting them. In Capital One’s case, the misconfigured WAF for whatever reason
was assigned too many permissions, i.e. it was allowed to list all of the files in any buckets of data,
and to read the contents of each of those files.

The type of vulnerability exploited by the intruder in the Capital One hack is a well-known method
called a “Server Side Request Forgery” (SSRF) attack, in which a server (in this case, CapOne’s WAF)
can be tricked into running commands that it should never have been permitted to run, including
those that allow it to talk to the metadata service.

Amazon pointed to several (mostly a la carte) services it offers AWS customers to help mitigate
many of the threats that were key factors in this breach, including:

–Access Advisor, which helps identify and scope down AWS roles that may have more permissions
than they need;

–GuardDuty, designed to raise alarms when someone is scanning for potentially vulnerable systems
or moving unusually large amounts of data to or from unexpected places;

–The AWS WAF, which Amazon says can detect common exploitation techniques, including SSRF
attacks;

–Amazon Macie, designed to automatically discover, classify and protect sensitive data stored in
AWS.

2|Page
Have a Capital One credit card? Then take these 5 steps

1. Freeze your credit

Security experts are unanimous that a credit freeze is an essential step to protect your data and halt
scammers from creating fake accounts in your name. Security experts note that a freeze is much
more effective than a fraud alert. Credit freezes don't affect your credit score, but they prevent
loans and other services from being opened in your name without your consent. A fraud alert simply
is a red flag alerting companies to the fact you may have been the victim of fraud.

That means a hacker would need to have access to your mobile phone as well as your account
information in order to gain access to your accounts.

2. Enable two-factor authentication

Adding an extra layer of security to your logins can help prevent scammers from gaining access to
your accounts. The most common form of two-factor authentication is when a business texts you a
one-time code that enables you to access your account.

3. Sign up for credit monitoring

These services can help you keep close tabs on your accounts, alerting you if someone opens an
unauthorized account in your name or even another family member's name.

4. Don't get phished

Ignore unsolicited requests for information, which could be phishing attempts, or when hackers
pretend to be a trusted company or individual, recommends financial site WalletHub. If you haven't
been asked to be contacted, don't respond to the email, its experts say.

5. Change your passwords regularly

Consumers can also protect themselves by taking a step that most don't follow: Changing their
passwords. And of course, too many consumers continue to use easy-to-guess passwords like
"123456."

3|Page