Kenna Security and Cyentia Research have released an analysis to compare software exploits against fix/patch cycles, showing that in a period of fifteen months, attackers had the upper hand for nine of them. This upper hand comes from about a quarter of vulnerabilities that were exploited before the vulnerability was even disclosed, and defenders taking about a month or more to apply patches once the patch became available.
The research report compared approximately 18,000 CVEs (Common Vulnerabilities and Exposures) disclosed in 2019, and found no real common path between vulnerabilities and exploits. The first appearance of a vulnerability fluctuated between the CVE and the patch almost equally (40% each) with exploit payloads being discovered first otherwise (about 20% of the time). Attackers encounter a much easier time exploiting software when it contains a known vulnerability, as they can simply leverage the exploit payload instead of crafting a custom attack. One sample tool that commonly generates deserialization attack payloads is ysoserial for Java and .NET, but other exploits can commonly be found to compromise weaknesses like CVE-2020-17530 in Struts2.
Exploitation metrics play a factor for both development teams, who produce patches, as well as operations teams that must deploy updates before their software is exploited. DevOps teams often focus on software composition analysis, helping development teams to understand which new libraries affect different code that is deployed and running.
While CVEs located in an application’s libraries and environment represent a risk, they are not the sole indicator to rely on for application security.
CVEs are most commonly listed in libraries and major software components, leaving a gap for a development team’s custom code.
Kenna’s analysis revealed that exploit code was often published before the CVEs, leaving the application vulnerable because the CVE does not exist but the exploit does.
In 2019, the public Docker OpenJDK image was serving a "mystery meat JDK," which leveraged a version number but did not contain the security patches to match. This meant that vulnerability checkers would report no CVEs when they were actually present.
Another issue is with usage and false reports of CVEs present without understanding if the vulnerable code ever loaded. This commonly occurred in older Java installations, where CVE analyzers would report applet-related vulnerabilities on backend systems that never used applets, or used a Java version that did not contain applets at all. This represents a risk manager’s koan: if vulnerable software is seen but never used, is it a risk?
Software risk continues between the time that a patch is released until the patch is actually applied. On the operations side, Kenna’s report indicates that it takes defenders about five months of patching and attackers about six months of hacking to reach about 80% of their target audience.
A key takeaway for development teams is the need to regularly patch and apply library updates on a regular basis. Automating this with tools such as GitHub Dependabot can prevent applications from being compromised like Equifax, however in every case the patch must be used and not just available.
