Two new supply-chain attacks come to light in less than a week
Most of us don’t think twice about installing software or updates from a trusted developer. We scrutinize the source site carefully to make sure it’s legitimate, and then we let the code run on our computers without much more thought. As developers continue to make software and webpages harder to hack, blackhats over the past few years have increasingly exploited this trust to spread malicious wares. Over the past week, two such supply-chain attacks have come to light.
The first involves VestaCP, a control-panel interface that system administrators use to manage servers. This Internet scan performed by Censys shows that there are more than 132,000 unexpired TLS certificates protecting VestaCP users at the moment. According to a post published last Thursday by security firm Eset, unknown attackers compromised VestaCP servers and used their access to make a malicious change to an installer that was available for download.
Poisoning the source
“The VestaCP installation script was altered to report back generated admin credentials to vestacp.com after a successful installation,” Eset Malware Researcher Marc-Étienne M.Léveillé told Ars. “We don’t know exactly when this happened, but the modified installation script was visible in their source code management on GitHub between May 31 and June 13.” VestaCP developer Serghey Rodin told Ars his organization is working with Eset to investigate the breach to better understand the attack.
Until the investigation is complete, it remains unclear precisely how the compromise worked. Based on Léveillé’s initial findings, the hack most likely started by exploiting a critical vulnerability, either in the VestaCP software or a server used to distribute it, that gave the attackers root control. From there, the attackers added the password-sniffing functions to the installation source code. VestaCP software already contained code that sent statistical information from user servers to the vestacp.com website.
Léveillé said he believes the malicious code simply added a few hard-to-decipher lines that caused encoded passwords to be included. The attackers then used their control over the VestaCP network to retrieve the pilfered passwords. While more complicated, this approach had the advantage of being harder to detect in the source code, the researcher said. The attackers, Léveillé said, then likely used the passwords to log in to servers over their secure shell interface.
Using SSH, the attackers infected the servers with ChachaDDoS, a relatively new strain of malware used to wage denial-of-service attacks on other sites. The malware offers a variety of advanced features, including ways to prevent administrators from finding it on servers and analyzing it. Chacha runs on 32- and 64-bit ARM, x86, x86_64, MIPS, MIPSEL, and PowerPC. On Tuesday, researchers from security firm Sophos described a newly discovered DDoS botnet they call Chalubo that almost certainly runs the same Chacha malware described by Eset.
It’s possible that the attack on VestaCP’s supply chain ran for longer than the 14 days documented in the source code. Posts such as this one show VestaCP users reporting server hacks in early April, almost two months prior to the May 31 date listed by Eset. Discussions such as this one suggest that the compromises affecting VestaCP users have continued well after the June 13 date when the malicious changes were removed from the source code. Léveillé said Eset plans to publish more details about the attack in a week or so.
Clipboard hijacker sneaked into PyPI
The second supply-chain attack to come to light this week involves a malicious package that was slipped into the official repository for the widely used Python programming language. Called “Colourama,” the package looked similar to Colorama, which is one of the top-20 most-downloaded legitimate modules in the Python repository. The doppelgänger Colourama package contained most of the legitimate functions of the legitimate module, with one significant difference: Colourama added code that, when run on Windows servers, installed this Visual Basic script. It constantly monitors the server’s clipboard for signs a user is about to make a cryptocurrency payment. When triggered, the script diverts the payments from the wallet address contained in the clipboard to an attacker-owned wallet.
This isn’t the first time Python’s official PyPI repository has been abused to carry out this type of social engineering attack. In 2016, a college student’s bachelor thesis used the same technique to get an unauthorized Python module executed more than 45,000 times on more than 17,000 separate domains, some belonging to US governmental and military organizations. A year later, PyPI was once again tainted with code packages that included “malicious (but relatively benign) code.”
Over the past six months, the clipboard hijacker stowed away in PyPI was downloaded 171 times, not counting mirror sites, with 55 of those in the last month. Servers that have been infected must not only remove the malicious Colourama module but also make registry changes that purge the Visual Basic script.
Remember NotPetya?
The evidence available so far suggests that neither of the recent incidents infected large numbers of people. That’s not always the case with supply-chain attacks. The 2017 outbreak of the NotPetya disk wiper that shut down computers around the world is one of the best examples of the destruction that can result from these types of attacks. It was seeded through a legitimate update module of M.E.Doc, a tax-accounting application that’s widely used in Ukraine. Researchers said the initial attack likely required access to the M.E.Doc source code and control over the company’s network. A suite of propagation tools inside the backdoored version of the application then caused it to spread rapidly around the world.
In 2017, the world saw another malware outbreak that was also seeded in the supply chain, this one for the CCleaner utility many people use to manage hard drives. The attack was carried out by first infecting the network used to develop and distribute the utility. The attackers then used their control to infect 2.27 million computers with a malicious version. Curiously, an advanced second-stage payload was delivered to only about 40 of those infected computers, which were hosted in networks belonging to 12 companies, including Samsung, Asus, Fujitsu, Sony, and Intel.
As it becomes harder for hackers to infect end users by exploiting the software and websites they visit, these types of supply-chain attacks are likely to become more common. Users should consider scanning downloaded installers and updates when possible and paying close attention to names to make sure they match the official modules they intended to install.
