Given their increasingly large attack surfaces, most organizations tie their vulnerability management cycle to vendor announcements. But initial disclosure of security vulnerabilities doesn’t always come from vendors, and waiting for official announcements can put you days, or even weeks, behind attackers, who discuss and share tutorials within hours of a vulnerability becoming known.
“Online chatter typically [begins] within 24 to 48 hours of the initial public disclosure,” says Levi Gundert, vice president of threat intelligence at Recorded Future, citing the firm’s in-depth analysis of discussions on foreign-language forums.
Vendor advisories, blog posts, mailing list messages, Homeland Security CERT alerts -- defenders aren’t the only ones reading these announcements. Knowing what piques attackers’ interest -- and how they plan to exploit holes before vendors can respond -- is a great way to get a jump on the next wave of attacks.
Last year’s Java object serialization flaw provides a perfect example. First disclosed in a conference talk in January 2015, the flaw didn’t attract attention until Nov. 6, when researchers at FoxGlove Security found that the issue impacted multiple core enterprise applications, such as WebSphere and JBoss. It took Oracle another 12 days and Jenkins 19 days to release formal announcements addressing the vulnerabilities in WebLogic Server and Jenkins.
Attacker communities, however, began discussing the FoxGlove Security blog post within hours, and a proof-of-concept exploit code appeared six days later, Recorded Future found. A detailed exploit tutorial describing how to execute the attack was available Nov. 13, five days before Oracle released anything. By the first week of December, attackers were already trading names of vulnerable organizations and specific links to trigger the flaw for those targets.
“Obviously the time between vulnerability recognition and vendor patch release or workaround is valuable for threat actors, but when detailed exploit guides are available in multiple languages, that time delta can be disastrous for businesses,” Gundert says.
The OPcache Binary Webshell vulnerability in PHP 7 is another example of attackers jumping ahead of the game. Security firm GoSecure described the new exploit on April 27, and Recorded Future uncovered a tutorial explaining how to use the proof of concept referenced in GoSecure’s blog post on April 30. As GoSecure noted, the vulnerability didn’t universally affect PHP applications. But with the resulting tutorial, attackers could have an easier time finding servers with potentially dangerous configurations that make them vulnerable to the file upload flaw.
“Even obscure blogs get picked up,” Gundert says.
For most people, GoSecure’s blog post went unnoticed. With so many competing reports, if a blog post doesn’t get much traction within defender communities, the potential attack vector it discusses is effectively overlooked. On the other side of the divide, however, attackers are discussing the flaw and sharing information and tools for exploiting it.
One reason why attackers get such a big jump on vendors and security pros is the vulnerability announcement process itself.
Vendor announcements are typically tied to when a security flaw gets a Common Vulnerability and Exposures (CVE) identifier. The CVE system is maintained by MITRE Corp., a nonprofit that acts as a central repository for publicly known information security vulnerabilities. When someone finds a security vulnerability -- whether it’s the application owner, a researcher, or a third-party entity acting as a broker -- MITRE receives a request for a new CVE.
Once MITRE assigns an identifier, akin to a Social Security number for vulnerabilities, the security industry, vendors, and enterprises have a way to identify, discuss, and share details of the flaw so that it can be fixed. In cases where the initial disclosure does not come from vendors, such as with the Java object serialization flaw, attackers have a head start over defenders still waiting for the CVE to be assigned.
This time difference is critical. Of course, with so many vulnerabilities to research, assess, and mitigate, but only finite security resources available to combat them, filtering out vulnerability reports based on whether the flaw has a CVE assigned is a “reasonable attitude,” and lets organizations err on the side of caution, says Nicko van Someren, CTO of Linux Foundation. The implication is that once a bug has a CVE, it exists and needs attention.
But lately, the CVE system itself has become a bottleneck. Several security professionals complain they cannot obtain CVEs for vulnerabilities from MITRE in a timely manner. The delay has an impact -- it is difficult to coordinate fixing a bug with software makers, partners, and other researchers if there isn’t a system to make sure everyone is referring to the same issue. Part of the current problem is scale, as the software industry is bigger than it was a decade ago, and vulnerabilities are found in greater quantities. As Recorded Future’s analysis showed, the delay in assigning the CVE gives attackers time to develop and refine their tools and techniques.
“There are lots of people that believe if there isn't a CVE then it isn't a real issue, and that is a huge problem,” says Jake Kouns, CISO of Risk Based Security.
Another issue is that not all vulnerabilities get assigned CVEs, such as web applications that are updated at the server and require no customer interaction. Unfortunately, mobile app vulnerabilities that require customer interaction to install an update are also not receiving CVEs. There were 14,185 vulnerabilities reported in 2015, 6,000 more than what was reported in the National Vulnerability Database and CVE, according to the 2015 VulnDB Report from Risk Based Security.
“The real value of the CVE system to consumers and information security practitioners is not actually measuring risk and security impact, but cataloging all known risks to a system regardless of severity,” says Kymberlee Price, senior director of researcher operations at BugCrowd.
Because CVE does not cover every exploit, you must look beyond the CVE to get a complete picture of what’s coming your way. This means you should stop pegging your vulnerability management activities exclusively to vendor announcements and start exploring other sources of information to stay on top of the latest disclosures. Your vulnerability management teams would be more effective if they looked for mentions of proof-of-concepts out on the web and signs of exploit activity within your environment.
There is a lot of public vulnerability information available beyond official vendor notifications -- so much so that defenders can’t be expected to stay abreast of all the blog posts disclosing various vulnerabilities, mailing list discussions between researchers regarding a particular security flaw, and other public notices. Instead of trying to subscribe to every possible mailing list and RSS feed, your vulnerability management team can go right to the forums and listen to what potential attackers are saying. That’s the best kind of advance warning.
“If I am responsible for vulnerability management in my organization, I would be paying attention to forum conversations, looking for substantial chatter about specific vulnerabilities,” Gundert says. “You won't catch a zero-day, but you will catch flaws that you will otherwise have to wait weeks to get guidance from vendors.”
As a threat intelligence company, Recorded Future wants enterprises to use its platform to listen for the threat chatter on forums -- English-speaking or foreign language -- but there are other options. Organizations can select a handful of forums, IRC channels, and other online sources to monitor discussions. In fact, Record Future analysts noted users consistently sharing posts written by individuals who appear to be recognized as a reliable source of information. Simply tracking what those "experts" are saying would help uncover conversations around the latest flaws. Keeping an eye on what is shared on GitHub can also go a long way to uncovering attackers’ plans.
Threat intelligence helps reduce the signal-to-noise ratio and uncover useful information, but it’s not the only way to find these conversations.
Defenders should keep an eye on their networks for increased scanning activity. An increase indicates the likelihood there are discussions on how to trigger vulnerabilities. For example, Recorded Future noted that scanning against the Groovy scripting engine in Elasticsearch started “almost immediately” after the disclosure of a remote code execution vulnerability. Forums were talking about ways to exploit and maintain persistence on compromised systems “over and over,” Gundert says.
Remote code execution flaws tend to trigger online chatter almost immediately. Local exploits, those that require the attacker to somehow gain a foothold on the device first, appear to not generate as much chatter.