JavaScript, the world’s most popular programming language, focuses primarily on controlling the behavior of web pages and apps. Though powerful, the process of coding a Java web app from scratch can be lengthy, frustrating and – depending on its scope and scale – often requires a team of developers. This is how open source has changed the game: now, individual developers can share and take advantage of the coding prowess of a global community.
As powerful as open source libraries are, increasing numbers of Java app vulnerabilities are bubbling up from publicly-posted code. The hardest hit victims are often oblivious, left scrambling to Google, asking ‘what is a reverse shell?’ while attackers unleash havoc on their server.
The power of a database
The npm database allows for chunks of code to be condensed into portable packages, and uploaded to the publicly available library. These packages are free to download, and span an incredible range of functions.
Npm is part of the solid foundation of Open Source Software. Somewhat of a techno-cultural marvel, Open Source is a philosophy and business architecture that flies in the face of traditional profit seeking ventures. Before open source, it was simply accepted that to make money, you had to be exclusive. In an economic climate that promotes individual ownership and intense competition, it’s only natural to keep a competitive edge by attempting to control access to stuff you created.
However, open source went nuclear in 2015. For good reason – a group of people can always create a better, more flexible solution than one individual could. Groups sharing their thoughts, suggestions and failures create software that is more than the sum of its parts. Seeing the efficiency and power of groups (and after swift adoption by Google and Microsoft), many development teams shifted their architecture towards a more open source design.
All open source applications are publicly accessible – from initial development to bug fixes and patches. This also means that strings of open source code become infinitely reused and recycled. The numbers don’t lie: npm currently holds over 1.2 million public packages and handles over 80 billion package downloads per month
Fantastic for efficiency, but catastrophic for security.
Malicious packages: everyone’s problem
Returning to the npm library, this public code collection is relatively unvetted. Thanks to this, it’s possible for packages to be uploaded that then become severe cybersecurity threats.
These packages often hide under the guise of legitimate functions. For example, typosquatting sees some packages replicate legitimate files, but adding an extra consonant or vowel. One recent example was the legitimate “electron” package being replaced by “electorn”. This could very well convince human npm users to install the wrong script.
Other counterfeits use a dependency confusion attack. This takes advantage of the fact that software installer scripts will always prioritize a file with the highest version number. In legitimate code, this guarantees that the installer always chooses the most recently-published and up to date file.
To make use of this feature, attackers name their npm package the exact same string as the legitimate one they’re faking. Having published this fake package, installer scripts will automatically download the malicious version until the legitimate one is updated.
Other dependency chain attack paths take advantage of once-supported packages. If a package suddenly gets taken down or otherwise disabled, then attackers are free to take advantage of programmers that are as-yet oblivious to the removal.
These three methods are very effective at gaining access to random servers around the world. That is precisely the danger of npm packages: any npm package can quickly compromise any system. This then has severe knock-on effects on every organization using those infected apps.
If these methods implant a false npm onto a system, then how does it become a security threat?
Backdoor business
Once third-party code has been installed onto a device, there’s a number of paths it can take to further entrench itself and lend access to a nefarious party.
Secure shell (SSH) is a network protocol that allows two computers to transfer data over a secure connection. SSH encrypts traffic that flows between the two devices, meaning that a hacker cannot see what is being transferred. An important aspect of SSH protocol is authorized keys. These are essentially login credentials, lending access to a company server.
One malicious npm package in particular first sought to access the device’s list of authorized keys. Once this has been found, the npm would then add the author’s public SSH key to that list. This meant that the author of the malicious npm file could now run commands on the infected device.
One other method saw the fake package establishing a reverse shell connection to the attacker’s device. Job done – the malicious actor could now simply run commands via the infected computer’s powershell script.
Defending against counterfeits
Thanks to their deep entrenchment within the development process, actually fixing the problem of malicious packages lies within the responsibility of a developer. This is where open source becomes a hindrance, as it by no means guarantees a trustworthy or active creator.
There are relatively new tools that address this, such as TypoGard and SpellBound. Both of these solutions are focused on identifying, alerting and reporting instances of typosquatting. The detection technique revolves around comparing the lexical similarities of names, then analyzes the package’s popularity.
When it finds a case of an unknown package mimicking a very popular one, the automated flagging system runs its course.
However, neither of these solutions help you if an app in your toolkit has previously been compromised. Instead, a business reliant on its apps should focus on preventing any further creation and exploitation of backdoors.
One major way to protect an enterprise is by preventing a reverse shell attack. This can be achieved through a number of safeguards, one of which is setting up a proxy server. A proxy server with tight controls and restricted destinations means that an attacker is far less likely to penetrate your own server.
Alongside locking down your outgoing connectivity, be sure to regularly patch your web apps and servers. For extra safety in a busy work environment, a reliable vulnerability scanner can test your web applications for anything you may not yet be aware of.