Flaws Found in Some Open Source Projects Exploited More Often

 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: