Vulnerabilities Management — 5 Ways to Find and Fix Open Source Vulnerabilities
Though open software has many advantages for organizations and developers, it also comes with a fair amount of exposure to different kinds of vulnerabilities which pose a significant risk.
The main problem is that open source software rarely go through a similar level of security checks as compared to commercial software. As open source dependency is often deployed to various web applications, a bug usually opens all those applications to potential risk.
We will discuss two of the most recent security issues presented by open source software and what could have been done to prevent the breach.
How Vulnerabilities Creep In — understanding both the Equifax Breach and the ESLint Incident
The ESLint Incident
In July 2018, a module called ‘eslint-scope’ was hijacked on npm. The module in question attempted to steal tokens within .npmrc. The hijacker released a new patch for the module which was rolled out to many developers that were using the library.
An issue was subsequently created for the GitHub repo of eslint-scope which pointed to an unexpected error message indicating that a particular version of the module was malicious. The GitHub issue resulted in quick responses and soon became the ground-zero for the incident, where all the discussion took place.
The malicious version of the module would load a file from pastebin and try to redirect users’ .npmrc files to the hijacker. Since .npmrc comes with authentication tokens for users’ accounts, the hijacker’s code would probably be intended to behave as a worm, i.e., gain publishing rights to other accounts that do not have publish-time 2FA enabled.
The cause of errors was found to be poorly written code. Due to the nature of the code, it is suspected that the hacker did not have a clear understanding of some aspects of JavaScript and Node.js best practices.
In a bid to rectify the problem, the npm team invalidated tokens created before the publication of the hijacked module. This made any credentials received by the module’s hijacker wholly useless and in turn, helped ensure additional modules would be secure.
The Equifax Breach
In September 2017 Equifax announced that malicious users had stolen sensitive information of more than 147 million Americans from their servers. Equifax further elaborated that customer names, social security numbers, addresses, and birthdates were among the data stolen.
The hackers launched the attack by crawling the web for vulnerable servers. In a couple of months, they identified Equifax’s dispute portal where users discussed claims. Here, the hackers used a known Apache Struts vulnerability and got access to the login credentials for 3 of these servers. They then realized that these credentials gave them access to a further 48 servers that held personal information.
The hackers went on to spend about 2.5 months inside Equifax’s network before detection. It has since been reported that the hackers stole the data in a piecemeal fashion from 50+ databases to avoid detection.
To enhance the security of component and dependencies, the five best practices below are suggested. This should help you manage vulnerabilities in open source code, review dependencies better, and patch vulnerable components when identified.
Set Strict Security Rules and Standards When Using a Dependency And Publishing It
It is a good idea to enforce policies requiring developers that use open source components to prove that they do contain any identified vulnerabilities.
It is paramount to have developers understand that risk of vulnerabilities that open source components can generate and the downside to the application or program in particular, and the company in general.
Such policies may require explicit review and approval from your in-house security team or need developers to prove the security of the software. Making developers aware of the risk goes a long way in mitigating possible risk.
Keep track of Security Updates for Dependencies
Maintain an updated inventory of the open source libraries being used by your organization. This should include libraries used during development as well as in production. Some organizations do not have this information regularly updated for the open source components their applications use.
Additionally, a number of the more popular applications include indirect open source components that may not have an active development or support community. In this case, these components go mostly unpatched and can become insecure as time passes. Ignoring these possible avenues of vulnerabilities can leave your application open to risk.
Test Your Components and Dependencies
Testing the security of the open source components you are using is probably the best way to ensure the safety of your application(s) and, in turn, your organization.
The timely and frequent analysis of open source components is as critical as proprietary code. This is especially true as the component in question may have unknown security vulnerabilities or its dependencies may differ with each use case. It is possible for a component to be secure in a particular application but vulnerable in another.
Develop and Use in-house Tools Instead of Unsupported Libraries
When it comes to unsupported or expired libraries, it is advisable to develop your tools in-house which you can regularly use to identify and fix vulnerabilities. The initial time and money investment to build the tools may seem like a deterrent. However, the functionality of an always-available in-house tool will be an asset to developers in the long run.
Use Security Tools to Check for Possible Security Vulnerabilities
A variety of different commercial and open source tools have been developed to address the problem of identifying the security vulnerabilities in different source components. Each of these tools approaches the problem differently.
Some of the more popular tools are listed below -
1. NPM Audit (previously Node Security Project)
NPM Audit is the de-facto tool for auditing NPM dependencies and Node.js modules. It was previously known as NSP, but the latest version of npm integrates NSP and implements the npm audit script. This enables it to check for known vulnerabilities in node modules and its related dependencies. You have to run npm audit to see a list of potential vulnerabilities in your application and npm audit fix to fix them.
2. RetireJS
An open source dependency checker, RetireJS is specific to JavaScript. Its USP is its easy usability. RetireJS includes different components, like plugins for Chrome, Firefox, Gulp, Grunt, Burp, and ZAP, etc. as well as a command line scanner.
3. OSSIndex
OSSIndex lends support to many different technologies. It can cover .NET/#C, JavaScript, and Java ecosystems. It also has free API vulnerability support.
4. Dependency-check
Dependency-check supports .NET, Java, JavaScript, and Ruby. It uses NIST NVD to extract its vulnerability information. There’s a similar tool called depcheck that checks for all dependencies and reports unused dependencies in your Node application.
5. Commercial tools
Apart from the free tools, there are a few commercial tools that you can use to help find vulnerabilities in your open-source code. The popular ones include:
Hakiri — a business tool that provides dependency checks for Ruby and Rails-based GitHub projects
WhiteSource — currently includes support for NPM, Ruby, PHP, Python, and Bower
SRC:CLR — Source Clear has different plugins to various IDEs, source repositories, and deployment systems, along with a command-line interface
Conclusion
Open source components are usually safe when they have a large community of people reviewing the code. That said, publishing the source code or having multiple sets of eyes reviewing the source code does not always guarantee that all security issues will be identified and fixed. Therefore, it is vital to include industry standard security policies into applications.
