Open-source Packages with Malicious Intent

Why re-invent the wheel?

This famous saying is what I think of when thinking about third-party code. Package managers such as npm, RubyGems, and Maven make it so easy to share code that has been written between people that developers use it for tasks as small as checking if a number is positive. This is absolutely great but how many of us stop to think about what exactly is going on behind-the-scenes, under-the-hood, behind-the-magic curtain?

Developers could have written any number of vulnerabilities, backdoors, or malicious activities into the library that they are providing for your use and you may never know. It is true that one could closely inspect the code content but in reality, developers don’t often have time for that. But what could they possibly do? Great question.

Any number of things could be written into the code, but let’s take a look at the rimfall example. Back in 2015, Lift security wrote a post on how the pre-install hook in the rimfall npm package contained and executed the command rm -rf /* onto the user’s system. This library only existed within the npm registry for 2 hours after the bad behaviour attracted the HackerNews community.

The above example wasn’t widespread but what if this had happened with left-pad?

In March, 2016 a popular npm package left-pad was removed by the developer Azer Koçulu after a name dispute over another package he maintained (See here for the full story). At the time, once a package had been removed from npm by a developer, any other user was able to upload a different package with the same name. When left-pad was removed, it had a catastrophic impact on the development community as this package was very popular and wide-spread. Had an attacker been quick on his feet, he would have been able to upload a package named left-pad which had the same functionality as the original package, but also with malicious activities. If done fast enough, many people would have been none-the-wiser. A similar case was identified on August 1st, 2017 by Oscar Bolmsten when he tweeted this message to Kent C. Dodds the owner of the popular cross-env package.

@kentcdodds Hi Kent, it looks like this npm package is stealing env variables on install, using your cross-env package as bait: pic.twitter.com/REsRG8Exsx

— Oscar Bolmsten (@o_cee) August 1, 2017

He pointed out that his package was being typo-squatted by a package with malicious intent. Typo-squatting is an attack by which the attacker relies on user mistakes. By choosing the similar package name crossenv the developer (who signed up to npm using the name hacktask) banked the spread of his malicious package on the fact that people may accidentally choose to download crossenv instead of cross-env. The user, who has since been removed from npm, also had published an additional 37 type-squatted packages.

The malicious package that hacktask had published would take the environment variables and send them to the npm.hacktask.net url. If you are interested in other impacts that these attacks might have, check out the post “Abusing npm libraries for data exfiltration” that Asankhaya wrote late 2016.

How can you find if any part of your code is sending data to an unexpected source?

SourceClear previously released a tool named Build Inspector — a forensic sandbox for continuous integration environments. Among other things, Build Inspector can be used to provide an overview of the network traffic made during the build.

Using the “Network activity” tab, you can find all resolved domain names, as well as any insecure requests which are being made over HTTP, an example of which is listed below.

By reviewing this list, a knowledgeable developer will be able to identify any potentially malicious activity that may be happening. In the example shown above, there are 2 suspicious items to note. Both suspicious items revolve around the areweflashyet.com domain. This isn’t a url that one would expect to see in a build. It may be a sign that there is some malicious activity going on. After investigation, even if you found that the communication with areweflashyet.com is legitimate, it will still be listed under “Insecure Network Activity” which means that it is not being conducted using HTTPS. This alone leaves you vulnerable to Man-in-the-Middle (MitM) attacks.

With more intimate knowledge of the build process and time, developers may also use the report that Build Inspector produces to find any unexpected file changes or executed commands that happen during the build process. Using Build Inspector on any unknown or suspicious dependencies uncovers insights on whether any fancy activities such as the theft of environment variables happened during build. Apart from dealing with npm builds, Build Inspector can also be used to perform and monitor builds with gradle, mvn, and gem. This makes it easy for Build Inspector to be the go to place for testing new, unknown, dependencies before allowing them to be part of your production build(s).

For more information on Build Inspector, its requirements, usage, and several examples, can be found at the following GitHub repository: https://github.com/continuous-security/build-inspector