Exploit in the wild, exploitability, and likelihood of exploitation are all complex concepts and are often debated in cybersecurity by cybersecurity analysts in vulnerability management and application security professionals with developers.
Our modern digital landscape is riddled with vulnerabilities, and as cyber threats become increasingly sophisticated, organisations face the pressing challenge of identifying which vulnerabilities pose the most significant risk. Central to this challenge is the concept of vulnerability exploitability. But what exactly is it, and how does understanding exploitability aid organisations in fortifying their cybersecurity defences?
The notion of exploitability and exploitation in the wild can be derived using many factors
- Likelihood of exploitation (referred to as the probability of exploitation) with feed like EPSS and CISA KEV with degree of confidence
- Presence of verified or unverified exploits (referred to as exploitability in the article)
- Number of exploits link and popularity of exploits (based on the number of links for example)
- Easiness of exploitation from attackers like remote code execution, authentication requirements and local vs network attacks (some of those factors can be identified in the NVD CVSS attack string)
Exploitability and its meaning:
What is an exploitable vulnerability?
- A vulnerability that attackers can exploit to gain unauthorized access, disrupt services, or steal data. Exploitable vulnerabilities pose a significant risk.
What is the meaning of exploitability?
- Exploitability refers to the likelihood of exploitation; the likelihood of exploitation forms the exploitability factor, the popularity of exploits and the availability of those exploits.
- The likelihood of exploitation can be driven by factors such as
- Availability of exploit
- Popularity of exploits
- likelihood of exploitation in the next 30 days (e.g. CTI and cybersecurity intelligence)
- The popularity of exploit (e.g. CISA KEV Top routinely exploited vulnerabilities)
- Attack method and attacker using a specific vulnerability
- Reachability and location from the network perspective of assets that have a specific vulnerability
- Reachability and location of the specific code that is vulnerable and even the likelihood of that piece of code to be called.
- Other factors are attack vectors, complexity, privileges required, etc.
- A High exploitability means the vulnerability can be easily weaponised or is very likely to get exploited.
What are the factors that affect the exploitability of vulnerability?
- Attack vector, complexity, required privileges, user interaction, scope, impact, availability of exploit code, etc. Remote code execution makes a vulnerability very exploitable.
What is an example of vulnerability exploitation?
- Log4Shell, SolarWinds, MS Exchange Server exploits are examples of how attackers exploited vulnerabilities to breach major corporations.
What are the big vulnerabilities in 2023?
- As per reports, top vulnerabilities include Log4j, Atlassian Confluence, ForgeRock, VMware vSphere Client, Sophos Firewall, and Citrix vulnerabilities.
Which vulnerability is exploited the most?
- As per data, cross-site scripting (XSS) and SQL injection vulnerabilities are among the most exploited currently.
Deciphering Exploitability: The Anatomy of Threat Prioritization and the data behind vulnerability priority
At its core, exploitability in cybersecurity refers to the likelihood of a vulnerability being exploited by malicious entities. This is not just a measure of technical feasibility but a composite of several factors that can augment or diminish this likelihood.
Top 10 Vulnerabilities by Criticality:
- Oracle
- Apache
- Debian
- Microsoft
- Fedoraproject
- Redhat
- VMware
- NetApp
- Zohocorp
Criticality typically aligns with the potential effect of an exploit. Nonetheless, this concept is very static and defined as a point in time. For instance, vulnerabilities within systems provided by Oracle or Apache are of high concern, given their widespread deployment across industries. The high placement of Microsoft underscores the broad user base of its products, making it a lucrative target for cybercriminals. The diagram below provides a more granular overview of the products associated with each vendor and how many critical or exploitable vulnerabilities are available.
Exploit/Vulnerability Recheability Code and Network are differnet
Reputation and source credibility play monumental roles in gauging the exploitability of specific vulnerabilities. The CISA KEV is a testament to this, offering actionable insights from a credible vantage point we’ve explored how EPSS and cisa kev interconnect.
Asset positioning is another determiner. A vulnerability on a frontline server is at a higher risk than one in an isolated testing environment. While those are directly applicable to infrastructure vulnerabilities, code-related vulnerabilities have some additional complexity. The concept of recheability is discussed more in this talk/article
Reachability of a function/code: for code, there is a concept called reachability that helps indicate whether a function is even called in a library or a piece of code. While static analysis tools and library analysis tools can indicate a “potential” vulnerability in a piece of code inside a library does not mean that the particular piece of code will be called upon in the execution of the program.
Phoenix Security can help with Prioritization and a risk-based approach to vulnerabilities
if you want to know more about Phoenix Security and doing vulnerability management at scale, contact us https://phoenix.security/request-a-demo/
Get an overview of your asset lineage
The Exploitability and Vulnerability Popularity Paradigm: Not All Vulnerabilities Are Equal
It’s not just about the potential damage a vulnerability can cause but also about how often it’s being mentioned and exploited.
Those two factors are extremely different but correlated.
The likelihood of exploitation defined by popularity is driven by how easily an exploit is available to an occasional non-experienced attacker.
The retrieved vulnerable data brings to light the correlation between exploitable and popular vulnerabilities.
Top 10 Vulnerabilities by Popularity:
- Microsoft
- Oracle
- Debian
- Apache
- NetApp
- Redhat
- Apple
- Fedoraproject
- Atlassian
For example, while Oracle tops the list in terms of criticality, Microsoft leads in terms of popularity. This might be due to the sheer ubiquity of Microsoft’s products, making it a frequent target. On the other hand, while Apple’s ecosystem is often lauded for its security, it’s still among the top 10 in terms of exploit popularity, reflecting the potential gains for attackers.
EPSS: Predicting Exploits Before They Occur and edge case, differences with Exploitability
The Exploit Prediction Scoring System (EPSS) is a great resource of information that brings a predictive lens to cybersecurity. Instead of merely being reactive, this system anticipates which vulnerabilities will most likely be exploited. How does it accomplish this? We’ve explored EPSS here for more details, for this article, let’s dissect EPSS:
- Foundational Philosophy: EPSS operates on the principle that not all vulnerabilities are exploited. Thus, by understanding the patterns and characteristics of those, one can better predict future exploitations.
- Data-Driven Analysis: EPSS gleans insights from a rich tapestry of data sources, encompassing years of historical data on vulnerabilities, exploits, and real-world attacks. It harnesses the power of machine learning, using this vast dataset to forecast exploitability.
- Dynamic Scoring: Traditional vulnerability scoring systems often rely on static factors, offering a real-time snapshot. In contrast, EPSS provides dynamic scores that evolve as the threat landscape changes, making it responsive and relevant.
- Interplay with Other Systems: EPSS doesn’t operate in isolation. It complements existing systems like the Common Vulnerability Scoring System (CVSS). While CVSS provides an inherent risk score based on the characteristics of the vulnerability, EPSS augments this with a predictive exploitability score.
Top 10 by Weighted Average EPSS:
- Oracle
- Microsoft
- Apache
- Debian
- Redhat
- Atlassian
- VMware
- F5
- GNU
- NetApp
By marrying the foundational risk assessment of vulnerabilities from systems like CVSS with the predictive analytics of EPSS, organizations gain a 360-degree view. For instance, when analyzed through the lens of EPSS, Oracle’s vulnerabilities indicate a higher likelihood of future exploitation. This can guide proactive defence strategies, patch prioritization, and more.
With EPSS, organisations can transition from a reactive stance, often likened to ‘firefighting’, to a proactive posture, where potential threats are neutralized even before they manifest. In the dynamic world of cybersecurity, anticipating threats is invaluable, and EPSS is the torchbearer of this paradigm shift.
With context and reliability, together with popularity and delta scores, you can have an excellent overview of what’s more exploitable and what are the upcoming trends.
Zero Day, New Vulnerabilities Exploited and Red Herrings
The exploitability and popularity of exploit feeds like EPSS and CISA KEV and the popularity of exploits. During the initial days of an exploit, the sources of information and popularity are low. Cyber threat advisories and dedicated cyber threat intelligence provide a better source of trustworthy information for those types of vulnerabilities.
Other sources like google zero day and zero day initiative are great resources for discovering new trends.
Edge Cases Log4j, and new vulnerabilities
While EPSS, the Popularity of exploitation, could potentially lead on the wrong path in the initial 15 days of an attack, it can help analysts focus on the more easily exploited vulnerabilities and free time to identify where new trends are emerging. Another factor that we are exploring is the speed of popularity. For Log 4j and other popular vulnerabilities, the number of links was growing at a rhythm of new exploit with a steep uptake of 75-250% is a good indicator of a new trend.
Source Hacker 1 hacktivity report
On the other hand, identifying a vulnerability at the very beginning can be critical.
Some edge cases: CVE-2023-38408, where at the beginning, the EPSS score and popularity score were quite low
From Phoenix Security Presentation – let’s go on a DATA with vulnerabilities
Another exciting aspect is the correlation between CISA Kev and EPSS score increase. Since 2021 when CISA KEV was established, the vulnerabilities started increasing in the EPSS dataset. Note that some of the scores increased after EPSS v3 March 7, 2023 that coincide with an increase in scoring.
CISA Kev Data analysis from Andrey L,
Why Exploitability Matters: Targeting the Right Threats
Knowing which ones to prioritise is paramount in the vast sea of vulnerabilities. Focusing on exploitability helps organisations channel their resources efficiently. It’s a guiding light, illuminating which vulnerabilities are mere distractions and which demand immediate attention.
Reputable sources play a crucial role here. Tools like CISA KEV, and its visualisation through resources like the CISA KEV Data Explorer, offer invaluable insights. These platforms don’t just provide raw data; they provide context, helping organisations discern patterns, trends, and impending threats.
How Phoenix Security Can Help:
Phoenix Security is a platform that collects information from various sources, contextualizes, and prioritizes vulnerabilities from code to the cloud leveraging CVSS 3, Contextual information, Cyber threat intelligence.
Phoenix security takes into account all the factors above, enables a quick assessment based on risk and a selection of which vulnerability is more exploitable.
CWE attack methods – What is CWE, and how it relate to CVE
The Common Weakness Enumeration (CWE) is a community-driven project sponsored by the US Department of Homeland Security. It serves as a formalized list and categorization of known software weaknesses. These weaknesses represent vulnerabilities in software applications that can lead to security breaches. The primary goal of CWE is to stop vulnerabilities at the source by educating developers, researchers, and educators about potential problems in software design and coding.
Key Features of CWE:
- Standardized Weakness IDs: Every known software weakness is assigned a unique CWE ID, which facilitates easier referencing and communication among security professionals.
- Hierarchical Structure: Weaknesses are structured in a hierarchy, from abstract high-level classes to specific, detailed vulnerabilities. This hierarchy aids in understanding relationships between different weaknesses.
- Detailed Descriptions: For every weakness, CWE provides comprehensive descriptions, common consequences, potential mitigations, and illustrative examples.
- Community-Driven: The CWE list is not static. It evolves with the contributions from the global community, ensuring that it remains up-to-date with emerging threats.
Why CWE Matters:
- Developer Awareness: By understanding and referencing CWE, developers can anticipate and prevent vulnerabilities during the software development lifecycle.
- Security Analysis: CWE aids security professionals in vulnerability assessment, penetration testing, and software assurance tools by providing a common language and standard for vulnerability identification.
- Risk Management: Organizations can prioritize remediation efforts by understanding the nature and impact of different weaknesses.
CWE serves as both a knowledge base and a lingua franca for the cybersecurity community, enabling proactive software security and fostering global collaboration.
CWE and attack methodology patterns
In the dataset, various vulnerabilities showcase fluctuating patterns of prominence:
- Improper Input Validation (CWE-20), with 160 instances, is prevalent and denotes a recurrent problem with how user inputs are handled across various software.
- Out-of-bounds Write (CWE-787) is represented 181 times, pointing to the software’s ongoing challenges with managing memory boundaries correctly.
- Use After Free (CWE-416), with 83 instances, indicates issues where software references memory after it has been freed, leading to unpredictable outcomes.
Vulnerabilities with the Highest Top 25 Scores:
- CWE-787: Out-of-bounds Write with a score of 63.72.
- CWE-79: Improper Neutralization of Input During Web Page Generation (‘Cross-site Scripting’) with a score of 45.54.
- CWE-89: Improper Neutralization of Special Elements used in an SQL Command (‘SQL Injection’) with a score of 34.28.
- CWE-416: Use After Free with a score of 16.71.
- CWE-78: Improper Neutralization of Special Elements used in an OS Command (‘OS Command Injection’) with a score of 15.65.
Vulnerabilities Present Across All Datasets (NVD, Hacker 1, Cisa Kev, Github):
- CWE-79: Improper Neutralization of Input During Web Page Generation (‘Cross-site Scripting’)
- CWE-787: Out-of-bounds Write
- CWE-89: Improper Neutralization of Special Elements used in an SQL Command (‘SQL Injection’)
- CWE-22: Improper Limitation of a Pathname to a Restricted Directory (‘Path Traversal’)
- CWE-20: Improper Input Validation
Looking further:
- Path Traversal (CWE-22), with 162 instances, emphasizes issues with how the software handles file paths, potentially allowing unauthorised access to files.
- An entry like NVD-CWE-noinfo with a whopping 467 instances indicates many vulnerabilities where the exact weakness isn’t classified, pointing to a potential gap in vulnerability documentation or emerging threats that are yet to be categorized.
- OS Command Injection (CWE-78) at 144 instances underlines the perils of mishandling user data that interacts with OS commands, a challenge, especially in web applications and server environments.
A few vulnerabilities, like Off-by-one Error (CWE-193) and the Use of Insufficiently Random Values (CWE-330), are less frequent. Still, they shed light on more nuanced coding errors and potential areas that might not get as much attention but can still have significant implications if exploited.
CWE Commonalities Across Data Sources
- Most Reported Vulnerabilities Across All Datasets:
- CWE-79: Improper Neutralization of Input During Web Page Generation (‘Cross-site Scripting’) with a total of 101,320 reports.
- CWE-200: Exposure of Sensitive Information to an Unauthorized Actor with a total of 57,171 reports.
- CWE-287: Improper Authentication with a total of 20,233 reports.
- CWE-89: Improper Neutralization of Special Elements used in an SQL Command (‘SQL Injection’) with a total of 16,214 reports.
- CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer with a total of 14,011 reports.
Note that the NVD score dwarfs all the other datasets; hence we excluded it from the plot above.
For a complete view, you can inspect the diagram below:
Moving from Reactive to Proactive with Phoenix
Traditional vulnerability management often takes a reactive approach, responding to threats as they arise. However, this method is no longer sustainable. With the sheer volume of vulnerabilities, a reactive approach is akin to playing an endless game of whack-a-mole.
Phoenix champions a shift towards a risk-based approach. Instead of reacting to every vulnerability, the focus is on the critical 1% that truly matters. By understanding vulnerability exploitability, the position of assets, and the potential business impact, organizations can prioritize their efforts more effectively.
Commonalities and patterns across CISA KEV, NVD, Exploitability Dataset CWE
- Exploitability dataset Emphasizes on NVD-CWE-noinfo with 467 instances, indicating a gap or emerging threats not yet categorized. This doesn’t appear in the other datasets.
- NVD Dataset: Features a broader list of vulnerabilities compared to the other datasets, such as CWE-190 Integer Overflow and CWE-502 Deserialization of Untrusted Data, suggesting a more comprehensive collection of vulnerabilities, whether or not they are frequently exploited.
- Hacker 1 Dataset: Highlights what’s being actively exploited. For instance, CWE-200 (Exposure of Sensitive Information) is second on this list but isn’t prominent on GitHub and only mid-tier on NVD. This suggests that even if a vulnerability type isn’t the most common, it can still be very attractive to attackers if it provides high value.
- Exploitability reflects vulnerabilities currently available on the public web and possibly fixed in open-source projects. It provides insights into what developers are struggling with now.
- NVD dataset represents a broad spectrum of known vulnerabilities. As a more comprehensive list, it’s an invaluable resource for understanding the threat landscape over time.
- Hacker 1 dataset provides insights into attacker behaviour and what vulnerabilities are being actively reported. It underscores the difference between known vulnerabilities and those of actual interest to attackers.
In conclusion, while some vulnerabilities remain consistently prominent across all datasets, each provides a unique perspective. For a holistic cybersecurity approach, it’s crucial to understand the prevalent vulnerabilities and those that attackers actively exploit.
The top attack methodologies found in the analysed dataset of exploitable vulnerabilities are the followings:
| CWE Number | Description | CWE Top 25 Score | Cisa Kev | Exploitability Dataset Mention |
| CWE-79 | Improper Neutralization of Input During Web Page Generation (‘Cross-site Scripting’) | 45.54 | 15 | 362 |
| CWE-787 | Out-of-bounds Write | 63.72 | 64 | 181 |
| CWE-89 | Improper Neutralization of Special Elements used in an SQL Command (‘SQL Injection’) | 34.28 | 14 | 171 |
| CWE-22 | Improper Limitation of a Pathname to a Restricted Directory (‘Path Traversal’) | 14.11 | 43 | 162 |
| CWE-20 | Improper Input Validation | 15.5 | 75 | 160 |
| CWE-119 | Improper Restriction of Operations within the Bounds of a Memory Buffer | 4.76 | 75 | 152 |
| CWE-78 | Improper Neutralization of Special Elements used in an OS Command (‘OS Command Injection’) | 15.65 | 50 | 144 |
| CWE-434 | Unrestricted Upload of File with Dangerous Type | 10.42 | 16 | 108 |
| CWE-502 | Deserialization of Untrusted Data | 5.56 | 25 | 106 |
| CWE-200 | Exposure of Sensitive Information to an Unauthorized Actor | 0 | 19 | 96 |
| CWE-94 | Improper Control of Generation of Code (‘Code Injection’) | 3.31 | 32 | 91 |
| CWE-416 | Use After Free | 16.71 | 51 | 83 |
| CWE-352 | Cross-Site Request Forgery (CSRF) | 11.73 | 2 | 69 |
| CWE-287 | Improper Authentication | 6.39 | 19 | 65 |
| CWE-269 | Improper Privilege Management | 3.32 | 31 | 61 |
| CWE-77 | Improper Neutralization of Special Elements used in a Command (‘Command Injection’) | 4.95 | 17 | 59 |
| CWE-125 | Out-of-bounds Read | 14.6 | 6 | 46 |
| CWE-863 | Incorrect Authorization | 3.16 | 8 | 43 |
| CWE-362 | Concurrent Execution using Shared Resource with Improper Synchronization (‘Race Condition’) | 3.54 | 8 | 42 |
| CWE-918 | Server-Side Request Forgery (SSRF) | 4.56 | 7 | 41 |
| CWE-306 | Missing Authentication for Critical Function | 3.79 | 8 | 39 |
| CWE-120 | Buffer Copy without Checking Size of Input (‘Classic Buffer Overflow’) | 0 | 3 | 35 |
| CWE-74 | Improper Neutralization of Special Elements in Output Used by a Downstream Component (‘Injection’) | 0 | 13 | 34 |
The Phoenix Paradigm: Towards Proactive Cybersecurity
Acknowledging and understanding exploitability is half the battle. The other half is strategic action, fortified with the right tools and insights.
Phoenix’s methodology isn’t about patching every chink in the armour; it’s about fortifying the most vulnerable and critical sections. This approach hinges on:
- Likelihood of Exploitation: Tools like Exploitability in the wild main drivers shed light on active threat landscapes.
- Actual Chances of Exploitability: EPSS scores ensure a balanced approach, focusing on present vulnerabilities and potential future threats.
- Verified Exploitation Sources: Platforms like CISA KEV and databases like Metaexploit validate assessments with real-world data.
- Business Implications: Beyond the technical realm, it’s imperative to gauge the cascading impacts on business operations, stakeholder trust, and revenue streams.
Risk-Based Prioritization: The Way Forward
Addressing vulnerabilities as they’re discovered is tempting, but this reactionary approach often spreads resources thin. Instead, organisations should adopt a risk-based prioritisation strategy, where vulnerabilities are addressed based on their potential impact and likelihood of exploitation. This approach revolves around several key considerations:
- Likelihood of Exploitation: Using tools that provide insights into potential exploits, such as Exploitability in the wild main drivers, can help assess which vulnerabilities are most likely to be exploited.
- Actual Chances of Exploitability: The EPSS score, a measure that predicts the likelihood of a vulnerability being exploited in the wild, provides a more nuanced understanding of exploitability than traditional metrics.
- Verified Sources of Exploitation: Platforms like CISA KEV and databases like Metaexploit give weight to exploitability assessments by confirming real-world exploitation instances.
- Business Impact and Consequences: Beyond technical implications, organisations must assess how a vulnerability can impact operations, brand reputation, and bottom lines.
Phoenix Security: Pioneering Proactive Cybersecurity
While understanding exploitability is crucial, implementing a risk-based approach requires more than just knowledge. It demands the right tools, expertise, and a mindset shift.
This is where Phoenix Security shines.
Phoenix focuses on the vulnerabilities that matter most. By harnessing risk-based prioritisation, Phoenix ensures that organisations stay aware of the noise of countless vulnerabilities. Instead, they zero in on that critical 1% that poses genuine threats.
Phoenix’s approach takes into account:
- The likelihood of exploitation is based on real-world data and trends.
- Authentic chances of exploitability using EPSS scores ensure that assessments aren’t just theoretical and rooted in reality.
- Verified sources of exploitation, such as CISA KEV, to add an additional layer of credibility to vulnerability assessments.
- The potential business impacts and consequences of vulnerabilities ensure that risk assessments are holistic and aligned with organisational goals.
In essence, Phoenix shifts organisations from a reactive posture to a proactive one. Instead of scrambling to address every vulnerability, organisations can confidently address threats that matter, ensuring optimal resource allocation and robust cybersecurity defences.
Get an overview of your asset lineage
Conclusion: Navigating the Future of Cybersecurity
The digital supply chain from ops to dev will always be peppered with vulnerabilities. But understanding exploitability, aided by reliable tools and a risk-based approach, ensures that organisations can confidently navigate this challenging landscape.
Phoenix Security champions this vision, empowering organisations to move from frantic vulnerability patching to strategic, informed cybersecurity. Ultimately, it’s not about addressing every vulnerability—it’s about focusing on the ones that matter most.
Embrace a proactive, risk-based approach. Prioritise with precision. Secure the future with Phoenix Security.
