Cybersecurity problems continue to persist. A Node.js library was found to have a major vulnerability that allows any hacker to run commands on your servers.
Every day we learn that there are more and more reasons that cybersecurity matters. Credential stealing. Phishing. Malware. Configuration problems. Passwords stored in plain text. Vulnerabilities in VPNs. Apps with known problems and no fix in place. There’s more, but we would be here all day if we tried to list out all of the security problems experienced by businesses, especially over the last year. It’s not getting better either, as we learned last week about a Node.js library with a high severity command injection vulnerability.
This particular vulnerability is tracked as CVS-2021-21315, and impacts the “systeminformation: npm” component. The component is downloaded around 800,000 per week and has nearly 34 million downloads since its arrival. The “systeminformation” component is a Node.js library that can be included in projects to retrieve information related to the CPU, hardware, battery, network, services and system processes. It is supposed to be used on the backend, according to the developer.
“This library is still work in progress. It is supposed to be used as a backend/server-side library (will definitely not work within a browser),” states the developer behind the component.
The problem is, the code injection flaw would have allowed an attacker to execute system commands. If they could carefully inject a payload within the unsanitized parameters the component uses, they could easily cause a lot of damage. The fix, as well as workaround options for those who can’t update, are listed on Bleeping Computer.
We have often talked about how there are layers in development. There’s infrastructure, functionality, design and security to consider. Business leaders around the world have been known to push through the development process, asking devs to skimp on security or rush through configuration. The rush to put out a new product somehow supersedes the need for it to be stable and secure. The intent to come back “later” and fix it never moves beyond intention, so customers are often left with unstable, insecure products that they don’t even know could be a problem.
This is also another prime example of why all open-source code should be reviewed. Anytime the open web has access to the same code that you are trying to use, you must review it. This is just one of many vulnerabilities discovered in open-source code, and we have seen instances of malware hiding in open-source packages as well as open-source dependencies of libraries. You have to check the whole dependency chain.
What we are seeing today is what happens when “later” never comes. There are a multitude of known vulnerabilities which are the most common vectors used to hack. Which is why businesses that have not conducted a security review in the last 6 months, absolutely need to do so. There have been a slew of known vulnerabilities hitting the web, nearly all of which have a fix created. If you find these problems in your business, the fix created must be implemented as soon as possible. The longer you delay on patching systems, the greater your risk of suffering a breach.
Users of open-source repositories should visit their respective website’s advisory page to stay up to date on the newest fixes. Again, those fixes must be implemented as soon as possible. If you don’t have the staff, personnel, training, know-how or have any reservations about security reviews or patching, please consult an expert. If not done properly, the problem won’t be resolved. Make sure it’s done right the first time!