Software vulnerabilities are often the cause of some of the most impactful incidents in cybersecurity. Log4Shell, MOVEit, ScreenConnect, Spring4Shell, and Follina are Common Vulnerabilities and Exposures (CVEs) that even those unfamiliar with information security are likely to have heard of – and these are only a small handful. Critical vulnerabilities, especially those within common third-party software solutions provide a tempting entry point for opportunistic threat actors, leaving security teams scrambling to apply relevant mitigations as fast as possible. Thus, it is critical for these teams to combine timely information with a robust patch prioritisation process.
In this post we’ll dive into the impact of some of the vulnerabilities above before showing how customers can utilise Silobreaker to prioritise and track vulnerabilities in real-time.
Recent critical vulnerabilities and their impact
ScreenConnect
On February 19th, 2024, ConnectWise released a security advisory for its remote desktop support application, ScreenConnect, commonly used in enterprise environments both in cloud and on-premises. The security advisory warned on-premise customers of two vulnerabilities: one of which later received the highest critical base score. Exploiting this vulnerability was extremely trivial and meant mass exploitation had already begun.
ConnectWise released updates to mitigate the vulnerabilities soon after and even suspended instances not running the latest versions. However, the damage had already been done. In-the-wild exploitation was observed within a mere three days of the vulnerabilities being publicly disclosed, with thousands of vulnerable ScreenConnect instances targeted. Opportunistic attackers dropped not only ransomware loads but also infostealers, remote access trojans (RATs), and Cobalt Strike payloads. Some security vendors detail sightings of threat actors deploying legitimate remote access tools such as Simple Help and Chrome Remote Desktop in attempts to gain persistence.
As indicators of compromise (IOCs) and tactics, techniques and procedures (TTPs) were discovered and shared across organisations, it became clear that security teams would need to keep a close eye on things in the weeks to come.
Log4Shell
While a critical vulnerability in third-party software is undeniably dangerous, an arguably more devastating scenario is one inside the underlying software library itself. This is exactly what happened three years ago.
As the corporate world began to slow down in anticipation of the December holiday season, bad actors had received their Christmas present early: a maximum severity vulnerability in Apache’s Log4j, a logging library used in Java applications. The vulnerability in question allowed for remote code execution and the infosec community quickly realised the holiday season would not be as quiet as they hoped. Advisories and warnings were released but another curveball was on its way. Another Log4j vulnerability had been discovered. And another. Mass exploitation had begun.
Tenable released data claiming that 10% of all assets were vulnerable to Log4Shell, the name given to the vulnerability in question, and warned that this could have a greater impact than EternalBlue, which was exploited to deploy WannaCry back in 2017.
Despite the relatively fast patch releases from Apache, vulnerable versions of Log4j were difficult for organisations to detect as it meant understanding the underlying libraries of third-party vendors. These third parties themselves would be at risk from their third parties too, creating a chain of risks that are difficult to mitigate.
As the weeks went on, through the Christmas break and into January, blue teams could only hope that they wouldn’t receive the dreaded notice from their vendors – one that would spell disaster for all involved.
Years later, Log4Shell is still exploited to this day. Cato Networks claims that Log4Shell is one of the most attempted exploits in 2024 and a report from the end of 2023 stated that one third of applications still use vulnerable instances of Log4j.
Follina
On May 27th 2022, Twitter user @nao_sec disclosed a zero-day vulnerability in Microsoft Office products. Dubbed “Follina the high-severity vulnerability was a low complexity remote code execution attack. Through abusing Microsoft’s support diagnostic tool service, attackers could force Office applications to execute commands, sometimes without user interaction (after an initial phish).
Though disclosed in May, researchers discovered the vulnerability was being exploited months before, with activity attributed to both nation state actors and opportunistic attackers.
As an arguably critical business function, Microsoft Office is used globally in millions of environments. The impact of a severe vulnerability in these products was huge. Like Log4Shell, Follina was a reminder that even the underlying software or libraries we take for granted can be a potentially devastating avenue of attack.
The prioritisation dilemma
The CVEs mentioned above are only a couple in a long list of the most impactful vulnerabilities in the past five years. In hindsight, a critical vulnerability with a max CVSS score is bound to have serious implications but prioritising such vulnerabilities may not be an entirely complex task. If it’s max severity and applicable to your environment: patch immediately.
However, vulnerability management teams are well aware of the various shortcomings of the CVS system. Vulnerabilities can be given scores inconsistent with expectations, exploits can be misunderstood, and corporate politics can make a mockery of a fair and accurate scoring methodology.
As a recent example, earlier in July of 2024, a zero-day command injection vulnerability was discovered in a wide variety of Cisco Nexus products. Though rated as a medium-severity vulnerability (CVSS 6.0) this flaw was exploited by Chinese nation state actors to execute commands and malware on the underlying Cisco Nexus devices’ operating system. It is clear that a CVSS score alone cannot be relied upon.
These issues (among others) can lead to complexity during the vulnerability prioritisation function. It is here where a central repository of the various scores from different vendors along with timely, relevant information is crucial.
Having briefly covered the different considerations to take into account when it comes to vulnerability management and prioritisation, let’s now take a closer look at how Silobreaker fits in.
Case Study 1: Vulnerability Monitoring
In Silobreaker, customers can utilise the platform’s ability to filter down on their tech stack to enhance their vulnerability management functions by tracking the products and software applicable to their organisation and any relevant vulnerabilities.
With the aggregation of many different sources of vulnerability intelligence, our customers are able to make informed decisions about vulnerabilities based off their criteria of source of trust. Alongside scores, we can also track discussion around specific vulnerabilities (by either their CVE number or colloquial naming) across millions of OSINT data sources and premium data sets.
This means, in one place, customers can track and monitor CVEs relevant to their environment and be alerted to upticks in mentions of available exploits, advisories and bulletins, updates to scores and more.
In the screenshot above, a CVE card shows its relevant scores from various vulnerability databases. Each of its properties (such as: attack complexity, integrity impact, scope, etc.) can be used in our queries to further filter down and prioritise as needed.
From this page we can also find mentions of this vulnerability in reporting and discover that even in 2024, this vulnerability is still being discussed.
Case Study 2: Advanced Vulnerability Patch Management
Mature teams may find themselves in need of a system to triage and manage actioned vulnerabilities. Such teams utilise collections and lists in-platform for this function. Along with what we refer to as a “workbench dashboard”, teams can collaborate in real-time to tag, triage and manage vulnerabilities.
These dashboards can be refined further if needed, for example to only include CVEs that have been triaged and are ready to send off to the vulnerability management team in an email alert or bespoke report. With the dashboard alert option, relevant teams and stakeholders can also receive alerts when vulnerabilities have been added by the intel team.
Takeaways
Combined, all of these functions enhance vulnerability management and provide a centralised system for tracking and prioritising vulnerabilities relevant to a specific environment. With multiple sources of truth, our customers gain increased confidence in their ability to analyse CVEs – critical or not – and provide their stakeholders with accurate information. If you would like to know more about how Silobreaker can help your organisation in monitoring vulnerabilities, get in touch here.