One of the “lucky” 334 downloaders here.
Is there any information if updating the package (through mise in my case) is enough for the compromise?
Or does the bitwarden cli need to actually be called for the extraction to happen?
@brauni unfortunately yes, just updating/installing the package was enough to trigger the payload. Based on the JFrog blog, it came with a preinstall script that would trigger the exploitation immediately. Look at their remediation section for how to cleanup and evaluate the fallout.
2 Likes
I’ve uninstalled the chrome extension and disabled the auto update for the native app and will rely on that for a few weeks, I’m very weary that an employee has been infected and that a phase 2 is coming on this…
We also have no idea on how the attack was perpetrated. Looking briefly at the GitHub workflows, it seems that the publish workflow is using Trusted Publishers, going through that requires write access to that repository to invoke the github workflow, on top of being able to publish a release somehow (I haven’t looked into the restrictions in place on this). Unless Bitwarden didn’t set up their NPM correctly to force Trusted Publishers which would be very sloppy.
Until I have more information into how this was possible, I’ll stay on the cautious side, and I encourage everyone to do so as well.
2 Likes
We do have some idea. From the very start, this has been reported as a supply-chain attack involving Checkmarx. And, Checkmarx confirms their involvement, so I don’t suspect the specific scenario of a compromised Bitwarden employee.
Given how quickly this was detected and mitigated, I do feel that Bitwarden has a competent incident response team/processes. Hopefully they have taken defensive actions, such as pausing CI/CD until such time as they can either regain confidence in Checkmarx, or removed them from the workflow.
Doing similar by pausing updates at the end-user level does seem a reasonable reaction, but if one does so, don’t forget to reverse the pause to avoid the risk of exceeding backward-compatibility. Since this threat appears to be directed at the npm ecosystem, pausing desktop, browser extensions, and mobile apps might not be indicated.
Meanwhile, you might consider voting for the feature request to skip/postpone updates so that there is an easy, consistent way to react to threats like the current one.
1 Like
This can be called a Checkmarx worm. A developer installs the worm via an npm update; it lifts all the tokens/keys as described in the mitigation steps in the OP, then propagates to another repository, and so on. As long as the tokens and keys are still valid, they are compromised. The good news is that the post-infection mitigations have already been spelled out. The questions are: how many machines/people have been infected? How long have those tokens/keys been compromised? Is there anything else not spelled out?
Bitwarden responded within a couple of hours, which might mean that either Bitwarden (implied by the OP) or the outside researcher ran scanning tools on the releases. They didn’t catch it in the workflow, but they caught it in the release. It would be another 11½ hours before JFrog’s post on X after the malicious package had been yanked. It’s no good for the 300+ tech people (and companies) who downloaded it, but it seems an unusually fast response time for a successful supply-chain attack.
Given the unknowns about what humans behind keyboards could have done with those tokens and keys, pausing updates also seems reasonable to me.
This commenter on Github speculates that the exploit may have involved a compromised employee account (and specifically calls out a specific employee as the likely victim):*
* The speculation referenced above turns out to have been unfounded, as clarified in the follow-up information posted here and here.
A post was split to a new topic: Safety of passkeys stored in Bitwarden if there is a passsword-stealing / info-stealer’s breach
Hi, I just replied in the GitHub issue thread. My account was not compromised. The workflow run referenced was due to reinstating the malicious actor’s branch temporarily which triggered the run.
4 Likes
@vgrassia Thanks for confirming this!
2 Likes
I think It is too soon to know if vaults or passwords were in fact compromised despite the “official” statement from Bitwarden.
Corporate legal speak is infuriating. I was one of many affected by another breach where the corporation was dismissive of the impact. They worded the statement in a positive way, stating that while usernames and passwords for bank and credit card accounts were never compromised, only Social Security numbers and other identifiable information were stolen. They effectively left it at that. I expect such a response from companies that develop password managers, and LastPass has had its share, but not from financial institutions.
This trend is common now. I recall Yahoo downgrading account storage and wording it in such a way that it a revolutionary benefit.
I’ve become jaded. Corporate talk about privacy and security is largely performative. It’s just security theater where companies go through the motions because they don’t actually care about protecting our data. It’s more about legal liability. Even then, depending on where you reside, payouts are puny where lawyers and their law firms get the benefit not those impacted
You don’t have to to rely on statements from Bitwarden. Two independent security research firms analyzed the malware payload, and found that the malicious code was designed to steal a number of credentials from a number of sources, none of which included the Bitwarden Password Manager vault of the infected user:
4 Likes
Is it really necessary to uninstall the Chrome extension? That didn’t seem to be affected. Seems a little extreme unless I’m missing something.
Here’s a comment from mandreko (BW) on reddit:
The attack did not come from a Checkmarx Actions dependency in the pipeline. It came from a malicious VSCode extension (from Checkmarx) on an engineers system.
The VS Code extension attack was announced by Checkmarx on April 22. That seems pretty tough to work around, except (at least) for the @loginatnine’s “drastic” step of removing (and/or pausing updates) any affected vendors as suggested above.
I’m leaning on the cautious side here. Bitwarden is obviously critical for a lot of us and these supply chain sometimes have multiple attack waves. We cannot be 100% sure that other critical credentials from Bitwarden hasn’t leaked to attackers here and they might go undercover for a while for the next round.
This is all conjecture let me be clear, but just like it’s a good idea to do a cooldown before updating dependencies in your software projects, I’m doing the same thing here. It does not cost much and will provide me a bit of piece of mind around this.
1 Like
A post was split to a new topic: Told by my company that password has been exposed on the site Bitwarden.com. Another incident?
Any updates?
A compromise in the software delivery chain is the worst case scenario for a password manager. So, before I pay for the new increased price, I need Bitwarden to post a full post-mortem analysis of the problem and what measures are they taking to prevent this kind of issue to happen again.