Some may think that critical cyberattacks are perpetrated by some hard-boiled hacker or weighty intelligence agencies. The reality is that unexpectedly simple hacks can have tremendous effects on a grand scale.
On Jul 29, Capital One declared a data breach which reportedly affected 100 million individuals in the USA and another 6 million in Canada. The stolen data contained sensitive financial and personal information, like Social Security Numbers.
Given the detailed nature of the FBI complaint on the case, I was able to theorize a possible way the hacker could have gained access to such a huge private dataset.
And, in relative terms, it’s worryingly simple.
In this analysis, I assumed that the data was hosted on Amazon Web Services. The complaint does not specify the identity of the “Cloud Provider” but it may be attributed to AWS because of the terminology used in the document(like S3).
I also assumed that the hacker was not an insider.
Entry point: Server-Side Request Forgery Attack
SSRF is a well-known web application attack. The attacker crafts a request to the vulnerable application in order to make the victim server fetch a URL, or a local file, and retrieves its content. A simplified example request is reported below:
GET http://####.com/?get=127.0.0.1/adminIf ####.com is vulnerable to SSRFs, it may fetch “passwords.txt” or remote resources that are only available in the server subnet and retrieve their content to the attacker
SSRF attacks are extremely powerful because they usually bypass WAFs (Web Application Firewalls).
In this particular scenario, I suppose an SSRF could have been used to gain access to an EC2 instance metadata through a vulnerable web application residing on the instance itself. On AWS EC2 retrieving the instance metadata is a trivial task. It is done by sending an HTTP request to the following URL:
But what is the metadata content and why it’s important?
Access gain: EC2 Instance Metadata
It contains information about configuring and managing the EC2 instance.
Among all the information inside it, an attacker could be particularly interested in one thing: IAM Role temporary credentials. More specifically the AccessKeyId, the SecretAccessKey, and the Token. With those, it’s possible to have the same permissions of the IAM role associated with the instance.
Although you can only access instance metadata and user data from within the instance itself, the data is not protected by cryptographic methods. Anyone who can access the instance can view its metadata. Therefore, you should take suitable precautions to protect sensitive data (such as long-lived encryption keys)
— from AWS EC2 documentation
In this scenario, I assume the EC2 instance (where the vulnerable web application was running) had full S3 permissions and that means…
Data stealing: S3 Buckets Access
Like in the real world, access keys open doors. No matter how big the dataset is, getting it could now be as easy as running three commands:
#!/bin/sh# After having configured the aws cli with the stolen access keys:aws s3api list-buckets --query "Buckets.Name"
aws s3api list-objects --bucket "PRIVATE_DATA_BUCKET"
aws s3api get-object --bucket "PRIVATE_DATA_BUCKET" --key "data_key"
Cloud Computing is a major trend for a number of reasons and for the advantages it brings, including infrastructure security. Although, events like the latest Capital One data breach, underline the importance of paying fine-grained attention to the security of every part of a system.
I’ll post a follow-up in which I discuss my insights on how this attack could be mitigated. Follow me and do not miss it!
FBI complaint: https://www.justice.gov/usao-wdwa/press-release/file/1188626/download
Capital One announcement: https://www.capitalone.com/facts2019/
SSRF Definition (OWASP): https://www.owasp.org/index.php/Server_Side_Request_Forgery
AWS S3 Documentation: https://docs.aws.amazon.com/s3/index.html
AWS EC2 Documentation: https://docs.aws.amazon.com/ec2/index.html