Written by Daniel Hood

on February 27, 2020

What Happens if You Post Your AWS Keys in a github repository

I’ve had a few people have asked what happens if my AWS keys become compromised. I’ve seen this situation drilled in AWS security exams, I’ve assisted clients with how to protect against this situation and I’ve worked on incident response cases where this has happened. It’s a scenario that everyone who works with AWS should know and understand. Whether you are a developer, an old school engineer, in DevOps or even management, if you work with AWS you should intimately understand what happens.

Access keys can be created for an entity within Amazon AWS and are used to authenticate to Amazon AWS APIs and perform actions. Access keys can be compromised if an adversary gains access to a developer’s workstation, if the credentials are exposed through vulnerable code or a variety of other means. The situation we’ll be investigating today is if the access keys are posted to a public Github repository by accident.

Testing

So what does happen exactly? I created a new AWS account to restrict the potential risk of something occurring. I enabled CloudTrail to ensure I could audit what happens exactly at all steps in the process. I then created a new IAM user ‘test’ and assigned the ‘AlexaForBusinessReadOnlyAccess’ role to the new user. I assigned this role for Alexa, as Alexa does not contain anything that could be utilised to cost more money or expose any sensitive information. I chose a read only set of permissions to stop a potential adversary from actually doing any damage. I created keys for the user but, I did not add management console access.

I created a new public repository in my Github account called “awshoneypot”, I tried to keep the name as inconspicuous as possible.

I created a credentials file as if I’d created it with “aws configure” and then “accidentally” committed these AWS keys to Github. I wanted to make sure that it as obvious as possible that these were AWS keys to ensure that any bots that were scanning repositories would find them easily.

Published

Less than a minute after I committed the code, I got the following email from Amazon Web Services. Amazon had created a new support case to track this incident, despite this account not having support. It identified the keys and which user they belonged to. Finally, it identified the exact location within Github where the keys were posted.

Amazon did not disable the keys. The keys were still active. If this was a real situation and I had lost keys that had access to some valuable resources, a malicious user could still use these keys.

I checked the CloudTrail for this account after 30 minutes and there were no entries. There were no AccessDenied attempts in CloudTrail for this account. I wondered if CloudTrail was not reporting the attempts.

I thought CloudTrail would have at least showed a few attempts from nefarious actors trying to create instances to mine cryptocurrency, find persistent access to the account or download all the files in private S3 buckets. There were none.

To confirm that CloudTrail was reporting the attempts to access the account using those keys, I tried to use the keys to list all S3 buckets within the account. CloudTrail logged this request successfully.

CloudTrail also observed a number of actions by the Amazon support team to access the account and do some diagnostics. I found it interesting that these actions were logged within CloudTrail, showing the level of transparency Amazon has.

I then got a call in Australia from a United States (+1) number at 4:21pm, it was Amazon calling about the compromised keys and advising me that I had a problem.

I left it for a few days longer and still nothing in the AWS CloudTrail logs.

The entire timeline for the publishing of my keys is as follows:

Recovery

At 11:59am on the 11/02, I finally deleted the keys on the “test” IAM user. This closed the security vulnerability. I received this email from Amazon after deleting the keys, advising that the compromised access key was now deleted.

The entire timeline for recovery is as follows:

Despite the fact that my keys were not utilised, I would still not recommend posting your keys to Github and instead storing them securely at all times. A key lesson that can be taken from this exercise is that Amazon did not disable the compromised keys. You should have a process in place to automatically take action when a key becomes compromised. There are a number of ways of achieving this using either Amazon’s own tools or a third party solution.

I would recommend learning more about GuardDuty and how to set it up, this can definitely help protect your AWS accounts against other attacks.

If you have any further questions, feel free to contact me through LinkedIn ( https://www.linkedin.com/in/daniel-hood-71904216/).