Changes to Microsoft Security Bulletins

For those that have been in the industry for more than a couple of years, you will remember when Microsoft retired the very powerful and well-documented security bulletins back in 2017. At the time, we felt that it was a severe reduction in the availability of information; Microsoft was suddenly communicating much less information. Yesterday, they did it again. As the leader of a vulnerability research team, I feel it is my responsibility to point out the shortcomings of this newest format.

If you didn’t read the MSRC blog on Monday, then when Microsoft dropped their patches this month, you were introduced to a very unexpected advisory layout. If you were paying attention, you didn’t get the five months’ notice they gave us before the 2017 change – you got 24 hours. If you don’t read their blog daily, you got no notice.

Microsoft’s blog on this new format claims to have no loss of information, but I feel that couldn’t be further from the truth. As soon as you look at Microsoft’s blog post, you can tell there’s going to be a loss of information, but a quick review of their infographic says otherwise. They argue that the typical three- or four-sentence description they previously provided maps to a few fields in the CVSS Score and the vulnerability name.

In the first example, they visually demonstrate that with this:

An information disclosure vulnerability exists when the Windows kernel improperly handles objects in memory. An attacker who successfully exploited this vulnerability could obtain information to further compromise the user’s system.

To exploit this vulnerability, an attacker would have to log on to an affected system and run a specially crafted application. The vulnerability would not allow an attacker to execute code or to elevate user rights directly, but it could be used to obtain information that could be used to try to further compromise the affected system.

The update addresses the vulnerability by correcting how the Windows kernel handles objects in memory.

Maps to this:

“Windows Kernel Information Disclosure Vulnerability”

“Attack Vector: Local”

“Remediation Level: Fix”

This example isn’t awful. When you look at these two “descriptions,” however, it is clear that provides better explication than the other. Of course, this is a basic example of the simplest of vulnerabilities, when something more complicated comes along, this new methods suffers even more.

According to Microsoft, this change was made to, “demonstrating its commitment to industry standards by describing the vulnerabilities with the Common Vulnerability Scoring System (CVSS).” Here’s the problem, CVSS is not exactly a descriptive or entirely complete means of communicating information. CVSS was not designed to provide a vulnerability description, it was designed to generate a score. We don’t need to get into details around how CVSS has yet to succeed at its primary goal, but it’s worth talking about how it, in no way, meets this arbitrary new requirement that Microsoft has forced on it.

I understand that I tend to be verbose and Microsoft is arguing for a minimalist approach to their security guidance, but this is just a further obfuscation of the advisories, something I recently wrote about as being an issue in our industry. However, in this case, they have removed too much data.

Let’s take a look at CVE-2020-17049. This is a rather complex vulnerability and there are additional configuration steps in the FAQ section. Unfortunately, there are many unknowns. First of all, what is the vulnerability? According to Microsoft’s blog, you’ll get everything you need to know from:

• Kerberos
• Security Feature Bypass
• Attack Vector: Network
• Privileges Required: High
• User Interaction: None
• Remediation Level: Official Fix

Was that helpful? Do you now know what the vulnerability is? What it impacts? What you could do to further defend yourself?

If we continue to look at this vulnerability, the FAQ provides three additional recommended steps:

• Set HKLMSystemCurrentControlSetServicesKdcPerformTicketSignature to 0
• Deploy the patch to all DCs
• Set the registry key to 1.

They also mention that a later release will remove the registry key and make signatures required. This seems like a random additional statement until you read the values you can put into the registry key and realize that a value of 1 is not the more secure setting.

The three values that Microsoft provides are:

• 0 – This disables ticket signatures and your domains are not protected
• 1 – This fix is enabled on the domain controller but the DC does not require that tickets conform to the fix.
• 2 – This enables the fix in required mode where all domains must be patched and all DCs require tickets with signatures.

If tickets do not conform to the fix, is the problem really resolved? Why is there this ‘2’ setting that enables required mode (something Microsoft says they will forcibly enable in the future) if we aren’t using it? Is the problem on ticket generation or ticket receipt? These are all questions and concerns that would have previously been clarified in the description.

When Microsoft says that there’s no loss of information and that this is an improvement, a comic word bubble with ‘Liar!’ flashes in my head. I’ve read every Microsoft bulletin released in the past 15 years professionally and had looked at many of them before that. I’ve summarized them for a decade to help people better understand what is going on. I can look at this and immediately recognize a loss of information. Sure, on many of the bulletins, the same level of detail is there because they release plenty of generic bulletins related to the same issue over and over again, but for the critical vulnerabilities, the ones that really matter, they’ve always provided more information.

I want to say I was angry when I saw this change, but it was more than that… it was sadness. I was filled with depression. Microsoft spent the early 2000s and 2010s as a leader in how vendors should communicate security issues. They made a lot of precedent setting changes that impacted the entire industry. They built the base on which modern vendor security operates and now, with the changes in 2017 and the changes again yesterday, they have taken a wrecking ball to that base. They’ve destroyed my confidence in them. They’ve made me wonder if they still care about security. It’s an erosion of trust and I’m not sure I’ll be able to trust them again.

The post ” Changes to Microsoft Security Bulletins” appeared first on TripWire

Source:TripWire – Tyler Reguly