Three npm packages identified by Sonatype this week conceal malware in "travis.yml," a CI/CD build configuration file used by Travis CI. These packages contain metadata, description, and code copied from the legitimate "cli-width" package but instead deploy malicious macOS binary, disguised as "Safari updates."
These malicious npm packages are:
-
tyibyc
-
x91yz
-
y78b
Analyzed by Sonatype security researchers Carlos Fernández, Raphael Luy, Sebastian Arias Amador, these packages have altogether scored around 114 downloads [1, 2, 3] until they were reported by us to npm and removed by the registry admins.
These packages contain tainted versions of files taken from the legitimate "cli-width" library to covertly drop a suspicious binary on the system they are installed on.
Taking a look at "x91yz," for example, its manifest file (package.json) runs a "package-lock.js" file as soon as the package is installed. The choice of name, "package-lock" seems intentional on the part of the malicious package author as "package-lock.json" (not .js) files are often used in npm packages to specify an exact, versioned dependency tree.
Note, the metadata contained in the manifest shown below has "author", "description" and project's "homepage" fields which are are all representative of the legitimate 'cli-width' library and not this malicious package:
Drops a bogus "Safari Update"
The "package-lock.js" contains code taken from "cli-width" which has been modified on lines 40-43. On these lines, we see the code creating a "~/Library/Application Support/Safari Update" directory on your macOS.
It then copies a bundled "travis.yml" file to this newly created directory, renames it to "updateSafari," and runs it.
This so-called "travis.yml" file is in fact a Mach-O binary and not plaintext YML configuration files used by Travis CI. The naming convention is, once again, intentionally in use to mislead the casual user of the package who may otherwise pay no heed to it.
The use of "nohup" (no hangup) command means the executable will keep running even if the shell itself terminates. Finally, the code in "package-lock.js" deletes the "package-lock.js" itself to remove traces of where the malicious binary was first called to execute from.
Other packages like "tyibyc" even overwrite the original "package.json" file after deploying the Mach-O binary to completely wipe traces of the "preinstall" command where the journey originally began.
Zero detections thus far
At the time of writing, this "travis.yml" file aka the bogus "updateSafari" binary remains undetected by most antivirus engines, according to VirusTotal. As such, relying on antivirus or endpoint protection solutions alone for newer strains like these may not be adequate.
What is it doing?
There are indicators which suggest that the Mach-O binary connects to the following URL to retrieve stage 2 payload: hxxps://passgenwizard[.]com/ts/getTs.asp?id=83401
The URL serves, what appears to be an empty file, 'vfcompat.dll,' which both hinders further analysis and is rather incongruous, given that the initial attack vector (a Mach-O binary) would execute on macOS systems, but the stage 2 payload it retreives would be a DLL. Another theory is, much like "travis.yml," the file name "vfcompat.dll" also uses a false extension as a façade to conceal its actual contents.
We believe that the server will only respond with a potent (non-empty) payload to requests originating from a certain User-Agent, IP address, and/or systems with a specific fingerprint, making this attack highly targeted.
The URL is also rather specific. Experimenting with different values for the "id" field did not yield valid downloadable content.
The "passgenwizard[.]com" domain in use, with its hosting environment running Windows IIS server, is new too. WHOIS records show it has been registered on 17th of July via Namecheap (registrar) and does not appear to be involved in prior attacks or large scale illicit activity which is widely known.
Who would download these packages?
That is our question too, given the specific and seemingly gibberish names of these packages. Granted these were caught early by us and removed after scoring just 114 downloads, we theorize that these packages are being used as a testing ground by their creator before they deploy their actual attack on the platform which might be more sophisticated and targeted than this one.
Open source malware blocked by Sonatype Repository Firewall
Sonatype Repository Firewall and Sonatype Lifecycle stay on top of nascent attacks and vulnerabilities and provide you with detailed insights to thwart previously undetected malware, Potentially Unwanted Applications (PUAs), and vulnerable components from reaching your builds:
Threat actors create malicious software components and distribute them through public open source repositories. This tactic is growing in popularity, and malicious open source is rapidly expanding.
Malicious open source is designed to evade typical software composition analysis (SCA) scanners. However, users of Sonatype Repository Firewall can rest easy knowing that these packages would automatically be blocked from reaching their development builds and keep their software development life cycle (SDLC) hygienic.
