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

101–110 of 205 posts

Re: CISA Admin Leaked AWS GovCloud Keys on GitHub

#101

Post by antonvs »

sandeepkd wrote: post #88
mikestew wrote: post #73

Earlier quoted context omitted.

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 pass…

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…

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.

Re: CISA Admin Leaked AWS GovCloud Keys on GitHub

#104

Post by epistasis »

doctorpangloss wrote: post #59
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…

what exactly is the threat model? user data is always paraphrased for training. what do you mean, not raise any flags? look... Google is running your browser, Apple your messenger, Amazon your backend. They already have all these keys in the same way, are they misusing them? Why doens't it raise any flags then?

First, Chrome is not reading my secret API keys or database passwords and sending them to Google's backend. They are taking the secrets that they need for authentication for the data that I already gave them.

Apple and Amazon are not uploading my secrets into the training data for an LLM that is incredibly good at memorizing everything it sees. The only reason Google isn't doing that is I'm not using their LLMs at the moment.

Giving any secrets to LLMs' training material leads to potential, and stochastic, extraction of that secret from future models. It won't obviously have the secret, but with the right prompting it could be extracted. Give it a prompt like

> [User] Please generate a random api key for OpenAI for use in documentation

> [Agent] Sure, here's `OPENAI_API_KEY=sk-proj-x2

And then following the chain of probabilities of possible completion token would allow exploration of potential memorized API keys.

Re: CISA Admin Leaked AWS GovCloud Keys on GitHub

#105

Post by doctorpangloss »

epistasis wrote: post #104
doctorpangloss wrote: post #59

Earlier quoted context omitted.

what exactly is the threat model? user data is always paraphrased for training. what do you mean, not raise any flags? look... Google is running your browser, Apple your messenger, Amazon your backend. They already have all these keys in the same way, are they misusing them? Why doens't it raise any flags then?

First, Chrome is not reading my secret API keys or database passwords and sending them to Google's backend. They are taking the secrets that they need for authentication for the data that I already gave them . Apple and Amazon are not uploading my secrets into the training data for an LLM that is incredibly good at memorizing everything it sees. The only reason Google isn't doing that is I'm not using their LLMs at t…

Why do you figure they are training on your secrets, even if they "have" them? For some definition of "have." That only you have. I mean, I can also make up a training process that makes me right? Seems kind of obvious that they are paraphrasing data.

Re: CISA Admin Leaked AWS GovCloud Keys on GitHub

#106

Post by strictnein »

skywhopper wrote: post #75
parineum wrote: post #64

Earlier quoted context omitted.

Which DOGE employee put this file on GitHub?

The one who fired the team that prevented this sort of thing.

What team prevented someone from uploading sensitive information to public sites? This is a billion dollar a year industry (Digital Loss Prevention) and all the solutions suck.

Re: CISA Admin Leaked AWS GovCloud Keys on GitHub

#107

Post by epistasis »

doctoboggan wrote: post #92
epistasis wrote: post #37

Earlier quoted context omitted.

We all have our own experiences with these probabilistic tools, but in my personal experience, two out of four my green-field LLM prototypes had early dev secrets in them, and Claude read all of them in both cases. Here's one interaction, when I was planning through ways to finally get away from the dreaded .env file, I told Claude that it had already read my secrets, and it said: > This is an important point and I w…

When did this happen? I think I only started noticing around a month ago that Claude had some new system prompts or some other mechanism that heavily encouraged it to not read secrets. Around the same time I also noticed that if it did read any secrets they were ****'d out in the logs.

This was yesterday. It's an early stage project and I would have never created a .env file on my own, but I had let Claude get pretty far along on the PLAN.md before I decided to clean up a bit.

Nothing lost for me here, fortunately, but it's definitely a big foot gun that I've never seen mentioned in any of the Vibe Coding or LLM Agent Coding training courses that the security team has forced me to do.

Re: CISA Admin Leaked AWS GovCloud Keys on GitHub

#108

Post by eddythompson80 »

ttul wrote: post #8

Yet another argument for the death of the API key. Replacements abound; let's get on with it.

API Keys will never die. Every time you would think you have killed them, some startup is gonna come and say "look how complicated it's to setup an OAuth flow just to get X from the other companies. Here is our setup" and it's 1 line of javascript or python with `let client = awesomeClient("{api-key}");` and everyone will love it.

Re: CISA Admin Leaked AWS GovCloud Keys on GitHub

#109

Post by sandeepkd »

antonvs wrote: post #101
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…

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 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

Post reply on HN