BitPay’s Copay Wallet was compromised – why and how did this happen? -TEISS® : Cracking Cyber Security
Information Security / BitPay’s Copay Wallet was compromised – why and how did this happen?
Sonatype’s CTO Brian Fox, talks to TEISS on how and why BitPay’s Copay wallet was compromised, why it’s new territory, and what the industry as a whole should be looking to do to secure their software supply chains to make sure it doesn’t happen again.
Is this the first instance of a malicious component, such as this, put into a bitcoin wallet? Have you seen anything else like this, and what does it mean for application security?
The pattern of intentionally injected malicious components isn’t a new one. In fact, we’ve been monitoring and talking about this trend since it first started to develop in the summer of 2017.
But this particular attack is surprising. As far as I’m aware right now, it’s the first time we’ve seen a socially engineered takeover of a project.
Previous injections have come from either typosquats or (allegedly) stolen credentials. In this case, a persistent, long game was played where the attacker submitted helpful patches to gain credibility on the dormant project and then asked to be able to publish new versions. This is textbook step 1 in “how to get involved in open source,” be helpful and submit patches.”
The actual malicious payload was itself removed just three days after the initial publication, apparently by the attacker. They published a new version without the payload, seemingly to cover their tracks, but also limiting potential impact – which, on the surface, felt counterproductive.
More came to light, however, on the afternoon of November 27th when information emerged showing the attack was designed to target Copay specifically, and not necessarily enable widespread hacks. The attack appears to be designed to patch known code used by Copay, and the event_stream component chosen as it was potentially publicly available that Copay used it.
This likely also explains why the payload was covered up after three days; the attacker may have been able to observe that the payload was delivered and therefore removed it from further distribution, to better hide their tracks. Which worked, for nearly two months.
All of these facts continue to reinforce that we aren’t dealing with people seeking to exploit already existing vulnerabilities. They are now moving beyond introducing new ones, and then opportunistically exploiting victims, all the way to selecting a specific victim and backtracking how to exploit them via the supply chain.
The majority of consumers got lucky this time because the attack was “only” on a niche bitcoin wallet platform’s website. This is, however, an escalation of the attack methodology; make no mistake about it.
Are there any immediate steps enterprises, and the industry at-large, can take to reduce the potential of these kinds of attacks?
First, the days of blindly downloading any component of unknown quality and origin should be numbered, if not completely over already.
There is no possibility to prevent the use of, or slow the adoption rate of, OSS packages being used in development. Nor would I ever want to. The momentum has been too strong for too long.
We can use as many OSS packages as we need, but we need to bear in mind the quality and security attributes of choices. This is true for all OSS packages, not just when thinking about a sophisticated attack like we saw here with event-stream,
For example, npm shared information on vulnerable package downloads from their repository last month. Within those stats, 51% of all npm package downloads had known vulnerabilities, 37% of which were known high level vulnerabilities and 11% of which were known critical vulnerabilities. If you’re using npm, you’ve likely downloaded a vulnerability.
Enterprises need to assume these things will happen and prepare for a response. They need to be able to have a definitive list of which components are being used, and in which applications.
If you can’t immediately answer – “are we affected by this?” and, if yes, “where?” then you have little chance of protecting your applications quickly enough. Unfortunately, many organisations are still unable to achieve this level of supply chain hygiene.
The standards applied to other industries haven’t yet made it over to software development. Manufacturers that failed to regulate their own quality and consumer protections saw governments step in with regulation, to protect the consumer. As these issues continue to build, we’re getting much, much closer to the tipping point with software than ever before.
I wish there was a silver bullet to “prevent” these types of malicious code injections. But, with every new type of prevention measure, someone will eventually bypass it with new advanced, persistent threats.
This is not to say prevention techniques aren’t important – but I do believe emphasis should focus on rapid identification and remediation, which in too many organisations is still lacking.