Taking over unclaimed npm packages in documentation on GitHub or your businesses documentation site is a new trend we will see hackers doing to spread malware.
All a hacker needs to do is find a package in your documentation that they can take over, and they can execute a successful attack that will lead to remote code execution (RCE) and the installation of malware.
This is a perfect attack for hackers for a few reasons:
- It's critical impact, easy to find, and very prevalent.
- Users install packages all the time by following installation instructions.
- Users would not suspect the package they're installing is malicious because it's coming from a trusted source.
- Unclaimed packages are in documentation everywhere.
How hijacked npm packages can been exploited
After a hacker hijacks an npm package, an attacker can insert arbitrary system commands in the package's preinstall script defined in the package.json file, or have arbitrary JavaScript executed during the installation process.
A PoC npm package would look like:
When this example PoC package is installed via a command like npm install, the output of the system command id would be saved to rce.txt and the content's of the user's /etc/passwd file would be saved to etc_passwd.txt.
The malicious code would be executed when a user installs the package by executing a command from the documentation like:
npm install package
In a real-world attack, the exploitation would not look this obvious, but an attacker would be able to execute anything on a developer's computer or application server where the package is installed.
An attacker could use this type of vulnerability to install malware on the developer's computer and then pivot to gain access to more parts of the organization.
Attack scenarios
A successful attack can occur in two ways after a hacker uploads a malicious package.
Waiting for intended behavior
A successful attack can occur naturally over time with no interaction with a victim.
Users reading the documentation, or a GitHub repository's README.md file, will follow the installation instructions as they are told to do so.
Social engineering
Having control of a package used in a company's installation instructions in their documentation is all an attacker needs nowadays to execute a successful social engineering attack, leading to compromise of the organization.
An attacker can send users the documentation link and social engineer them to follow the installation instructions. Their targets can either be the developers or potential users.
A hacker can social engineer someone as simple as saying "I'm having trouble using this program, I followed the installation instructions, and it did not work. Can you help me?".
The process for someone trying to help is to try to reproduce the steps someone took to the point where they experienced the issue, which includes following installation instructions.
Attack prevention
You can safeguard your businesses from facilitating malware installations and being responsible for unsuspecting people getting hacked by making sure every package in your documentation and GitHub repository's README.md file is up-to-date.
This can be done by manually searching each package, which is a very mundane task.
One caveat, packages can go missing at any time.
A developer might decide to change the name of their package or add a scope to it one day.
These changes can happen randomly at any time, and when these changes occur you aren't automatically notified that a package in your documentation can be taken over by hackers.
You would have to manually check each package every day to make sure your documentation is secure. 😰
But there is another option to make it easier...
SupplyShark solves this problem with continuous dependency monitoring. We can analyze all the dependencies in your documentation and alert you as soon as a package can be taken over by a hacker.
We make it easy for you, save you time, and keep you safe! 🥳
Sign up for SupplyShark to get started securing your supply chain!