This is the first of a 4 part blog series on security issues and monitoring in AWS.
Identity and Access Management (IAM) in AWS is basically a roles and permissions management platform. You can create users and associate policies with those users. And once those users are established you get set of keys (access key and a secret key), which allow you to then interact with an AWS account.
So, it’s kind of like having a card key into the data center, and if you get into the data center, you have physical access to assets and you can do a bunch of things – in the AWS world there is no physical access to a data center therefore you can create keys and an API and you can interact with the API to do the same things that you would do in a physical environment, like physically racking servers in a data center.
Common IAM risks are associated with folks getting a hold of, for example, a set of keys that have some policy associated with them that enables an attacker to get into the environment and do some potentially risky stuff.
Following are a couple examples:
- EC2 instance creation or deletion. This is fairly common and relatively easy to do compared with the other examples. If somebody gets a hold of a set of keys that allows them to create EC2 instances in your AWS account, that’s the first thing they’re going do. There are a lot of bots out there looking for this access, and if a bot finds a set of keys that allows it to start interfacing with EC2, it’s going to spin up a bunch of instances – likely to start mining cryptocurrency.
This actually happened to Tesla, a pretty good sized company with quite a few resources to allocate to securing their infrastructure. There are many examples in the news about keys getting published to GitHub inadvertently, and there are bots out there scraping GitHub looking for access keys and the second they find them they’re in your AWS account seeing what they can do.
- Another scenario is roles that do automated things, like take RDS snapshots or EBS snapshots. The attacker might abuse the automated process to back up various resources like EBS or an RDS database.
If an attacker gets access to that role or the keys associated with it and takes snapshots of these resources, they can deploy a new RDS database based on the snapshot. And when they do that they get to reset the passwords associated with the database. So now they’ve got access to all of your data without actually having to have the passwords required on the RDS instance.
It’s the same thing with the EBS (Elastic Block Store) snapshot. If somebody is able to take a snapshot, basically of a hard drive in AWS, they can launch a new instance connected to that block store and do some interesting things with it.
For example, assuming they’re able to create an SSH key pair in your account, they could launch a new instance from the snapshot and assign their key pair to the instance, giving them full access to the data of the original instance. If they can’t create SSH keys in your account, they might try to mount the snapshot to an existing instance they can already access.
Basically this is a crafty way to work around credential control and access control. This is a technique that’s been used to actually exfiltrate data out of AWS, just by taking snapshots.
- The last example is account hijacking. One story that got some headlines a while back involved attackers getting full control of an AWS account through a set of keys. The account was compromised so thoroughly that trust in the service was eroded to the point that the company went out of business – an extreme scenario, but if someone gets that level of access in your AWS account, you can pretty well expect that they’re going to hold it for ransom.
There are other risks, like S3 bucket exposure risks, that are much easier to take advantage of. The good news is that Amazon has recently added 4 new options that allow the account owner to set a default access setting for all of an account’s S3 buckets. The new settings override existing or newly created bucket-level ACLs (access control lists) and policies.
We’re not highlighting S3 bucket exposure risks above because there were too many to choose from. In my search for specific data exfiltration issues that have occurred with S3, I came across this GitHub Repo where the well-known public breaches are organized by date.
You’ll find 25 different instances of actual breaches where somebody had leaked data from a publicly exposed S3 bucket.
It works as follows: Say somebody creates an S3 bucket, where they’ve got some process running that’s capturing some data and writing the information to a file in the bucket. Then somebody else comes along later and makes that bucket publicly readable. Or, the bucket was initially set up as publicly readable and nobody noticed it.
This kind of thing happens all the time, and there are adversaries out there just scanning S3 looking for publicly accessible buckets. And once they find the buckets they just scrape the data in them and figure out what treasures they’ve got later. They don’t even care what they’re downloading.
It’s a simple thing for them to carry out. It doesn’t require a super sophisticated attack vector. We’ll dig further into AWS security risks and what to do about them in the next blog of this series.
The post IAM and Common Abuses in AWS appeared first on Cybersecurity Insiders.
November 29, 2018 at 09:09AM
0 comments:
Post a Comment