[ad_1]
For those who 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 in 2017. At the time, we felt 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 believe it is my responsibility to point out the shortcomings of this newer format.
If you didn’t read the MSRC blog on Monday, when Microsoft released its patches this month, you were presented with a very unexpected warning design. If you were paying attention, you didn’t get the five month notice they gave us before the 2017 change; has 24 hours. If you don’t read their blog daily, they don’t warn you.
The Microsoft blog on this new format claims no loss of information, but I think it couldn’t be further from the truth. As soon as you look at Microsoft’s blog post, you may notice there will 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 provided above maps to a few fields in the CVSS score and the name of the vulnerability.
In the first example, they visually demonstrate that with this:
An information disclosure vulnerability exists when the Windows kernel incorrectly 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 into an affected system and run a specially crafted application. The vulnerability would not allow an attacker to execute code or elevate user rights directly, but 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 the way that the Windows kernel handles objects in memory.
It is assigned to this:
“Windows Kernel Information Disclosure Vulnerability”
“Attack Vector: Local”
“Level of remediation: correct”
This example is not terrible. However, when you look at these two “descriptions”, it is clear that it provides a better explanation than the other. Of course, this is a basic example of the simplest of vulnerabilities, when something more complicated comes up, this new method suffers even more.
According to Microsoft, this change was made to “demonstrate their commitment to industry standards by describing vulnerabilities with the Common Vulnerability Scoring System (CVSS).” Here’s the problem, CVSS is not exactly a descriptive or completely comprehensive 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 go into detail about how CVSS has yet to succeed in its main goal, but it’s worth talking about how it in no way meets this arbitrary new requirement that Microsoft has placed on it.
I understand that I tend to be wordy and Microsoft advocates a minimalist approach to their security guidance, but this is just a further obfuscation of the warnings, something I recently wrote about as an issue in our industry. However, in this case, they have deleted too much data.
Let’s take a look at CVE-2020-17049. This is a fairly 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 the Microsoft blog, you will get everything you need to know about:
- Kerberos
- Bypassing security features
- Attack vector: network
- Required privileges: High
- User interaction: none
- Remediation level: official settlement
Was that helpful? Do you know now what the vulnerability is? What impact? What could you do to defend yourself even more?
As we continue to analyze this vulnerability, the FAQ provides three additional recommended steps:
- Set HKLM System CurrentControlSet Services Kdc PerformTicketSignature to 0
- Roll out the patch in all developing countries
- Set the registry key to 1.
They also mention that a later version will remove the registration key and require the signatures. This seems like a random extra statement until you read the values that you can put in the registry key and realize that a value of 1 is not the safest setting.
The three values 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 domain controller does not require tickets to conform to the fix.
- 2 – This enables the correction in required mode where all domains need to be patched and all DCs require tickets with signatures.
If the tickets don’t fit the correction, is the problem really solved? Why is there this ‘2’ setting that enables required mode (something Microsoft says they will forcibly enable in the future) if we’re not using it? Is the problem in ticket generation or receipt of tickets? These are all questions and concerns that would have been clarified previously in the description.
When Microsoft says there is no data loss and that this is an improvement, a comic bubble appears with “Liar!” flashes in my head. I have read all the Microsoft bulletins published in the last 15 years in a professional way and have looked at many of them before that. I have summarized them for a decade to help people better understand what is happening. I can look at this and immediately recognize a loss of information. Sure, in many of the bulletins, the same level of detail is there because they publish a lot of generic bulletins related to the same issue over and over, but for critical vulnerabilities, the ones that really matter, they have always provided more. information.
I mean I was angry when I saw this change, but it was more than that … it was sadness. I was full of depression. Microsoft spent the early 2000s and 2010s as a leader in how vendors should communicate security concerns. They made many changes that set precedents that affected the entire industry. They built the foundation on which modern vendor security operates and now, with the changes in 2017 and changes again yesterday, they have brought a wrecking ball to that foundation. They have destroyed my trust in them. They have made me wonder if they still care about safety. It’s an erosion of trust and I’m not sure I can trust them again.
