CISA Admin Leaked AWS GovCloud Keys on GitHub
krebsonsecurity.com371 points by LelouBil 16 hours ago
371 points by LelouBil 16 hours ago
>Valadon said he reached out because the owner in this case wasn’t responding and the information exposed was highly sensitive.
obviously leaking the credentials itself is crazy, given that its (a contractor to) CISA, but to not respond when notified? crazy crazy.
but wait! it gets worse somehow
"“AWS-Workspace-Firefox-Passwords.csv” — listed plaintext usernames and passwords for dozens of internal CISA systems"
while i understand and sympathize with the fact that CISA is kind of being gutted, a passwords.csv with weak passwords is inexcusable incompetence. not much budget is required for a password manager.
embarrassing all around.
The word you're looking for is "gross negligence"
Sometimes I feel like it's a cover for some other org actually just wanting to steal the data and this being the excuse.
You mean like if our government was compromised at the highest levels and they wanted to undermine everything without the public realizing? Btw what happened to all the social security data that DOGE exfiltrated?
When empires collapse, it's usually not caused by a foreign power, but by negligence and corruption from within
the fact we're asking about it means the public realized
the problem is the public is dumb, at least when it comes to security, and couldn't tell you why password123 is bad
"crazy crazy" gets the same point across
Yeah, but the words gross negligence is legal for you're going to be sued for a whole lot of money.
While I agree that it should not have happened, at the same time its probably true that most people are never formally trained on security.
The real story here is a big gap in existing implementations where shared credentials are needed and used pretty much across all the systems but there are no good solutions for managing such use cases. People are naturally more sensitive about their personal secrets than something thats shared across the company/group
The real story here is a big gap in existing implementations where shared credentials are needed and used pretty much across all the systems but there are no good solutions for managing such use cases.
This strikes me as so wrong, I wonder if I’m misreading your comment. For instance, team password managers are a thing. And IT teams at many large corporations are not passing around an unsecured CSV files full of passwords.
Lets take a concrete example, suppose you have AWS root account credentials. Are you going to assign them to one individual identity or as a company you would keep them accessible to a group of admins. Its going to be the second choice almost for every big company which makes them shared credentials.
Coming to team password managers at high level, its a shared location guarded behind closed doors (probably encryption at transit and rest). They would be another set of software that every company specially small business or contractors may not be incentivized to pay for. Some one in their naivety considered Github as a safe enough place, assuming that the access is guarded which turned out to be wrong and exposed this thing.
Lastly IT teams in large corporations being secure is a myth for most part. Your root keys for the most popular CA providers were shared in plain text emails not so long ago.
This organization is using AWS apparently. They would store the root account credentials in AWS Secret Manager. That costs $0.40 per month. People in the relevant admin group would have access to them. They would log in with their individual AWS credentials in order to access the root credentials if they need that.
But, requiring AWS root credentials itself is an anti-pattern and implies an immature organization. That should not be needed for day-to-day operation.
This is all just ignorance and incompetence, nothing more.
> Lastly IT teams in large corporations being secure is a myth for most part.
This is CISA. The Cybersecurity and Infrastructure Security Agency for the United States. Security is what they're supposed to specialize in.
The only potential excuse here is that DOGE gutted them to a point that has completely compromised their capabilities. However, this situation is bad enough that it suggests that problems predated that incident.
To be honest I do not know how to respond to this, cause this plays out quite often this way and sounds pretty convincing on surface. Unfortunately this is the gap between theory and implementation. There is a reason why the ROOT credentials are called ROOT. In case of anything going wrong, all your regular user accounts would be locked, see how you lock yourself out of this circular dependency. ONE SHOULD NEVER NOT PUT THEIR ROOT CREDENTIALS IN THE SECRET MANAGER OF SAME ACCOUNT. Its a classical circular problem, compilers compiler type. For AWS itself they have this additional concept of management account that allows you to defer this problem to just one more level.
Bottomline, you can have any number of boxes to lock other boxes and put their key to bounding box, ultimately there would be one outermost box that is locked by key which is not in any box
We deleted the root credentials efter initial setup where we added mgmt iam accounts used by our automation. If we ever needed them we used the recovery process. All users and services use temporary credentials.
I made an assumption that you have federated AWS account setup. One organization management AWS account and then federated accounts under it and you are referring to deletion of deletion of ROOT credentials in the federated accounts.
Considering thats not the case, what you just did is move the goal post to a account recovery process. Question becomes who has ability to recover the account, in case its tied with email then most likely it has to be a shared email box. What you have now is a much more fragile system in case of custom domains, where whoever is controlling the email domain (DNS management capability) can take over the AWS accounts.