supply chain
Pretty much every developer uses some third-party libraries — with millions of developers sharing their creations with the world, leveraging existing modules to help solve your tasks is a smart use of time. But using somebody else’s code means trusting the developers of that code. BitPay, developers of the Copay cryptowallet, recently ran up against the shortcomings of using open-source third-party assets.
Copay is basically a multiplatform Bitcoin/Bitcoin Cash cryptocurrency wallet that allows users to create shared wallets. Copay is developed using JavaScript, and it relies on a lot of third-party open-source libraries.
One of those is an open-source Node.js module called event-stream. Its repository on the version control service GitHub was maintained by a developer who had lost interest in the project long ago and hadn’t really taken part in the repository’s fate in several years. So, when some other developer with little to no previous activity on GitHub approached him and asked whether he could have the admin rights to maintain the repository, the original developer gave that person access rights.
The new developer got right to work. First, the event stream library began using a module called flatmap-stream from the GitHub repository of the same developer. Then actor modified the module, adding some malicious code. Three days after the update, the said developer uploaded yet another version of flatmap-stream, this one with no malicious code — probably to hide the malicious activities.
That is how the event-stream library was compromised. It is widely used not only by BitPay, but also by many other companies. Supposedly, it remained compromised for just three days, but that was enough time for Copay’s developers, who didn’t realize it had been modified to carry a malicious payload, to include the updated version of the library in their project. The updated cryptowallet software was published on app shops and downloaded by many users.
Perhaps Copay’s developers didn’t want to invest much of their time in looking at the changes in the libraries they used. Nowadays, updating libraries that are used in a project is easily automated thanks to package management services such as npm. With npm, a developer can run a single command to update all third-party modules used in their project.
Even if the devs did take a look at the updated libraries, the malicious code would have been hard to find. Libraries used in a project can depend on other libraries (the way event-stream depended on flatmap-stream), and checking all of the dependencies can take a lot of time. In this particular case the process was additionally complicated by the fact that the flatmap-stream module was encrypted.
According to CCN, the flatmap-stream library was modified to leak private keys (basically, cryptowallet passwords) from applications relying both on event-stream and copay-dash libraries. The latter suggests that this was a targeted attack against BitPay, the creators of Copay and the authors of copay-dash. In this case, the keys would be leaked only if both libraries were used, and that would be true only in products based on Copay’s code.
According to ArsTechnica, the malicious payload allowed the malefactor to get unauthorized access to users’ wallets and transfer funds from there. The flaw was discovered and reported by a GitHub user. But before that, several versions of Copay wallets containing malicious code were distributed. BitPay eventually admitted the compromise and advised the customers who used Copay versions from 5.0.2 to 5.1.0 to upgrade to the latest version, 5.2.0. For now, no information on the number of affected users and the amount of money they’ve lost is available.
This is a classic supply-chain attack, with a malefactor compromising a third-party library used by the developers of an app. The problem here stems from the use of open-source software, which is maintained by you-never-know-who. There’s no guarantee that this software is functioning the way it was functioning several versions ago. Developers of open-source software are not to blame for that — they provide their products as-is, not guaranteeing a thing.
The tricky aspect in this case is that Copay is also open-source — and is widely used by developers of other cryptowallets. So the problem may be bigger.
Businesses making money from providing software (and especially software that is involved in transferring large amounts of money) should make sure that prior to release, their software undergoes security checks including very careful analysis with each new version of all third-party libraries used in their project.
Best practice is to take a look at the status of the repository, consider ratings from other developers, check how often the project has been updated as well as how long it’s been since the last update, and browse through the bug log. Any peculiarities may merit deeper investigation — or moving on to another module.
If something goes wrong with such a library, clients blame the company that provided the software that relies on the library, even if it’s not them but the developers of the library to blame. Of course, we do not discourage using open-source products, but we advise staying very alert and being very careful when relying on them.
Tips