Hacker backdoors widely used open-source software to steal Bitcoin




A hacker or hackers sneaked a backdoor into a widely used open-source code library with the aim of surreptitiously stealing funds stored in bitcoin wallets, software developers said Monday.

The malicious code was inserted in two stages into event-stream, a code library with 2 million downloads that’s used by Fortune 500 companies and small startups alike. In stage one, version 3.3.6 published on September 8 included a benign module known as flat-stream. Stage two was implemented on October 5 when flat-steam was updated to include malicious code that attempted to steal Bitcoin wallets and transfer their balances to a server located in Kuala Lumpur. The backdoor came to light last Tuesday with this report from Github user Ayrton Sparling. Officials with the NPM, the open-source project manager that hosted event-stream, didn’t issue an advisory until Monday, six days later.

NPM officials said the malicious code was designed to target people using a Bitcoin wallet developed by Copay, a company that incorporated event-stream into its app. This release from earlier this month shows Copay updating its code to refer to flat-stream, but a Copay official said in a Github discussion that the malicious code was never deployed in any platforms.

Copay removed the reference to the malicious flat-stream module after the attack came to light on Monday. It is contacting copay-dash, another developer that uses the same open-source code in its wallet app.

“This compromise was not targeting module developers in general or really even developers,” an NPM official told Ars in an email. “It targeted a select few developers at a company, Copay, that had a very specific development environment set up. Even then, the payload itself didn’t run on those developers’ computers; rather, it would be packaged into a consumer-facing app when the developers built a release. The goal was to steal Bitcoin from this application’s end users.”

Supply-chain attacks abound

According to the Github discussion that exposed the backdoor, the longtime event-stream developer no longer had time to provide updates. So several months ago he accepted the help of an unknown developer. The new developer took care to keep the backdoor from being discovered. Besides being gradually implemented in stages, it also narrowly targeted only the Copay wallet app. The malicious code was also hard to spot, because the flat-stream module was encrypted.

The attack is the latest to exploit weaknesses in a widely used supply chain to target downstream end users. Last month, two supply-side attacks came to light in a single week. One targeted VestaCP, a control-panel interface that system administrators use to manage servers. The attackers then modified an installer that was available on VestaCP’s website.

The second supply-chain attack slipped a malicious package into PyPI, the official repository for the widely used Python programming language. The PyPI event came two years after a college student’s bachelor thesis used a similar technique to get an unauthorized Python module executed more than 45,000 times on more than 17,000 separate domains. Some belonged to US governmental and military organizations.

The supply-chain attacks show one of the weaknesses of open-source code. Because of its openness and the lack of funds of many of its hobbyist developers and users, open-source code can be subject to malicious modifications that often escape notice.

NPM uses a feature called lockfile that requests only specific versions of code. That makes it possible for people to use only known good versions of a package when there are buggy or malicious versions that they depend on. Last year, NPM also acquired Lift Security, a company that maintained a database of known JavaScript vulnerabilities. NPM has since built the database directly into its command-line tool.

The ability for malicious code to make its way into a code library used by so many applications and then escape notice for weeks shows that these NPM measures, while useful, are by no means sufficient. The time has come for maintainers and users of open-source software to devise new measures to better police the millions of packages being used all around us.




Be the first to comment

Leave a Reply

Your email address will not be published.


*