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

171–180 of 205 posts

Re: CISA Admin Leaked AWS GovCloud Keys on GitHub

#171

Post by nijave »

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…

In fairness, any secrets in your .env file in your development tree shouldn't have very important secrets. They should be limited access dev secrets and any secrets that go to "production" systems like an OpenAI dev environment should be limited, where possible.

Besides leaking, it's easy to oopsie and DoS a system or send malformed requests in the course of testing and development. You don't want a surprise $1k bill cause someone was working on some test automation and accidentally sent thousands of real results in the process.

Re: CISA Admin Leaked AWS GovCloud Keys on GitHub

#172

Post by nijave »

Ironically they could have used those AWS keys to use one of the many AWS services that's more secure.

For example S3 (ideally with KMS), Parameter Store (ideally with KMS), EBS, EFS, AWS Secrets Manager, even just KMS to directly encrypt the files

Really any AWS service that supports KMS and doesn't require giving the service principal access to the key

Re: CISA Admin Leaked AWS GovCloud Keys on GitHub

#173

Post by Sohcahtoa82 »

epistasis wrote: post #168
Sohcahtoa82 wrote: post #166

Earlier quoted context omitted.

That's still not any better. If the LLM can run any code it writes itself, it can retrieve those credentials. It's just one `curl` away. If you don't let it run `curl`, but you let it run `python`, it can just run a Python script that fetches it using `requests`. Or a Node script that calls `fetch`. Point is, if creds are accessible programmatically, the LLM can and may try to retrieve them if it thinks it needs them…

Aws credentials are short lived precisely so that leaking them has a time limited blast radius. Automatic retrieval, instead of keeping them on disk, is what makes short lived credentials possible.

I'm not convinced that time-limiting the blast radius matters. It just means that malicious use of the credentials has to be automated, and that's a pretty damn low bar.

Re: CISA Admin Leaked AWS GovCloud Keys on GitHub

#174

Post by epistasis »

j0ej0ej0e wrote: post #167
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…

[Cursor appears to at least be trying...]( https://cursor.com/docs/reference/ignore-file#why-ignore-fil... ) > Cursor automatically ignores files in .gitignore ... >While Cursor blocks ignored files, complete protection isn't guaranteed due to LLM unpredictability. [Antigravity appears to just _do_, not _try_)[ https://antigravity.google/docs/strict-mode ]

I hope Cursor has better agent tools than Claude Code, because though there are fanstastic restrictions on the tools for read and write that can implement a block list per-file, the shell commands are just the Wild West for Claude.

Today I got a macOS "Allow Claude to Access Your Files" SIP alert, because Claude hadn't guessed the path for a source file and instead decided to run a `find /Users/yourusername` across my entire home directory. The filters on the find wouldn't have exposed much to Claude in this particular instance but it's absolutely ridiculous aggressive all the time in slurping up as much data as possible.

I asked in a rather, um, firm tone for it to never do an action like that and it apologized and wrote a memory, but upon inspection it only wrote the memory for that particular source directory.

After some more "firm" words it wrote a hook to prevent `find` from being overly aggressive, but any such fixes are just wack-a-mole solutions.

If anybody else figures out remote sessions like Claude can do, I'm done with Claude, I think. But until then, I'll take the weirdness.

Re: CISA Admin Leaked AWS GovCloud Keys on GitHub

#175

Post by jonnyasmar »

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…

[flagged]

Re: CISA Admin Leaked AWS GovCloud Keys on GitHub

#176

Post by sincerely »

jonnyasmar wrote: post #175
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…

[flagged]

LLM spam account

Re: CISA Admin Leaked AWS GovCloud Keys on GitHub

#177

Post by nerdsniper »

tantalor wrote: post #15
john_strinlai wrote: post #9

> 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 " w…

The word you're looking for is "gross negligence"

I think willfully not reporting this is gross negligence, but also other things.

Re: CISA Admin Leaked AWS GovCloud Keys on GitHub

#178

Post by acdha »

sandeepkd wrote: post #57
binkHN wrote: post #50

Earlier quoted context omitted.

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

None of this is true at the federal level, or at least wasn’t before the current administration. There are standards for all of this, and if you haven’t read them most are quite reasonable — I keep the NIST 800-63 reference handy anytime someone tries to say password expirations are a good idea — and there are people who are paid full time to enforce them.

Having a password list or static AWS credentials is not only a direct policy violation but also implies a number of other failures, from monitoring GitHub repo administration and secret scanning to failure to enforce policies against sharing credentials (part of everyone’s standard training), require use of phishing-proof authentication, failure to use short-term credentials, etc. One mistake can be an individual but this is a multiple-manager failure going up to the executive level.

Re: CISA Admin Leaked AWS GovCloud Keys on GitHub

#179

Post by acdha »

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…

> 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 more secure, it’s also easier:

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-ena...

Old school, you’d have a shared password in an encrypted team vault (possibly requiring x of y users to decrypt it) and two FIDO tokens locked in a safe. Again, this is rare and at a federal agency you have a physical security team with 24x7 staffing so you can say “in an emergency, one of the people on this list can get a key out of a safe in the CIO’s office”.

Re: CISA Admin Leaked AWS GovCloud Keys on GitHub

#180

Post by strbean »

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…

Plug for my buddy's project: http://agentsh.org/

Block agents from misbehaving at the OS level instead of asking them to behave.

Post reply on HN