131–140 of 191 posts
> This is one of the frustrating realities of these attacks: once the malware runs, identifying the source becomes extremely difficult. The package doesn't announce itself. The pnpm install completes successfully. Everything looks normal. Sounds like there’s no EDR running on the dev machines? You should have more to investigate if Sentinel One/CrowdStrike/etc were running.
> Running npm install is not negligence. I beg to differ and look forward to running my own fiefdom where interpreter/JIT languages are banned in all forms.
It has nothing to do with interpreters or JIT, it has nothing to do with npm at all. All package managers have the insane security model of "arbitrary code execution with no constraints".
>All package managers have the insane security model of "arbitrary code execution with no constraints".
Not all of them, just the most popular ones for these highly sophisticated, well thought-out bunch of absolute languages.
The approach the attacker took makes little sense to me, perhaps someone else has an explanation for it? At first they monitored what's going on and then silently exfiltrated credentials and private repos. Makes sense so far. But then why make so much noise with trying to force push repositories? It's Git, surely there's a clone of nearly everything on most dev machines etc.
Earlier 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…
> 1. You don’t have any access keys in plain text That's not correct. The (ephemeral) keys are still available. Just do `aws configure export-credentials --profile ` Sure, they'll likely expire in 1-24 hours, but that can be more than enough for the attacker. You also can try to limit the impact of the credentials by adding IP restrictions to the assumed role, but then the attacker can just proxy their requests throu…
That’s not on the file system though. Which is the point I’m directly addressing.
I did also say there are other ways to pull those keys and how this isn’t completely solution. But it’s still vastly better than having those keys in clear text on the file system.
Arguing that there are other ways to circumvent security policies is a lousy excuse to remove security policies that directly protect you against known attacks seen in the wild.
> Sure, they'll likely expire in 1-24 hours, but that can be more than enough for the attacker.
It depends on the attacker, but yes, in some situations that might be more than long enough. Which is while I would strongly recommend people don’t set their OIDC creds to 24 hours. 8 hours is usually long enough, shorter should be required if you’re working on sensitive/high profile systems. And in the case of this specific attack, 8 hours would have been sufficient given the attacker probed AWS while the German team were asleep.
But again, i do agree it’s not a complete solution. However it’s still better than hardcoded access keys in plain text saved in the file system.
> You also can try to limit the impact of the credentials by adding IP restrictions to the assumed role, but then the attacker can just proxy their requests through your machine.
In practice this never happens (attacks proxying) in the wild. But you’re right that might be another countermeasure they employ one day.
Security is definitely a game of ”cat and mouse”. But I wouldn’t suggest people use hardcoded access keys just because there are counter attacks to the OIDC approach. That would be like “throwing the baby out with the bath water.”
Earlier quoted context omitted.
> 1. You don’t have any access keys in plain text That's not correct. The (ephemeral) keys are still available. Just do `aws configure export-credentials --profile ` Sure, they'll likely expire in 1-24 hours, but that can be more than enough for the attacker. You also can try to limit the impact of the credentials by adding IP restrictions to the assumed role, but then the attacker can just proxy their requests throu…
> That's not correct. The (ephemeral) keys are still available. Just do `aws configure export-credentials --profile ` That’s not on the file system though. Which is the point I’m directly addressing. I did also say there are other ways to pull those keys and how this isn’t completely solution. But it’s still vastly better than having those keys in clear text on the file system. Arguing that there are other ways to ci…
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 usually long enough. And in the case of this specific attack, 8 hours would have been sufficient given the attacker probed AWS while the German team were asleep.
They could have just waited a bit. 8 hours does not materially change anything, the credential is still long-lived enough.
I love SSO and OIDC but the AWS tooling for them is... not great. In particular, they have poor support for observability. A user can legitimately have multiple parallel sessions, and it's more difficult to parse the CloudTrail. And revocation is done by essentially pushing the policy to prohibit all the keys that are older than some timestamp. Static credentials are easier to manage.
> In practice this never happens (attacks proxying) in the wild. But you’re right that might be another countermeasure they employ one day.
If I remember correctly, LastPass (or was it Okta?) was hacked by an attacker spying on the RAM of the process that had credentials.
And if you look at the timeline, the attack took only minutes to do. It clearly was automated.
I tried to wargame some scenarios for hardware-based security, but I don't think it's feasible at all. If you (as a developer) have access to some AWS system, then the attacker running code on your behalf can also trivially get it.
Earlier quoted context omitted.
> 1. You don’t have any access keys in plain text That's not correct. The (ephemeral) keys are still available. Just do `aws configure export-credentials --profile ` Sure, they'll likely expire in 1-24 hours, but that can be more than enough for the attacker. You also can try to limit the impact of the credentials by adding IP restrictions to the assumed role, but then the attacker can just proxy their requests throu…
> That's not correct. The (ephemeral) keys are still available. Just do `aws configure export-credentials --profile ` That’s not on the file system though. Which is the point I’m directly addressing. I did also say there are other ways to pull those keys and how this isn’t completely solution. But it’s still vastly better than having those keys in clear text on the file system. Arguing that there are other ways to ci…
Login then check your .aws/login/cache folder.
Earlier quoted context omitted.
> That's not correct. The (ephemeral) keys are still available. Just do `aws configure export-credentials --profile ` That’s not on the file system though. Which is the point I’m directly addressing. I did also say there are other ways to pull those keys and how this isn’t completely solution. But it’s still vastly better than having those keys in clear text on the file system. Arguing that there are other ways to ci…
They are on the filesystem though. Login then check your .aws/login/cache folder.
>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…
> No, your security failure is that you use a package manager that allows third-parties push arbitrary code into your product with no oversight.
How about both? It’s conceptually straightforward to build a language in which code cannot do anything other than read its inputs, consume resources, and produce correctly typed output.
This would not fully solve the supply chain problem — malicious code could produce maliciously incorrect output or exploit side channels, but the exposure would be much, much less than it is now.
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?
My SSH keys aren't on my computer: they're safely hidden on a hardware token, behind a secure element, like a Yubikey.
Devices like the Yubikey do precisely exist because computers aren't things to be trusted. So their reason for being is to offer a minimal attack surface.
When I git fetch/pull/push I just do it. But it requires me to physically use my Yubikey. It's not 100% foolproof but it's way better than having SSH keys only protected by a password.
So Git over SSH, on a Git/SSH server that supports Yubikeys.
Earlier quoted context omitted.
Or use a FIDO token to protect your SSH key, which becomes useless without the hardware token. https://wiki.archlinux.org/title/SSH_keys#FIDO/U2F That's what I do. For those of us too lazy to read the article, tl;dr: ssh-keygen -t ed25519-sk or, if your FIDO token doesn't support edwards curves: ssh-keygen -t ecdsa-sk tap the token when ssh asks for it, done. Use the ssh key as usual. OpenSSH will ask you to tap the…
Except that an attacker can modify the ssh config to enable session multiplexing with a long timeout and then piggy-back off that connection, right?
Anyway, what about the sshd server having this config line:
sshd_config MaxSessions 1