Problems with open-source implementation
Open-source software components are a part of practically every development team’s standard practice and most organizations’ offering to their customers throughout all industries and verticals. The numbers speak for themselves: today, open-source software components compromise between 60% to 80% of most organizations’ code base.
More and more companies ask themselves: should they implement open-source code in their environments, but developers have no way of knowing their level of quality or safety. When organizations don’t invest in managing their open source usage, they put themselves at risk.
The prevailing assumption is that open source is safe for use and has been tested by its many users and companies. Let us show you some example of the other side of the coin:
“A Backdoor in a popular open-source framework has affected an estimated 28 million users. According to security firm Synk, a malicious version of web development tool Bootstrap-Sass has been published on the official RubyGems repository. The researchers found a backdoor that enables hackers to conduct remote command execution on server-side Rails applications.”
The Inquirer - Backdoor in popular open-source tool put 28 million users at risk
Another example is the Docker Engine;
“At the tail end of 2018, a significant vulnerability in Google’s Kubernetes open-source controller for container orchestration was found, catching plenty of folks off guard as Kubernetes has become a core infrastructure tool throughout the industry”.
WhiteSource - Top 5 New Open Source Vulnerabilities in January 2019
“An audit released today by the Cloud Native Computing Foundation has uncovered no fewer than 34 vulnerabilities in the code for Kubernetes, the highly popular open-source container orchestration system.”
siliconAngle - Security audit reveals 34 vulnerabilities in Kubernetes code
According to the findings by MITRE, this vulnerability could allow attackers to cause a denial of service (DoS) on the system.
In order to mitigate open source risks, we need to track the open source components that we are using, including all their dependencies.
The best way to ensure we are one step ahead of the risks, without missing a beat, is to perform Code Review (manual or automatic tools) and search the following things in the code, for example, How identify Backdoors in the code:
Backdoor is an example of implemented code in the program that allows hackers to enter the system without fingerprint or any permission.
- • Unconventional Ports – search for high ports which may use to open suspicious connection.
- • Check for import of suspicious libraries – if you don’t recognize the import libraries search for more security info on the internet.
- • Check for using registry values or local files – check what does this registry value doing and why they need to change it.
- • Check for external suspicious connection such as WebSocket, HTTP, UDP, ICMP, SMTP, etc.
Example of How identify Vulnerability in the code:
Vulnerability is a weakness which can be exploited by a threat actor, such as an attacker, to perform unauthorized actions within a computer system
- • Check the user input– if there is any sanitation on the input values to prevent attacks like XSS, SQL Injection, etc.
- • Check for default hardcoded hashes and keys in the code – look for use in string hashes and difficult encryption keys.
- • Run source code analysis tools.
- • Check for known vulnerabilities –
- o Check for Known CVE’s
- o Check for unfixed and submitted issues in the code’s repository
- • Search Google for the combination of the source code’s application name and keywords like “hack”, “exploit”, “vulnerability”, “bypass,” etc.
- • Check for latest security updates of the implemented source code by the developers.
In conclusion, we can see that although open source can give us huge advantages, we need to think twice, double-check the code and not trust the open-source community to do that for us.
Back
