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

91–100 of 205 posts

Re: CISA Admin Leaked AWS GovCloud Keys on GitHub

#91

Post by antonvs »

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…

> shared credentials are needed and used pretty much across all the systems but there are no good solutions for managing such use cases.

What do you mean by this? There are password managers and more enterprise-oriented secrets managers, and application platforms typically have integration with them. Individuals shouldn't be using shared secrets. This is a completely solved problem and it's not difficult to set up properly, especially in a cloud environment like AWS, where you can use services like AWS Secrets Manager.

Re: CISA Admin Leaked AWS GovCloud Keys on GitHub

#92

Post by doctoboggan »

epistasis wrote: post #37
doctoboggan wrote: post #12

Earlier quoted context omitted.

I've noticed recently that at least Claude will try its best not to read your env files. You really need to push it in the prompt if you want it to read and access your DB for example.

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.

Re: CISA Admin Leaked AWS GovCloud Keys on GitHub

#93

Post by [deleted] »

antonvs wrote: post #91
sandeepkd wrote: post #57

Earlier quoted context omitted.

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…

> shared credentials are needed and used pretty much across all the systems but there are no good solutions for managing such use cases. What do you mean by this? There are password managers and more enterprise-oriented secrets managers, and application platforms typically have integration with them. Individuals shouldn't be using shared secrets. This is a completely solved problem and it's not difficult to set up pr…

[deleted]

Re: CISA Admin Leaked AWS GovCloud Keys on GitHub

#94

Post by SV_BubbleTime »

totetsu wrote: post #26
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…

One the one hand the CISA is being gutted, and on the other hand there is an ever increase of rhetoric about cybersecurity, national interests, critical infrastructure..

[flagged]

Re: CISA Admin Leaked AWS GovCloud Keys on GitHub

#95

Post by john_strinlai »

scottyah wrote: post #90
throwaway5752 wrote: post #42

Earlier quoted context omitted.

DOGE. It's DOGE. This is just things going according to plan for people that think the US government is too powerful or that there is a fortune to be made in stealing public sector resources and privatizing them. It is a bad plan that has and will continue to harm people, but it is intentional.

[flagged]

this does not align with.. well.. anything ive read about DOGE

Re: CISA Admin Leaked AWS GovCloud Keys on GitHub

#96

Post by SV_BubbleTime »

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.

I’m not sure you can complain that the people who should prevent this type of thing are having their funding reduced what are the example is they just did this exact thing.

Re: CISA Admin Leaked AWS GovCloud Keys on GitHub

#97

Post by ceejayoz »

parineum wrote: post #89
throwaway5752 wrote: post #83

Earlier quoted context omitted.

"I didn't create the epidemic, I just fired all the doctors and dissolved the medical schools" Security doesn't happen by magic. It is enforced by process, maintained by people and systems built and run by people. Furthermore, when people are under stress and underresourced, they make more mistakes. This was inevitable given the budget cuts. You can't fire everyone at AWS and say one intern will support it, and say t…

The analogy to not posting secrets to the public isn't medical schools and doctors, it's a sign in the bathroom that says "employees must wash hands".

They replaced the people who put the signs up with people who think signs are too woke.

Re: CISA Admin Leaked AWS GovCloud Keys on GitHub

#98

Post by malcolmgreaves »

parineum wrote: post #81
skywhopper wrote: post #75

Earlier quoted context omitted.

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

I really hope they didn't also fire the "don't shit your pants" team or that office is going to smell really bad.

DOGE only fired those who were loyal to the facist. Anyone who is competent was illegally fired.

Re: CISA Admin Leaked AWS GovCloud Keys on GitHub

#100

Post by jallmann »

kittoes wrote: post #65
jallmann wrote: post #61

Earlier quoted context omitted.

> OAuth with refresh tokens. Then the LLM slurps up your refresh token. What's next?

Is that really a concern though in the same way API keys are? Since when do OAuth clients store refresh tokens in areas that LLMs regularly scan? API keys are truly passwords, while refresh tokens are exchanged for a password. Sure, a leak would be bad but I'd argue that it's orders of magnitude less likely compared to the accepted norm.

The accepted norm is, increasingly, full disk access, regardless of how bad of an idea it is. At a minimum, agents typically will have a way of obtaining new access tokens.

Refresh tokens don't solve anything in this case; they just shuffle the problem around, and introduce other complications of their own.

What you want are capability scoped credentials that are enforced on the backend. That is agnostic to credential issuance mechanism, although passkeys are the best.

Using these credentials effectively still presupposes hygiene that might not exist in a typical developer environment, eg no root credentials (or access to such) sitting anywhere. There's probably a good product and market for whoever can solve this in a low-friction way.

Post reply on HN