One Article Review
| Source |  AlienVault Blog |
|---|---|
| Identifiant | 924125 |
| Date de publication | 2018-11-28 14:00:00 (vue: 2018-11-28 16:00:42) |
| Titre | IAM and Common Abuses in AWS |
| Texte |
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 |
| Envoyé | Oui |
| Condensat | that able about above abuse abuses access accessible account account's acls across actual actually added advantage adversaries all allocate allow allows along already amazon another api are around assets assign associate associated assuming attack attacker attackers automated aws back based basically because been block blog bot bots breaches bucket buckets bunch business but came can can’t capturing card care carry center choose comes common company compared compromised connected control could couple crafty create created creates creation credential cryptocurrency data database date default deletion deploy different dig doesn't don't downloading drive easier easy ebs ec2 elastic else enables environment eroded established even example examples examples: exfiltrate exfiltration existing expect exposed exposure extreme fairly figure file find finds first folks following follows: from full further get gets getting github giving going good got had happened happens hard has have having headlines highlighting hijacking hold iam identity inadvertently information infrastructure initially instance instances interact interesting interfacing involved issues it's it’s just key keys kind known last later launch leaked level like likely lists looking lot makes management many might mining monitoring mount much new newly news next nobody not noticed now occurred once one options organized original other out override owner pair part passwords permissions physical physically platform point policies policy potentially pretty process public publicly published quite racking ransom rds readable recently relatively repo require required reset resources risks risky role roles running same say scanning scenario scrape scraping search second secret securing security seeing series servers service set setting settings simple sized snapshot snapshots some somebody someone sophisticated specific spin ssh start store story stuff super take takes taking technique tesla that's that’s them then therefore these they're they've they’re they’ve thing things thoroughly those through time too treasures trust try used users various vector way we'll we’re well went what when where which without work works world would writing you'll your |
| Tags | |
| Stories | Tesla |
| Notes | |
| Move | 
|
L'article ne semble pas avoir été repris aprés sa publication.
L'article ne semble pas avoir été repris sur un précédent.