October 2021 saw our vulnerability research team uncover a Microsoft vulnerability dating back 14 years. In the wrong hands, it would have caused untold damage to businesses reliant on Microsoft’s VPN.
What was the vulnerability?
A Denial of Service (DoS) vulnerability named CVE-2022-23253, the vulnerability hid deep inside the kernel. This is the code responsible for helping a machine recover when something goes wrong.
Due to its location, should the faulty code have caused a Windows machine to crash, no error message would show. The CPU would generate an exception because it wouldn’t know what to do. Instead, it would present the ‘blue screen of death.’
LRQA found the Microsoft vulnerability whilst using a custom-built fuzzing tool to research Microsoft’s code. The tool was specifically configured to target language on Microsoft’s VPN server. This in-depth research process can identify previously unfound issues as it progresses.
We believe this DoS vulnerability dated back to at least 2008, the original release of Windows Server 2008. CVE-2022-23253 scored 6.5 on the Common Vulnerability Scoring System (CVSS). The closer to a ‘critical’ score of 10 the higher the risk.
Who was at risk?
CVE-2022-23253 lived in Microsoft’s VPN. Therefore, any organisation reliant on the widely used system for its day-to-day work was at significant risk.
Given the move to remote and hybrid work, during and since the pandemic, many businesses developed sophisticated VPNs to collaborate from multiple locations and accommodate substantial numbers working from home.
Had the vulnerability been triggered, entire VPN networks could have collapsed. As Microsoft had no fix for this unknown issue, the situation would have been challenging.
Many organisations risked suffering lengthy downtime whilst IT teams worked out what protocol had instigated the crash. Recovery could have taken many weeks, especially for those with large networks.
LRQA reported the vulnerability to Microsoft on 29th October 2021. It created and released a patch this month (8th March 2022).
Of course, had the vulnerability been exploited by cyber-attackers, Microsoft would have accelerated the fix. But the delay would still have caused widespread disruption.
Why was this a cyber risk?
Threat actors are continually scouring code to uncover exploitable vulnerabilities. This vulnerability would have been perfect to create immense damage.
A semi-skilled attacker could have brought an organisation to its knees by accessing one rogue machine and sending a few small packets of data to keep the network permanently offline. The vulnerability was relatively easy to take advantage of.
Compared to the ransomware opportunity, this downtime might have seemed minor.
Having caused disruption, the attacker could have demanded a hefty ransom to restore order. Given the fact that any IT team would need time to identify the unknown fault, the stakes were high.
Taking the risk one step further, organisations would be forced to hurriedly use alternative communication and collaboration tools or remain isolated from each other until the situation was resolved. Neither option would be good for operations or reputation management.
Quite simply, this simple DoS vulnerability could have caused a lot of damage for many businesses.
Coordinated disclosure
When our vulnerability research team discovers a vulnerability in code, we follow a Coordinated Disclosure process to ensure best practice.
First, we confirm the vulnerability exists. This could mean developing a process to trigger it.
We then report our findings to the code developer. In this case, the Microsoft Security Research Centre. On receipt, the developer agrees to create a patch for the vulnerability.
LRQA would not disclose details about the vulnerability until confirmation of a patch release. Best practice is to wait 30 days before publishing details.
Our vulnerability research team continually investigates and challenges code. Whilst not always specifically hunting for vulnerabilities they uncover issues every few months.
Heighten your security posture
The stark reality is vulnerabilities continue to exist in all types of code. Written by developers, mistakes are inevitable, and vulnerabilities can lie dormant for years.
Therefore, cyber-attackers will always find ways into your machines and network. Your priority must be to heighten your security posture and barriers to entry.
“It’s not about preventing someone getting into your network, because that’s almost definitely possible. It’s about making it hard for that person to do anything once they’re in. Implement all your security fixes promptly and invest in people who know how to make your network secure. Someone will eventually get in. Your best defence is to spot it quickly and know what to do,” said Alex Nichols, Senior Vulnerability Researcher at LRQA.
Your attitude to risk determines your optimum security posture. You might choose to have a Security Operations Centre (SOC) team constantly monitoring your network.
Whatever your attitude, we recommend you reflect on your worst-case scenario and become prepared for it. Had this DoS vulnerability triggered, for example, your VPN would have gone down for some time. How would you even report your VPN failure without access to it?
By heightening your security posture and having a recovery plan should a disruption occur, you’re building the best possible cybersecurity defence for your organisation.