7 ms·
AWS Built a Security Tool. It Introduced a Security Risk
- oldpersonintx 1y ago[dead]
- bulatb 1y agoSomeone invented the two-sentence clickline. Now even blogs do it.
- dangus 1y agoAs an AWS-focused practitioner, I started doing Google Cloud training and it blew my mind when I found out that the multiple account sub-account mess that AWS continues to use just doesn’t exist there. GCP sensibly uses a folder and project system that provides a lot of flexibility and IAM control. It also blew my mind that Google Cloud VPCs and autoscaling groups are global, so that you don’t have to jump through hoops and use the Global Accelerator service to architect a global application. After learning just those two things I’m downright shocked that Google is still in 3rd place in this market. AWS could really use a refactor at this point.
- thinkindie 1y agoI think Google scares a lot of people away with their approach of not being able to talk to any human whatsoever unless you spend a lot of money on a monthly basis. I read a lot of horror stories of people getting in troubles with GCP and not being able to talk to a human person, whereas you would get access to some human presence with AWS. Things might have been changed, but I guess a lot of people have still this in the back of their mind.
- phinnaeus 1y agoI’m scared of Google realising that maintaining a given cloud product just isn’t fun anymore and sending it to the Google graveyard.
- MortyWaves 1y agoOr sell it off to nefarious companies like SquareSpace
- stackskipton 1y agoLike IoT service? I had friends working in that field that scrambled for a year when that happened and they will never touch Google Cloud again.
- Xunjin 1y agoAhhhh it wasn't nice, but we at Echo54[0] had a plan/execution (6 months before the due date) to migrate to RabbitMQ (with MQTT Plugin) works way better and cheaper than GCP IoT service. We did all of that in less than 2 months. 0. https://www.echo54.com/ https://www.echo54.com/
- thinkindie 1y agotrue that too
- bigstrat2003 1y agoYeah I think anyone who chooses to do business with Google at this point is taking a needless risk. I wouldn't trust them to continue to provide anything except perhaps the ad business.
- placardloop 1y agoThis so called “security risk” is a role in a nonprod that can list metadata about things in your production accounts. It can list secret names, list bucket names, list policy names, and similar. Listing metadata is hardly a security issue. The entire reason these List* APIs are distinct from Get* APIs is that they don’t give you access to the object itself, just metadata. And if you’re storing secret information in your bucket names, you have bigger problems.
- philipwhiuk 1y agoAt the end of the day if you deploy a tool that can access production data, you need to treat it like production. That's the reality here.
- placardloop 1y agoNo, that’s not the reality. “Production data” isn’t as black and white as that. Metadata about your account, regardless of if you call it “production” or not, is not guaranteed to be treated with the same level of sensitivity as other data. Your threat model should assume that things like bucket names, role names, and other metadata are already known by attackers (and in fact, most are, since many role names managed by AWS have default names common across accounts).
- EliavLivneh 1y agoHey, author of the blog here :) Just wanted to point out that it is not just names of objects in sensitive accounts exposed here - as I wrote, the spoke roles also have iam:ListRoles and iam:ListPolicies, which is IMO much more sensitive than just object names. These contain a whole lot of information about who is allowed to do what, and can point at serious misconfigurations that can then be exploited onwards (e.g. misconfigured role trust policies, or knowing about over-privileged roles to target).
- placardloop 1y agoListPolicies does not show the contents of policies, so the information you mentioned isn’t possible to obtain from there. Things like GetKeyPolicy do, but as I mentioned in my comments already, the contents of policies are not sensitive information, and your security model should assume they are already known by would-be attackers. “My trust policy has a vulnerability in it but I’m safe because the attacker can’t read my policy to find out” is security by obscurity. And chances are, they do know about it, because you need to account for default policies or internal actors who have access to your code base anyway (and you are using IaC, right?) You’re right to raise awareness about this because it is good to know about, but your blog hyperbolizes the severity of this. This world of “every blog post is a MAJOR security vulnerability” is causing the industry to think of security researchers as the boy who cried wolf.
- ahoka 1y agoThe link is ironically blocked by my companies security suite.
- MortyWaves 1y agoBlocking pseudo-“security research” like this one is probably a safe bet.
- abhisek 1y agoIAM is complex. More so with federation and cross account trust. Not sure every weakness can be considered as a vulnerability. In this case, I was looking for a threat model within which this is a vulnerability but unable to find so.
- jonfw 1y agoThe security industry, unfortunately, is awash with best practice violations masquerading as vulnerabilities
- yfiapo 1y agoI agree this was a security concern and it was reported and addressed appropriately. With that said as things go this is pretty minor; perhaps a medium severity issue. Information disclosures like this may be leveraged by attackers with existing access to the lower environment, in conjunction with other issues, to escalate their privileges. By itself, or without the existing access, it is not usable. More over, the issue wasn’t that AWS recommended or automatically setup the environment insecurely. Their documentation simply left the commonly known best practice of disallowing trusts from lower to prod environments implicit, rather than explicitly recommending users follow that best practice in using the solution. I don’t think over-hyping smaller issues, handled appropriately, helps anyone.
- liquidpele 1y agoSounds like typical hyperbole. Worked at a place once where some “security researcher” trashed the product because they could do bad things on the appliance… if logged in as root.
- deleted 1y ago[deleted]
- MikeIndyson 1y agoDepends on your implementation, you should not store sensitive data in metadata
- swisniewski 1y agoThe article is bullshit. AWS has a pretty simple model: when you split things into multiple accounts those accounts are 100% separate from each other (+/- provisioning capabilities from the root account). The only way cross account stuff happens is if you explicitly configure resources in one account to allow access from another account. If you want to create different subsets of accounts under your org with rules that say subset a (prod) shouldn’t be accessed by another subset (dev), then the onus for enforcing those rules are on you. Those are YOUR abstractions, not AwS abstractions. To them, it’s all prod. Your “prod” accounts and your “dev” account all have the same prod slas and the same prod security requirements. The article talks about specific text in the AWS instructions: “Hub stack - Deploy to any member account in your AWS Organization except the Organizations management account." They label this as a “major security risk” because the instructions didn’t say “make sure that your hub account doesn’t have any security vulnerabilities in it”. AWS shouldn’t have to tell you that, and calling it a major security risk is dumb. Finally, the access given is to be able to enumerate the names (and other minor metadata) of various resources and the contents of IAM policies. None of those things are secret, and every dev should have access to them anyways. If you are using IAC, like terraform, all this data will be checked into GitHub and accessible by all devs. Making it available from the dev account is not a big deal. Yes, it’s ok for devs to know the names of IAM roles and the names of encryption key aliases, and the contents of IAM policies. This isn’t even an information disclosure vulnerability . It’s certainly not a “major risk”, and is definitely not a case of “an AWS cross account security tool introducing a cross account security risk”. This was, at best, a mistake by an engineer that deployed something to “dev” that maybe should have been in “prod” (or even better in a “security tool” environment). But the actual impact here is tiny. The set of people with dev access should be limited to your devs, who should have access to source control, which should have all this data in it anyways. Presumably dev doesn’t require multiple approvals for a human to assume a role, and probably doesn’t require a bastion (and prod might have those controls), so perhaps someone who compromises a dev machine could get some Prod metadata. However someone who compromises a dev machine also has access to source control, so they could get all this metadata anyways. The article is just sensationalism.
- atoav 1y agoA fundamental problem that plagues many security solutions can be understood by analogy: Imagine a incredibly secure castle. There are thick unclimbable walls, moats, trap rooms, everything compartmentalized, an attacker that gains control of one section didn't achieve much in terms of the whole castle, the men in each section are carefully vetted and are not allowed to have contact or family relationships with men stationed in other sections, so they cannot be easily bribed or forced to open doors. Everything is fine. But the king is furious, the attackers shouldn't control any part of the castle! As a matter of principle! The architects reassure the king that everything is fine and there is no need to worry. The king is unconvinced, fires them and searches for architects that do his bidding. So the newlyfound architects scramble together and come up with secret hallways and tunnels, connecting all parts of the castle so the defenders can clear the building in each section. The special guards who are in charge of that get high priviledges, so they could even fight attackers who reach the kings bed room. The guard is also tasked to keep in touch with the attackers so they are extra prepared for when they attack and understand their mindset inside out. The king is pleased, the castle is safe. One night one of those guards turns against the king and the attackers are sneaked into the castle. The enemy is suddenly everywhere and they kill the king. A battle that should have been fought in stages going inwards is now fought from the inside out and the defenders are suddenly trapped in the places that were meant for the very enemies they are fighting. The kingdom has fallen. The problem with many security solutions – including AV solutions – is that you give the part of your system that comes into contact with the "enemy" the keys to your kingdom, usually with full unchecked priviledges (how else to read everything that is going on in the system). Actual security is the result of strict compartmentalization and a careful and continous vetting of how each section can be abused and leveraged once it has fallen. Just like in mechanical engineering where each new moving part can add a new failure point, in security adding a new priviledged thing adds a lot of new attack surface that wasn't previously there. And if that attack surface gives you the keys to the kingdom it isn't the security solution, it is the target.
- jiggawatts 1y agoThe difference here is that A/V scanning and security vulnerability scanning can be done from the “outside” using read only privileges. Many clouds now support scans of snapshots, removing the need for direct access to the read/write internals of a workload. This is where your analogy falls flat a bit.
- gitroom 1y agoMan, this got me thinking hard about where the line really is for what counts as a real risk versus hype. Everyone draws it different. you ever catch yourself worrying too much about stuff that probably isn't even a threat?
- 18172828286177 1y agoThis is just incompetence on the part of the person deploying this solution. Just because AWS say “don’t deploy to management account” doesn’t mean you should a deploy something with access to all your accounts into a dev account.
- tasuki 1y agoWithout reading this article: of course! Most "security tools" introduce security risks. An antivirus is usually a backdoor to your computer. So are various "endpoint protection" tools. The whole security industry is a sham.
- ben-dh-kim 1y agoThis can be a sensitive issue for organisations of a certain size. Depending on how widespread and complex the trust relationship is, it may or may not be a threat. But I think one of the points that everyone is questioning is how the first attack vector can be initiated. I agree with what you're saying about the complexity of IAM and trust relationships in general.