PoC leak swiftly followed by widespread exploitation - once again
When security research can be more harmful than helpful
Attackers have had themselves a field day abusing a vulnerability in Fortinet’s FortiNAC appliance, thanks in no small part to a PoC exploit which was released by security research company Horizon3 - just two business days after Fortinet warned customers to patch the vulnerability.
The PoC exploit leverages the vulnerability to write arbitrary files to disk, and has been abused by attackers to deploy both interactive and reverse web shells on vulnerable FortiNAC devices.
Is two days enough?
While it’s not surprising that attackers were quick to capitalise on the weaponised exploit, it’s difficult to understand Horizon3’s reasoning for having released it as soon as they did.
Sure, you might argue that for large organisations lucky enough to have formalised vulnerability management teams and processes - they may have been able to identify and patch the vulnerability in the two business days separating the disclosure of the vulnerability and release of the PoC.
Smaller entities, however - think regional hospitals, public schools, or even small-scale MSSPs - will likely have neither the capacity or ability to do the same.
And this isn’t that far-fetched a scenario either - this hypothetical lines up very neatly with six of Fortinet’s publicly listed case study clients who use FortiNAC appliances in their networks:
Timing is everything
Releasing PoC exploits can help defenders better understand the vulnerable attack surface and detect attempts to exploit it - that’s great, and you’ll find no arguments from me on that.
Where this becomes counter-productive, though, is when the PoC exploits - weaponised or not - are released before organisations have the chance to patch the vulnerability they abuse.
There are a myriad of reasons why organisations may be seen to be dragging their heels on patching, many of which are out of the control of the security team or broader organisation, for example:
The organisation is coming up to an important event where absolutely nothing can go wrong - e.g. they’re about to be listed on a stock exchange, their latest product is about to be released for sale, or a long holiday period is coming up - in these cases a “Change Freeze” can be put in place that prevents security teams from making any changes without running a gauntlet of internal approvals;
The software requires staged updates to multiple components before the vulnerable asset itself can be patched - this can take time and co-ordination from multiple internal and vendor stakeholders;
The asset provides critical functionality, and is only able to run as intended on a legacy, vulnerable version. Believe it or not, business requirements can supersede security risks, with “compensating controls” such as “enhanced monitoring” often accepted as a substitute for eliminating a vulnerability - regardless of how critical it is. Ask anyone who’s run a Penetration test on a hospital what the oldest version of Windows they’ve seen on the network is - try not to grimace in disgust when they do.
Onwards and upwards
Security research is an invaluable input to Cyber Defence functions, as it provides actionable insights into attacker techniques, security vulnerabilities, and more - all of which defenders must understand, in order to protect against them.
I’ve been lucky enough to work in several roles on the defensive side, and have seen first-hand how bureaucracy, poor solution design, and convoluted chains of approval can run down the clock when trying to patch security gaps.
My point is - it’s not always for lack of trying, and sometimes all we need is more time.
Oh, and it goes without saying - though just in case it needs to be said - I didn’t write this piece to take aim at Horizon3.
Their work is great - their timing on this one simply presented the opportunity to address a systemic problem in vulnerability disclosure and management.
I have nothing but respcpt for their team, and wish them all the best.
