The Double Sides of Open Source
Open source code has become the backbone of an entire generation’s method of technology development. Followers of this mindset work to keep the source code of software open and free to download. Not only is it freely available, but organizations and individuals are also free to modify and incorporate this code into their own projects, which helps to improve the software itself over time.
Richard Stallman, founder and ex-president of the Free Software Foundation (FSF), is one man that brought open-source to the masses. His explanation of free software is also delightful: free software is about accessibility, not price – “You should think of ‘free’ as in ‘free speech,’ not as in ‘free beer.'”
However, the collaborative utopia of open source software sees both the good and bad of copied and pasted code. Whereas it offers huge leaps in efficiency and cross-platform integration, it also replicates swathes of shaky, vulnerable code.
For example, open source projects will almost always make use of open source libraries of code. Incredibly useful pieces of pre-packaged functionality, packages are the lifeblood to the pulsing heart of open source.
These libraries are also incredible entry points for a lot of malicious actors. Embedding themselves in the code of an application’s very beginning is one of the most passive forms of malicious actors. This means a cybercriminal can branch deeper into the software developer’s device, or potentially hijack a software’s user base for their own ends.
Node Package Manager (npm) is the world’s largest software registry. Npm contains millions of packages for every occasion. However, the lack of substantial malware checks before a package is uploaded has risked considerable threat from bad actors. One example of this was found recently in a ‘speedy-ts-compiler’ package.
Once a developer installs this package into their coding environment, the package swiftly runs a script where it downloads another file, from an external URL. For any security-conscious developer, this would start to set off a small number of alarm bells. However, upon further inspection, it appeared that this secondary file was almost empty. It contained only skeleton code.
This second file was a distraction tactic. If it made the developer stop and inspect it for even a minute, then it succeeded. Instead of the file doing anything, the URL in the package is in fact the suspicious component. Here, a GET parameter in the URL was siphoning off the path to the user’s npm cache. This stores and sends off the system’s username and IP address.
Another example noticed by analysts was a false ‘colorsss’ package. This is an example of typosquatting, where the malicious package imitates the legitimate ‘colors’ file. When an unsuspecting developer downloads and installs the colors file, the malicious package begins tracing the device’s file directory, following it to the Discord app.
Once the package has located a Discord application, it begins collecting information. This includes user tokens; the victim’s IP address; the PC username; and browser details. The theft of Discord tokens is a recurring theme among malicious packages, as they represent a relatively easy path to further exploitation.
Protecting Your Package
The Open Source Security Foundation (OpenSSF) was created in 2020 in response to these threats. Founders include industry giants such as GitHub, Google, JPMorgan, and IBM. OpenSSF recently released their Package Analysis project.
The Package Analysis project’s goal is understanding first; combatting second. Here, GitHub analyzes the behaviors and capabilities of each package uploaded to the repository. Patting down each package, OpenSSF can see what files it accesses; which URL addresses it requests a connection to; and what commands are included. These elements are also tracked over time, allowing analysts to see when previously safe packages suddenly become compromised.
However, there’s often a wide gap between knowing a package has been compromised and its removal from an application. This process demands that the developing organization spend time on searching and destroying the malicious package.
However, despite the technological world being uber-collaborative via open source software, it is also intensely competitive. Time is of the essence. Returning to an older piece of software with the intent of scrolling through its code and replacing a single package can be pretty low down the priority list – or a bigger demand than expected.
This assumes that the developer even intends on patching up their glaring holes in security. If an app is no longer actively supported, then devs may not even attempt a fix. This leaves your organization bearing the brunt of security responsibility.
RASP to the Rescue
It’s here that Runtime Application Security Protection (RASP) can defend against threats that are even deeply embedded within a software. RASP runs on a server, and hums in the background when an app is booted up. From bootup to close, RASP sits in the background and monitors an app’s permissions, behavior and context.
RASP intercepts all calls from the app to its host system, validating data requests. RASP is also customizable to your own security setup. When set to a diagnostic mode, RASP merely sounds an alarm when something is amiss.
However, once in protection mode, RASP will attempt to prevent a successful attack. For example, it can recognize an app requesting files outside of its context, and terminate the execution. This would prevent a package from pinching unrelated information – such as Discord tokens.
This differentiates a RASP solution to a Web Application Firewall. RASP – like a WAF – can terminate a solution, but RASP has a window into the inner components of an app. It sure can’t fix sketchy lines of code, but it can keep attackers out of a compromised system.
It’s this hyper-flexibility and automated attack response that makes RASP an essential component to any enterprise’s cybersecurity toolkit.