Why Capital One isn’t the last breach involving overprivileged Machine Identities
Opinions expressed are solely my own and do not express the views or opinions of my employer
A lot has been written about the Capital One breach that was disclosed on July 19. Unsurprisingly Brian Krebs has been very active in reporting on the breach — after all if it doesn’t end up on his blog, did it actually happen?
Federal prosecutors charged a Seattle woman with stealing data from more than 100 million credit applications made with Capital One. FBI agents arrested Paige A. Thompson on suspicion of downloading nearly 30 GB of Capital One credit application data from a rented cloud data server. Capital One said the incident affected approximately 100 million Americans and included approximately 140,000 Social Security numbers and approximately 80,000 bank account numbers on US consumers.”
In a response to Senator Ron Wyden, AWS has subsequently provided a lot more detail on how the attack occurred, most notably:
“As Capital One outlined in their public announcement, the attack occurred due to a misconfiguration error at the application layer of a firewall installed by Capital One, exacerbated by permissions set by Capital One that were likely broader than intended. After gaining access through the misconfigured firewall and having broader permission to access resources, we believe a SSRF attack was used (which is one of several ways an attacker could have potentially gotten access to data once they got in through the misconfigured firewall.”
Krebs highlights more detail in a subsequent post on the overly privileged credentials assigned to the WAF:
In AWS, exactly what those credentials can be used for hinges on the permissions assigned to the resource that is requesting them. In Capital One’s case, the misconfigured WAF for whatever reason was assigned too many permissions, i.e. it was allowed to list all of the files in any buckets of data, and to read the contents of each of those files.
In the same letter to Senator Ron Wyden, AWS reiterates some great advice on creating defence in depth with multiple layers of protection and intentional redundancies. Most helpfully, AWS specifically highlights that:
Even if a customer misconfigures a resource, if the customer properly implements a “least privilege” policy, there is relatively little an actor has access to once they are authenticated — significantly diminishing the customer’s risk.
So what does this all tell us? Sadly it tells us that this is all very likely to happen again and again. Here are a couple of reasons why I believe this to be the case.
Capital One has one of the better cloud security teams — so if it can happen to them, it can happen to anyone
Capital One is widely respected as having one of the leading cloud security teams across the world. Despite having security expertise and resources that most organizations only dream about, an attacker was still able to gain access. The vulnerabilities exploited weren’t zero-day or techniques developed by advanced persistent threats. Human error resulted in the application firewall misconfiguration and overly permissive identities including cloud identities is unfortunately very common.
Cloud Service Provider managed policies can get you into trouble
You might wonder how easily this can happen? Well here is a great example of how CSP managed policies (i.e. default roles provided by the CSP) can get you into trouble without much effort on your part.
Amazon publishes a number of standard IAM Managed Policies intended to help customers quickly get access to resources within their AWS accounts. Sounds perfect for an organization new to the cloud, right?
Sadly not in all cases — Without the proper understanding of how AWS IAM policies work and ongoing review of the managed policies details, I think it is almost inevitable that they will result in overprivileged identities and resources.
For example, what’s the difference between ReadOnlyAccess and ViewOnlyAccess? Can’t be that important right? Well — ViewOnlyAccess allows the console user to view lists of resources and get at certain metadata without actually granting access to the data on the resources, while ReadOnlyAccess also provides broad read access to data resources (S3 objects, DynamoDB items, etc) — or all the data you’ve stored in the cloud.
Multi-cloud = multi-cloud attack surface
Multi-cloud is here to stay. According to Gartner, “By 2020, 75 percent of organizations will have deployed a multicloud or hybrid cloud model.” A further study from IDC indicates that already over half of public cloud infrastructure-as-a-service (IaaS) users have multiple IaaS providers.
Multi-cloud means increased complexity and interconnectivity between the multi-cloud, increased attack surface to defend, and unsurprisingly an extra truck load of identities to manage.
DevOps speed meets least privilege
The standard security advice for granting least privilege (i.e. granting only the permissions required to perform the required task) is great advice, but is increasingly difficult to get right (You can read through my previous article on least privilege here), particularly when building an application or application pipeline on cloud infrastructure for the first time.
It’s typically a slow exhausting process of trial and errors to determine what privileges (at a granular level) are required for a specific identity (human or machine identity: service accounts, bots, API keys etc.) to do what it needs to do on which resources once in the production. Even with significant analysis and thought, it’s seldom that least privileges get designed right without breaking the application being built or providing too much privilege.
In most organizations, the more common (easier?) solution is simply to be overly permissive with the intent to sort it out later, which never happens.
Some of the more sophisticated cloud native companies (e.g. Netflix) are using automation to reduce privileges over time based on activity of the identities, which is a great approach. There are even commercial tools being built to do the analysis over time and right size permissions based on what permissions are being used. CloudKnox.io (disclaimer: founded by a good friend of mine even though we support different cricket teams) is a company doing exactly this.
The companies that adopt these approaches to reduce least privilege continuously will undoubtably significantly reduce cyber risk as a result; and hopefully similarly reduce the chances of ending up as the next victim of overprivileged machine identities. Hopefully none of my readers end up as the subject of a Brian Krebs blog.