Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CISA Admin Leaked AWS GovCloud Keys on GitHub

krebsonsecurity.com

Post reply on HN
Print view View original

191–200 of 205 posts

Re: CISA Admin Leaked AWS GovCloud Keys on GitHub

#191

Post by sandeepkd »

acdha wrote: post #179
sandeepkd wrote: post #88

Earlier quoted context omitted.

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…

> 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. You’d use AWS Organizations so each admin authenticates using their own credentials, gets short-term credentials to access the member account for the handful of operations needing root, and audit usage. It’s not only…

great, now apply this to a 4 person startup who are just focussed to get business somehow. This is not on their radar and they would not be willing to spend money to address this either cause its not a problem that they are even aware of.

This is a tip of ice-berg, companies like openai, anthropic, perplexity, stripe, all of them have implemented their authentication and security flows in some interpreted language (python, ruby, typescript) cause that was the readily available talent on their product teams and most likely a good number of them do not even have their dependencies locked in.

Re: CISA Admin Leaked AWS GovCloud Keys on GitHub

#192

Post by protastus »

andrewflnr wrote: post #169
protastus wrote: post #149

Earlier quoted context omitted.

When negligence is so bad that it looks like sabotage from a hostile agent, then criminal investigations are needed to learn more about the people who did it, the others who enabled it, and deter similar future acts. DOGE did a lot of bad things, but it didn't force anyone to commit credentials to a repo, disable scanners to get away with it, and then make the repo public.

> When negligence is so bad that it looks like sabotage from a hostile agent It doesn't though. There's no actual evidence for anything beyond negligence. The "sabotage" angle is just speculation in the vain hope that surely people this stupid don't work for the US government.

We doesn't need a signed affidavit on GitHub to trigger an investigation.

This already crossed the line of reasonable suspicion. The investigation is where evidence gets collected.

Who knows what other improper behavior these people have engaged in and what other secrets they have leaked, intentionally or by side effect.

Re: CISA Admin Leaked AWS GovCloud Keys on GitHub

#194

Post by raxxorraxor »

nrub wrote: post #28
epistasis wrote: post #4

I think one thing that people are sleeping on is passing a ton of secrets to OpenAI and Anthropic or your OpenRouter by having a .env or secrets on disk in your repo, but not checked in Your LLM will happily read the entire file, ship it off to be training data for future versions of ChatGPT, and not raise any flags, because let's be fair it was on ok thing to check if all the env vars were set, or it you had set up…

I no longer keep my dotenv files in plaintext. I use `sops` to keep an encrypted env around and you can use tools like direnv to make them available to your shell while you're working. Obviously the LLM could print any of these secrets, but it's less likely. Additionally I find that at least claude seems to avoid reading the dotenv. And lastly, don't make any local secrets that important. Limited scope, dev accounts,…

Tools like cursor make typical files like .env inaccessible to models. Now the models have become quite apt to just extract the content through the console.

Re: CISA Admin Leaked AWS GovCloud Keys on GitHub

#195

Post by acdha »

sandeepkd wrote: post #191
acdha wrote: post #179

Earlier quoted context omitted.

> 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. You’d use AWS Organizations so each admin authenticates using their own credentials, gets short-term credentials to access the member account for the handful of operations needing root, and audit usage. It’s not only…

great, now apply this to a 4 person startup who are just focussed to get business somehow. This is not on their radar and they would not be willing to spend money to address this either cause its not a problem that they are even aware of. This is a tip of ice-berg, companies like openai, anthropic, perplexity, stripe, all of them have implemented their authentication and security flows in some interpreted language (p…

That’s a pretty different scenario than we’re taking here, but it still doesn’t salvage your previous comment. Those people could still use one of the password managers which support this, which again would be easier than what this guy did.

Re: CISA Admin Leaked AWS GovCloud Keys on GitHub

#196

Post by stackedinserter »

ceejayoz wrote: post #154
stackedinserter wrote: post #150

Earlier quoted context omitted.

[flagged]

We can know, and we do know. https://techcrunch.com/2025/03/11/doge-axes-cisa-red-team-st... > Elon Musk’s Department of Government Efficiency (DOGE) has fired more than a hundred employees working for the U.S. government’s cybersecurity agency CISA, including “red team” staffers, two people affected by the layoffs told TechCrunch. https://www.nytimes.com/2025/04/05/us/politics/trump-loomer-... > For four years, [Tru…

[flagged]

Re: CISA Admin Leaked AWS GovCloud Keys on GitHub

#197

Post by doginasuit »

EdwardDiego wrote: post #135
passive wrote: post #78

Uh, so it says this dates from Nov 2025. Nov 2025 was also when most of us learned about the acting Chief Security Officer at DHS, whose name AND photo seem exactly like the calling card of someone who had these "keys to the kingdom". https://bsky.app/profile/andylevy.net/post/3m6ivhnthts2o I want to believe...

I wanna be whoring? Come on, no way that's real. Also, she looks like she was generated in the character creator from Oblivion.

It is real:

https://www.yahoo.com/news/articles/fact-check-iwona-b-horyn...

Re: CISA Admin Leaked AWS GovCloud Keys on GitHub

#198

Post by jcattle »

array_key_first wrote: post #183
SV_BubbleTime wrote: post #94

Earlier quoted context omitted.

[flagged]

Gutting doesn't magically solve incompetence. It's a anti-solultion that people peddle because it requires literally zero thought or nuance. If an organization has systemic incompetence and you gut them, then they're still incompetent but now they're also pressured and therefore more likely to make mistakes. So, you're just in a worse position.

On the contrary you can argue that gutting should lead to lower number of mistakes/incompetence.

There can't be any mistakes if no work is being done.

Re: CISA Admin Leaked AWS GovCloud Keys on GitHub

#199

Post by antonvs »

sandeepkd wrote: post #109
antonvs wrote: post #101

Earlier quoted context omitted.

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. Tha…

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…

> In case of anything going wrong, all your regular user accounts would be locked

You're talking about a very specific and rare scenario, and certainly not something that justifies storing all your passwords in plaintext in a CSV file.

In almost all scenarios where you would need root credentials, having them in the provider's secret manager is fine.

Obviously you need to store root credentials outside of the secret manager as well, but that should be a "break glass" scenario that's only used in emergencies. And you don't store them in plaintext CSV.

> Unfortunately this is the gap between theory and implementation.

I don't disagree that there are many, many organizations that practice bad security. But that doesn't mean there are none that have good security. And one would expect CISA to have good security, otherwise there's really no point in its existence.

There's a difference between saying "this is what most organizations are like" and "this is the way it has to be". The former is true, the latter is false.

Re: CISA Admin Leaked AWS GovCloud Keys on GitHub

#200

Post by sandeepkd »

acdha wrote: post #195
sandeepkd wrote: post #191

Earlier quoted context omitted.

great, now apply this to a 4 person startup who are just focussed to get business somehow. This is not on their radar and they would not be willing to spend money to address this either cause its not a problem that they are even aware of. This is a tip of ice-berg, companies like openai, anthropic, perplexity, stripe, all of them have implemented their authentication and security flows in some interpreted language (p…

That’s a pretty different scenario than we’re taking here, but it still doesn’t salvage your previous comment. Those people could still use one of the password managers which support this, which again would be easier than what this guy did.

I am not trying to find an excuse when something is clearly wrong, what I am trying to share is how we ended up in a particular situation. The scenario is not much different, the rationale is that security (secure practices) are not the part of the product offering for most products/contracts. I have lost quite a few battles to management for security, it does helps me to understand how people think and priortize. People don't care for what they do not understand.
Post reply on HN