7 mins to read
How to Secure Lost and Forgotten Access Keys
What criminal wouldn’t take advantage of a pair of house keys left lying around a cafe table? Those keys give entryway to your home, any valuable possessions inside, and even the ability to live in the home as if they were the original owner. The same goes for access keys left around your cloud environment.
Access keys and other credentials offer high reward – ease of use, programmatic access – but also a high risk. In this blog, we’ll review how access keys function in the cloud, some of the troubles surrounding them, and access key best practices and alternatives to better secure them.
What are access keys and how do they work?
IAM access keys are long-term credentials you can create to give programmatic access to cloud resources. They work in two parts: an access key ID and a secret access key. The pairing of these two parts together is what authenticates a user’s access to make encrypted requests to APIs or the CLI.
Access keys can allow convenient access to human users so they can avoid repeatedly signing on and authenticating themselves manually, but also allow machine identities and workloads to complete automated actions in your cloud like patching EC2 instances.
If someone holds your access keys, they are able to fully operate as if they were you – with all the privileges and access you are authorized to have. Once an access key is created, the access is indefinite, increasing the chances of exploitation. This only further emphasizes the need for secure storage and protection.
Some examples of access keys across different clouds:
- AWS access keys: long term access key
- Azure access keys: SaS token
- GCP access keys: JSON web token
Where can I find them?
In terms of creating access keys, in AWS, one creates keys for an IAM user in the AWS Management Console or the AWS CLI. In Azure, you can find them in the portal, in PowerShell, or the Azure CLI. Finally, in GCP, access keys are made in the Google Cloud console.
There are a number of places one can come about access keys after they’re made. More generally, you can find them in environment variables or in configuration files on disk. Beyond that you could find left behind keys in a container image, accidentally included in a code repository, or even in metadata on a workload.
Watch this live hack to see where you can find access keys in a real world attack.
In terms of proper and secure storage options – cloud providers offer secrets and key management services like AWS Key Management Service, Azure Key Vault, and GCP Secrets Manager.
Access key challenges
Insecure Storage
Access keys are frequently left behind, lost, and forgotten. This creates a lot of room for danger.
Let’s say you’re a developer and you’re looking for more programmatic access to avoid having to repeatedly sign in to the cloud or authenticate with two-factor, so you leverage access keys to remain signed into a console and work seamlessly. After completing your work, you bundle it up and commit it to a repository – without knowing, you’ve actually included your access keys into this bundle. From there – they’re built into a gold image and end up in the cloud on a workload. Now these keys are sitting on a disk in a workload in the cloud. If someone gains access to this workload, they can gain access to these keys –and from there, they hold whatever access that developer holds.
A real-world example to consider is Toyota’s 2022 breach compromising customer data – all because of a credential left in a public repository. A subcontractor put source code into the repository, but inside it was a hardcoded access key that led to a server containing customer data. Anyone with that credential could then access the contact information of over 290,000 customers.
Third Party Risk
Another common use case for access keys is giving a third-party access to your environment.
For example, your business is leveraging a data analysis company and they need to mine your data warehouses. To allow this, you create a service account token to offer the third party access into your GCP environment. However, even when the project is done, the token is misplaced or forgotten about, and the third party continues to hold a doorway into your environment. Down the road, this third party ends up in the news for a data breach, but the reality is – their data breach is also your company’s data breach, because all it takes is a bad actor coming across that misplaced service account token to compromise your business as well.
A real world example is Uber’s 2022 breach. In this incident, Uber used a third party for tracking and asset management, however, the third party’s AWS server was compromised. This breach leaked various source code and the personal information of 77,000 Uber employees.
Lateral Movement
These challenges go beyond just being left behind and extend to how these keys can be used if they fall into the wrong hands. Access keys can play a big role in lateral movement opportunities for nefarious actors. Let’s consider the following attack path in an example Sonrai detected:
Here, we see an EC2 instance in a Sandbox environment with a vulnerability on it allowing entry for an attacker. This workload has a key that’s been left on disk tied to user 1. Once the workload is breached, this attacker now has access to the keys and can operate as if they were User 1. This means they can leverage the policy tied to User 1, offering them the sts:assumerole permission – leading them to assume User 2. User 2 has cross-environment access to another EC2 instance in Production. From here the attacker now can leverage the access to a Production data container – all starting from a vulnerability in a Sandbox account.
Keys are a golden opportunity for lateral movement – helping attackers hop around and operate as if they were authorized users, ultimately gaining access to sensitive property.
6 Access keys best practices & alternatives
AWS Access keys best practices
Step 1: Find lost access keys
Sonrai scans your environment to discover lost keys.
Step 2: Map keys to owners
Once keys are detected, Sonrai is able to compare them to existing infrastructure or other keys and discover their owner.
Step 3: Compute effective permissions
This is where Sonrai’s secret sauce comes into play. Sonrai’s patented permissions analytic model can compute the full scope of abilities any cloud identity holds. This includes all the privilege an identity can access that was never directly assigned to it. In the cloud, identities hold privilege we can’t see because it is inherited indirectly and unintentionally via trust relationships, conditional access, compounding groups and toxic combinations of permissions.
Step 4 Know what could happen if key exploited
Sonrai’s effective permissions analytics then gives insight into what could happen if a specific key were exploited. This means insight into every permission accessible – down to the most specific action (e.g. editing configurations, deleting infrastructure, etc.) and insight into ultimately what applications or data the key could allow access to.
Step 5 Know every identity that can get to key
Not only does Sonrai tell you what someone could do with the access key, but also a current picture of every entity that has an access path to acquiring these keys. This gives your teams a heads up that Joe in development or a service account in GCP unintentionally can access the keys.
Step 6. Prioritize remediation based on risk level
All of this extra context allows you to better prioritize remediation. Your teams could be inundated with numerous security alerts related to access keys, but if the key is sitting on a disk with no identities able to access it – or if the key leads to a dead end with no critical data access – you may be able to deprioritize it for another day. We understand team resources and time are currency.
Access key alternatives for long-term use
It is best to defer to short-term access keys if possible, but if you’re using longer-term credentials, consider the following tips from AWS:
- Don’t embed the keys in repositories or application codes – instead consider using AWS Secrets Manager
- Create IAM roles for temporary access – these are more secure as they’re not tied directly to a user, but instead are requested for use when needed.
- Don’t create long-term keys for human users needing service access – for external identity provider users, instead consider creating temporary credentials in AWS IAM. Identity Center lets you create permissions to grant the external users access.
- Don’t store long-term access keys in compute services – instead, you can create a role with access to the service. For example if you want to set up access to an EC2 instance, you would create an instance profile and assign a role to the profile with access to whatever applications you choose. Then, anything on the instance can get temporary credentials.
Taking the risk out of access keys with Sonrai
A lot of vendors can scan your cloud to locate lost access keys – and even map those keys back to their owners. But what they can’t do is tell you 1) who can get their hands on those access keys at any given moment and 2) what that person could do if they held those access keys. Access keys can be a part of a ten-step lateral movement chain that includes role assumptions, group policies, inherited access, trust relationships and more, all making it very difficult to see how a pair of access keys in development can end up accessing production data. Sonrai can see this sort of unintended access, allowing you to remediate toxic permissions with built-in policies, bot remediation, or prescriptive instructions for CLI or Console.
FAQs
What are some best practices for managing and securing access keys?
It is best practice to not have access keys assigned to your root user, to remove or delete old access keys, to rotate access keys regularly, properly secure and keep track of access keys, and instead consider using temporary access credentials.
How can I rotate, disable, or delete my access keys?
You can manage access keys within your cloud provider’s portal like AWS Management Console, from there navigate to security credentials and create, activate, deactivate or modify the key. Alternatively running CLI commands like “DeleteAccessKey.”
In what scenarios might I consider using alternatives to access keys?
If the necessary access is short-lived, consider using temporary credentials like AWS Security Token Service, which work just as access keys, but are short-term and not stored with the trusted user.
How can I mitigate risks associated with access keys?
The best way to mitigate risks associated with access keys is properly inventorying your keys, knowing their location, knowing who and what has access to them, what they could do with them, regularly scanning for lost keys, and properly securing them in services like AWS KMS or GCP Secrets Manager.
