87 comments

  1. How is it that the intruder was even able to access the misconfigured Web Application Firewall in the first place? Isn’t some sort of authentication necessary to do this? If not, or if the method of authentication is weak (using a password such as “password123”), wouldn’t some form of strong authentication for accessing the WAF have prevented the breach, despite the other misconfigurations? Or did the misconfiguration of the WAF itself disable any authentication necessary to access the WAF?

    • Most likely, the WAF was intentionally exposed to the Internet and was expected to transparently pass requests to servers running on EC2 instances inside the AWS account VPC.

      This article implies that the intruder was able to cause the WAF to trigger AWS commands to enumerate and dump the contents of the S3 buckets. This would imply that the WAF was itself running on an EC2 with an overly-permissive IAM role.

      Another possibility is that the intruder used an additional hop and caused the WAF to pass HTTP requests to an EC2 server inside the VPC, and that server executed the S3 commands. A misconfiguration on the WAF could allow requests to be passed to a server that wasn’t intended to be exposed, and thus have a permissive role.

      • Actually, on reading related articles in more depth, the consensus appears to be that the WAF was intentionally set up to “redirect” incoming requests (really, more like a reverse proxy). Due to the misconfiguration, the intruder was able to send a request to the local metadata service, which returned the temporary IAM credentials the WAF was using. Then, the intruder used those creds to make API calls to the S3 service and dump all the data.

        This would imply two bad configurations: Whatever was on the WAF that allowed the redirection to the metadata service, and the overly-permissive role assigned to the EC2 instance and allowed all the S3 access.

        This is a common, easy, well-understood attack. The configuration errors are very easy mistakes to make.

      • I think it’s more so that they sent a request through the WAF that was a SSRF attack that called the metadata service on the EC2s running the WAF application to retrieve credentials. These credentials are for the role the EC2 is running under and had too permissive policies. Those credentials allowed the hacker to list buckets contents and download data from the attackers machines not from machines in Capital Ones VPC.

        • Yes, it looks that way. Sadly, your reply pointing that out appeared before my reply pointing that out.

          Looking at the earlier article, it looks like she typically also used creds to set up EC2 instances and set up other services to exfiltrate. Just pulling straight off the S3 buckets would have worked for Capital One, though.

  2. Regardless of HOW this happened, wasn’t the personal data that was stolen encrypted? Or was it poorly encrypted and able to be brute-forced?

    • Gordon Weakliem

      Leaving it unencrypted would be a huge security violation. My guess is that it was encrypted on S3 but the role on the EC2 had KMS decrypt permissions attached.

      • Almost certainly. The data was clearly not programmatically encrypted by the application. Given the SSRF risks and just “whoopsie” permissions issues with configuring S3 properly, and issues dealing with IAM roles – as mentioned by Krebs and the linked article from Evan, that stuff is complex and confusing, sensitive data should never be stored in S3 unencrypted. Figure out a way to programmatically encrypt it and protect the hell out of those keys. It just was not hard enough for this hacker to get to this data.

        • In public articles, Capital One’s CIO stated quite clearly, that Capital One created a product called “Cloud Custodian” that would “automatically encrypt all Capital One data” going into AWS. (not some..ALL).

    • Is there any evidence the data is not still encrypted by CapOne? There is reporting that data was exfiltrated. Nothing says it was in a format actually useful to the hacker.

  3. should has a deny block in S3 bucket policy, just use the IAM and encrypts are not enough. Remember your data is on public-clouds.

    • I agree, simple S3 policies are not enough, more restrictions to make access more specific can help. Even if the instance credentials are compromised, e.g. the S3 vpc-endpoint whitelisting may deny outside access.

  4. Te basic 4 control family veracity were not there. If any of the 4 mentioned control families were weak, the threat is inevitable to become reality.
    Always try to have Control veracity at highest when it comes to:
    1, AAA (authentication, authorization, access)
    2, Channel Security or crypto in transit
    3, Content Security or crypto at rest (hoping it is separated from 2)
    4, Audit (lastly this is where we all miss the signs of security “tickles” that we get before we fall over).
    It is easy to blame the vendors or admins or…
    The truth of the matter is that we are all vulnerable to low resources, authority, and budget to have the controls above maintained and operated. Far too many times when we are successful the first question from MGT is what do those guys do behind closed doors.

  5. Something I never see addressed. The executives of all these companies that have had break-ins, was any of THEIR personal information included? Do they keep their info sand boxed away from the customer databases? If they can keep their own information safe then why can they not keep ALL information safe?

  6. In the deposition, it mentioned that someone saw the Capital One files on Github and informed Capital One at which point they began their investigation. It also states that she mentioned encrypting the information prior to putting it on Github. So, this also raises the question, how secure is encrypted information on Github?

    • GitHub isn’t designed for security per se.

      It’s designed for distributed coordination of development on source code. Generally speaking, it’s a way to share code and make changes to code.

      If you choose to encrypt your content before submitting it to GitHub, then it’s up to you wrt how you choose to encrypt it.

      Connections to GitHub themselves are transport encrypted w/ TLS/SSH, but that’s mostly just to prevent MitM attacks. Generally speaking anyone who is authorized can read the content of a given repository, and I think most repositories are public.

  7. Isn’t anyone concerned that by notifying customers through various means if they were involved will only create a much larger phishing campaign with hackers moving forward? Why is Capital One not establishing a search index similar to what Equifax did?

    • Equifax’s response to their data breach was more horrible than the breach itself. It isn’t and shouldn’t be up to the victim to find out whether they are affected or not. The responsibility of notifying the victim was Equifax’s. By setting up a website for users to input 6 of the 9 digits in their social security number is just asking for someone to setup a rogue website to collect social security numbers.

  8. most of capitalone should have migrated away from mod_security around 2 years ago

  9. 2 years ago capitalone switched their WAFs away from mod_security