Malicious Pull Request Inserted Into Ethereum Code Extension: Research

A hacker inserted a malicious pull request into a code extension for Ethereum developers, according to researchers at cybersecurity firm ReversingLabs.

The malicious code was inserted into an update for ETHcode, an open source suite of tools used by Ethereum devs to build and deploy EVM-compatible smart contracts and dapps.

A blog by ReversingLabs reveals that two malicious lines of code were buried in a GitHub pull request that comprised 43 commits and 4,000 updated lines, and that concerned itself primarily with adding a new testing framework and capabilities.

The update was added to GitHub on June 17 by Airez299, a user who had no prior history.

The pull request was analysed by GitHub’s AI reviewer and by members of 7finney, the group responsible for creating ETHcode.

Only minor changes were requested, with neither 7finney nor the AI scanner finding anything suspicious.

Airez299 was able to obscure the nature of the first malicious line of code by giving it a similar name to that of a preexisting file, while also obfuscating and jumbling the code itself, making it harder to read.

The second line of code functions to activate the first, which according to ReversingLabs ultimately has the purpose of creating an automated function (a Powershell) that downloads and operates a batch script from a public file-hosting service.

ReversingLabs is still investigating what exactly this script does, although it’s working under the assumption that it’s “intended to steal crypto assets stored on the victim’s machine or, alternatively, compromise the Ethereum contracts under development by users of the extension.”

Speaking to Decrypt, the blog’s author Petar Kirhmajer reported that ReversingLabs has no indication or evidence that the malicious code has actually been used to steal tokens or data.

However, Kirhmajer writes in the blog that ETHcode has 6,000 installs, and that the pull request—which would have been rolled out as part of an automatic update—may have spread “to thousands of developer systems.”

This is potentially concerning, and some developers suggest that this kind of exploit happens a lot in crypto, given that the industry relies heavily on open source development.

“Too much code and not enough eyes on it.”

According to Ethereum developer and NUMBER GROUP co-founder Zak Cole, many developers install open source packages without checking them properly.

“It’s way too easy for someone to slip in something malicious,” he told Decrypt. “Could be an npm package, a browser extension, whatever.”

Recent high-profile examples of this include the Ledger Connect Kit exploit from December 2023, as well as the discovery last December of malware in Solana’s web3.js open source library.

“There’s too much code and not enough eyes on it,” adds Cole. “Most people just assume stuff is safe because it’s popular or been around a while, but that doesn’t mean anything.”

Cole affirms that, while this kind of thing is not particularly new, “the addressable surface of attack is spreading” because more and more developers are using open source tools.

“Also, keep in mind that there are entire warehouses full of DPRK operatives whose full time job is to execute these exploits,” he says.

While Cole suggests that there is probably more malicious code lurking around than many devs probably realise, Kirhmajer told Decrypt that, in his estimation, “successful attempts are very rare.”

This leads to the question of what developers can do to reduce their chances of using compromised code, with ReversingLabs recommending that they verify the identity and history of contributors before downloading anything.

The firm also suggested that devs review files such as package.json in order to evaluate new dependencies, which is something that Zak Cole also advocates.

“What helps is locking down your dependencies so you’re not pulling in random new stuff every time you build,” he said.

Cole also recommended using tools that scan for weird behavior or sketchy maintainers, while also looking out for any packages that might suddenly change hands or update out of the blue.

“Also don’t run signing tools or wallets on the same machine you use to build stuff,” he concluded. “Just assume nothing is safe unless you’ve checked it or sandboxed it.”