Live data from Hacker News

Shai-Hulud compromised a dev machine and raided GitHub org access: a post-mortem

trigger.dev

181–190 of 191 posts

Re: Shai-Hulud compromised a dev machine and raided GitHub org access: a post-mortem

#181

Earlier quoted context omitted.

If you have data events enabled for your S3 bucket, CloudTrail will log every access to that bucket along with the identity of the principal used to access it. https://docs.aws.amazon.com/awscloudtrail/latest/userguide/l...

Right and in my example it would be the principal of the service account, not the compromised AWS account. If you ran a cloud trail query that's essentially "Did Alice access user data in S3 ever?" the answer would be "No" So that brings us back to the question, what is meant by "trust CloudTrail"

Most non-trivial security investigations involve building chains of events. If SSM Session Manager was used to access the EC2 instance (as is best practice) using stolen credentials, then the investigation would connect access to the instance to the use of instance credentials to access the S3 bucket, as both events would be recorded by CloudTrail.

CloudTrail has what it has. It's not going to record accesses to EC2 instances via SSH because AWS service APIs aren't used. (That's one of the reasons why using Session Manager is recommended over SSH.) But that doesn't mean CloudTrail isn't trustworthy; it just means it's not omniscient.

Re: Shai-Hulud compromised a dev machine and raided GitHub org access: a post-mortem

#182

Earlier quoted context omitted.

> That’s not on the file system though. They are. In `~/.aws/cli/cache` and `~/.aws/sso/cache`. AWS doesn't do anything particularly secure with its keys. And none of the AWS client libraries are designed for the separation of the key material and the application code. I also don't think it's even possible to use the commonly available TPMs or Apple's Secure Enclave for hardware-assisted signatures. > 8 hours is usua…

> They are. In `~/.aws/cli/cache` and `~/.aws/sso/cache`. AWS doesn't do anything particularly secure with its keys. Thanks for the correction. That’s disappointing to read. I’d have hoped they’d have done something more secure than that. > And none of the AWS client libraries are designed for the separation of the key material and the application code. The client libraries can read from env vars too. Which isn’t per…

Agreed.

> A sufficiently advanced attack can gain access but that doesn’t mean we shouldn’t be hardening against less sophisticated attacks.

I'm a bit worried that with the advent of AI, there won't be any real difference between these two. And AI can do recon, choose the tools, and perform the attack all within a couple of minutes. It doesn't have to be perfect, after all.

I've been thinking about it, and I'm just going to give up on trying to secure the dev environments. I think it's a done deal that developers' machines are going to be compromised at some point.

For production access, I'm going to gate it behind hardware-backed 2FA with a separate git repository and build infrastructure for deployments. Read-write access will be available only via RDP/VNC through a cloud host with mandatory 2FA.

And this still won't protect against more sophisticated attackers that can just insert a sneaky code snippet that introduces a deliberate vulnerability.

Re: Shai-Hulud compromised a dev machine and raided GitHub org access: a post-mortem

#183

Earlier quoted context omitted.

> Repos are cattle not pets. What do you mean by this?

A core SRE principle is that "machines/servers are cattle, not pets". They shouldn't be special or bespoke in a way that makes replacement painful or difficult.

I've heard the term used for servers before but not version control repositories. I just don't understand what it would mean for a git repo to be a cattle vs a pet. Like what is an example of a cattle repo vs a pet repo. The metaphore just sounds like gibberish to me idk.

Unless all it means is that that you can have more than a few like the other commenter said but I didn't think that was what the metaphore meant with respect to servers so again I have no idea lol

Re: Shai-Hulud compromised a dev machine and raided GitHub org access: a post-mortem

#184

Earlier quoted context omitted.

No, you are the problem because you have a higher expectation than reality. People shouldn't have to run npm in containers. You're over simplifying with one case where you have found one solution while ignoring the identical problems elsewhere. You are preventing us from looking at other solutions because you think the one you have is enough and works for everyone.

I agree with you that I shouldn't have to treat my libraries like untrusted code. I don't know what the rest of your comment means. I don't see how I'm preventing anybody from looking at other solutions to npm, they just don't want to do it because it's hard. And I have similar criticisms for cargo as it just copies npm and inherits all of its problems. I hate that. npm has had a bad ecosystem since its inception. Th…

The problem is you're victim blaming.

  > snickerbockers > No, your security failure is that you use a package manager
  > you > It isn't victim blaming. People like you make it impossible to avoid attacks like these because you have no appetite for a better security model.
I'd wager a large portion of people with `npm` don't actually realize they have `npm`. I'd also wager that most people that know they have `npm` aren't aware of the security issues.

Under those conditions, people are not in fact making choices. These are not people "that have no appetite for a better security model". These are people who don't even know they are unsafe!

Yes, this is victim blaming. Just in the same way people blame a rape victim for what they wear. Does what you wear modify the situation? Yes. Does it cause the situation? No. We only really blame a victim if they are putting themselves directly, and knowingly, in harms way. This is not that case! This is a case where people are uninformed, both in the dangers present as well as the existence of danger.

FFS, on more than one occasion I've installed a package only to see that it bundles `npm` along with it. And I'm more diligent than most people, so I know tons of people don't know it's happening. Especially because you can't always run `which npm` to find if it is installed. But the fact is that you can do something like `brew install foo` and foo has a dependency that has a dependency that has node as a dependency.

Dependency hell is integral to the problem here! So you can go ahead and choose a package manager that doesn't allow 3rd parties to push arbitrary code and end up with a package manager that allows 3rd parties to push arbitrary code! That's even what made left-pad a thing (and don't get me started on the absurdity of using a module for this functionality!).

  > Nobody has the appetite to be held accountable for who they put their trust in
That is jut not the reality of things. In the real world nobody can read all the lines of code. It just simply isn't possible. You aren't reading everything that you're running, let alone all the dependencies and all the way down to the fucking kernel. There just isn't enough time in the day to do this within your lifetime, even if you are running a very cut down system. There's just too many lines of code!

So stop this bullshit rhetoric of "know what you're running" because it is ignoring the reality of the situation. Yes, people should do due diligence and inspect, but the reality is that this is not possible to do. Nor is it bulletproof, as it requires the reader to be omniscient themselves, or at least a security expert with years of training to even be able to spot security mistakes. Hell, if everyone (or just programmers) already had that kind of training then I'd wager 90+% of issues wouldn't even exist in the code in the first place.

So stop oversimplifying the situation because we can't even begin to talk about what needs to be done to solve things if we can't even discuss the reality of the problem.

Re: Shai-Hulud compromised a dev machine and raided GitHub org access: a post-mortem

#185
post #167

Earlier quoted context omitted.

What no appetite? I just don't like your solution. The industry needs an answer to this problem stat, and it can't be "just read the code before".

At some point you must be open to being compelled to read code you run or ship. Otherwise, if that's to hard, then I don't know what to tell you. We'll just never agree. If you find a better solution than being responsible for what you do and who you trust, I'm all for it. Until then, that's part of the job. When I was a junior, our company payed a commercial license for some of the larger libraries we used and it in…

I hope you've read every diff to every Linux kernel you've ever deployed... There's LOADS of code you've deployed I can bet a large amount of money you never read. So clearly there's solutions that solve the problem of having to read every line of every dependency you deploy. It's just that certain ecosystems are more easy to exploit so new solutions are needed. Read everything is not a solution, it's a bandaid that shows there's a problem of trust to be solved (or improved enough to discourage this wave of attacks) with a technical solution.

Re: Shai-Hulud compromised a dev machine and raided GitHub org access: a post-mortem

#186

Earlier quoted context omitted.

A core SRE principle is that "machines/servers are cattle, not pets". They shouldn't be special or bespoke in a way that makes replacement painful or difficult.

I've heard the term used for servers before but not version control repositories. I just don't understand what it would mean for a git repo to be a cattle vs a pet. Like what is an example of a cattle repo vs a pet repo. The metaphore just sounds like gibberish to me idk. Unless all it means is that that you can have more than a few like the other commenter said but I didn't think that was what the metaphore meant wi…

To me it would mean that a git repo should not have scripts, runners, etc. configured that we don't have the means to easily and readily replace. It should all be documented and understood well enough that we could kill the repo and init another at will.

Re: Shai-Hulud compromised a dev machine and raided GitHub org access: a post-mortem

#187
post #119

Earlier quoted context omitted.

> Also the OP seemingly implies credentials are stored on-filesystem in plaintext but I might be extrapolating too much there. To be fair, some tools only support a netrc file for http(s) based auth. Regardless, if you want to use git via http this vector exists almost always.

Serious question: what tools only support netrc for authentication? I'm aware of lots of tools that (unfortunately IMO) support netrc as a source of credentials, but I can't think of a single one that requires it.

Afaik, nix for https-based git(hub/lab/...) repositories and http-auth protected resources (via fetchurl and friends).

Re: Shai-Hulud compromised a dev machine and raided GitHub org access: a post-mortem

#188

"The simultaneous activity from US and India confirmed we were dealing with a single attacker using multiple VPNs or servers, not separate actors." Did it really? It's not clear to me why the possibility that the exfiltrated credentials were shared with other actors, each acting independently, is ruled out.

Yeah, that claim makes no sense by itself, and I found it contradictory as one actor accessing repos over two vpns at the same time seems unlikely.

I think if you look at all the actions, and see that they don't overlap, then it might make sense.

If access was: Location: Repo USA: 1,2,3,4 India: 5,6,7,8

The it is reasonable to assume that the access was from that same actor, as it is coordinated in some way.

Re: Shai-Hulud compromised a dev machine and raided GitHub org access: a post-mortem

#189
post #3

I have been thinking about this. How do I make my git setup on my laptop secure? Currently, I have my ssh key on the laptop, so if I want to push, I just use git push. And I have admin credentials for the org. How do I make it more secure?

You can use split-ssh on Qubes OS, such that your development environment won't have the access to your private keys: https://forum.qubes-os.org/t/split-ssh/19060

Re: Shai-Hulud compromised a dev machine and raided GitHub org access: a post-mortem

#190

Earlier quoted context omitted.

I agree with you that I shouldn't have to treat my libraries like untrusted code. I don't know what the rest of your comment means. I don't see how I'm preventing anybody from looking at other solutions to npm, they just don't want to do it because it's hard. And I have similar criticisms for cargo as it just copies npm and inherits all of its problems. I hate that. npm has had a bad ecosystem since its inception. Th…

The problem is you're victim blaming. > snickerbockers > No, your security failure is that you use a package manager > you > It isn't victim blaming. People like you make it impossible to avoid attacks like these because you have no appetite for a better security model. I'd wager a large portion of people with `npm` don't actually realize they have `npm`. I'd also wager that most people that know they have `npm` aren…

It's cute that you truncated the most important part of the other commenter's message; "your security failure is that you use a package manager [that allows third-parties push arbitrary code into your product with no oversight]."

> I'd wager a large portion of people with `npm` don't actually realize they have `npm`.

Recklessness is not a defense.

> But the fact is that you can do something like `brew install foo` and foo has a dependency that has a dependency that has node as a dependency.

That's good to know. I've never looked at brew and wasn't planing on using it, but I will stay away from it in the future. It sounds like you learned your lesson though, right?

Because if you haven't, that sounds like negligence. You can't be unaccountable for your actions by admitting that you did not expect those outcomes when you did not do your due diligence. And if you don't hold yourself accountable, then you sure aren't about to hold others accountable either. So your whole ecosystem is screwed.

> Yes, this is victim blaming. Just in the same way people blame a rape victim for what they wear.

Not even remotely. I can say and it's bad for people to abuse exploits and they don't deserve that. At the same time, if I put my private key without a passphrase into the public, or commit secrets to git and share them with the public, I am being negligent.

You are leaving your car unlocked with the windows rolled down in a dodgy part of town overnight. And when it's gone/pilfered in the morning, it's completely fair to say that you did a stupid thing.

We can say that is negligent without saying that you deserved it or that it ought to have happened. And it's absolutely okay for me, or anybody else, to say that you should have known better, without you comparing me to a rape apologist.

> In the real world nobody can read all the lines of code. There's just too many lines of code!

I don't know why you went on that rant when you quoted me talking about "trust". I wouldn't need trust if I could fully understand everything about every machine I use and only rely on myself.

> So stop this bullshit rhetoric of "know what you're running" because it is ignoring the reality of the situation.

Naw, it isn't. I trust packages from my operating system's package manager. The issues we see with left-pad and shai-hulud, have never and will never happen to me using those packages because they simply do not accept the kinds of garbage people put up on npm, or brew apparently as you pointed out.

I avoid running stuff like on-my-zsh because I don't have the patience to audit that and I certainly don't want to run untrusted stuff in my shell as root. But it's a very popular package because people, like you, have a greater risk tolerance. And that's fine, as long as you accept the consequences of that risk tolerance. You aren't paying for support or liability, you aren't reading the code, you are putting trust in random sources and hoping that things work out.

If you want the luxury running untrusted code as root, or the luxury of leaving your car open in a dodgy part of town overnight, then maybe maybe what you want is a surveillance state, idk. There is a cost to that. A tradeoff. If that's what you want and that's your goal, then I can't stop you. But it's you could also just ... not do such risky things.

Post reply on HN