- Let's Connect!
- Email: support@securityboat.net
- Phone: +91 9175154999
Modern software projects increasingly rely on open source software, from operating systems to user interface widgets, and from back-end data analysis to front-end graphics. Despite the numerous benefits that open-source software offers, it does come with a number of security risks that must be understood and managed. In general, these risks can be associated with the use of any third-party software component, whether it is open-source or commercial. The widespread adoption of open source means increased open-source security vulnerabilities. These vulnerabilities are easier to exploit because they are publicly disclosed. Your organization is at risk if you’re not regularly managing your open source components and all their dependencies.
Open Source Security is a methodology to provide users better visibility into the open-source inventory of their applications. This is accomplished by analyzing components via binary fingerprints, using professionally curated and proprietary research, matching accurate analysis with that proprietary intelligence, and providing developers access to that intelligence inside their favourite tools.
In this blog, we will get to know what Open-Source Security is, and why it is so important.
What is Open-Source Security?
As we know before the deployment, every software goes from some phases like designing, modelling, testing and many more. Unlike this, the open-source software has only two phases, the first one is Development and the second one is Production. Open-Source Security works in both of the phases.
Generally, Open-Source Security refers to the tools and processes used to secure the Open-Source Software from development to production phase. Usually, this is done by automation. The essential objectives Behind this process are identifying the open-source dependencies of the software, providing critical versioning and usage information and triggering alerts when risk and policy violations are detected.
There are two types of Open-Source Software Community Open-Source Software.
This Software is developed and managed by a community, or we can call it a developer group that continuously improves and supports without any compensation. Typically, most of these projects are run by non-profit foundations.
This type of open-source project has copyrights and patents which a single person controls. These contributions of the source code will only be accepted if the contributor transfers the ownership rights to the owner. They may distribute their software for free or take charge. They generate revenue by providing consulting and technical support services to the users.
Now let’s Look at some advantages of Open-Source Security
When you buy new software, you can’t get information on the code base, support from an online community, or information on any potential bugs. So, Transparency is when you can get information about the code base and potential software bugs, which are all made publicly available to everyone.
Having open-source software means the code of the software is continuously reviewed and tested by the community, and it makes the software more efficient and reliable. And the community is also continuously discussing your product, so it makes it easier for companies to trust in the safety of the platform.
To maintain customer trust, security patches should be very quick. As the open-source community continuously reviews the software, if there is any issue found, then they will find a quick fix for that. Security was once one of the reasons enterprises complained about using open-source software. Now the companies no longer worry about it because they know online communities ensure security patches occur fast.
Open-source software allows for not only better flexibility but also agility. Not having enough flexibility while using the software can lead to security issues for many companies. Most importantly, when you offer open-source platforms, you prevent the users from dealing with lock-ins from proprietary software companies. Not being able to use the software the way they want could lead to a security issue for the user that they won’t be able to configure it as per their business structure. They will leave them vulnerable to a hacker.
Once the open-source software is fully developed, then it’s often that the online communities will grow indefinitely. Therefore, the community will provide continuous security updates and support. As a result, the product will be continuously in an improved state, and it will help the product to stay competitive by keeping up with the latest trends and features.
As we know everything has two sides, so let’s take a look at the darker side of open-source security now that we have seen the pretty picture. In the further section, we will let you know about some challenges of Open-Source Security, previous exploits and how the community overcomes the challenges.
Open-Source Security Challenges
Open source is no different. Just like all software, it has some vulnerabilities. During the remediation process, open-source community members help in reducing the flaws, but at the same time, they tend to open up the gap between open-source security and open-source attacks. All the details, from how to carry out the attack to how to exploit the vulnerabilities, are publicly available. As a result, this allows an attacker to gain the required information and carry out the attack.
As we know that the open-source community has pure Transparency about the product which means the source code is readily available to everyone in the world. Transparency has many advantages, but this also enables hackers to gain the necessary information to carry out the attack. So, the challenge comes here to track these loopholes and try to fix them. There are many platforms that provide information about open-source vulnerabilities. One of them is The National Vulnerability Database. The problem here is that these vulnerabilities are published on multiple platforms; thus, tracking them becomes difficult. Even if they have been located, updating, patching or fixing can require some time, and during that phase, you’d be at risk.
However, the Open-source software is free, but it comes with some license that allows the users to use, enhance and modify the source code. The problem with these licenses is that most of them don’t meet the required OSI and SPDX definition of open source. Sometimes, with so many licenses, there is bound to be some compatibility risk which means users have to use them together which will put users at some risk. Like using Apache 2.0 and GPL V2 together.
There are many source code libraries publically available. Sometimes the developer copies and pastes code from those libraries. Copy-pasting code from those libraries without verifying it leads to a security risk. Because some snippet contains some vulnerabilities and adding that code to your codebase means adding vulnerabilities in your software. once you added them to your codebase then there is no way to track or update the snippet.
Sometimes using open-source components may put enterprises at a security risk, Because of operational insufficiencies. Open-source components create a lot of additional work for teams, like keeping track of what components are used and updating them as new versions are available sometimes these updates may contain some high-risk vulnerability and delaying the updates means putting the system at some risk.
As with any open-source product, open-source software doesn’t come with a warranty for its security, support, or content. Although Some projects are supported, they are done by volunteers and their development can be halted at any time without warning. Usually, community members evaluate the software for security issues and provide support through open forums, although they are neither obligated to do so nor liable for incorrect guidance.
There are some vulnerabilities that were exploited previously, let’s take a look at some of them.
Apache Log4j2
Log4j is the Java library that is responsible for logging. In some scenarios application faces errors, in such scenarios enabling logging is one efficient way to track the issue. It is possible with the help of the log4j library package which tracks the events runtime without modifying the application binary.
The vulnerability in the Log4j java logging library package was discovered on 9th Dec 2021 which leads an attacker to execute an arbitrary code by sending requests to servers. This vulnerability has been published as CVE-2021-44228. Log4j affects Apache versions between 2.0 to 2.14.1.
Let’s understand the vulnerability, So, what log4j does is while parsing the logs, it inspects the input and tries to resolve the variable contained within the input. An interesting thing about log4j is it supports a JNDI(Java Naming and Directory Interface) library function which allows users to interstate with some protocols like LDAP, TCP, HTTP, and others. So, what an attacker does is he will send the string to the application which contains the address of the attacker’s own server, then the server will run the log4j process then log4j will evaluate that string and it will send a request to the attacker’s server.
The patch this vulnerability has released earlier which affected users should upgrade their Apache version with the latest one which is 2.15. If this is not possible then the user should remove the class JndiLookup from the java classpath.
Lodash
Lodash is the popular JavaScript library that provides 200+ utility functions for common programming tasks, which helps developers to write clean and easy to maintain JavaScript code.
The vulnerability in the Lodash library was discovered on 30th April 2020, which is called prototype pollution in lodash.js. which was published as CVE-2020-8203.
Before jumping into the vulnerability first we will understand what prototype pollution vulnerability is. JavaScript is prototype-based, Prototype-based is one type of Object-Oriented Programming, in which reuse is performed via a process of reusing existing objects that serve as prototypes. A prototype is an object which is associated with functions. So, the vulnerability that arises when an attacker makes changes to the objects by modifying them, is called prototype pollution.
The vulnerability was discovered in lodash function called zipObjectDeep(). This function allows users to modify the prototype of the objects if the object identifiers are user-supplied. Now let’s see how this functionality was exploited. So, first what the attacker will do is he will send maliciously crafted objects to zipObjectDeep() function. Then he will call zipObjectDeep() function, this will pass input objects and functions assigned to this object to baseZipObject() function. Then baseZipObject() function is passed to the baseSet function which is responsible for modifying the prototype and the interesting thing about this function is it doesn’t validate any input objects, then what the attacker will do is he will send a maliciously crafted prototype as an input to this function which will cause the prototype pollution attack. This prototype pollution attack can lead to Denial of Services or Code Execution.
Fix for this vulnerability has been released which can be fixed by using object.freeze() function which freezes the object or by defining the null object object.create(null). It also can be remediated by validating the input to check for added prototypes.
Cachet
Almost all Software-as-a-Service companies now provide status pages. As a result, startups created as-a-service status pages and offered open-source self-hosted options. Cachet for Cachet HQ is another example of Remote code execution. Cachet is a PHP-based system for displaying status pages. Security researchers from SonarSource have reported multiple vulnerabilities in Cachet alongside a Remote Code Execution tracked as CVE-2021-39172. The vulnerability is caused by improper handling of user input while updating email, server configuration.
Let’s understand how this vulnerability is exploited, First, the attacker will send a request to change email provider settings, the controller will initiate the object of UpdateConfigCommand class, then the laravel command will be executed on execute() call of the object. The UpdateConfigCommandHandler, is responsible for performing changes in the .env file by replacing existing entries with new entries. UpdateConfigCommandHandler triggers code in two different locations, First one is at SetupController@postStep3 once the instance is installed, this code path is not reachable further, as it is the last step of the setup process, the second one is at SettingsController@postMail, this is responsible for updating .env file entries. It first evaluates the full configuration file, then checks if the derivative to update is already defined, and replaces the entry with a new entry. the interesting thing is it does not validate incoming data, if the configuration entry already exists, it will be replaced with the value coming from the parameter, so what the attacker will do is he will send a value containing newlines, because of no incoming data validation, it will create a new entry in .env file. This will lead the attacker to execute arbitrary code in the system.
Vulnerabilities in open-source security pose a major challenge. And if you want to overcome the challenges, detecting and resolving them must be a priority. So, we will see some of these open-source best practices which are used to catch these vulnerabilities in time, before they affect any business.
How to Overcome these challenges
Testing open-source software and looking for vulnerabilities is fundamental for any organization those who are using or deploying open-source code. As soon as an organization scales their software, it becomes a very tedious task to track the health of the software. In this scenario, using an automation tool for identifying vulnerabilities is always the better option. Automated tools that monitor security problems help you protect your project and keep control over open-source components; if a possible breach is discovered, then automation tools notify through the notification system.
Source code for all Open-Source systems is constantly tested for flagged vulnerabilities raised in community posts, and when a vulnerability is fixed, the code owner releases a security patch to address it. In order to protect your applications from the risks associated with these releases, it is essential that you need to keep yourself up-to-date with them.
As we know nowadays, almost every organization uses agile methodology because it provides the reusability of code. But in the name of reusability, you should not copy-paste the code blindly or import libraries without checking. Therefore, as a precautionary measure, before reusing the code it is very important to run some standard security checks to verify the program’s security.
In conclusion, by involving many people who discover bugs quickly, open-source does not pose any significant security barriers but provides concrete examples of reusable, secure, and working code, as well as concrete benefits to business customers and the community.
Hacker | Blogger | Geeky I do have exposure to Web applications, Mobile Applications and Network security.
