Vulristics Vulnerability Score, Automated Data Collection and Microsoft Patch Tuesdays Q4 2020. In this episode I would like to make a status update of my Vulristics project. For those who don’t know, in this project I retrieve publicly available vulnerability data and analyze it to better understand the severity of these vulnerabilities and better prioritize them. Currently, it is mainly about Microsoft Patch Tuesday vulnerabilities, but I have plans to go further. Also in this episode I want to demonstrate the new Vulristics features on Microsoft Patch Tuesday reports for October, November and December 2020.

Patch Tuesdays Automated Data Collection

First of all, I dealt with the annoying collecting of the data for Microsoft Patch Tuesdays reports. Previously it took pretty long time. I had to go to Microsoft website and search for CVE IDs. After that, I had to get the comments from various Vulnerability Management vendors and researchers blogs (Tenable, Qualys, Rapid7, ZDI). I wanted this to be as much automated as possible. I have added some code to make CVE search requests on the Microsoft website for a date range (including the second Tuesday of the month). I also figured out how to make searches on the Vulnerability Management vendors blogs. So, now to get a Microsoft Patch Tuesday report it’s only necessary to set the year and month.

Simple like this:

import functions_report_ms_patch_tuesday

functions_report_ms_patch_tuesday.make_ms_patch_tuesday_report(year="2020", month="December", rewrite_flag=True)

Vulristics Vulnerability Scoring (VVS)

I decided that CVSS is not suitable for evaluating, sorting and comparing vulnerabilities. I needed something to automatically process hundreds vulnerabilities every month and to highlight the most critical ones. Finally, I decided to make my own scoring – Vulristics Vulnerability Scoring (VVS).

Do you know the perfect formula for counting vulnerability criticality? Well, I don’t. 🙂 Any scoring that I can make will be subjective and will probably change over time. But at least I can make it transparent and easily changeable, so that everyone can make their own vulnerability scoring most appropriate for a particular organization.

Such scoring should consider

• CVSS Base score
• existence of the exploit
• exploitability of the vulnerability in the wild
• popularity of the vulnerable software
• type of the vulnerability

Examples:

2. Elevation of Privilege – Windows Kernel Local (CVE-2020-17087) – Critical [628]

component	value	weight	comment
Exploited in the Wild	1.0	18	Exploitation in the wild is mentioned at Vulners (AttackerKB object), AttackerKB, Microsoft
Public Exploit Exists	0	17	Public exploit is NOT found at Vulners website
Criticality of Vulnerability Type	0.5	15	Elevation of Privilege
Vulnerable Product is Common	1.0	14	Windows component
CVSS Base Score	0.7	10	NVD Vulnerability Severity Rating is High

3. Elevation of Privilege – Windows Print Spooler (CVE-2020-17001) – Critical [614]

component	value	weight	comment
Exploited in the Wild	0	18	Exploitation in the wild is NOT found at Vulners, Microsoft and AttackerKB websites
Public Exploit Exists	1.0	17	Public exploit is found at Vulners (Microsoft Windows Local Spooler Bypass)
Criticality of Vulnerability Type	0.5	15	Elevation of Privilege
Vulnerable Product is Common	1.0	14	Windows component
CVSS Base Score	0.7	10	NVD Vulnerability Severity Rating is High

Exploitablity in The Wild and Vulners

The really interesting thing was to detect if the vulnerability is being exploited in real attacks. I made a post in my telegram channel asking for ideas. We can’t use Microsoft data directly because they do not update it after the initial vulnerability release. Other good sources are AttackerKB by Rapid7 and US-CERT Bulletins.

I asked my friends from the Vulners team to add this feature and now you can search for CVEs exploited in the wild based on data from AttackerKB and US-CERT.

And also this data is available in JSON format for the vulnerability:

... 
         "exploitation": {
            "wildExploited": true,
            "wildExploitedSources": [
              {
                "type": "cisa",
                "idList": [
                  "CISA:2B970469D89016F563E142BE209443D8",
                  "CISA:61F2653EF56231DB3AEC3A9E938133FE",
                  "CISA:990FCFCEB1D9B60F5FAA47A1F537A3CB"
                ]
              },
              {
                "type": "attackerkb",
                "idList": [
                  "AKB:7C5703D3-9E18-4F5C-A4D2-25E1F09B43CB"
                ]
              }
            ],
            "modified": "2020-12-25T13:57:26"
          },
... 

I also added direct AttackerKB processing to Vulristics and some code to filter out false positives in “Exploitablity in The Wild”.

VM Vendor’s Comments

What about VM Vendor’s Comments? Firstly I thought that the existence of the comment from the vendor should be taken into consideration when counting the vulnerability score. But then I decided that it’s a bad practice because the vendors are not who makes the criticality but they help you to test your scoring.

For example, if your score shows that some vulnerability is critical and vulnerability management vendors don’t mention it, this means that your scoring has some flaws or the experts of VM vendor don’t understand something.

Microsoft Patch Tuesdays Q4 2020

Now let’s take a look on the Vulrisctics Microsoft Patch Tuesday reports for October, November and December 2020.

October 2020

• All vulnerabilities: 87
• Urgent: 0
• Critical: 2
• High: 20
• Medium: 63
• Low: 2

It has been an interesting month.

