Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Application Security

Flaws Found in Some Open Source Projects Exploited More Often

A study of major open source projects finds that 3.3% of vulnerabilities are exploited, but the rate of exploitation varies significantly.

 Vulnerabilities in major open source projects are not commonly turned into attacks — only 3.3% are "weaponized" — but at least one in 10 software flaws found in the most-targeted projects has had those weaknesses turned into exploit code, according to an analysis of 54 major open source projects published by security firm RiskSense on Monday.

The research used data on 2,694 vulnerabilities in the 54 open source projects, analyzing which issues had published exploitation code. Of the 89 weaponized vulnerabilities, or 3.3% of the total, only 18 allowed remote-code execution. Six are currently being used in active attack campaigns, RiskSense stated in the report.

"Our data shows that OSS vulnerabilities are a growing and increasingly critical part of an organization's attack surface," says Srinivas Mukkamala, CEO of RiskSense. "Managing vulnerabilities in those projects may require some added attention from both developers as well as security and IT staff."

The research suggests that companies should first concern themselves with the riskiest vulnerabilities — those that have already have published exploit code. In addition, some open source libraries — such as Vagrant, Artifactory, Chef, and JBOSS — should be given priority in patching because vulnerabilities in those projects tend to be exploited more often.

Vagrant, for example, is the project with the highest rate of weaponization for its vulnerabilities — out of nine issues discovered in the past five years, six have been exploited, for a rate of weaponization of 67%, RiskSense said. Ten of the 54 projects — Vagrant, Alfresco, Artifactory, Chef, Kaltura, SVN, Ansible, Redis, LifeRay Portal, and Odoo — had weaponization rates of 10% or higher.

Weaponization rates are "worth noting and monitoring going forward, as organizations should be aware of their software that is the most likely to be weaponized," RiskSense stated in its report.

The RiskSense report is not the first to underscore the risks that developers have accepted — perhaps unknowingly — when they use open source components to build software. In May, for example, application-security firm Veracode revealed that old or unpatched open source components left 71% of customers' software open to attack.

The variability in terminology and naming schemes also makes the organizations that use open source projects more likely to miss vulnerable components, according to a study by the Linux Foundation and the Laboratory for Innovation Science at Harvard University, which also confirmed the link between older software and greater vulnerability.

The open source projects themselves are often targeted by attackers. In May, GitHub revealed that more than two dozen open source projects were serving up malicious code after an attack compromised the developers' systems and replaced code objects created with the NetBeans IDE with Trojanized versions.

"In an OSS [open source software] context, it gives the malware an effective means of transmission since the affected projects will presumably get cloned, forked, and used on potentially many different systems," Alvaro Muñoz, a security researcher with the GitHub Security Lab, said in a blog post. "The actual artifacts of these builds may spread even further in a way that is disconnected from the original build process and harder to track down after the fact."

While the total number of vulnerabilities in the major projects studied by RiskSense jumped in 2019, compared with other years, the number of weaponized software flaws remained fairly level, with less than two dozen exploits for vulnerabilities published in any given year.

The number of vulnerabilities disclosed for a particular project varied enormously. The e-commerce project Magento, for example, had no published vulnerabilities in 2018, but 137 disclosed in 2019, according to the report. The variability in the number of vulnerabilities found in different projects is due to a variety of factors, says Mukkamala.

"Some vulnerabilities are naturally easier or more difficult to exploit, and ... certain types weaknesses are more prone to have associated exploits," he says. "So it often comes down to value of the target app, value of the exploit itself, and how hard it is to develop."

The report also found significant lag between the day a vulnerability is reported and when the issues is documented in the National Vulnerability Database, or NVD. On average, the NVD did not post information on a vulnerability until 54 days after it is disclosed.

The most common class of weaponized vulnerability has been cross-site scripting (XSS) issues with 11 exploited vulnerabilities in the 54 projects, with improper input validation coming in second with nine weaponized issues, and improper access control accounting for seven exploited flaws.

"In the worst cases, XSS can give an attacker control over a site, so they can be very impactful," says Mukkamala. "But certainly not every XSS falls into this category. ... On the other end of the spectrum, we only had one containerization vulnerability, but it was trending in the wild."

Related Content:


Veteran technology journalist of more than 20 years. Former research engineer. Written for more than two dozen publications, including CNET News.com, Dark Reading, MIT's Technology Review, Popular Science, and Wired News. Five awards for journalism, including Best Deadline ... View Full Bio

Recommended Reading:

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
Ransomware Is Not the Problem
Adam Shostack, Consultant, Entrepreneur, Technologist, Game Designer,  6/9/2021
How Can I Test the Security of My Home-Office Employees' Routers?
John Bock, Senior Research Scientist,  6/7/2021
New Ransomware Group Claiming Connection to REvil Gang Surfaces
Jai Vijayan, Contributing Writer,  6/10/2021
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Current Issue
The State of Cybersecurity Incident Response
In this report learn how enterprises are building their incident response teams and processes, how they research potential compromises, how they respond to new breaches, and what tools and processes they use to remediate problems and improve their cyber defenses for the future.
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2021-06-21
White Shark System (WSS) 1.3.2 has a SQL injection vulnerability. The vulnerability stems from the log_edit.php files failing to filter the csa_to_user parameter, remote attackers can exploit the vulnerability to obtain database sensitive information.
PUBLISHED: 2021-06-21
White Shark System (WSS) 1.3.2 has web site physical path leakage vulnerability.
PUBLISHED: 2021-06-21
White Shark System (WSS) 1.3.2 has an unauthorized access vulnerability in default_user_edit.php, remote attackers can exploit this vulnerability to escalate to admin privileges.
PUBLISHED: 2021-06-21
White Shark System (WSS) 1.3.2 has a sensitive information disclosure vulnerability. The if_get_addbook.php file does not have an authentication operation. Remote attackers can obtain username information for all users of the current site.
PUBLISHED: 2021-06-21
White Shark System (WSS) 1.3.2 has a SQL injection vulnerability. The vulnerability stems from the control_task.php, control_project.php, default_user.php files failing to filter the sort parameter. Remote attackers can exploit the vulnerability to obtain database sensitive information.