Lessons Learned from Capital One Breach & More Leon Jiang Sep 2019

Leon - Who is this guy? Current: Director of InfoSec at Roostify, a fintech startup in SF Past: 11 years with Oracle, MBA An experienced information security practitioner with strong business acumen.

Disclaimer Many facts are obtained from the federal document or other public sources. However, some parts are hypothetical analysis for research and future reference purpose only which may not necessarily be truthful or pertained to Capital One breach.

Capital One Breach - What Happened 7/29 - Capitale announced a breach. On the same day, a federal criminal complaint filed against the alleged hacker known as ‘Erratic’. 7/17 - A reporting email sent to Capital One alleging there appeared to be leaked data belonging to Capital One. 4/21 - Erratic uploaded a file to GitHub gist (a code sharing feature separated from GitHub main site, similar to pastebin) which contains commands to access Capital One data but NOT the data itself 8/28 - From the released indictment, not just Capital One, 30+ other companies were being victims of the same hacker between March and July 2019

Analysis Efforts from My End

How Could it Happen? -From the Criminal Complaint 1st Command Obtain (AWS) Credential 2nd Command List (S3) Buckets 3rd Command Sync (S3) Data

How Could it Happen? - From Her Twitter

Key Point - IAM Role on EC2 Instances What is it? According to AWS, We designed IAM roles so that your applications can securely make API requests from your instances, without requiring you to manage the security credentials that the applications use. To simplify, no more username/password or API Key, you have the right once you’re on the machine. How did it go wrong in these cases? Too much privilege were given to the roles - i.e. violating LEAST PRIVILEGE principle

Last Line of Defense - App/Field Level Encryption 100 million individuals was affected, but only 140,000 social security numbers and 80,000 bank account numbers were disclosed. Why? It could be encryption Encrypted data at field or application level so much of the leaked data is not readable As a comparison - Instance/database/bucket level encryption won’t help much in this scenario

Questions Remain Unclear How were the instances compromised in the first place? For Capital One case, different theories Federal Doc: Misconfigured firewall (but how?) Evan J: SSRF (server side request forgery) Instance is not compromised but rather a temporary AWS credential is obtained and following attacks remains the same except not directly launched from the compromised instance Why has it never been detected until reported? Enough suspicious activities: Connection coming from TOR, S3 files sync, data dump, instance launch, malicious software deployed. AWS has some tools such as Guard Duty, Macie, and now Security Hub Of course, running a SOC with thousands of alerts everyday is never easy!

Summary of Lessons Learned Least privilege on IAM role assignment and anything else Extra caution on AWS access Examine the need of IAM roles for Internet facing servers Lock down the IP that those credentials can be used Application level encryption of data or file elements to be stored in DB or S3 Secure and patch vulnerable instances Detection and monitoring A lot of ML/AI based tool is on the rise but the effect is to be examined.

References https://www.roostify.com/blog-home/2019/7/31/capital-one-data-breach-step-by-step-analysis https://www.capitalone.com/facts2019/ https://www.justice.gov/usao-wdwa/press-release/file/1188626/download https://www.justice.gov/usao-wdwa/pr/former-seattle-tech-worker-indicted-federal- charges-wire-fraud-and-computer-data-theft https://ejj.io/blog/capital-one