[BreachExchange] Brace Yourself for the July 14th Fujiwhara Vulnerability Effect

[Destry Winant]

https://www.riskbasedsecurity.com/2020/07/07/brace-yourself-for-the-july-14th-fujiwhara-vulnerability-effect/

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, on July
9th Oracle will provide an estimate of vulnerabilities.

HIGH-PROFILE 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.
<https://www.brighttalk.com/webcast/16541/416592>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riskbasedsecurity.com/pipermail/breachexchange/attachments/20200710/5e13f7cc/attachment.html>