Security vulnerabilities are regularly published by the dozens, and software vendors are in a constant race to issue updates that patch or mitigate them. This happens at an even faster pace in popular platforms that are appealing to researchers and attackers alike. That makes Microsoft’s Windows operating system — the leading desktop operating system by market share — a high-profile target, with a constant stream of vulnerabilities published regularly. Microsoft uses its monthly Patch Tuesday updates to automatically secure many Windows devices from those vulnerabilities.
That means most users are safe because they have an up-to-date version of Windows. However, there are many environments in which that is not the case. For example, industrial networks are often not managed, and are isolated from the online update services, meaning that many computers are left unpatched and vulnerable.
In these cases, IT administrators will still want to know based on the installed updates on a host, what vulnerabilities remain unpatched. In other words, to determine which vulnerabilities are resolved given a list of installed patches.
During our research we found this task difficult because of different complexities in the Microsoft update process. We will describe these challenges and walk through the journey of collecting data from different sources, building a dependency flow of updates, and eventually listing all remaining vulnerabilities on a host based on the list of installed updates.
Before we dig into the specifics of what we found, it’s important to understand some terminology.
Patch Tuesday – Since October 2003, Microsoft has published security updates across its product lines on the second Tuesday of every month, known as Patch Tuesday. This predictable update cycle has been the centerpiece of vulnerability management programs for almost 20 years, allowing users to build routines around patching Microsoft vulnerabilities.
Knowledge Base (KB) – Microsoft KBs are a repository of articles describing issues affecting Windows and other Microsoft products. Security updates start with the letters KB and refer to a specific Knowledge Base article; each KB contains a number of updates and patches. Updates are enumerated “KB123…” and are not sequential, which can lead to confusion when trying to determine patch levels and completeness.
KBs can be found using the systeminfo
command on a Windows machine:
There are two main types of updates (as explained in Microsoft Docs):
Security-Only Updates (SO) contain security updates for the month in which they are released, and each update is product-specific.
Monthly Rollups (MR) are cumulative security and reliability updates. Each Monthly Rollup addresses new security issues for a specific product and will include updates that were previously released.
Below is an illustration of KBs for Windows Server 2012 R2 showing connections between Monthly Rollups and Security-Only Updates.
Windows Version – a reference to a specific Windows operating system, service pack, and build:
Windows 10 build 1909 (aka build 18363)
Windows 10 build 21H1 (aka build 19043)
Windows 7 SP1
The following resources are available from Microsoft, and were useful during our research as we tried to understand the relationships between specific CVEs and the KBs that remediate or mitigate them.
Every Patch Tuesday, the MSRC publishes a Security Update Guide where users can find release notes for the KBs. Users can download the guide and map affected products to articles (KBs) and understand the impact of vulnerabilities, their severity as determined by Microsoft, and the CVE (Common Vulnerabilities and Exposures) number. From here you can download an Excel spreadsheet containing this information.
This resource helps users learn more details about specific KBs, in this case below, the November 2021 Monthly Rollup. Here, users can connect all KBs related to a specific Windows Version.Users can learn which KBs are mapped to which Windows Version via the Microsoft Support resource.
This searchable resource provides information about KBs and allows users to download KBs as well. Users should also note the “Package Details” tab, which allows users to see how KBs are connected, and which KBs replace previous ones.
Now that we understand the resources available, let’s tackle our problem, which is to understand the relationships between CVEs and the chain of KBs that remediate vulnerabilities.
For a user wishing to understand which KB addresses a particular CVE, the MSRC’s Security Update Guide may not provide enough information because it doesn’t illustrate the cumulative connection between KBs. Below, you can see this connection: the May Monthly Rollup contains CVE-1, while the June Monthly Rollup contains CVE-2 and also CVE-1 because it cumulatively includes the May update. The July Monthly Rollup, meanwhile, is another cumulative rollup that patches CVE-1, CVE-2, and CVE-3.
CVE details provided in the Security Update Guide connect only to the first KB that resolves it (blue arrows, below), but not to newer KBs that also contain the original fix (red arrow), as illustrated below. For this information, users have to make that connection in the Microsoft Update Catalog, or Microsoft Support page.
There needs to be a single cumulative mechanism to understand the relationships between CVEs and KBs and whether a machine is at a current patch level.
In order to solve the problem we need:
Source 1: For each CVE, the KBs that directly fix it; this information is easily collected from MSRC
Source 2: For each KB, a way to identify subsequent KBs. Building this relationship requires using additional data sources (Microsoft Update Catalog or Microsoft Support)
Once we have that information, the process would look like this:
1. To determine the first connection between a CVE and all direct KBs that resolve it, download the Excel spreadsheet from MSRC (Source 1).
2. To identify all future KBs that resolve a CVE:
For every KB detailed in MSRC’s spreadsheet, use the list of cumulative KBs that contain it (Source 2).
This step will give us a KBs chain, where each KB contains all KBs that were previously published. In the example below, the June Monthly Rollup contains the May Monthly Rollup, and the July Monthly Rollup contains the June Monthly Rollup and hence, also the May Monthly Rollup.
3. To connect CVEs to all the KB chains that remediate them:
For every CVE in the MSRC spreadsheet, determine its direct KB.
If one of the direct KBs is installed on the computer it means the CVE is patched.
If one of the installed KBs is later on that chain than the direct KB resolving this CVE, it also means the CVE is patched. In the example below, the installed KB is the July Monthly Rollup and the direct KB is the May Monthly Rollup. July follows May in the chain, hence this computer is not vulnerable to this CVE.
Otherwise, the CVE is not patched and the computer is vulnerable.
In the second step above we searched Microsoft Update Catalog to build a chain of KBs.
This, however, turned out to not be so easy. While collecting KB connections from this source, we discovered that they do not form a single, one-to-one chain.
The KBs represented below are the blue nodes, and the edges represent the connection between the KBs based on Catalog searches. You can see it looks like a mash connection, since the information in Catalog about a specific KB isn’t only the latest KB it’s connected to, but also all the KBs before it.
For example, we should expect them to be in chronological order from January 2020 → February 2020 → March 2020, but as you can see we also have the indirect connection between January 20 and March 20.
To get the one-to-one chain we wanted, we searched the mash connections for the longest path, creating this new one-to-one chronological (however, not sequential) chain graph.
The example below shows the process of creating the KB chain and understanding based on installed KBs, what CVEs the computer is vulnerable to.
Windows version: Windows Server 2012 R2
Date: December 2021, after Patch Tuesday
KB Installed: KB5008263, December Monthly Rollup, the latest Monthly Rollup for that date
To simplify this example, we will focus only on some of the CVEs from MSRC that affect Windows Server 2012 R2 (only those with a critical severity and a potential impact of remote code execution upon successful exploitation).
Highlighted below:
KB5008263 December Monthly Rollup (the installed KB on device)
KB5008285 December Security Only
KB5007247 November Monthly Rollup
KB5007255 November Security only
Our question now: What are the relationships between those four KBs?
Here we’ll describe only one way to find the KB relationships using Catalog; alternatively you can use other resources such as Support to make faster connections rather than recursively gather information. But take note that the connections aren’t always the same and you should choose the way that better suits you.
Below is a search in Catalog for a specific KB for example KB5008263, the December Monthly Rollup:
In the Package Details, you can find KB5007247 among the KBs that KB5008263 replaced, showing the cumulative Monthly Rollup from December to November.
This demonstrates the relationship between four CVEs for this Windows Version from MSRC and its corresponding KBs:
Direct installed KB impact: December Monthly Rollup remediates all three of December’s CVEs.
Cumulative impact: December Monthly Rollup remediates November’s CVE because it contains the November Monthly Rollup.
Windows updates are complex. The information about them is spread among multiple sources and the relationships between them is not straightforward.
We showed, however, that this can be untangled by properly understanding the mechanism to its full extent. This is an important step for a security practitioner to be able to have an accurate view of vulnerabilities that put their network at risk.
We have demonstrated how you can connect both a CVE to all the KBs that resolve it, and a KB to all the CVEs it resolves. The next time you hear about a new vulnerability, you have the knowledge and tools to verify if you’re patched.
Mapping the existing installed updates to applicable vulnerabilities, while sometimes more complex than you would have thought, can be achieved with a bit of research and investment.
CWE-770: Allocation of Resources Without Limits or Throttling
When performing an online tag generation to devices which communicate using the ControlLogix protocol, a machine-in-the-middle, or a device that is not configured correctly, could deliver a response leading to unrestricted or unregulated resource allocation. This could cause a denial-of-service condition and crash the Kepware application. By default, these functions are turned off, yet they remain accessible for users who recognize and require their advantages.
PTC recommends users take a defense-in-depth stance with regards to their manufacturing networks ensuring proper access control is maintained. Additionally, proper adherence to the Kepware Secure Deployment Guide will minimize this threat through accurate configuration and use of the product.
CVSS v3: 5.3
CWE-732: Overriding critical files
The vulnerability, if exploited, could allow a miscreant to read and write an AVEVA Reports for Operations project and/or tamper with installation files
CVSS v3: 7.8
CWE-22: Path Traversal leading to Arbitrary Code Execution
The vulnerability, if exploited, could allow a miscreant to execute arbitrary code under the privileges of an interactive AVEVA Reports for Operations user.
CVSS v3: 7.8
CWE-420: Unprotected Alternate Channel
A vulnerability exists in the affected products that allows a threat actor to bypass certain communications restrictions between slots in a 1756 chassis. If exploited on any affected module in a 1756 chassis, a threat actor could potentially execute CIP programming and configuration commands on a Logix controller in the chassis.
CVSS v3: 8.4
CWE-676: Use of Potentially Dangerous Function may allow security feature bypass
CVSS v3: 8.0