Blog
The Vulnerability Fujiwhara Effect: Microsoft and Oracle Collide
Table Of Contents
When Microsoft and Oracle collide
Whether you are working in IT or not, you’re probably familiar with Microsoft’s Monthly Patch Tuesday. Introduced in 2003, this is when the software giant releases updates and patches for its software products. We have seen more and more vendors piggybacking on this approach and releasing their own patches on the same day. Now, with 2020 barely underway, we kick off the year with an almost-unprecedented schedule of substantial releases of new patches to fix known vulnerabilities.
When two hurricanes collide, the phenomenon is called the Fujiwhara effect. The vulnerability intelligence world is about to experience just such an event, on steroids, as the release dates for several major vendors, including Oracle and Microsoft, collide. This event, which last occurred in 2014, will happen three times this year. What makes this event unprecedented is that organizations face an impending collision between six vendors. Organizations, and their vulnerability intelligence teams, are in for a rough year.
As per the norm, next Tuesday, January 14th, 2020, several prominent vendors will be disclosing a long list of vulnerabilities that organizations will have to assess. But what is making this coming Patch Tuesday even more significant is the impending collision. In addition to the expected Microsoft Patches, Oracle will be releasing their quarterly Critical Patch Updates as well. These two vendors are in addition to several others that co-opted “Patch Tuesday” years ago, including Adobe.
2020 Vulnerability Fujiwhara Effect dates
- January 14th, 2020
- April 14th, 2020
- July 14th, 2020
On the surface this may seem like a positive thing, and is certainly an improvement on uncoordinated disclosures (still referred to as “irresponsible disclosure” by many vendors and described as a situation that “hurts customers”). But as more vendors have gravitated towards releasing on Patch Tuesday, organizations are now being subjected to the routine updates of six vendors on the same day, with the possibility of an additional seven. This is in stark contrast to the normal day of vulnerability disclosures.
“The amount of vulnerability work that is going to be dropped in the laps of already overloaded IT and cyber security teams is going to be massive.”
Jake Kouns, General Manager OF RBS at Flashpoint
Last month on Microsoft Patch Tuesday, our VulnDB® research team analyzed and published 188 new vulnerabilities in a single day. With Oracle now planning to release on the same day, we expect vulnerability teams will have to aggregate and review a massive list (perhaps doubled) of what will most likely be critical database and product vulnerabilities.
“Even in a best-case scenario, with a well-staffed team, this will take weeks. Most large organizations won’t be able to handle it at all.”
Brian Martin, Vulnerability Historian at Flashpoint
It can’t be ignored that there is a clear and substantial risk to organizations that do not have the necessary vulnerability intelligence and processes in place to enable the handling of the large volume of vulnerabilities being disclosed.
If you are using any of the following vendors, we suggest that you prepare for the impending storms:
Confirmed
- Microsoft
- Oracle
- Adobe
- SAP
- Siemens
- Schneider Electric
Potential
- Apple
- Mozilla
- Intel
- Cisco
- F5
- Juniper
UPDATED on 1/13/2020
It looks like the Microsoft portion of The Fujiwhara Effect is going to be quite severe. Early on Monday, January 13th, 2020, Will Dormann from CERT/CC tweeted the following ominous message:
Later in the day KrebsOnSecurity posted an article that provided more specific details including information from a source that seemed to validate the severity:
“Those sources say Microsoft has quietly shipped a patch for the bug to branches of the U.S. military and to other high-value customers/targets that manage key Internet infrastructure, and that those organizations have been asked to sign agreements preventing them from disclosing details of the flaw prior to Jan. 14, the first Patch Tuesday of 2020.”
KrebsonSecurity
UPDATED on 1/14/2020
More details about the Microsoft Patch Tuesday have emerged, and from it, CVE-2020-0601 has been born.
CVE-2020-0601
Reported by the National Security Agency (NSA), CVE-2020-0601 is essentially a mistake in the computer code for Microsoft’s Windows 10 operating system.
This vulnerability potentially enables a hacker to forge digital signatures and install spyware or ransomware on computers by disguising them as legitimate programs.
According to the Washington Post, Anne Neuberger, the director of the NSA’s Cybersecurity Directorate is expected to announce Tuesday the discovery of the flaw and their warning to Microsoft.
The impending Vulnerability Fujiwhara Effect is already formidable and as we have said before, organizations are being subjected to the updates of five other vendors on the same day, with the possibility of an additional seven.
At Flashpoint, we have seen these vulnerability storms building for many years now and are prepared for our customers. We have taken the necessary steps to ensure that VulnDB continues to be the most comprehensive source of detailed and timely vulnerability intelligence.
There’s never been a better time to see the power of VulnDB, and how it would help your organization handle this perfect storm of vulnerabilities that are coming.
Patch Tuesday: The Fujiwhara storm is over for now, but it’ll be back soon
Tuesday January 14th started the year with a cornucopia of vulnerability disclosures from Microsoft, Oracle, Adobe, Intel, Siemens, SAP, VMware, Schneider Electric, Apache, Symantec, and Lenovo. All on the same day!
2:00 AM EST: The eye of the storm
SAP and Siemens started very early by releasing 10 and 18 new or updated security advisories, respectively. After that warm-up, Adobe graciously released two security advisories covering nine vulnerabilities in their Adobe Illustrator and Adobe Experience Manager products. Out of character, Adobe released their advisories a few hours earlier than normal and did not release any advisories for Flash Player or Acrobat Reader. Microsoft followed with a relatively light release of “only” 49 security advisories.
Other major vendors also published advisories, which has become the norm on “Microsoft Tuesday” or “Patch Tuesday”, as it is more appropriately referred to these days. These releases were all on the smaller side. Many other vendors, who are also known to release on Patch Tuesday, opted out completely.
In total, the major vendor disclosures covered 80 newly reported vulnerabilities. While fairly low for a Patch Tuesday, it still adds up to a very busy day for system administrators and security teams. Normally, this would be the end of a normal Patch Tuesday, but the disclosures had only just begun.
4:30 PM EST: Landfall
A few hours after the release of the Microsoft security advisories, Oracle dropped their quarterly CPU of 333 vulnerabilities across 93 products, with 205 of them being new disclosures. In total, our VulnDB team published 325 new vulnerability reports on January 14th to our customers and updated an additional 312 entries. Considering the average number of newly published vulnerabilities in a day is around 61, it was clearly a busy day.
“Here at Flashpoint, our teams of VulnDB analysts and researchers in the USA and EU closely monitored these disclosures and jumped on them as soon as they came out. They worked for about 22 hours straight to properly analyze and process them,” said Carsten Eiram, VP of Vulnerability Research at Flashpoint.
“This ensured that our customers got the vulnerability intelligence in a standardized and easily digestible format with clear descriptions, solutions, and metadata. This provides a great advantage and starting point for making better decisions about the risk to their organizations and proper prioritization. It also saves a significant amount of time and resources that should have otherwise been spent on collecting and analyzing these disclosures prior to focusing on remediation.”
Many larger organizations are sure to be using products from most, if not all, of the vendors that disclosed vulnerabilities on Patch Tuesday. There is no way around the fact that it’s quite a challenge for an organization to deal with so many vendor disclosures in an efficient and properly prioritized manner. The number of man hours required by IT security teams to collect, analyze, triage, and then address that many vulnerabilities is significant.
The aftermath: Notable vulnerabilities
While CVE-2020-0601 (VulnDB 221392), a vulnerability in the Windows CryptoAPI that allows spoofing ECC certificates, got the most attention, it’s still important to note that many of the other vulnerabilities disclosed that day should also receive timely attention and not just be thrown in the backlog.
On top of the disclosures during Patch Tuesday, Microsoft released a security advisory on January 17th covering a 0-day vulnerability in the Internet Explorer scripting engine (CVE-2020-0674) that allows arbitrary code execution. This is being actively exploited and currently has no fixes available.
For all the flaws and limitations of CVSS, the chart below shows the distribution of all the vulnerabilities pushed by the VulnDB team on January 14th by CVSS severity.
More storms expected this year
The bad news is that while the storm is over for now, it’ll be back in three (and also six) months, where the Microsoft and Oracle disclosures collide yet again with a lot of other vendors’ disclosures on top.
The good news is that there are solutions that can help you weather the storm like our VulnDB vulnerability intelligence solution, whereas basic patch and vulnerability management solutions come up short. VulnDB helps you prepare, prioritize, and process the vulnerability reports in the most efficient manner. Please don’t hesitate to reach out for a demo, so you can be properly equipped to not only deal with the upcoming storms but also the daily vulnerability reports that may impact your organization.
To spread or not to spread, that is the question
Even before the recent Microsoft and Oracle disclosure collision, it has long been the norm for vendors to piggy-back on Patch Tuesday (originally known as Microsoft Tuesday). Back in October 2003, Microsoft formalized their release schedule to be on the 2nd Tuesday of each month. In 2012, Adobe changed their release schedule to coincide with Microsoft’s release dates. Since then, various vendors including SAP, Siemens, Schneider Electric, Intel, and Lenovo have jumped on the bandwagon.
Over the years we’ve had discussions about this with some of these vendors. Their main argument is that customers requested this, and that it is in their customers’ best interest that many major vendors release on the same day. This allows customers to plan ahead and address everything at once.
Is it really in your best interest, though? Are customers requesting this? And perhaps, most importantly, is it even possible to address so many patches all at once?
“There is an advantage in having vendors disclose at known intervals, but it is becoming a significant problem that so many vendors piggy-back on the same day. When major vendor disclosures are scheduled in a way that doesn’t prevent them from clashing, it becomes even worse for customers who would prefer to focus on select vendor disclosures like Microsoft and Adobe.”
Carsten Eiram, VP of Vulnerability Research at Flashpoint
Organizations without a highly mature vulnerability management program, which includes a vulnerability intelligence solution, have no efficient way to deal with this approach of just starting from one end and working their way through. This could easily take weeks and may result in critical vulnerabilities not being addressed in a timely manner. In the meantime, other critical vulnerabilities coming in after Patch Tuesday may be outright missed or end up in the backlog for an undefined amount of time.
Most of our customers we’ve discussed this with have expressed unhappiness regarding the decision of so many vendors to cram Patch Tuesday with their releases. Instead, they’d prefer to focus only on the Microsoft and Adobe disclosures. Though they do appreciate the predictability of knowing when to expect vendor disclosures, the consensus is that vendor disclosures should be properly spread out.
Those who would bear the disclosure and scorns of time
We’re very curious about your views. If you’re not yet our customer, and would value access to a vulnerability intelligence solution that is superior to the basic vulnerability management products out there, please don’t hesitate to contact us for a demo and trial account.
April 14th’s Vulnerability Fujiwhara event
Back in January, we first warned organizations about the Vulnerability Fujiwhara Effect that will hit three times this year. These major security events, in which Microsoft, Oracle and other multiple large vendors disclose vulnerabilities in popular products on the same day, pose a particular challenge for Vulnerability Management teams who are left analyzing and prioritizing hundreds of disclosures before remediation can even begin. We have already seen the impacts of the first storm that occurred on January 14th.
What we observed from the first storm
Microsoft’s monthly Patch Tuesday has proven to be a very busy day for IT teams, as many vendors have adopted the same routine. The first such event of the year, on January 14th, saw the following vendors participate in Patch Tuesday:
- Microsoft
- Oracle
- Adobe
- SAP
- Siemens
- Schneider Electric
- Symantec
- Apache
- VMWare
- Intel
- F5
Starting at 2:00 AM EST, our VulnDB team began the long day which consisted of analyzing and publishing new vulnerability reports to our customers, and updating an additional 300+ entries. Among the disclosed vulnerabilities were a number of high-profile ones such as the Microsoft pre-auth RCE vulnerability and the 0-day vulnerability in the IE scripting engine, however there were many others that deserved the same scrutiny.
A high of 500+, with lows around 300
Even with companies such as Google announcing that they would pause upcoming Chrome and Chrome OS release, they stated that they would continue to prioritize any updates related to security. This is for good reason as the discovery and disclosure of vulnerabilities doesn’t pause for the Coronavirus pandemic, of course. The upcoming storm next week will be hitting organizations hard on April 14th despite the ongoing business disruption faced by organizations and their security teams.
In our recent Vulnerability Management In the Time of a Pandemic we touched on the topic, noting that for each of the remaining two Vulnerability Fujiwhara events of the year, organizations could expect to see, on the high end, 500 or more vulnerabilities disclosed. That is a significant increase when compared to the average number of newly published vulnerabilities in a day, which typically is around 60. Even for large organizations, processing these new “Patch Tuesday” disclosures can take weeks, and that’s with a well-funded and coordinated team. The hours required for IT security teams to collect, analyze, triage, and then address the coming vulnerabilities will be considerable.
2020: A complicated situation
If there wasn’t enough going on already, organizations must somehow manage the coming Vulnerability Fujiwhara Effect despite the current business disruption and pressure on security budgets. If Vulnerability Management teams do not have the resources they need to manage the staggering volume of vulnerabilities that are coming, analysis and remediation will inevitably be slower, putting organizations at risk.
Organizations may also face increased exposure to data breaches at this time as research has shown that cybercrime increases during a recession. So far, we have seen over 700 organizations face lawsuits after suffering a data breach, and we believe that the number is drastically under-reported. While some security regulations have been relaxed due to the ongoing pandemic, organizations need to ensure that their security teams can perform necessary patching and remediation to keep systems secure to avoid any potential legal fallout.
Equip your teams with the intelligence they need
At times like these, Better Data Matters® and is even more important. Organizations will greatly benefit from a comprehensive source of intelligence, so that their security teams can spend less time on vulnerability assessment, and more time on vulnerability management.
If you do not have the proper intelligence and processes in place, don’t hesitate to reach out. Ensure that you are properly equipped to not only deal with the upcoming storm on April and July 14th, but also the daily vulnerability reports that may impact your organization. If we can help you with that, get in touch.
April’s Vulnerability Fujiwhara has passed, but July’s is yet to come
On April 14th, security teams were hit by the latest Vulnerability Fujiwhara Effect, which is the name we’re giving to the events when the disclosure schedules for multiple significant vendors collide. In the storm we saw Microsoft, Oracle, Adobe, SAP, Siemens, Schneider Electric, Broadcom, IBM, McAfee, Xen, Lenovo, VMware, and Intel collectively release a staggering amount of vulnerability disclosures and patches for previously disclosed issues. As we stated previously, the hours required for IT security teams to collect, analyze, triage, and then address these vulnerabilities will be considerable.
A projected forecast of 300 – 500+
January’s Vulnerability Fujiwhara saw a total of 325 new vulnerabilities, which we used as a benchmark to predict the number of vulnerabilities for April’s event. Based on the work of our VulnDB team, who closely monitor vulnerability disclosure trends, we advised a potential of 500 or more new vulnerabilities during our recent webinar Vulnerability Management In the Time of a Pandemic.
So, what was the total for the latest storm? Overall, April’s Vulnerability Fujiwhara affected close to 600 vulnerabilities. After our research team assessed each one, a total of 465 new vulnerabilities were published on that day. That number may still slightly rise, as our team continues to process entries from additional sources, typically in software that doesn’t enjoy a high distribution.
The average number of newly published vulnerabilities in a day this year is 66, so processing 465 in a single day is a tremendous undertaking. This is especially true during a period when some organizations have shed IT staff in the face of economic disruption, and many are working remotely or dealing with disrupted business processes.
Takeaways from April’s Fujiwhara Effect
Here are some noticeable takeaways we saw during April’s Vulnerability Fujiwhara Effect:
- There were three Microsoft fixes for 0days being exploited in the wild
- There were 101 vulnerabilities disclosed that had a CVSSv2 rating of 7.0 – 10.0
- If your organization prefers CVSSv3, 243 vulnerabilities were disclosed that had a CVSSv3 rating of 7.0 – 10.0
- Disclosures from six prominent vendors spanned over 12 hours
Aside from Intel, most of the vendors we listed as ‘possibly’ disclosing did not release. However, as though to make up for this, SAP’s vulnerability disclosure was larger than usual.
For organizations relying solely on CVE and NVD, be aware that at time of publication, NVD is missing CVSS scoring and Common Platform Enumeration (CPE) details for several Microsoft vulnerabilities. Even worse? At the time of publication of this blog, they are still missing. This will unfortunately hamper assessment and remediation efforts for organizations dependent on that information.
Pay close attention to Oracle
The bulk of the vulnerabilities disclosed during this month’s Patch Tuesday came from Oracle. According to Dark Reading, Oracle accounted for “70% of the patch load, addressing 405 new security vulnerabilities” (based on CVE identifiers). However, to be more precise, out of those 405 fixes, only 230 of the vulnerabilities were newly disclosed. The remainder of the 175 patched vulnerabilities had been disclosed previously, meaning that for these vulnerabilities, organizations have been vulnerable to known flaws for some period of time.
How long exactly? The answer is over a period of up to six years. Oracle spread out their disclosures in four different advisories:
- Oracle Critical Patches – 264 new vulnerabilities in Oracle’s own code, with the oldest vulnerability patched originating from 2015. 203 previously disclosed vulnerabilities in third-party code used within the Oracle suite of software, with the oldest vulnerability patched originating from 2014.
- Solaris Third Party Bulletin – Zero new vulnerabilities in Solaris itself. 16 previously disclosed vulnerabilities in third-party libraries going back to March, 2019.
- Oracle Linux – Zero new vulnerabilities disclosed. 210 previously disclosed vulnerabilities, with the oldest vulnerability patched originating from 2014. Interesting to note that four of the 30 kernel vulnerabilities are attributed directly to issues in “Unbreakable Enterprise Kernel”, but all four are actually vulnerabilities in the upstream Linux Kernel.
- VM Server – Zero new vulnerabilities, but three previously disclosed issues all from this year.
Is this in the customer’s best interest?
600 vulnerabilities and patches in a single day, with 465 of those being new vulnerabilities, is an incredible amount. This raises questions we at Flashpoint have been asking for a long time; is it even possible to address so many patches at once? If so, how long does it take? Even if vendors truly do have their customer’s best interest in mind, at what point does it simply become too much?
Many vendors have adopted Microsoft’s Patch Tuesday as their own, which is now an established norm. We reached out to some of these vendors and had discussions on this topic. In the end, their stance is that by releasing everything at once this allows customers to plan ahead and address everything at once. What they don’t account for is when many of them do it at the same time.
Vendors don’t make it easy
Organizations need to be able to prioritize effectively so that they can mitigate risks that will have a higher impact on them. While there is an advantage in having vendors disclose at known intervals, if nothing is done to prevent massive clashing, focusing on select vendor disclosures like Microsoft, Adobe, and Oracle becomes infeasible.
What ends up happening instead is an overload of information that needs to be assessed. The sheer size of the workload, and the manner in which it is shared, may cause key vulnerabilities to be lost in the process. For many of these Patch Tuesday disclosures, organizations cannot rely on a single advisory. While our research team is prepared and equipped to quickly sift through numerous advisories , many organizations are not.
How did your organization handle April’s storm?
April’s Vulnerability Fujiwhara dumped 465 new vulnerability disclosures on already overworked IT security teams. If your organization is struggling with assessing and triaging the results of this Patch Tuesday, please don’t hesitate to reach out.
If you’re curious to see how your organization would benefit from the most comprehensive vulnerability intelligence solution, we are offering trial access to our flagship VulnDB product.
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, Oracle has provided 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.
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.
Vulnerability management in a Fujiwhara Effect
The Vulnerability Fujiwhara Effect has run its course for the immediate future, but Cyber Threat Intelligence (CTI) teams and Vulnerability Managers may feel its impact for months to come.
In the latest Fujiwhara, on July 14th, there were 406 newly disclosed vulnerabilities, with Microsoft and Oracle comprising 83% of the workload. Given that the average number of published new vulnerabilities is around 66, organizations are no doubt still collecting, analyzing, prioritizing and patching the many issues brought to attention in July’s Fujiwhara Storm.
Let’s take a look at how the day played out (and where you should focus your attention):
1:00 PM EDT: Microsoft and SigRed
Microsoft kicked things off by releasing 123 vulnerabilities, 62% of which were rated high severity by CVSSv2. For organizations opting for CVSSv3, that figure jumps to 72%.
As with January’s Fujiwhara Effect, several of July’s vulnerabilities have had high-profiles in the industry and social media.
MICROSOFT MULTIPLE PRODUCTS CONTACTS LINK VULNERABILITY (CVE-2020-1147)
This vulnerability has a public exploit and has been making a buzz on social media, shared over 3,000 times within various IT security communities. Despite being classified by NVD as 6.8 (CVSSv2), our researchers have determined that CVE-2020-1147 may be more dangerous than CVE may lead you to believe.
With a public exploit, as well as two potentially vulnerable (but untested) endpoints, organizations may want to revisit this vulnerability – especially if it was relegated to the backlog given its initial “medium” rating.
MICROSOFT WINDOWS DNS VULNERABILITY (SIGRED)
CVE-2020-1350, dubbed SIGRed, has had the security community in a state of frenzy. Shared well over 13,000 times on social media, this vulnerability has low complexity in both access and attack, yet extremely high impacts on confidentiality, integrity, and availability.
According to The Hacker News, the vulnerability could allow an “unauthenticated, remote attacker to gain domain administrator privileges over targeted servers and seize complete control of an organization’s IT infrastructure.”
To make matters worse, this vulnerability is considered to be wormable. The potential for damage was so high that the US Department of Homeland Security and The Cybersecurity and Infrastructure Security Agency (CISA) mandated that government agencies update or reduce its risk within 24 hours. Forbes’ Davey Winder also commented on SIGRed’s potential:
“Being wormable puts this vulnerability right up there in terms of criticality with WannaCry and NotPetya in that it has the potential to propagate without user interaction, and propagate very rapidly indeed.”
Davey Winder, Forbes
All of this was disclosed 16 minutes from the start of July’s Fujiwhara Storm. By itself, SIGRed can tie up an organization’s entire security management or IT team. However, there was a lot more still to come.
4:20 PM EDT: Oracle drops nearly twice as many vulnerabilities as Microsoft
As has become an unfortunate norm, Oracle released 213 vulnerabilities at what was, for many, close to the end of the business day. With nearly twice the number of vulnerabilities as Microsoft, this late release forces many teams to triage late or to ignore it until the next morning.
This trend has become a steady theme for the Vulnerability Fujiwhara and for Patch Tuesdays as a whole: the inconsistency of timing causes problems for organizations as hundreds of vulnerabilities “linger” in the background due to the impossibility of remediating all of them at once.
As we analyze and catalog Vulnerability Fujiwhara and Patch Tuesday vulnerabilities, we continue to see “stalling” periods of where vendors will drop hundreds of disclosures in between hours of relative silence. Doing so reinforces a mindset that “it wasn’t THAT bad,” yet those actually involved in the process know that this is untrue. Organizations that do not have a fully mature vulnerability management program will have to resort to handling each vulnerability one by one, especially if they do not have a vulnerability intelligence solution that can help prioritize and remediate risk.
7/15/2020: Vendors continue to disclose
The Vulnerability Fujiwhara Effect continued to linger into the following day as Adobe, Cisco, and Apple published their vulnerability disclosures, effectively extending the Fujiwhara into a 48-hour period.
Interestingly, Adobe’s share was low compared to previous Fujiwhara events and Patch Tuesdays due to the absence of Flash and Reader vulnerabilities, which usually represent the bulk of their disclosures. Cisco however made up for the lack of Adobe Flash the next day by publishing a sizable amount of vulnerabilities, as did Apple.
Why do all of this yourself?
While our research team was fully prepared to handle the Vulnerability Fujiwhara Effect, it still meant 48 hours (with no down-time) collecting and assessing vulnerabilities. In preparation for the event we dispersed the workload between the entire team, ensuring that we took advantage of their diverse locations across the world. Researching and processing vulnerabilities is what we do, and we are uniquely equipped to meet the challenge.
Most organizations cannot support a dedicated, in-house vulnerability research team of this size. Even where an in-house team is an option, the workload required for such an event, or even for daily reports, is staggering and expensive. How long has it taken for your organization to fully process the Vulnerability Fujiwhara? Are you still working through those vulnerabilities? This prompts us to ask an important question – is it worth it for organizations to perform their own vulnerability research?
Time spent collecting and assessing vulnerabilities takes away from the time available to actually manage and remediate them. There are too many vulnerabilities to manage in an effective way. To make matters worse, vulnerability reporting has become tremendously decentralized, and the ability to compile reliable and accurate details also diminishes as there is no singular public source for every disclosed vulnerability.
This challenge has led some organizations to make unnecessary compromises in the data that they consume. Some believe that they must sacrifice quality for timeliness, or vice-versa. However, organizations can have both by employing a vulnerability intelligence solution.
VulnDB can provide the following for IT teams and Vulnerability Managers:
- A singular source for all the vulnerabilities on products and vendors you care about
- Standardized vulnerability reports that are pre-assessed for validity and accuracy
- Added technical details that cannot be found in the original reports
- Extra metrics to help better prioritization including information about severity, exploit availability, and report confidence
- And much more.
With VulnDB you can spend less time on vulnerability assessment, and more time on vulnerability management. VulnDB is the most comprehensive, detailed, and timely source of vulnerability intelligence, with over 94,000 that cannot be found in CVE/NVD. Ensure that you are properly equipped, not only for a future Vulnerability Fujiwhara, but also for the daily vulnerability reports impacting your organization.
2020 Vulnerability Fujiwhara: The writing on the wall
In January, Flashpoint published a blog warning about the upcoming “Vulnerability Fujiwhara”, a term we adopted for the colliding of Oracle and Microsoft patches on the same day. These Vulnerability Fujiwhara would be a completely different beast compared to usual “Patch Tuesday” events, which had already become the conglomeration of as many as a dozen vendors all releasing patches at once. But with the inclusion of Oracle, who typically releases over 400 patches in a single day, these Fujiwhara storms would undoubtedly become a significant event in the lives of IT staff.
These Fujiwhara events are typically rare, but 2020 saw three of them: January 14, April 14, and July 14. The last two observed pre-2020 Fujiwhara events occurred in 2015 and the next two will be seen in 2025—beginning on January 14! That illustrates just how infrequent these events are and why they stand out as a point of stress and additional risk for organizations. It is also important to note that 2015’s single Fujiwhara event saw a total of 277 disclosed vulnerabilities from all reports that day, less than half of what we saw from the April Fujiwhara this year.
That big increase is precisely the reason Flashpoint sounded the alarm on these three days. During April’s Fujiwhara event we saw 506 new vulnerabilities reported, 79% of which came from seven vendors. Compared to other Patch Tuesdays this year, the highest reported “only” 273 new vulnerabilities on June 9th. These Fujiwhara incidents, even though there are just three this year, are the writing on-the-wall so to speak. In the coming years, these increased totals will steadily become the norm.
Even if companies have been forced to become acclimated to already large coordinated patch days, how many vulnerability disclosures can they handle before it simply is too much? What is absurd about where we find ourselves is that the vendors creating the vulnerable software that put its paying customers at risk are also the ones creating the circumstance that adds additional risk. Perhaps “business as usual” needs to be re-examined.
Fujiwhara by the numbers
While Patch Tuesday originated with Microsoft, Adobe began releasing on the same day around 2012. In more recent years, additional vendors have begun to join the fray and reliably release on those days as well. They include SAP, Siemens, and Schneider Electric. To make the day more “convenient”, other vendors such as Apple, Mozilla, Intel, Cisco, and others sometimes participate in the festivities. As we saw with the latest Fujiwhara (July 14), Apple ended up releasing 27 new vulnerabilities, and Cisco 32, turning that event into a 48 hour, non-stop stream of triage for organizations.
Just two days accounted for 818 vulnerabilities, or 7.3% of the entire mid-year’s disclosures so far. However, if we include July’s Fujiwhara event (which falls after the mid-year reporting period in this report), three days will have been responsible for 10.5% of all 2020 vulnerabilities – 13% if you factor in the following day for each. In the middle of a global pandemic with many teams working with reduced staff, that is an incredible number of issues that must go through the triage process.
Tuesday is now 48 hours long
Around the inception of Patch Tuesday, we saw Microsoft and Adobe normally release a substantial number of vulnerabilities in the span of a few hours – a habit that they have kept since. Our research team knew that it would take a few hours to process the information and then we would move on with the rest of the day. However, over time, as more vendors began to adopt the Patch Tuesday movement, that window of expected disclosures has increased dramatically.
Whenever Oracle is involved, we know that we are in for a long day as they tend to release at the end of business hours (EST). Once SAP joined the fray, it further extended our hours considerably as they typically release in the early hours of the morning US time. With just these two vendors alone, our dedicated and fully staffed team is often looking at an 18 – 20 hour day. Does this experience sound familiar? If your organization is performing its own vulnerability research it should be all too familiar. When additional vendors are part of the mix, the sheer volume can cause us to perform triage and prioritize which entries we process first. The increased volume makes it easy for us to envision a full 24 hour cycle doing nothing but Patch Tuesday vulnerabilities.
In some cases, we may all need to block out a portion of Wednesday as well. A day after July 14th’s Fujiwhara incident, we ran into the situation where Cisco and Apple released a total of 59 vulnerabilities between them. That meant that between Tuesday and Wednesday we saw a grand total of 623 new vulnerabilities, creating a 48-hour cycle of disclosures.
Unfortunately for all of us, the writing is on the wall. This is likely something we can expect to occur more frequently in the future, even without the Vulnerability Fujiwhara effect. We have to ask, “Who benefits from this all-at-once disclosure of vulnerabilities?” Certainly not the paying customers. Due to the workload this places on IT departments, an unintended beneficiary may well be the bad actors waiting in the wings to exploit the newly released vulnerabilities. Are the software vendors looking to hide their releases in the crowd? If so, we’ll do our best not to let that happen.