For those familiar with my social media, you know that I have frequently said that our industry is failing the commons. InfoSec represents a huge market, companies get paid exorbitant amounts of money, salaries can border on the ridiculous, and the concept of researchers being famous for their work is still alive. Meanwhile, vulnerabilities are increasing in software, data breaches are up, ransomware incidents are up, nation-state actors are more prevalent than ever, and we see no meaningful progress in helping change the security posture of the world.
In this blog I am going to point out how something that should be relatively simple, is failing in huge ways. We all know that patching is already a complete game of cat-and-mouse as we routinely see patches for vulnerabilities that were discovered being exploited in the wild. Even for issues that were not, the process from vendor patch release to corporate application of that patch is not so simple. Testing must be done when the patch is released to ensure that it does not interfere with their specific installations and configurations. Over a decade ago, the time from patch release to implementation could be weeks, bordering on a month.
Today, waiting weeks for a patch to be installed simply does not cut it. Even waiting days is exposing an organization to additional risk. For the sake of this blog and my argument, let’s pretend 30 days is an acceptable time frame to apply a security patch for a garden variety vulnerability with no evidence of active exploitation and no evidence of public exploit code, reported and disclosed in a coordinated fashion. Let’s go a step further and say that patches for non-operating system vulnerabilities get 60 days, despite the fact that phishing attacks make them as risky, or actually more risky, than operating system vulnerabilities.
We’re going to look at just two vulnerabilities, that’s it. With these two I put forward the argument that they are concrete evidence we have completely lost the battle and war. Information Security has fail to do its job and all of our efforts have been in vain. Of course, while profiting heavily from the journey because that is the real motivation for too many in our industry.
First up, we have CVE-2017-0199, a vulnerability in Microsoft Office disclosed on April 7, 2017. At the time of me writing this text, that was 7 years, 9 months, 18 days ago (2850 days). This vulnerability saw active exploitation on October 1, 2016, 188 days before disclosure, making it even more critical to patch. Add to that, the attack vector is a malicious RTF document that can be delivered via email making it trivial to exploit in many cases. The vulnerability is summarized as: Microsoft Office RTF File OLE 2 Link Object Handling Arbitrary Code Execution. The amount of exploit activity around this vulnerability is considerable, and more to the point, ongoing to this day. Here is a very abridged, far from complete history of some exploitation to illustrate the point:
- 2017-04-13 – Not Just Criminals, But Governments Were Also Using MS Word 0-Day
- 2018-03-29 – Top 10 vulnerabilities used by cybercriminals
- 2019-02-05 – Pro-Tibet groups targeted with ExileRAT in spy campaign
- 2020-05-03 – CISA Advisory: Dridex Malware
- 2021-11-03 – Added to CISA KEV
- 2022-10-28 – 南亚之蟒–APT组织针对印度国防部投递新型Python窃密软件活动分析
- 2023-03-07 – Ransomware’s Favorite Target: Critical Infrastructure and Its Industrial Control Systems
- 2024-11-08 – New Campaign Uses Remcos RAT to Exploit Victims
- 2025-01-10 – Unit42: We still find malicious Office docs in the wild exploiting CVE-2017-0199…
The second vulnerability for this exercise is CVE-2017-11882, also a vulnerability in Microsoft Office that can be exploited via phishing as a vector. First disclosed on November 14, 2017, it saw active exploitation as early as November 28 (14 days later). More interesting are reports that this vulnerability had been present for 17 years before disclosure. This too would be critical to patch when we think back to our ‘acceptable’ patching time frame for the purpose of this argument. This vulnerability is summarized as: Microsoft Office Equation Editor Font Record Name Handling Stack Buffer Overflow. At the time of me writing this text, that was 7 years, 2 months, 11 days ago (2629 days). Again, the amount of steady exploitation this vulnerability has seen since is baffling. Another very brief timeline:
- 2017-11-28 – Hackers are exploiting Microsoft Word vulnerability to take control of PCs
- 2018-01-17 – Attackers Use Microsoft Office Vulnerabilities to Spread Zyklon Malware
- 2019-03-15 – Phishing attacks more than doubled in 2018 to reach almost 500 million
- 2020-05-01 – New phishing campaign packs an info-stealer, ransomware punch
- 2021-07-29 – Feds list the top 30 most exploited vulnerabilities. Many are years old
- 2021-11-03 – Added to CISA KEV
- 2022-04-27 – 2021 Top Routinely Exploited Vulnerabilities
- 2023-12-21 – NHS UK: Exploitation of Microsoft Office Vulnerability CVE-2017-11882
- 2024-04-16 – A sneaky new steganography malware is exploiting Microsoft Word — hundreds of firms around the world hit by attack
- 2025-01-16 – Hackers Hide Malware in Images to Deploy VIP Keylogger and 0bj3ctivity Stealer
If you have any questions about trusting vendors who disclose vulnerabilities, consider that Microsoft rates this ‘Important’, not ‘Critical’, and further says as of today that it has not been exploited and exploitation is ‘less likely’. Perhaps that is a big contributing factor as to why so many organizations have not patched this issue.
Two vulnerabilities, each with over seven years of active exploitation that began shortly after disclosure and continue to this day. How is that possible? What organizations are getting compromised using these old vulnerabilities that are large enough to make news? It might be easy to write this off as “maybe the company missed a server” which often happens leading to an operating system based compromise. But I don’t think that is the case here as these are desktop applications and should all be patched in the same timeframe. If organizations are consistently missing patching desktops like this it means they are lacking some fairly rudimentary asset inventories and their framework does not have fallback patching notifications and warnings.
I am not a system administrator responsible for blue team patching efforts like this so I am not qualified to give specific advice. That said, in my mind a system that allows the patch from the vendor to be installed after 30 days, if the corporate ‘gold image’ patch is not installed, might be a good fallback mechanism. If the vendor patch crashes the system because it is missing some modification specific to the organization, fine. It becomes a great alert that the system is not part of the current patching infrastructure and that needs to be addressed too.
One way or another, if consistent exploitation of a vulnerability happens for more than seven years, it shows a systemic problem in our industry. Secure software development lifecycle (SSDLC) is failing, patching isn’t working, defense-in-depth (DiD) often isn’t being deployed in a meaningful manner, user awareness is not reliable, data breach penalties are not a deterrent, and overall our best efforts are simply far from enough.