Skip to content

Developers

Jump to bottom
Arris Huijgen edited this page Mar 7, 2019 · 1 revision

This page is dedicated to people who want to join improving the Windows Exploit Suggester - Next Generation tool.

One of the challenges are the false positives which due to Microsoft's large dataset of KBs consisting of various different structures and standards are hard to tackle. Moreover, required information about supersedence of patches is missing from the dataset which makes it hard to extract senseful results from this vast amount of data.

The first section lists the datasets we are dealing with. The next section defines what KB information is required for WES-NG to function and how KBs (should) work. The observations section list the complicating behavior of both the systeminfo output files and Microsoft's datasets. Finally, I listed some thoughts on approaches to improve the results.

This page is essentially a braindump which helps me to structure my thoughts and improve WES-NG. Feel free to complement in case you have additional information or thoughts on how to approach the challenge of improving the results from the WES-NG tool.

Datasets

Available datasets

  • We have a huge dataset of KBs dating back to 2001
  • There are various datasets:
    • Microsoft Security Bulletin Data [1]
      • BulletinSearch2001-2008.xlsx: KBs between 20010111 and 20081111 (currently not used by WES-NG)
      • BulletinSearch.xlsx: date range KBs between 20081111 and 20170314
      • MSRC-CVRF.zip: Contains CVRF XML documents about vulnerabilties ms12-036 till MS17-004, but does not contain information about patches, so not used by WES-NG
    • MSRC API [2]
      • KBs between 20160412 and today
    • Microsoft Update Catalog [3]
      • Most KBs are available here
  • Datasets are regularly missing attributes like supersedence

KBs

Minimum required KB attributes for WES-NG to function:

  • KB identifier: Unique identifier patch
  • Supersedes: Identifiers of one or more KBs (attribute above) that have been superseeded by this KB (patch)
  • CVEs: Required to identify exploits from NIST's NVD

Statements regarding KnowledgeBase (KB) units

  • A KB defines which CVEs it patches
  • A KB includes one or more CVEs
  • A KB can be superseeded by another KB
  • A KB can be specific for an Operating System or apply to multiple Operating Systems
  • If a KB is installed on a system, the CVEs that are listed in the KB have been mitigated
  • If a KB is installed, it also includes all KBs listed in the supersedes attribute of this KB
  • If a KB is not installed on a system and is not listed in the supersedes attribute of any other KB, the system is vulnerable to the CVEs listed in this KB

Observations

Systeminfo

  • From the systeminfo output it is not possible to distinguish between Windows Server 2003 and Windows Server 2003 R2.
  • The list of KBs in the systeminfo outputs of Windows XP, Windows 7 and Windows Server 2012 R2 (but probably more OSs) are cut off at around 245 items; the full list is available in the output of the wmic qfe list brief command.
  • Windows XP (but probably more OSs) list hotfixes starting with a Q like Q147222.
  • Windows XP (but probably more OSs) lists hotfixes called "File 1".
  • The systeminfo output does not show the decimal build number relevant for Windows 10

Datasets

  • Some updates (KBs) are not reported because they are simply completely missing from the MSRC data set, for example KB4091664 which does show up when listing updates on an example Windows Server 2016 VM, but not in wes.py when providing it with the pre-update systeminfo output. In this case however, the update is not a Windows security-related update (it's Spectre Intel CPU microcode update), which might be the reason that it is omitted.
  • Some updates (KBs) are mistakenly reported because according to the MSRC data set they have never been superseeded by another update, for example KB3200970 does not show up when listing updates, but does show up in wes.py because in the MSRC dataset KB3206632 does not superseed any updates, while that KB actually supersedes KB3200970 [1].
  • In the MSRC dataset a small number of remediations have "Release Notes" string as identifier instead of the KB identifier. In above cases, searching the Windows Update Catalog [3] for the KB numbers, does show the correct information about supersedence etc.

Solutions brainstorm

These fixes can either be applied by default or by adding a flag which enables them.

  • From the systeminfo output pick the KB with the most recent publishing date and filter out all vulnerabilities for KBs that were published before this date.
  • Include a machine-readable version of the Windows 10 - Release information page [4] to the information downloaded via the --update flag, allow users to specify the exact OS build (systeminfo does not include the decimal build number) and filter out all vulnerabilities that were published before the availability date of that specific build.
  • Somehow collect the supersedence information from the Microsoft Update Catalog [3] which appears to be more complete than the the MSRC API [2].

References

[1] Microsoft Security Bulletin Data: https://www.microsoft.com/download/details.aspx?id=36982

[2] MSRC API: https://portal.msrc.microsoft.com/en-us/developer

[3] Microsoft Update Catalog: https://www.catalog.update.microsoft.com/

[4] https://docs.microsoft.com/windows/windows-10/release-information

Clone this wiki locally