Brace Yourself for the July 14th Fujiwhara Vulnerability Effect
July 7, 2020 • RBS
2020 hasn’t exactly been a walk in the park for security teams around the world, and things are about to get even more challenging. On July 14th, IT organizations around the world will face the Vulnerability Fujiwhara Effect for the third (and thankfully final) time this year.
The Fujiwhara Effect, named after Japanese meteorologist Dr. Sakuhei Fujiwhara, who first described it, takes place when two or more hurricanes interact. A Vulnerability Fujiwhara, then, is when the disclosure schedules for multiple significant vendors – specifically Oracle and Microsoft – collide. It’s an event that will occur an unprecedented three times in 2020.
In the last such storm, on April 14th, 2020, the release schedules of thirteen vendors coincided, resulting in the release of an alarming number of vulnerabilities on the same day. It’s time to assess whether your organization is prepared to collect, analyze, and address the vulnerabilities we can expect on July 14th.
What We’ve Learned From the Last Two Events
For an indication of what we can expect, we can look to the recent past. The last two Vulnerability Fujiwhara Effects, January 14th and April 14th, saw significant spikes in volume that kept our research team, Vulnerability Managers, and IT teams working late into the night to process and analyze the new information, prioritize remediation, and patch and maintain systems.
Around 66 new vulnerabilities are published on an average day. But the last two storms have proven to be a daunting task for security professionals, with 600 total vulnerabilities (506 of which were newly disclosed) on April 14th alone.
Previously Disclosed Vulnerabilities
Keep in mind that some of the fixes provided are for previously known vulnerabilities, meaning that for these flaws, organizations may have been vulnerable for some time. In April 2020, Oracle patched a vulnerability originating in 2015 (not to mention those found in third-party code that were older still). Looking ahead, it is reasonable to expect a repeat of this scenario. For those who want to do a preliminary assessment, Oracle has provided an estimate of vulnerabilities.
Given the sheer volume of vulnerabilities during one of these events, it is extremely difficult (if not impossible) for most organizations managing vulnerabilities in-house to analyze and assess every report that is disclosed in a timely manner. We are acutely aware of what is involved, because our own research team has to do exactly that in order to provide the comprehensive, timely, and actionable data that we’re known for to our customers.
Among the hundreds of vulnerabilities newly disclosed on April 14th were several that had high-profiles in the industry and press such as the infamous Windows CryptoAPI Spoofing Vulnerability (CVE-2020-0601). Other notable vulnerabilities included Microsoft’s Scripting Engine Memory Corruption Vulnerability (CVE-2020-0674), and three Microsoft fixes for 0days being exploited in the wild: Adobe Font Manager Library Remote Code Execution Vulnerability (CVE-2020-0938), Windows Kernel Elevation of Privilege Vulnerability (CVE-2020-1027) and Microsoft’s Outlook Forwarded HTML-formatted Email Handling Link Spoofing Weakness Vulnerability (still with no CVE assigned).
While these vulnerabilities took much of the lime-light, there were many other disclosures that also required timely attention. In April’s Fujiwhara Event, 101 vulnerabilities were disclosed that had CVSSv2 scores of 7.0 and above. For those organizations using CVSSv3, that number suddenly jumps to 243. Organizations cannot afford to blindly assign Fujiwhara Effect vulnerabilities to the backlog.
Related: CVSSv3: Newer Is Better, Right?
Timely and Actionable Data
The vulnerabilities released during a Vulnerability Fujiwhara can have massive impacts on your organization’s security ecosystem. Your security team will need every single piece of information that is available in order to properly assess, prioritize and work with IT teams to remediate risk.
Unfortunately, those relying on commonly used or free vulnerability databases do not get the luxury of timely intelligence. Many vulnerabilities can take weeks for a CVE ID to be created (if one is created at all), and much longer for the corresponding NVD entry to be published. Many organizations, not equipped with the best vulnerability intelligence, saw this unfortunate delay play out in several disclosures released during these past Vulnerability Fujiwhara events, for example:
- Windows Kernel Elevation of Privilege Vulnerability (CVE-2020-1027)
- Adobe Font Manager Library Remote Code Execution Vulnerability (CVE-2020-0938)
Both of these vulnerabilities affected Microsoft and had public exploits. But despite the urgency and severity, both entries took nearly a week for their details to be added in NVD.
I Need My Data Now
For those dissatisfied with the ambiguity and delay that comes from relying on common databases, consider a comprehensive vulnerability intelligence solution. With VulnDB you can spend less time on vulnerability assessment, and more time on vulnerability management.
Ensure that you are properly equipped to not only deal with the upcoming storm on July 14th, but also the daily vulnerability reports that may impact your organization.
For a focused look into how to mature your vulnerability management program with vulnerability intelligence, watch our on-demand webinar.