Don’t Start Static – Mitigating Cloud API Credential Exposure
And away we go!
Here’s the first in our recently announced series on the Top 10 Cloud Attack Killchains – a set of blogs that aim to help you and your organization prevent exposure to some of the most widespread and painful security issues threatening today’s cloud deployments.
In this first installment – mirroring my recent presentation at the RSA Security Conference 2020 in San Francisco – we’ll take a closer look at what my fellow researchers and I consider to be THE most common problem found on the landscape – Static API Credential Exposure to Account Hijack.
Based on our ongoing research into AWS and Azure deployments, organizations are still having huge issues in preventing static credentials – largely in the form of Access Keys and SaaS Tokens, along with secret keys – from being shared erroneously in public. In addition to our RSA presentation, I’ve also seen a lot of traction around this topic on the popular Cloud Security Slack.
This is a big problem, of course, because these credentials are still required to manage our hybrid environments, and, once attackers gain access it’s all too simple for related campaigns to spring up and escalate.
It’s worth noting that the BIG problem here is that once credentials are spilled and find their way into nefarious hands, attackers gain the ability to carry out any API action supported by the IAM policies attached to involved users. In addition to IAM, access keys are also frequently used for purposes such as enabling AWS access for application components. And, since federation integration tends to be a point of friction within many IT departments, we see far greater proliferation of IAM users than is typically recommended.
To top it off in terms of framing associated risk, we estimate that it only takes 3-5 mins between the time when such credentials go public and are then subsequently discovered and thrown into action.
The Basic Killchain
Methods of Exposure:
As it turns out, the reality is that it is also extremely easy to make a mistake that leads to Static API Credential Exposure. I found this out the hard way a few years back when I received an email from Amazon informing me that I’d done just that when I’d left an old credential in my notes and it snuck through into production.
As a result, someone got into my environment, launched some extra-large instances and started cryptomining [FYI we’ll talk more about cryptomining specifically in a later post].
The reality is that there are a ton of ways to expose credentials – via GitHub, Bitbucket, shared images and snapshots, just to name a few. When organizations perform credential scans they typically find API Access Keys and SaaS Tokens all over the place. It’s inevitable that some get released into live code or left vulnerable by misconfiguration.
The short list of the most common scenarios includes:
- Keys embedded in application code
- Keys checked into version control because they were in a local configuration file
- Keys stored on developer and administrator systems
- Keys stored in instances or containers (and their images)
- Keys in snapshots, saved scripts, and other storage
It’s worth repeating that attackers CONTINUOUSLY scan the Internet for these potential sources.
Mitigating the Attacks:
Taking action to mitigate the impact of these exposures is simpler once you understand where it’s smartest to break the killchain and cut off related attacks.
For starters, in AWS, we have to minimize the use static credentials, like Access Keys, period. You don’t need them as much as you think. I’d suggest moving to heavier use of IAM Roles and federation.
Next, you simply MUST scan for these issues in your code repositories and your corporate GitHub, along with using static analysis tools and open source tools. After that you need to employ strong ID management hygiene to help reduce the ability for attacks to escalate.
AWS Credential Exposure Mitigation
Cloud providers are also starting to offer more support for detecting when keys show up in unusual locations. While these still suffer from false positives in dev environments [using Amazon GuardDuty as an example] they’re pretty useful for production.
Azure Credential Exposure Mitigation
The biggest difference between AWS and Azure environments is that – as noted by my RSA co-presenter Shawn Harris, Managing Principal Security Analyst and Starbucks – while in AWS attackers go for IaaS first, in Azure they tend to aim their efforts more at PaaS services.
This is driven by the fact that in Azure, there are lots of service named entities and service principal accounts – essentially where you can store account data for your services in a key vault – that make attractive targets. That said, you can also use access policies in Azure to monitor use of credentials from Azure Security Center, so that’s helpful in identifying potential attacks.
In general, I’d recommend that you follow these basic tips to prevent static cloud API credentials from falling prey to malicious intents:
- Continuously assess security and network security groups for Internet-facing ports 22 and 3389
- Avoid use of default and weak passwords
- Keep systems patched to reduce the risk of vulnerabilities
- Manage Internet exposed administrative servers
- Restrict access
As noted, there are a lot of helpful tools that can empower you to carry out related assessments.
Here at DisruptOps, we’re intently focused on enabling organizations to carry out some of these tasks at scale through the use of automation – because there’s no way that today’s organizations can keep up without dedicated capabilities to do just that.
Stay tuned for the next installment, and please, share your thoughts with us in the comments below. Have you got any related tips or war stories? We’d love to hear from you!