Compromised NPM Packages, Malware, and GitHub
Last Updated on December 1, 2022
Security professionals always have a lot of work to do. You may even get the impression that the number of things that have to be done grows more and more with time. Especially now, when in recent years the popularity of solutions based on external, dynamically loaded dependencies, such as entire libraries or individual functions, has grown. The popularity of NPM packages is also of great importance here. Currently, when creating an IT system, we are rarely entirely its authors, so we do not always have 100% control. External scripts may quite easily execute any malware.
What is malware?
Malware is a fairly broad term referring to all programs that are harmful to our system or ourselves – its users. This slogan covers all kinds of viruses, trojans, spywares, keyloggers, and many other harmful types of software. A particularly popular type is ransomware, which blocks access to our systems (often by encrypting data) and then demands a ransom to unblock access. I recommend reading the Ransomware attacks on GitHub, Bitbucket, and GitLab article to get a better insight into this topic.
In December 2020 new malicious packages were found in NPM. Seemingly, these were sensible tools to make a database out of JSON files. Everything was cleverly prepared, and the packages felt legitimate. Unfortunately, their installation downloaded and launched a Trojan called njRAT, which made it possible to execute remote commands. This tool allows keylogging, access to the camera, stealing passwords stored in browsers, manipulating files, etc. Dangerous tool.
You can find njRAT on GitHub if someone is interested in it. The README file does, however, contain a warning:
NPM packages
Let’s explain what the NPM ecosystem really is and what GitHub has to do with it. Behind this inconspicuous name is a powerful tool that is part of the Node.js environment. The NPM registry is a kind of central repository for JavaScript packages. Actually, it is the largest one! It can be used to publish and share open-source software, but also to manage private, internal development by many organizations.
Ready to safely store code in GitHub? Do the next best thing and secure it with the first professional GitHub backup.
So, if we want to include a given package in our project, for example, “lodash” (helps with arrays and numbers), just install it with npm install <module>. We can also add various dependencies to our project, in the package.json file. These dependencies would be installed together with the project.
It is both a blessing and a curse for such a solution. It is easy to imagine a situation when our project has external libraries connected, which suddenly stop working as we expect. These may be deliberate actions by their creators, although this is unlikely. Rather, the real threat is that these external dependencies would be compromised and the authors would lose control of them. As a result, our NPM module installation would download infected packages, and we can call that scenario a NPM malware vulnerability.
How NPM is vulnerable to malware and what GitHub does about it
GitHub is aware of potential NPM security issues. You don’t have to look far for evidence. At the end of 2021, a serious vulnerability was discovered that would have allowed the publication of malicious versions of any package on the NPM registry. Any existing package! That’s crazy. This was due to an authorization problem in the microservice architecture. User validation worked fine, however after this step the decision about which package to publish was made based on the content of the package file. This means that the request was validating for package A, but it was able to publish package B.
After discovering this vulnerability, GitHub began to require two-factor authentication for maintainers and admins of popular NPM packages. In addition, the NPM team is constantly working on improving security, among others by automatically monitoring newly published versions of packages to track any new NPM malware in real-time.
A harmless example
Dependence on external dependencies is something beneficial and normal in IT, but at the same time, we will never let go of the feeling that some outsider may mess up with our project. A quite recent example is the “protestware” – connected to the war in Ukraine. In the latest version of node-ipc module there is a change that creates a file with a call to peace and end of the war. It is a non-destructive example of NPM control, security, and vulnerability that impacts our projects.
The need to have a backup
As you can see, we can never fully rely on external dependencies. They are useful and drive the IT world, we absolutely should not stop using them. However, at the end of the day, we have to take care of our own safety. That is why we should always remember about backup and restore tools that can save our skin in a crisis situation.
