Thousands of software vulnerabilities are made public each year, leaving IT and security teams to sift out irrelevant issues from the bugs that need to be fixed. Rapid7’s latest community-based project brings crowd-sourced feedback to enterprise defenders to help them figure out which flaws to pay attention to.
The Attacker Knowledge Base is intended to help security professionals assess the impact of a vulnerability to an organization and triage threats. The web platform will act as a central repository of information on vulnerabilities to help defenders determine how easy it would be for someone to weaponize the vulnerability, or to determine how much access an attacker would gain in the organization’s network.
“The process of monitoring and triaging new vulnerabilities is so time-consuming and effort-intensive that it often detracts from defenders’ ability to mitigate risk quickly and decisively,” wrote Caitlin Condon, Rapid7’s manager of software engineering.
It is not controversial to say that organizations don’t have to worry about every single software vulnerability. A manufacturing plant focused on protecting its control systems doesn’t need to worry about vulnerabilities in video conferencing software. A law firm likely won’t care about issues in industrial control systems. Organizations need to pay attention to vulnerabilities that are relevant to their businesses and not spend time on issues that don’t effect them.
But when a vulnerability becomes public, the security community has to act quickly to understand the threat and the potential business impact. Enterprise defenders are asking the same questions across multiple organizations, but they can't readily tap into discussions happening outside their own. Answers and discussions are scattered across social media, news reports, blog posts, and other discussion forums. Each team has to figure out how the vulnerability impacts their environment and how to triage the threat. The entire process could be far more efficient and thorough if the defenders could hear what others in the community had already found and tried.
"When a new vulnerability prompts discussion on Twitter or hits media outlets, the security community collectively participates in a familiar triage process: Is the bug pervasive, exploitable, or both? Is it worth dropping everything to patch or mitigate? Is the expected shelf life long enough that it's worth developing an exploit for? Or is it actually...not useful or interesting?," Condon wrote in a blog post announcing the closed beta of AttackerKB back in January.
Advice and Analysis
On paper, a remote code execution vulnerability which doesn't require authentication and can lead to a complete system compromise can seem as serious a threat to an organization's network as another RCE flaw. Perhaps the first RCE is easier to weaponize, and a working exploit is much more likely than the second one. That level of analysis—that one vulnerability is more attractive than another to the attacker despite being similar—is valuable for entperise defenders, since they can then focus their energies on the one that would more likely be used in an attack.
Or there may be an information leakage flaw that doesn't seem as big a deal, but when combined with a different privilege escalation flaw, could be used to cause widespread damage in enterprise networks. Researchers can discuss what they have learned about the vulnerability and how it can be combined with other vulnerabilities. Defenders get a better understanding of what can happen with the vulnerability rather than just relying on the technical information in the security advisory.
Penetration testers may have developed, or seen, fully functional and reliable exploit chains during various client engagements over the years. A centralized place to "chronicle the insights and the data they’ve amassed" make a difference for defenders as they can develop plans to block these attack methods.
"Patch, but don’t freak out." (AttackerKB entry for CVE-2019-14287)
The front page of the Attacker Knowledge Base.
The AttackerKB thread discussing CVE-2020-3952, the the information disclosure flaw in VMware's vCenter Servier is a good example of how information from different sources can be collected into one centralized location. The thread contained links to the advisory, the original research from Guardicore, and a detailed Twitter thread discussing the bug.
A vulnerability in sudo which would let users run commands as the root user was publicized last October. It seemed like a big deal, except it impacted a very niche set of targets, Linux systems with very specific, non-standard configuration settings. Comments on the AttackerKB thread ranged from, "There are far more scary privilege escalations for Linux out there, and this one is pretty easy to patch," "I’ve seen Runas specifications on exactly two servers in the wild," "Due to being almost 100% non-existent in the wild, this is only useful in CTF environments," and "Patch, but don’t freak out."
Having specifics on why a scary-sounding vulnerability is not an all-hands-on-deck situation is helpful.
Details of a potentially wormable remote code execution vulnerability in the Microsoft Server Message Block 3.1.1 (SMBv3) protocol (CVE-2020-0796) accidentally leaked in March before Microsoft had a security patch ready. AttackerKB users started sharing their own assessments of the risks and links to proof-of-concept code as they became available. The vulnerability appeared to be valuable to for attackers because it affected many enterprises, but several users noted that it was difficult to weaponize. “Due to modern mitigation technologies, exploiting this vulnerability remotely to obtain code execution is non-trivial,” a user wrote on the thread.
Shortly after the vulnerability leaked, but before Microsoft released its out-of-band update, another AttackerKB user wrote, “[with] everyone Coronavirus sequestered, you’re unlikely to inflict any sort of at-scale exploitation if everyone’s at home on a host-isolated VPN and literally inaccessible from a mass networking PoV in an office. Hey, maybe working from home is good for security!”
That kind of context is extremely useful for enterprise defenders.
A thread discussing BlueKeep, the use-after-free vulnerability in the Windows Remote Desktop protocol, discussed the difficulty in developing an exploit (“this requires an understanding of your targets Host devices”) and shared links to proof-of-concept code. One user provided information about how the vulnerability could be exploited in cloud-based systems. Another posted things to remember to do when patching the flaw, such as restarting (“Must restart.”) the system.
Discussion, not Consensus
Security professionals can post their analysis of the vulnerability via GitHub and many of the answers in the knowledge base came from surveys completed by security researchers, engineers, and product managers. Over the past three months in closed beta, security professionals "shared their personal experiences, in-depth technical analyses, expert opinions, and mitigation advice," Condon wrote.
If AttackerKB is to be a marketplace of ideas for the security community to discuss emergent vulnerabilities and how defenders should deal with them, discussion is essential. Trying to force everyone to adopt a single viewpoint or to look for a consensus opinion will not work because teams have different environments, risk appetities, and priorities. There may be situations where different people will view the same vulnerability with varying levels of alarm, and that is okay, because everyone has access to the information and analysis to make judgement call based on what makes sense for their situation.
Beyond CVSS
AttackerKB could help enterprise defenders go beyond looking at the Common Vulnerability Scoring System to determine the impact of the vulnerability in their environment. The assumption is that a flaw with a CVSS score of 9 is a more serious problem than one that has a score of 4—but that doesn’t tell the whole story. CVSS reflects technical exploitability, and that isn’t necessarily the same as the likelihood of being exploited, or even more importantly, what the impact of an exploit would look like. Attackers do not incorporate a vulnerability into their operations just because the CVSS is high—they are just as likely to use a bug with a low CVSS score if they can accomplish their goals with a less expensive attack.
Past research from Cyentia Institute and Kenna Security found that a vulnerability management strategy focusing on flaws with a CVSS score of 7 or higher meant the security team missed 47 percent of the issues they needed to address.
Consider 2014’s Heartbleed vulnerability in OpenSSL, which had a CVSS score of just 5. From a technical standpoint, the kind of information which could be leaked (private information, security keys) was limited to what was in the component’s memory at the time. An attacker would not be able to directly compromise the system, execute code, or make the system unavailable. However, the impact of Heartbleed was high, as it could potentially impact the security of SSL certificates and passwords used by websites and online services. In contrast, the Meltdown and Spectre vulnerabilities had high CVSS scores, but they are also extremely difficult to exploit.
“When security practitioners raise the alarm to stakeholders, they must be confident in their understanding of a threat and its potential business impact,” Condon said.
Community Collaboration
AttackerKB is not intended to replace the Common Vulnerabilities and Exposures (CVE) catalog and the National Vulnerability Database (NVD) from the National Institute of Standards and Technology (NIST). According to NVD, there were about 17,300 vulnerabilities announced in 2019, and 2020 has already uncovered more than a third of the number—and it is only April. CVE and NVD aren't considered complete, since they exclude vulnerabilities in certain types of products (CVE doesn’t include web platform issues, for example). Nor is the goal to replace any of the private vendor-based repositories or community-driven databases.
AttackerKB will depend on community members willing to contribute their assessment of a vulnerability—which means it may not have historical vulnerabilities, and may not have every new flaw that is discovered in hardware and software. If information about a flaw is not available on AttackerKB, that doesn’t put the enterprise defenders any worse than they were before. AttackerKB is just another source of information the defenders can have when evaluating a vulnerability in order to develop a mitigation plan.
"We’re excited to collaborate with folks from every part of this industry to boost signal, stomp out noise, and highlight the hot takes and measured technical assessments that, together, do the necessary (and sometimes messy!) work of moving this industry forward," Condon wrote.