Why vulnerabilities are like buses
How organisations can address the growing trend in which multiple vulnerabilities within a single product are exploited over a short period.
Tonywestphoto via Getty Images
There's an old saying that you wait ages for a bus, and then several come at once.
A growing trend is the mass exploitation of a critical vulnerability in a product, followed shortly after by further critical vulnerabilities (and often 'in-the-wild' exploitation) in the same product. Organisations will have worked hard to push out-of-band patches for the initial vulnerability, only to have to repeat the process later when new vulnerabilities appear.
In this blog, we'll explore the factors driving this, and explain how organisations can better protect the software they've just patched from exploitation of future vulnerabilities.
Why does it happen?
A hostile actor looking for a usable vulnerability (or a security researcher identifying material for a publication or conference) only needs to find a single vulnerability in a product. Once identified, the incentive to keep looking for others in the same product falls away. Products and services are very complex, and vendors or bug-bounty researchers are unlikely to find all the security flaws they contain.
When responding to a mass exploitation (or when vendors only have a fixed amount of time to address a flaw before an imposed deadline), they must focus on patching the immediate issue, rather than in-depth remediation of more fundamental flaws. Fixing these underlying problems - hopefully - starts in parallel, but it can take months of work to retire or rewrite dangerous flaws in a product.
When a high-impact vulnerability is mass exploited and makes the news, it suggests the software contains other exploitable flaws. Security researchers or threat actors may then decide that it's worth further research. They might familiarise themselves with the technology and go on to find new security issues, which they then release to the vendor - or if their intentions are malign, use as an exploit. This can lead to another wave of exploitation. In some cases, an organisation may not be affected in the first wave, but is later compromised when the second (or third) vulnerability appears.
Even if the vendor has made initial efforts to improve a product's security, it may still take longer to find and fix more fundamental issues than it takes threat actors - who have now smelt blood - to find and exploit them.
What can organisations do?
The rush to apply patches is unfortunately necessary once 'in-the-wild' exploitation is observed. The NCSC's advice remains for organisations to install security updates as soon as it's practicable.
However, in the immediate aftermath, defenders might consider how they can better protect the software they've just patched from future exploitation, when a patch isn't available or isn't yet applied.
An effective way to protect software is to reduce the attack surface by turning off or limiting software functionality. This can include:
- turning off interfaces or protocols not in use
- where possible ensuring admin interfaces are not exposed to the internet
- disabling legacy components or settings
- upgrading or replacing legacy software where patches are no longer available
- restricting network traffic to and from the device
- reviewing authentication and authorisation for the device
- making sure future patching happens as soon as is practicable
- crucially, ensuring that the system isn't unpatchable in the first place.
Organisations can also use the case studies emerging from real-world vulnerability exploitations to consider whether their own monitoring system would have detected activity on software and devices, and make adjustments where necessary.
Never let a good crisis go to waste
If considered strategically, the need to apply out-of-band patches in a high-pressure situation can give an organisation the required momentum to harden its internet-exposed software. This can help shift an organisation's security mindset from mostly reactive to more proactive, ultimately improving its fundamental network security.
A high-profile exploitation (such as the 'Proxyshell' issues in Microsoft Exchange Server mentioned earlier, or the current critical vulnerability affecting the Apache Log 4j 2 library) often brings considerable interest from an organisation's senior decision-makers. This can then provide the impetus to secure the senior sponsorship and financial buy-in for slower, but equally important longer-term security projects, which might be harder to 'sell' in normal circumstances.
David C
Principal Security Architect
Share and print this article
Written by
CTO for Architecture
