Why vulnerabilities are like buses

Any malicious actor searching for a usable vulnerability, or a security researcher in pursuit of material for publication or presentation, only needs to identify a single flaw in a product. Once found, their motivation to seek other vulnerabilities within the same product diminishes. Given the complexity of products and services, it is unlikely that vendors or bug-bounty researchers will uncover every security flaw within them.

When dealing with mass exploitation—or when vendors face a tight deadline to rectify a flaw—they tend to concentrate on fixing the immediate issue instead of conducting a comprehensive investigation into more systemic deficiencies. Addressing these fundamental problems ideally begins concurrently, yet it may require extensive effort over several months to eliminate or reconstruct serious flaws within a product.

When a high-impact vulnerability is widely exploited and gains media attention, it raises suspicions that the software may harbor other exploitable flaws. Consequently, security researchers or threat actors might find it worthwhile to investigate further. They may become familiar with the technology and subsequently discover new security concerns, which they may either report to the vendor or exploit for malicious purposes. This can trigger another wave of exploitation. In some instances, an organization might remain unscathed during the initial wave, only to become compromised later as subsequent vulnerabilities surface.

Even with initial improvements in a product’s security by the vendor, it may take longer to uncover and rectify more fundamental issues than it does for threat actors—who have now sensed vulnerability—to identify and exploit them.

The urgent need to apply patches is regrettably required when exploitation in the wild is observed. The NCSC advises organizations to implement security updates as promptly as feasible.

However, in the immediate aftermath, defenders may consider strategies to better shield the software they have just patched from future exploitation, especially when a patch is not currently available or has not yet been applied.

A practical method for protecting software involves reducing the attack surface by disabling or restricting software functionalities. This approach can encompass:

• disabling unused interfaces or protocols
• ensuring, when feasible, that administrative interfaces are not publicly accessible
• disabling outdated components or configurations
• upgrading or replacing legacy software for which patches are unavailable
• restricting network traffic to and from the device
• reviewing authentication and authorization settings for the device
• ensuring that future patching is performed as soon as practicable
• and, importantly, confirming that the system is not inherently unpatchable.

Organizations should also leverage the case studies arising from real-world exploitation incidents to assess whether their monitoring systems could have detected activities on their software and devices, making necessary adjustments as needed.

If approached strategically, the necessity to implement out-of-band patches during a crisis can provide the impetus for an organization to strengthen its internet-exposed software. This shift can aid in transitioning an organization’s security approach from predominantly reactive to increasingly proactive, thereby enhancing its overall network security.

High-profile exploitation events, such as the ‘Proxyshell’ vulnerabilities in Microsoft Exchange Server or the critical vulnerability affecting the Apache Log4j 2 library, often attract significant attention from senior decision-makers within an organization. This interest can subsequently motivate leaders to secure the necessary sponsorship and budget for longer-term security initiatives that may be more challenging to advocate for during typical circumstances.

David C
Principal Security Architect