Most of the VM vendors and researchers focused on “Remote Code Execution – Windows TCP/IP (CVE-2020-16898) – High [500]”, dubbed “Bad Neighbor”. It affects all supported versions of Windows OS, and maybe unsupported/earlier versions of Windows as well. Tenable wrote: “According to a blog post from McAfee, Microsoft Active Protections Program (MAPP) members were provided with a test script that successfully demonstrates exploitation of this vulnerability to cause a denial of service (DoS). While the test scenario does not provide the ability to pivot to RCE, an attacker could craft a wormable exploit to achieve RCE. While an additional bug would be required to craft an exploit, it is likely that we will see proof-of-concept (PoC) code released in the near future.” However, there has been no news since October.

But there is a more critical vulnerability with a public exploit “Remote Code Execution – Microsoft SharePoint (CVE-2020-16952) – Critical [640]”. It was mentioned by all vendors, but without much emphasis.

And the second critical vulnerability is “Elevation of Privilege – Windows COM Server (CVE-2020-16916) – Critical [628]” for which there is a flag of exploitation in the wild in AttackerKB. How much can you believe it? Well AttackerKB is a crowdsourcing platform, so possibly it can be fake.

For many other vulnerabilities (including 19 RCEs), there are no exploits or signs of exploitation in the wild. Among them, much attention has been paid to RCE in Microsoft Outlook (CVE-2020-16947). A quote from Tenable: “Because Outlook’s Preview Pane is affected by this flaw, a user does not have to open the message in order for the vulnerability to be exploited. As Outlook is widely used for enterprise email, we highly recommend prioritizing the patching of this CVE.”

November 2020

• All vulnerabilities: 112
• Urgent: 0
• Critical: 3
• High: 17
• Medium: 90
• Low: 2

2 vulnerabilities were critical because there is information about them that they are Exploited in the wild.

All VM vendors initially did not notice “Security Feature Bypass – Kerberos KDC (CVE-2020-17049) – Critical [709]”, only ZDI wrote that they don’t understand what it is: “What security feature in Kerberos is being bypassed? What is the likelihood?”. But then a post appeared with a detailed description of the exploitation.

The second critical is “Elevation of Privilege – Windows Kernel Local (CVE-2020-17087) – Critical [628]”. It was used to escape Google Chrome’s sandbox in order to elevate privileges on the exploited system.

The third critical vulnerability “Elevation of Privilege – Windows Print Spooler (CVE-2020-17001) – Critical [614]” has a public exploit at Vulners (Microsoft Windows Local Spooler Bypass)

Most of the comments this month were about  “Remote Code Execution – Windows Network File System (CVE-2020-17051) – High [513]”. A quote from Tenable: “In a blog post by McAfee, there is speculation about combining CVE-2020-17051 with CVE-2020-17056, a remote kernel data read vulnerability in NFS, in order to bypass address space layout randomization (ASLR), which could increase the probability of a remote exploit”. But in fact, we did not see any attacks or exploits for this vulnerability.

Also worth mentioning RCEs in

• Microsoft Exchange Server (CVE-2020-17083, CVE-2020-17084)
• Windows Print Spooler (CVE-2020-17042)
• Microsoft Excel (CVE-2020-17019, CVE-2020-17064, CVE-2020-17065, CVE-2020-17066)
• Microsoft SharePoint (CVE-2020-17061)
• Microsoft Teams (CVE-2020-17091)

But we did not see any attacks or exploits for them either.

December 2020

• All vulnerabilities: 58
• Urgent: 0
• Critical: 1
• High: 23
• Medium: 30
• Low: 4

There were no vulnerabilities with exploits.

The critical is only “Remote Code Execution – Microsoft Exchange (CVE-2020-17144) – Critical [705]”, because of AttackerKB. How realistic is this? You know, crowdsourcing. Rapid7: CVE-2020-17144 which is another remote code execution vulnerability also stemming from improper validation for cmdlet arguments, this one only affects Exchange Server 2010 SP3 and does require additional user interaction to successfully execute”. Besides this, there were many other Microsoft Exchange RCEs (CVE-2020-17117, CVE-2020-17132, CVE-2020-17141, CVE-2020-17142).

Other RCEs worth mentioning were in:

• Windows NTFS (CVE-2020-17096). Tenable: “An RCE in Windows NT File System (NTFS), the file system used in Microsoft Windows and Microsoft Windows Server. No user interaction is required to exploit this vulnerability. Depending on the attacker’s position, there are a few avenues for exploitation. For an attacker that has already established a local position on the vulnerable system, executing a malicious application that exploits the flaw would result in an elevation of privileges. Alternatively, a remote attacker could exploit the flaw by sending malicious requests to a vulnerable system, so long as they could access it over the Server Message Block version 2 protocol (SMBv2). Successful exploitation in this context would grant the attacker arbitrary code execution”.
• Hyper-V (CVE-2020-17095)
• Microsoft SharePoint (CVE-2020-17118, CVE-2020-17121)
• Microsoft Excel (CVE-2020-17122, CVE-2020-17123, CVE-2020-17125, CVE-2020-17127, CVE-2020-17128, CVE-2020-17129)

Thank you, I will be glad to know your opinion about Vulristics and how it can be further improved. Write to https://t.me/avleonovchat.

Full reports are available here:

• October 2020
• November 2020
• December 2020