| layout | title | permalink | nav_order | description | image | author |
|---|---|---|---|---|---|---|
default |
CVE Analysis |
/docs/CVE-analysis |
3 |
CVE analysis is one road of many that leads to the identification and comprehension of vulnerability classes and discovery. |
/assets/images/jeff-golenski-PjTBdhXI_7s-unsplash.jpg |
clearbluejar |
CVE analysis is just one road of many that leads to the identification and comprehension of vulnerabilities and their corresponding vulnerability classes.
Photo by Jeff Golenski on Unsplash
- toc {:toc}
The analysis of a CVE will grant experience with the specific software that contains the reported vulnerability. As the component is analyzed, it will highlight the current problem and help put you in the context to identify other areas the same problem might exist (variant analysis).
Variant analysis is the process of using a known vulnerability as a seed to find similar problems in your code. Security engineers typically perform variant analysis to identify possible vulnerabilities and to ensure that these threats are properly fixed across multiple code bases. Source
The analysis of several CVEs within the same software can help to generalize common security issues or vulnerability classes found within a particular system.
A vulnerability class is a set of vulnerabilities that share some unifying commonality pattern or concept that isolates a specific feature shared by several different software flaws -TAOSSA
A fundamental understanding of vulnerability classes expands a researchers ability to spot the requirements for the various types of vulnerabilities. Each class will have several preconditions that enable a security flaw, such as a undersized buffer, failure to sanitize input, or one of several other mistakes that lead to vulnerabilities. The prerequisites for each type of vulnerability class act as breadcrumbs leading ultimately to the discovery of a vulnerability or the failure to meet some base requirement for a particular type of vulnerability, ruling it out. Over time, vulnerability classes develop as mental models that help researchers identify subtle security flaws, providing new lenses by which out of to approach various auditing tasks.
As you study CVEs, your knowledge of vulnerability classes will increase with repetition. You will see the same vulnerability class presented in several different real world contexts, giving you experience to see them a bit faster each time. As your set of known vulnerability classes increases, your ability to discover related and new vulnerabilities should grow in proportion. You can only find what you can see. You can only see what you understand.
The basic idea is to look at CVEs, build up your knowledge of vulnerability classes, and discover vulnerabilities.
More formally, the high level idea is to:
- Research relevant CVEs
- Perform analysis (CVE and Patch Diffing) to reach a sufficient level of understanding.
- Leverage the knowledge gained throughout the process to discover new or related vulnerabilities.
Taking a step back, and looking at the ideal process as applied to the Windows Print Spooler, we have the following graph.
graph TD;
A1[ CVE Research] --> A[CVE-2020-1048];
A1 --> B[CVE-2020-1337];
A1 --> C[CVE-2020-17001];
A1 --> D[CVE-2010-2729];
A1 --> E[CVE-2020-1030];
A --> F[CVE Analysis + Patch Diffing];
B --> F;
C --> F;
D --> F;
E --> F;
F --> I[System Comprehension]
F --> G[Vulnerability Classification];
F --> H[Root Cause Identification];
G --> J[Develop Mitigation Requirements / Novel Understanding];
H --> J;
I --> J;
J --> K[Discover New and/or Related Vulnerabilities]
This next section takes you through the details of CVE analysis for several Windows Print Spooler CVEs. In the process, we will discover relevant vulnerability classes and gain a better understanding of why the Windows Print Spooler recently reported several CVEs within the past year.
Let's begin.
Following along from our research, we will continue looking at CVEs from the Windows Print Spooler. Those linked below provide sample CVE analysis. Those selected were CVEs with plenty of public documentation, making the total analysis time minimal (~2-3 hours). If the CVE you seek lacks public research, patch difffing and further analysis may be your Obi-Wan Kenobi (only hope) for understanding.
This list was pulled in Jan 2021 searching "Windows Print Spooler" then reduced the list to those CVEs that had at least one public blog post or code sample.
| Name | Description |
|---|---|
| CVE-2020-17001 | Windows Print Spooler Elevation of Privilege Vulnerability This CVE ID is unique from CVE-2020-17014. |
| CVE-2020-1337 | An elevation of privilege vulnerability exists when the Windows Print Spooler service improperly allows arbitrary writing to the file system, aka 'Windows Print Spooler Elevation of Privilege Vulnerability'. |
| CVE-2020-1048 | An elevation of privilege vulnerability exists when the Windows Print Spooler service improperly allows arbitrary writing to the file system, aka 'Windows Print Spooler Elevation of Privilege Vulnerability'. This CVE ID is unique from CVE-2020-1070. |
| CVE-2020-1030 | An elevation of privilege vulnerability exists when the Windows Print Spooler service improperly allows arbitrary writing to the file system, aka 'Windows Print Spooler Elevation of Privilege Vulnerability'. |
| CVE-2010-2729 | The Print Spooler service in Microsoft Windows XP SP2 and SP3, Windows Server 2003 SP2, Windows Vista SP1 and SP2, Windows Server 2008 Gold, SP2, and R2, and Windows 7, when printer sharing is enabled, does not properly validate spooler access permissions, which allows remote attackers to create files in a system directory, and consequently execute arbitrary code, by sending a crafted print request over RPC, as exploited in the wild in September 2010, aka "Print Spooler Service Impersonation Vulnerability." |
CVE analysis isn't magic. There is no perfect set of steps to follow for full understanding of a particular CVE. For each of the linked analyses above, a basic analysis was perform using a predefined template. The analysis wasn't too complicated or long. It was mostly taking time to think about various security related topics as they pertained specifically to Windows Print Spooler and various security boundaries. Identifying the vulnerability classes, either explicitly stated or implied, in the public blogs and code samples. And finally, asking questions, making connections, and attempting to understand by digging a bit deeper than simply reading a blog post.
CVE analysis, or simply the study of CVEs is difficult to teach, rather best learned through experience. It will make the most sense when trying to answer some of the questions yourself. If you are new to security research, guard rails can be helpful to keep you on track. To provide the rails, a template is presented to guide your study of the CVEs and offer some hints for points of comparison to later be generalized in the development of your understanding.
Take a moment to read through some of the linked CVE analyses in the table above before moving on to the explanation of the template.
To help with the CVE analysis process, a standardized template can be helpful.
tags: #cve-analysis
- metadata
- CVE #:
- Related CWE(s):
- Related CVE(s):
- created: 2021-02-03
- title:
- web:
- platform:
- descriptor tags: #cve #security
# CVE-####-####
## Summary
## Components affected
## Security Boundaries
*which [security boundaries](https://www.microsoft.com/en-us/msrc/windows-security-servicing-criteria) have been crossed? **
## Hashtags
*connect CVE to a specific topic, event, theme or concept*
## Requirements
*what stars needed to align?*
## Fundamental Issue / Root Cause
### Best Fit Vulnerability Class (or CWE) for *this* CVE
### Is this CVE the Root Cause or a Causal Factor?
Choose **one**:
- **root cause** - *underlying issue or fundamental reason of a problem or issue*
- **causal factor** - *major contributor to an undesirable condition that if eliminated, would have either prevented the occurrence of the incident or reduced its severity or frequency*
## Patch Info
### Version
- Date
- Link
### Treating a Symptom or Cure?
CVE Analysis Template
This is quite a bit all at once. Before digesting, let's talk about some of the reasons for using a template. Then walk through the process of filling in the template for CVE-2020-1048.
- A Path to Follow - A template helps remove the guesswork of analysis. It provides a standard set of concepts and attributes to consider and helps a researcher focus the important aspects as related to the vulnerability.
- Efficiency through Standardization - As the process becomes familiar, the speed of analysis increases. With experience comes the ability to pick out the relevant information. With this (or another) prescribed template, the concepts to watch for are clear.
Let's walk through the process of CVE analysis for CVE-2020-1048. The responses and answers for the primary sections of the template are all based on this detailed post for CVE-2020-1048.
data about your data providing context for the CVE
At the top of the template is the metadata section. This section can help to categorize the CVEs, provide an easy way to go back and find relevant information, and give relational context to other CVEs.
- CVE #: CVE-YYYY-####
- Related CWE(s): Related Vulnerability Classes -** Related CVE(s)**: list of CVEs that relate to this instance
- created: 2021-01-29
- title: self created or internet deemed title
- web: list of reference blog links related to the CVE
- platform: Windows/Android/ios/etc
- descriptor tags: #hastagsToDescribeCVE
CWE stands for common weakness enumeration. Yet another community list helping to identify and categorize various types of vulnerabilities. The easiest way to explain the difference is to contrast CWE with CVE.
A CVE ID (common vulnerability and exposure) is an instance of a particular vulnerability. (ie CVE-2020-1048) A CWE (common weakness enumeration) is the category that a vulnerability fits in, it's type or vulnerability class.
Also, see CWE-Common-Weakness-Enumeration for more details.
- metadata
- CVE #: CVE-2020-1048
- Related CWE(s):
- [Improper Control of a Resource Through its Lifetime \- (664)](https://cwe.mitre.org/data/definitions/664.html)
- [Incorrect Resource Transfer Between Spheres \- (669)](https://cwe.mitre.org/data/definitions/669.html)
- [Client-Side Enforcement of Server-Side Security \- (602)](https://cwe.mitre.org/data/definitions/602.html)
- [Improper Access Control \- (284)](https://cwe.mitre.org/data/definitions/284.html)
- [Improper Privilege Management \- (269)](https://cwe.mitre.org/data/definitions/269.html)
- [Privilege Context Switching Error \- (270)](https://cwe.mitre.org/data/definitions/270.html)
- Related CVE(s):
- [CVE-2020-1337](CVE-2020-1337.md)
- [CVE-2020-17001](CVE-2020-17001.md)
- created: 2021-02-02
- title: Client Side Port Check Vulnerability (CVE-2020-1048)
- web:
- https://github.com/shubham0d/CVE-2020-1048
- https://windows-internals.com/printdemon-cve-2020-1048/
- https://github.com/ionescu007/PrintDemon
- https://i.blackhat.com/USA-20/Thursday/us-20-Hadar-A-Decade-After-Stuxnet-Printer-Vulnerability-Printing-Is-Still-The-Stairway-To-Heaven.pdf
- platform: Windows
- descriptor tags: #cve #security #printers
Some of the metadata is straightforward (date, web links, ID) and some are more complex.
The most difficult metadata bullet. The goal is to identify the vulnerability classes that relate to the particular CVE. Labeling a CVE with a CWE helps you to think about the specific vulnerability class and it's relationship in the context of your CVE. For CVE-2020-1048, two vulnerability classes were made explicit in the corresponding blog post.
Yes, it was that simple. The UI dialog has a client-side check… the server, does not. And PowerShell’s WMI Print Provider Module… does not.
The Spooler is impersonating… SYSTEM! It seems the code was never written to handle a situation that would arise where a user might have logged out, or rebooted, or simply the Spooler crashing, and now we can write anywhere SYSTEM can. Indeed, looking at the NT4 source code, the PrintDocumentThruPrintProcessor function just zooms through and writes into the port.
To standardize, match specific CWEs to the identified vulnerabilities classes. Here are the matches listed respectively:
Consider not only the direct matches (CWE-602 and CWE-270), but parent CWEs (parent CWEs generally being a more abstract version of the child). Explicitly mapping out the CWEs in this way can help a researcher identify relationships to other CVEs at a different level of abstraction. This is a convention that helps a novice researcher classify vulnerability classes and better understand their relationships. There are a few different views for CWEs, with the research view being suggested for vulnerability researchers.
Now that the metadata is out of the way, time to tackle the main content of the template. Don't go overboard here, but try to think and answer each question with the information that is available.
In your own words, summarize the primary details of the vulnerability. It's OK to quote, but make sure you able to communicate the vulnerability in your own writing. Paraphrasing helps to build your understanding.
>*PrintDemon is an elevation of privilege (EoP) vulnerability that exists in the Windows Print Spooler service as it improperly allows arbitrary file writing on the file system [](https://voidsec.com/cve-2020-1337-printdemon-is-dead-long-live-printdemon/)*
A local user can craft an print job (via a SHD file) which contains arbitrary data and an arbitrary file path as `SYSTEM`. This occurs because of two primary reasons.
- There are specific security checks that exist on the client side when adding a printer port that are missing on the server side, and those checks can be circumvent.
- The print spooler, when writing the file to disk creates and writes the file as the `SYSTEM` user if the impersonation token has no context. Which software or operating system components are affected by the CVE? Does it involve memory management? Kernel or user? File I/O? Authorization? Networking?
## Components affected
- Windows Print Spooler
- Windows Services
- AuthorizationAs the template highlights, "which security boundaries have been crossed"? Security boundaries help you understand when there is a problem. The boundary exist to separate different security domains (components with the same access level). The link provided is what Microsoft considers to be a security boundary, which depending on your goal, may just be a subset of all the boundaries to consider.
## Security Boundaries
*which [security boundaries](https://www.microsoft.com/en-us/msrc/windows-security-servicing-criteria) have been crossed?**
- **User** - A user cannot access or tamper with the code and data of another user without being authorized.
For CVE-2020-1048, a user was able to write a file as SYSTEM (a privileged user).
This section is more open ended. It's single purpose is to help label relationships or concepts relevant for the particular CVE. After reading the blog post, these are what came to mind. This would be helpful
## Hashtags
*connect CVE to a specific topic, event, theme or concept*
#lpe #printers #impersonation #clientSideOnlyChecks #privFileWriteThis section is a fun one. It is the step for in which you can challenge yourself and is sure to increase your skill at spotting vulnerabilities. It is essentially the section that maps out the requirements for the CVE. Take some time to think about the prerequisites needed to make this CVE a reality? What didn't the developer or software consider? What played a major role? What stars needed to align??
## Requirements
*what stars needed to align?*
- User context
- unprivileged users can add printers (and assign a printer port)
- ability to assign a printer port to an arbitrary file path.
- Several APIs are able to do this. Some clients have security checks for the path `PortIsValid`, some do not. This is a **Client Side Port Check Vulnerability**.
- >Yes, it was that simple. The UI dialog has a client-side check… the server, does not. And PowerShell’s WMI Print Provider Module… does not.
- Windows Print Spooler contains a Self Impersonation Privilege Escalation (SIPE)
- The print spooler relies on capturing the user's token. but:
- >Normally, this isn’t a big deal, because all subsequent print job operations will have the user’s token captured, and the file accesses will fail. **But not**… if you reboot, or kill the Spooler in some way.
- Controlling Print Spooler State
As you approach the Root Cause section in the latter half if the Template-for-CVE-analysis, there are several things to keep in mind. The idea is to determine the underlying security issue that caused the vulnerability. Sometimes this is clear from the various blog post and CVE write ups and other times clarity will only come from digging deeper with patch diffing. It's best to strive for a basic understanding of the root cause to determine if the vulnerability was sufficiently patched or alternatively if there are potentially other ways to reach the vulnerability that were not considered.
Armchair theorizing, armchair philosophizing, or armchair scholarship is an approach to providing new developments in a field that does not involve the collection of new information but, rather, a careful analysis or synthesis of existent scholarship, especially frivolously or superficially so. Wikipedia
Understanding the fundamental issue gives us a stepping stone to the reason as to why any particular CVE exists in the first place. Until the root issue is addressed, security remains a concern. In this section of the template, initially provide an armchair theory about the fundamental issue. Reason being, there is a bit of a chicken and egg situation here, you can't really know the root issue until you dig a little deeper. To dig a little deeper an analyst can apply both patch diffing and then further clarify with root cause analysis.
Best fit vulnerability class is the main category that the particular CVE instance aligns with. Sometimes a CVE can span multiple, but that can be fleshed out in the summary and previous section. The idea behind this section is to determine the best fit for the particular CVE. For those with more experience, a simple "use-after-free" reference might be enough. The novice researcher would do best to take a look at the CWE list, providing some rails on which to categorize the particular CVE. Arguably, this practice can help form links to new ideas about vulnerabilities (Vulnerability Class ideation) and increase overall comprehension.
From the blog post and initial observations above, we found two primary vulnerability clasess or CWEs:
- Client Side Port Check Vulnerability
- Self Impersonation Privilege Escalation (SIPE)
For this CVE-2020-1048, and for reasons made clear during the patch diffing applied, it is clear that the CVE that was patch for this CVE is:
### Best Fit Vulnerability Class (or CWE) for *this* CVE
- [Client-Side Enforcement of Server-Side Security - (602)](https://cwe.mitre.org/data/definitions/602.html)The answer to this question is often more subtle than expected. To really get the root cause, we will later take a look at root cause analysis in order to properly understand its application. In case you can't wait, take a look at Finishing Root Cause Section in the Template.
This section will be covered later, when we have a better grasp of Patch-Diffing, we can enriched our understanding when we apply the techniques in Patch-Diffing-Applied.
There are alternate templates. In July of 2020 Googe's Project zero shared a template for root cause analysis. They also keep a spreadsheet to summarize their findings across the years. See Google-Project-Zero-Template. What is most important is that you have a process that works for you.
We will now pivot. From information gathering and familiarization to the process of finding patterns within your analysis. Reviewing several CVEs for a particular piece of software should help connect some dots by defining the requirements (aka primitives) needed to enact the vulnerabilities. The more you can observe, the more likely a pattern will emerge. As you being to become familiar with a particular software component, it will be easier to notice the security relevant areas of the software.
Simply reviewing the CVE search result table's text can give you some hint without looking any further. You can see that this is a Windows service, likely running at an elevated privelege, accessible by RPC and able to write arbitrary files.
Result of dumping the above text in a word art generator
Reading some of the completed CVE analyses above, you can begin to get a feel for the vulnerabilities within the Windows Printer Spooler. Generalizing patterns from within the various sections can help you see clearer.
Leveraging several sections from the template across multiple CVEs, patterns emerge.
- Arbitrary file write as
SYSTEMleading to code execution
- User - A user cannot access or tamper with the code and data of another user without being authorized.
- Network boundary - An unauthorized network endpoint cannot access or tamper with the code and data on a customer’s device.
- User context - running code as user
- Networked / Shared Printer
- Controlling State
- ability to (start/stop/resume print jobs)
- TOCTOU
From the CVE analysis, some general insights emerge:
- The Windows Print Spooler is a popular target because it is running as
SYSTEMand can easily be interacted with from a standard user via Win32 APIs over RPC. - The Windows Printer Spooler performs several privileged file operations and is subject to Time of Check Time of Use Vulnerabilities.
- The Windows Printer Spooler is also subject to network attacks via its HTTP component.
From repeated CVE analysis you can begin to understand the complexity (service,user,network) of this system. The entry points and attack surface (APIs). Clarity about particular security relevant sections (authentication, files writes) start to become clear. And finally, a general idea about which vulnerability classes (CWEs and more generally TOCTOU, race condition).
There is no such thing as a perfect analysis. There isn't enough time or resources to provide complete comprehension. It's OK to not fill in the template completely. This process details a repeatable analysis to be applied with consideration to the time and resources available.
The hope is that CVE analysis would be a repeatable process to increase comprehension of a specific vulnerability and vulnerability classes, that would lead to further competence in vulnerability research, that would culminate in new discovery and insight.
graph LR;
A[CVE Analysis] --> B[Comprehension / Familiarity];
B --> C[Competence];
C --> D[Discovery];
This section we walked through the analysis of CVE-2020-1048 and we now have our heads around what is means to analyze a CVE from public sources. It is now time to discover for ourselves how a particular vulnerability was patched, looking for the binary truth via our skills in reverse engineering, and leveraging patch diffing to fill in some of the gaps and provide further clarity. Before we get there, we need to understand at a fundamental level how security patches are provided for the Windows Operating System.
graph TD;
classDef current fill:#00cc66;
F:::current;
A1[CVE Research] --> A[CVE-2020-1048];
A1 --> B[CVE-2020-1337];
A1 --> C[CVE-2020-17001];
A1 --> D[CVE-2010-2729];
A1 --> E[CVE-2020-1030];
A --> F[CVE Analysis];
B --> F;
C --> F;
D --> F;
E --> F;
Next section: Security Patches{: .btn .btn-primary .fs-4 .mb-4 .mb-md-0 .mr-2 }