Malicious Libraries Threaten Corporate Data Security

Whenever you set out to build something in the real world, you’re probably relying on or using tools or infrastructure created by someone else. Whether it’s the materials you use, the tools you select for the job or — in the case of a larger construction like a house — things like the electric and water supplies you connect to, very few constructions are 100 percent your work. The builder therefore has to trust that the third-parties involved are pulling their weight.

The same thing is true when it comes to proper data security and code. Nearly all larger software systems and software products today are assembled from various components (read: collections of programs) in the form of external code.

The essential components used for a piece of software are called dependencies. As the name implies, the software is dependent on them. Dependencies save coders time and cost, and allow them to utilize features that may be outside their specific knowledge base. After all, there’s no reason to reinvent the wheel if someone has already invented a perfectly great one.

Just like a house builder may not also know how to wire up an electric grid, so too is a coder not necessarily an expert in every domain. A dependency might allow, for example, the writer of a messaging app to also incorporate message encryption in the form of a piece of software written by someone else. The messaging app depends on the encryption program to function.

Vulnerable dependencies

The problem (or potential problem) comes when there is a vulnerability with the dependency. Vulnerable dependencies make an application exploitable. To return once more to the housebuilding analogy, the builder could make sure that they have securely installed a lock on their front door, but if there is a problem with that lock that allows it to be opened by other keys, that means a vulnerability exists in the house.

There are no shortage of examples of vulnerabilities involving dependencies. For example, in October 2020, several JavaScript npm packages were uploaded by the same user to a GitHub page, a public code repository. Any coders accidentally mistyping the name of one of these JavaScript npm packages could wind up downloading the packages, which masqueraded as legitimate. This is a technique known as typo-squatting. In fact, once they were downloaded and installed, the malicious code gathered information about the users’ IP address, their country, their city, their computer username, home directory path, and their CPU model information. This information was then shared without their knowledge.

While it is not 100 percent clear what the exact purpose of this may have been, it could be used to develop malware that could attack a specific computer architecture. The bad actor behind the vulnerable packages could then, if they wished, create an update to the packages to push more damaging malicious code.

Fortunately, the JavaScript npm packages were rapidly found and removed, thereby stopping others from downloading them — although that would not necessarily help those who had already made use of them.

Do your due diligence

It’s important to stress that the vast majority of third-party library repositories are safe. But bad actors do exist in this domain, and their ill-intentioned work can spread rapidly if unchecked. Malicious npm code that steals user data has the potential to be devastating in its consequences. Security measures are constantly being explored to root out these problematic packages. They are also frequently discovered quickly when added to libraries on Github.

However, in the meantime it’s important that respected developers carry out due diligence when it comes to their software project dependencies. Developers already have to make sure they select the right dependencies when working on a project, so as to avoid the raft of compatibility issues and runtime errors they might otherwise face when choosing badly. As a result, they should take steps like thoroughly testing their software on the target platform, avoid specific software version dependencies (because software platforms are regularly updated), and more.

In the same way, they should also make sure that they scrutinize project dependencies to make sure that they are legitimate. The risks of not doing so are simply too great.

Bring in the experts

One added way to safeguard when it comes to data security is to bring in the cybersecurity experts. Tools like Web Application Firewalls (WAFs) and other data security solutions will help to detect and block the exfiltration of user data. That should include auditing data activity — even including local privileged users and applications.

This rapid detection and split-second response to possible threats isn’t an alternative to writing sloppy code and failing to properly check the sources of dependencies. However, accidents can happen — and it’s better to be prepared. Thankfully, the cybersecurity tools now exist that allow you to do just that. Just make sure to pick the tools you can trust.

 

Disclosure: This is a collaborative post and the author’s views here do not necessarily reflect those of the blog owner.