CERT/CC Blog FeedConfluence Syndication Feedhttps://vuls.cert.org/confluenceProbably Don’t Rely on EPSS YetJonathan Springtag:vuls.cert.org,2009:blogpost-107642882-32022-06-15T14:09:12Z2022-06-06T04:00:00Z<div class="feed"> <p>
Blog post
<b>edited</b> by
<a href=" https://vuls.cert.org/confluence/display/~jspring
">Jonathan Spring</a>
</p>
<div style="border-top: 1px solid #ddd; border-bottom: 1px solid #ddd; padding: 10px;">
<p><em>Author's Note: This post was updated on June 9, 2022, to correct factual errors including references to Kenna Security instead of AlienVault and Fortinet. This post was updated on June 14, 2022, to edit content to reflect the publication of the</em> <a href="https://www.first.org/epss/faq" class="external-link" rel="nofollow"><em>EPSS FAQ</em></a> <em>on June 10, 2022.</em><br/><br/></p><p><a href="https://en.wikipedia.org/wiki/Vulnerability_management" class="external-link" rel="nofollow">Vulnerability management</a> involves discovering, analyzing, and handling new or reported security vulnerabilities in information systems. The services provided by vulnerability management systems are essential to both computer and network security. This blog post evaluates the pros and cons of the <a href="https://www.first.org/epss/model" class="external-link" rel="nofollow">Exploit Prediction Scoring System (EPSS)</a>, which is a data-driven model designed to estimate the probability that software vulnerabilities will be exploited in practice.</p><p>The EPSS model was initiated in 2019 in parallel with <a href="https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=538368" class="external-link" rel="nofollow">our criticisms of the Common Vulnerability Scoring System (CVSS)</a> in 2018. EPSS was developed in parallel with our own attempt at improving CVSSS, the <a href="https://github.com/CERTCC/SSVC" class="external-link" rel="nofollow">Stakeholder-Specific Vulnerability Categorization (SSVC)</a>; 2019 also saw <a href="https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=636379" class="external-link" rel="nofollow">version 1</a> of SSVC. This post will focus on EPSS version 2, released in February 2022, and when it is and not appropriate to use the model. This latest release has created a lot of excitement around EPSS, especially since improvements to CVSS (version 4) are still being developed. Unfortunately, the applicability of EPSS is much narrower than people might expect. This post will provide my advice on how practitioners should and should not use EPSS in its current form.</p><p>This post assumes you know about the services comprising <a href="https://www.first.org/standards/frameworks/csirts/csirt_services_framework_v2.1#7-Service-Area-Vulnerability-Management" class="external-link" rel="nofollow">vulnerability management</a> and why prioritization is important during analysis and response. Response includes remediation (patching or otherwise removing the problem) and mitigation (doing something to reduce exposure of vulnerable systems or reduce impact of exploitation). Within coordinated vulnerability disclosure roles, I’ll focus just on <a href="https://vuls.cert.org/confluence/display/CVD/3.4.+Deployer" rel="nofollow">people who deploy</a> systems. These are the folks most likely to have legitimate uses of EPSS, but even for many deployers this approach can lead to a short circuit rather than a shortcut if they’re not careful.</p><p>EPSS semi-formalized as a <a href="https://www.first.org/global/sigs/" class="external-link" rel="nofollow">special interest group (SIG)</a> at <a href="https://www.first.org/" class="external-link" rel="nofollow">FIRST</a> in 2020. I’ve participated on the SIG since its inception. I say this not to give myself any special authority, but rather to clarify why I’m posting this information here rather than integrating it into the EPSS website. The SIG has not prioritized publicizing the information in this post, and I think it is important information to consider when organizations decide if and how to adopt EPSS. A SIG at FIRST <a href="https://www.first.org/global/sigs/framework" class="external-link" rel="nofollow">serves to</a> “explore an area of interest or specific technology area, with a goal of collaborating and sharing expertise and experiences to address common challenges.” Basically, this means I’ve been on a lot of calls and email threads with people trying to improve EPSS. In general, I think everyone on the SIG has done a great job working within the constraints of donating their time and resources to a project, which was initially described by <a href="https://academic.oup.com/cybersecurity/article/6/1/tyaa015/5905457" class="external-link" rel="nofollow">this 2020 paper</a>.</p><p>However, I have a few concerns about EPSS that I’d like to highlight here. I have raised these concerns within the SIG, but the SIG has no formal voting process, so I can’t be sure whether my views represent a minority opinion.</p><p>Here are the two general spheres of problems I see: problems due to model opacity and problems stemming from the details of data provenance (elaborated below). EPSS cannot replace a vulnerability analysis or risk management process and should not be used by itself. However, EPSS v2 is currently useful in some restricted scenarios, which I’ll highlight below.</p><h1 id="ProbablyDon’tRelyonEPSSYet-EPSSOpacity">EPSS Opacity</h1><p>The EPSS target audience, development process, and future governance are opaque.</p><p>EPSS <a href="https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=633583" class="external-link" rel="nofollow">uses</a> <a href="https://insights.sei.cmu.edu/blog/tags/artificial-intelligence-and-machine-learning/" class="external-link" rel="nofollow">machine learning</a> to predict exploitation probabilities for each <a href="https://www.cve.org/" class="external-link" rel="nofollow">CVE ID</a> (CVE IDs provide identifiers for vulnerabilities in IT products or protocols). This reliance on pre-existence of a CVE ID is one reason why EPSS is not useful to software suppliers, CSIRTs, and many bug bounty programs. Most of those stakeholders need to prioritize vulnerabilities that either do not have public CVE IDs (because, for example, the vendor is coordinating a fix prior to publication) or are types of vulnerabilities that never receive CVE IDs, such as misconfigurations. Furthermore, zero-day vulnerabilities may get a CVE ID upon publication and disclosure, but a zero day is almost always published because it is widely known to be exploited. The <a href="https://www.first.org/epss/faq" class="external-link" rel="nofollow">EPSS FAQ</a> clarifies that vulnerabilities widely known to be exploited are out of scope for EPSS. That is, the target audience for EPSS is opaque. My understanding, based on these design decisions, is that EPSS is useful for some organizations that deploy software systems to prioritize application of software patches tied to CVE IDs. It is useful as long as the organization is mature enough that it can distinguish and has capacity to address vulnerabilities that are “just below the obvious” threats of widely exploited vulnerabilities and the EPSS data provenance matches the organization (see below). This is a big group of organizations that are worth helping. It can be complicated to determine whether you are in the target audience or not, so I recommend that you give the decision careful consideration.</p><p>EPSS <a href="https://www.first.org/epss/" class="external-link" rel="nofollow">calls itself</a> an “open, data-driven effort”—but it is only open in the sense that anyone can come and ask questions during the meetings to the handful of people who actually have access to the code and data for producing the scores. SIG members generally do not have access to the code or the data. That handful of people are generally super nice and do their best to answer questions seriously within the constraints of the proprietary aspects of the data collection, training, and modeling. However, because salient operational details of the EPSS prediction mechanism are not open to the SIG generally, we can only rely on the metrics about them that are made available. These are fairly good metrics, because they include the performance metrics used to train the model. However, as a SIG member I have no special access to information beyond what any reader would have from going to the <a href="https://www.first.org/epss" class="external-link" rel="nofollow">EPSS website</a>. There is not a formal layer of governance and oversight that the SIG performs on the development of the model. That is, the process is opaque.</p><p>In addition, there is no guarantee that either the input data or the work to produce the predictions from the data will continue to be donated to the public indefinitely. It could go away at any time if just a couple key members of the SIG decide to stop or to charge FIRST for the data. Multiple vendors donating data would make the system more robust; multiple vendors would also address some, but not all, of the problems with the data discussed next.</p><p>This opacity makes the clear labeling of the outputs critically important, which is the topic of the next section.</p><h1 id="ProbablyDon’tRelyonEPSSYet-EPSSDataandOutputs">EPSS Data and Outputs</h1><p>EPSS outputs genuine probabilities. In the phrase “the probability that _____,” that blank needs to be filled in. On the <a href="https://www.first.org/epss/" class="external-link" rel="nofollow">first line of its website</a>, EPSS purports to fill that blank as “probability that a software vulnerability will be exploited in the wild.” The EPSS SIG elaborates on this statement (e.g., explanations of how to interpret <a href="https://www.first.org/epss/articles/prob_percentile_bins" class="external-link" rel="nofollow">probabilities</a> in general and the <a href="https://www.first.org/epss/model" class="external-link" rel="nofollow">data sources</a> that go in to the calculation of the probabilities). Nonetheless, even with understanding the elaborations, this statement is oversimplified enough that I think it is both misleading and wrong.</p><p>EPSS got here attempting to avoid one of our <a href="https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=9382369" class="external-link" rel="nofollow">key criticisms of CVSS</a>: CVSS vector elements are not actually numbers, just rankings, and so the whole idea of using mathematics to combine the CVSS vector elements into a final score is unjustified. EPSS takes in qualitative attributes, but the machine learning architecture treats all of these with the right kinds of mathematical formalisms and produces a genuine probability. These outputs still need the correctly specified event and timeframe. EPSS forecasts the probability that “a software vulnerability will be exploited in the wild in the next 30 days.” This statement appears to be well-defined, until we dig into what the inputs are and the implications this has for generalizability of the output data.</p><p>I’m worried about assumptions and connections that get introduced into the probability that we cannot capture with simple unit conversions or calculation of conditional probabilities. Here is the crux of the problem. As far as I know, the EPSS phrase “a software vulnerability will be exploited in the wild [in the next 30 days]” actually means the following:</p><ul><li>software vulnerability = a CVE ID in the <a href="https://nvd.nist.gov/" class="external-link" rel="nofollow">National Vulnerability Database</a> with a CVSSv3 vector string (see discussion of EPSS audience in relation to CVE ID dependencies above)</li><li>exploited = an IDS signature triggered for an attempt to exploit the CVE ID over the network</li><li>in the wild = a contributor to AlienVault or Fortinet whose network is instrumented with their IDS systems and their data is shared</li><li>in the next 30 days = model training parameter window for analysis over past data</li></ul><p>There are further important details that are not clear from the documentation. For example, only about 10 percent of the vulnerabilities with CVE IDs even have IDS signatures. So 90 percent of CVE IDs could never be detected to be actively exploited this way. Anyone who cares about vulnerabilities that are not exploitable over the network needs information in addition to EPSS.</p><p>Even for network-exploitable vulnerabilities, the way IDS signatures are created is complex. Moreover, the signature curators have their own priorities and performance aspects to optimize, which means the coverage for the signatures is probably much better than random as long as your environment is similar to the environment the IDS vendor is managing. The flip side is that your coverage is plausibly worse than random if your environment is a mismatch.</p><p>In some important way, EPSS is doing something smart. It’s saying, <em>Hey, we saw IDS alerts for attempts to exploit these CVE IDs, and here are a handful of things we didn’t see alerts for but that seem similar</em>. That’s great if you have an environment similar to the environments of AlienVault’s or Fortinet’s main and biggest customers. I don’t know where that is, but my guess is offices and other classic IT shops. They probably run mail and AD servers, databases, and Microsoft endpoints; are midsize; have employees who are English-speaking; are located primarily in North America; and are regular commercial-ish businesses.</p><p>The operational security of Fortinet and AlienVault means they shouldn’t openly disclose the exactly location of their IDS sensors. Fortinet at least publishes vague data about <a href="https://www.fortiguard.com/threat-research/map" class="external-link" rel="nofollow">where threats originate</a>; as far as I know, <a href="https://cybersecurity.att.com/alien-labs" class="external-link" rel="nofollow">AT&T</a> says nothing about AlienVault's shared content. How to adequately corroborate processes and conclusions <a href="https://tylermoore.utulsa.edu/nspw17.pdf" class="external-link" rel="nofollow">in security</a> to understand the extent of <a href="https://link.springer.com/article/10.1007/s13347-018-0329-z" class="external-link" rel="nofollow">generalization that is justified</a> is itself an open research question. We are working on it, but it’s a wicked problem.</p><p>Organizations should measure and validate the usefulness of EPSS in their environments. No organization should assume that its environment matches the data used to train EPSS. However, many organizations’ environments should be a near-enough match. It would help us solve this problem if organizations would tell the SIG how they validated fit-to-environment and what the results were.</p><p>EPSS fairly consistently gives, for instance, low scores to IoT vulnerabilities that we know are being exploited. For example, there are several CVE IDs in CISA’s <a href="https://www.cisa.gov/known-exploited-vulnerabilities-catalog" class="external-link" rel="nofollow">known exploited vulnerabilities</a> list with low EPSS scores, and there are plenty of CVE IDs with high EPSS scores not in that list. People seem to think that this discrepancy means one or the other is wrong. Actually, it probably does not inform rightness or wrongness about either. The discrepancy might be telling us that attackers use different methods to attack the organizations in CISA’s constituency than they use to attack AlienVault’s and Fortinet’s constituency. This interpretation would be consistent with the fact that <a href="https://www.usenix.org/conference/usenixsecurity19/presentation/li" class="external-link" rel="nofollow">we know</a> <a href="https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=466027" class="external-link" rel="nofollow">attackers</a> <a href="https://ieeexplore.ieee.org/abstract/document/7140298" class="external-link" rel="nofollow">target</a> <a href="https://insights.sei.cmu.edu/blog/domain-blacklist-ecosystem-a-case-study/" class="external-link" rel="nofollow">victims</a> using <a href="https://www.sciencedirect.com/science/article/pii/S1874548213000036" class="external-link" rel="nofollow">specific</a> <a href="https://pure.tudelft.nl/ws/files/94649359/WEIS2021_Measuring_CaaS_Offerings_in_a_Cybercrime_Forum.pdf" class="external-link" rel="nofollow">infrastructure</a>. Perhaps, however, it is just the result of the expected error rate reported about the EPSS model. This result further suggests to me that organizations need to empirically validate that their environment fits well enough to the environments used to train EPSS.</p><h1 id="ProbablyDon’tRelyonEPSSYet-HowtoUseEPSSNow">How to Use EPSS Now</h1><p>EPSS is great in that it is bringing attention to threat data. I agree 100 percent that paying attention to what attackers are exploiting is important in prioritizing vulnerabilities. The <a href="https://www.first.org/epss/faq" class="external-link" rel="nofollow">EPSS FAQ</a> does not provide specific advice on where to start using EPSS scores; I’ll share my advice here. In summary, EPSS is not suited to software vendors, coordination CSIRTs, or PSIRTs and SOCs handling a large number of misconfigurations or other vulnerabilities without CVE IDs (common with bug bounty programs). EPSS is not good for protecting <a href="https://en.wikipedia.org/wiki/Operational_technology" class="external-link" rel="nofollow">Operational Technology</a> networks in infrastructure, healthcare, or manufacturing sectors. It is suited to teams doing patch management in mature organizations that already have good asset management and the surge capacity to handle emergencies posed by widely exploited vulnerabilities as an input to decisions about vulnerability management. EPSS is clear that “<a href="https://www.first.org/epss/faq" class="external-link" rel="nofollow">EPSS is not and should not be treated as a complete picture of risk.</a>”</p><p>SSVC <a href="https://github.com/j---/SSVC/blob/main/doc/md_src_files/082_relatedSystems.md" class="external-link" rel="nofollow">could use EPSS</a> data and combine it with these other information items right now. CVSSv3 can also account for threat in the temporal metrics. I happen to not like that CVSSv3 implicitly assumes everything is being exploited (default worst case, temporal scores only reduce scores) even though we know from EPSS data and <a href="https://www.usenix.org/conference/cset20/presentation/householder" class="external-link" rel="nofollow">other sources</a> that most vuls are not exploited; however, properly using the CVSS base, environmental, and temporal scores is probably better than using EPSS alone. When the EPSS website says EPSS is better than CVSSv3, it means CVSSv3 base scores. The CVSS SIG has made it clear you should not be using CVSS base scores by themselves to rank and sort vulnerabilities. EPSS is useful because it calls attention to that shortcoming with the way people have used CVSS base scores.</p><p>A high EPSS score is a signal that many people could pay attention to. If your environment resembles the environment that EPSS data comes from, you should use a high EPSS score to set values in SSVC or CVSSv3 temporal metrics related to public proof of concept or active exploitation. That would certainly be a win. To be clear, this is my recommendation on how to combine CVSSv3 with EPSS; there is <a href="https://www.first.org/epss/user-guide.html" class="external-link" rel="nofollow">no consensus on this topic</a>.</p><p>One way to validate that your environment resembles the same starting point as the EPSS data is to try to measure how many false positive prioritizations and the number of misses of things you should care about. For stakeholder organizations that do not have the maturity to evaluate this question, improving your asset management system is probably a better use of your time than adopting EPSS.</p><p>You also might want to know how expensive it will be to remediate the CVE ID. I don’t know of anyone who has a good public system for this, but we know it’s something people need to be able to integrate into the decision.</p><h1 id="ProbablyDon’tRelyonEPSSYet-AdditionalResources">Additional Resources</h1><p>Read the SEI white paper, “<a href="https://resources.sei.cmu.edu/library/asset-view.cfm?assetID=538368" class="external-link" rel="nofollow">Towards Improving CVSS</a>,” which I coauthored with Eric Hatleback, Allen Householder, Art Manion, and Deana Shick.</p><p>Read the SEI white paper, “<a href="https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=653459" class="external-link" rel="nofollow">Prioritizing Vulnerability Response: A Stakeholder-Specific Vulnerability Categorization (Version 2.0)</a>,” which I coauthored with Allen D. Householder, Eric Hatleback, Art Manion, Madison Oliver, Vijay S. Sarvepalli, Laurie Tyzenhaus, and Charles G. Yarbrough.</p><p>Read the SEI white paper “<a href="https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=644720" class="external-link" rel="nofollow">Historical Analysis of Exploit Availability Timelines</a>,” which I coauthored with Allen D. Householder, Jeff Chrabaszcz (Govini), Trent Novelly, and David Warren.</p><p>The <a href="https://kb.cert.org/vuls/" class="external-link" rel="nofollow">CERT Coordination Center Vulnerability Notes Database</a> provides information about software vulnerabilities. Vulnerability notes include summaries, technical details, remediation information, and lists of affected vendors.</p>
</div>
<div style="padding: 10px 0;">
<a href="https://vuls.cert.org/confluence/pages/viewpage.action?pageId=107642882">View Online</a>
</div>
</div>Jonathan Spring2022-06-06T04:00:00ZFinding Privilege Escalation Vulnerabilities in Windows using Process Monitoruser-9a25etag:vuls.cert.org,2009:blogpost-91750423-22022-06-14T18:00:35Z2021-06-21T04:00:00Z<div class="feed"> <p>
Blog post
<b>edited</b> by
Anonymous
</p>
<div style="border-top: 1px solid #ddd; border-bottom: 1px solid #ddd; padding: 10px;">
<h2 id="FindingPrivilegeEscalationVulnerabilitiesinWindowsusingProcessMonitor-Overview"><style type='text/css'>/*<![CDATA[*/
div.rbtoc1710843605085 {padding: 0px;}
div.rbtoc1710843605085 ul {margin-left: 0px;}
div.rbtoc1710843605085 li {margin-left: 0px;padding-left: 0px;}
/*]]>*/</style><div class='toc-macro rbtoc1710843605085'>
<ul class='toc-indentation'>
<li><a href='#FindingPrivilegeEscalationVulnerabilitiesinWindowsusingProcessMonitor-Overview'>Overview</a></li>
<li><a href='#FindingPrivilegeEscalationVulnerabilitiesinWindowsusingProcessMonitor-TheConcept'>The Concept</a></li>
<li><a href='#FindingPrivilegeEscalationVulnerabilitiesinWindowsusingProcessMonitor-Whattolookfor'>What to look for</a></li>
<li><a href='#FindingPrivilegeEscalationVulnerabilitiesinWindowsusingProcessMonitor-Usingthefilter'>Using the filter</a></li>
<li><a href='#FindingPrivilegeEscalationVulnerabilitiesinWindowsusingProcessMonitor-Investigatingresults'>Investigating results</a></li>
<li><a href='#FindingPrivilegeEscalationVulnerabilitiesinWindowsusingProcessMonitor-Mistakesthatdevelopersmake'>Mistakes that developers make</a>
<ul class='toc-indentation'>
<li><a href='#FindingPrivilegeEscalationVulnerabilitiesinWindowsusingProcessMonitor-Unexpectedpathsbeingaccessed'>Unexpected paths being accessed</a>
<ul class='toc-indentation'>
<li><a href='#FindingPrivilegeEscalationVulnerabilitiesinWindowsusingProcessMonitor-URL-encodedpaths'>URL-encoded paths</a></li>
<li><a href='#FindingPrivilegeEscalationVulnerabilitiesinWindowsusingProcessMonitor-POSIXpaths'>POSIX paths</a></li>
<li><a href='#FindingPrivilegeEscalationVulnerabilitiesinWindowsusingProcessMonitor-Useofalibrarythatloadsfromanunexpectedpath'>Use of a library that loads from an unexpected path</a></li>
<li><a href='#FindingPrivilegeEscalationVulnerabilitiesinWindowsusingProcessMonitor-Useofpathsthatonlyexistonadeveloper'ssystem'>Use of paths that only exist on a developer's system</a></li>
</ul>
</li>
<li><a href='#FindingPrivilegeEscalationVulnerabilitiesinWindowsusingProcessMonitor-UnexpectedACLsappliedtopathsbeingused'>Unexpected ACLs applied to paths being used</a>
<ul class='toc-indentation'>
<li><a href='#FindingPrivilegeEscalationVulnerabilitiesinWindowsusingProcessMonitor-UsingtheC:\ProgramData\directorywithoutexplicitlysettingsACLs'>Using the C:\ProgramData\ directory without explicitly settings ACLs</a></li>
<li><a href='#FindingPrivilegeEscalationVulnerabilitiesinWindowsusingProcessMonitor-Installingtoasubdirectoryoffofthesystemroot'>Installing to a subdirectory off of the system root</a></li>
<li><a href='#FindingPrivilegeEscalationVulnerabilitiesinWindowsusingProcessMonitor-Allowinguser-specifiedinstallationdirectorieswithoutsettingsACLs'>Allowing user-specified installation directories without settings ACLs</a></li>
</ul>
</li>
</ul>
</li>
<li><a href='#FindingPrivilegeEscalationVulnerabilitiesinWindowsusingProcessMonitor-Defensesagainstprivilegeescalation'>Defenses against privilege escalation</a>
<ul class='toc-indentation'>
<li><a href='#FindingPrivilegeEscalationVulnerabilitiesinWindowsusingProcessMonitor-Remove"Createfolders"permissiononsystemrootforunprivilegedusers'>Remove "Create folders" permission on system root for unprivileged users</a></li>
<li><a href='#FindingPrivilegeEscalationVulnerabilitiesinWindowsusingProcessMonitor-DonotinstallsoftwareoutsideofC:\ProgramFiles\'>Do not install software outside of C:\Program Files\</a></li>
<li><a href='#FindingPrivilegeEscalationVulnerabilitiesinWindowsusingProcessMonitor-Testandfortifyyourownsystems'>Test and fortify your own systems</a></li>
</ul>
</li>
</ul>
</div><br/>Overview</h2><p><span style="color: rgb(0,0,0);">This post will explain how to find privilege escalation vuls on Windows that no one appears to be looking for, because it's been pretty easy to find a bunch of them. After explaining how to find them, I'll introduce some defenses that can partly mitigate the problem in different ways. But what I'd like to see change is for developers to start looking for these vuls in the way I describe so that they stop introducing them in the first place.</span></p><p><span style="color: rgb(0,0,0);">Back when we first released <span style="color: rgb(255,0,0);"><a href="https://vuls.cert.org/confluence/display/tools/CERT+BFF+-+Basic+Fuzzing+Framework" rel="nofollow">CERT BFF</a></span>, the usual process for putting together a proof-of-concept exploit for a memory corruption vulnerability was:</span></p><ol><li><span style="color: rgb(0,0,0);">Fuzz the target until you get control of the instruction pointer.</span></li><li><span style="color: rgb(0,0,0);">Find out which bytes can be used to store your shellcode, using <span style="color: rgb(255,0,0);"><a href="https://insights.sei.cmu.edu/cert/2016/06/visualizing-cert-bff-string-minimization.html" class="external-link" rel="nofollow">BFF string minimization</a></span>.</span></li><li><span style="color: rgb(0,0,0);">Use <span style="color: rgb(255,0,0);"><a href="https://en.wikipedia.org/wiki/Return-oriented_programming" class="external-link" rel="nofollow">ROP</a></span> as necessary to modify the program flow so that it executes your shellcode.</span></li></ol><p><span style="color: rgb(0,0,0);">It was often relatively straightforward to go from <span style="color: rgb(255,0,0);"><a href="https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=463982" class="external-link" rel="nofollow">Start to PoC with CERT BFF</a></span>. As time went on, the bar for exploiting memory corruption vulnerabilities was raised. This can likely be attributed to two things that happened over the years:</span></p><ol><li><span style="color: rgb(0,0,0);">Increased fuzzing by parties releasing software.</span></li><li><span style="color: rgb(0,0,0);">Increased presence of exploit mitigations in both software and the platforms that they run on.</span></li></ol><p><span style="color: rgb(0,0,0);">I have recently worked on a vulnerability discovery technique that reminded me of the early BFF days. Both with respect to how easy it is to find the vulnerabilities and also how easy it can be to exploit them. In fact, the concept is so trivial that I was surprised by how successful it was in finding vulnerabilities. Just like the idea of going directly from fuzzing with BFF to a working exploit became less and less viable as time went on, I'd like for there to be much less low-hanging fruit that can be easily found with this technique.</span></p><p><span style="color: rgb(0,0,0);">In this post I will share some of my findings as well as the filter itself for finding privilege escalation vulnerabilities with <span style="color: rgb(255,0,0);"><a href="https://docs.microsoft.com/en-us/sysinternals/downloads/procmon" class="external-link" rel="nofollow">Sysinternals Process Monitor</a></span> (Procmon).</span></p><h2 id="FindingPrivilegeEscalationVulnerabilitiesinWindowsusingProcessMonitor-TheConcept">The Concept</h2><p><span style="color: rgb(0,0,0);">When software is installed on the Windows platform, some components of it may run with privileges, regardless of which user is currently logged on to the system. These privileged components generally take two forms:</span></p><ol><li><span style="color: rgb(0,0,0);">Installed services</span></li><li><span style="color: rgb(0,0,0);">Scheduled tasks</span></li></ol><p><span style="color: rgb(0,0,0);">How might we achieve privilege escalation on a Windows system? Any time that a privileged process interacts with a resource that an unprivileged user may be able to influence, this opens up the possibility for a privilege escalation vulnerability.</span></p><p><br/></p><h2 id="FindingPrivilegeEscalationVulnerabilitiesinWindowsusingProcessMonitor-Whattolookfor">What to look for</h2><p><span style="color: rgb(0,0,0);">The easiest way to check for privileged processes that might be able to be influenced by non-privileged users is to use a Process Monitor filter that displays operations based on the following attributes:</span></p><ol><li><span style="color: rgb(0,0,0);">Files or directories that do not exist.</span></li><li><span style="color: rgb(0,0,0);">Processes that have elevated privileges.</span></li><li><span style="color: rgb(0,0,0);">Locations that may be writable by an unprivileged user.</span></li></ol><p><span style="color: rgb(0,0,0);">Checks 1 and 2 can be trivially implemented in Process Monitor. Check 3 is a little more complicated and may result in some false positives if we limit our tool to strictly what can be done with a Process Monitor Filter. But I've created a </span>filter<span style="color: rgb(0,0,0);"> [<a href="https://github.com/certcc/privesc" class="external-link" rel="nofollow">Download from Github</a>] that seems to do a pretty good job of making privilege escalation vulnerabilities pretty obvious.</span></p><p><br/></p><h2 id="FindingPrivilegeEscalationVulnerabilitiesinWindowsusingProcessMonitor-Usingthefilter">Using the filter</h2><p><span style="color: rgb(0,0,0);">Using the Privesc.PMF Process Monitor filter is relatively straightforward:</span></p><ol><li><span style="color: rgb(0,0,0);">Enable Process Monitor boot logging (Options → Enable Boot Logging)</span></li><li><span style="color: rgb(0,0,0);">Reboot and log in</span></li><li><span style="color: rgb(0,0,0);">Run Process Monitor</span></li><li><span style="color: rgb(0,0,0);">Save the boot log when prompted</span><br/><span style="color: rgb(0,0,0);"><span class="confluence-embedded-file-wrapper confluence-embedded-manual-size"><img class="confluence-embedded-image" draggable="false" height="154" src="https://vuls.cert.org/confluence/download/attachments/91750423/procmon_boot_log.png?version=1&modificationDate=1624279602160&api=v2" data-image-src="https://vuls.cert.org/confluence/download/attachments/91750423/procmon_boot_log.png?version=1&modificationDate=1624279602160&api=v2" data-unresolved-comment-count="0" data-linked-resource-id="91750402" data-linked-resource-version="1" data-linked-resource-type="attachment" data-linked-resource-default-alias="procmon_boot_log.png" data-base-url="https://vuls.cert.org/confluence" data-linked-resource-content-type="image/png" data-linked-resource-container-id="91750423" data-linked-resource-container-version="2" alt=""></span></span></li><li><span style="color: rgb(0,0,0);">Import the "Privesc" filter (Filter → Organize Filters → Import...)</span></li><li><span style="color: rgb(0,0,0);">Apply the Privesc filter (Filter → Load Filter → Privesc)</span></li><li><span style="color: rgb(0,0,0);">Look for and investigate unexpected file accesses.</span></li></ol><p><br/></p><h2 id="FindingPrivilegeEscalationVulnerabilitiesinWindowsusingProcessMonitor-Investigatingresults">Investigating results</h2><p><span style="color: rgb(43,43,43);">Let's start by looking at a boot log of a common baseline that we might deal with as a vulnerability analyst - a 64-bit Windows 10 2004 system with VMware Tools installed:<br/><span class="confluence-embedded-file-wrapper"><img class="confluence-embedded-image" draggable="false" src="https://vuls.cert.org/confluence/download/attachments/91750423/win10_clean_privesc.png?version=1&modificationDate=1624279602143&api=v2" data-image-src="https://vuls.cert.org/confluence/download/attachments/91750423/win10_clean_privesc.png?version=1&modificationDate=1624279602143&api=v2" data-unresolved-comment-count="0" data-linked-resource-id="91750403" data-linked-resource-version="1" data-linked-resource-type="attachment" data-linked-resource-default-alias="win10_clean_privesc.png" data-base-url="https://vuls.cert.org/confluence" data-linked-resource-content-type="image/png" data-linked-resource-container-id="91750423" data-linked-resource-container-version="2" alt=""></span><br/></span></p><p><span style="color: rgb(0,0,0);">Even with virtually no software installed in our VM, we can already see something suspicious: <strong>C:\Program%20Files\</strong></span></p><p><span style="color: rgb(0,0,0);">Windows users may be familiar with the path <strong>C:\Program Files\</strong>, but what's with the <strong>%20</strong>? Why might such a file operation occur? We'll cover the reason in the section below.</span></p><p><br/></p><h2 id="FindingPrivilegeEscalationVulnerabilitiesinWindowsusingProcessMonitor-Mistakesthatdevelopersmake">Mistakes that developers make</h2><p><span style="color: rgb(0,0,0);">There are a number of mistakes that a developer might make that can lead to a privileged process being able to be influenced by an unprivileged user. The mistakes that I've noticed with respect to simple privilege escalation vulnerabilities with Windows applications fall into two main categories:</span></p><ol><li><span style="color: rgb(0,0,0);">Unexpected paths being accessed.</span></li><li><span style="color: rgb(0,0,0);">Unexpected Access Control Lists (ACLs) applied to paths being used.</span></li></ol><h3 id="FindingPrivilegeEscalationVulnerabilitiesinWindowsusingProcessMonitor-Unexpectedpathsbeingaccessed">Unexpected paths being accessed</h3><p><span style="color: rgb(43,43,43);">In some cases, an unexpected path is accessed during the execution of a program. That is, the developer would probably be surprised if they realized that the path was being accessed. These unexpected path accesses can be caused by a number of reasons:</span></p><h4 id="FindingPrivilegeEscalationVulnerabilitiesinWindowsusingProcessMonitor-URL-encodedpaths"><span style="color: rgb(43,43,43);">URL-encoded paths</span></h4><p><span style="color: rgb(0,0,0);">As we noticed in the screenshot above, the VMware Tools process <strong>VGAuthService.exe</strong> attempts to access the path <strong>C:\Program%20Files\VMware\VMware%20Tools\VMware%20VGAuth\schemas\xmldsig-core-schema.xsd</strong>. How might this happen? If a path containing spaces is <span style="color: rgb(255,0,0);"><a href="https://www.w3schools.com/tags/ref_urlencode.ASP" class="external-link" rel="nofollow">URL-encoded</a></span>, those spaces will be replaced with %20.</span></p><p><span style="color: rgb(0,0,0);">What are the consequences of this transformation? The most important aspect of this new path is that rather than being a subdirectory of <strong>C:\Program Files\</strong>, which has proper ACLs by default, this requested path now starts looking at the root directory. Unprivileged users on Windows systems can create subdirectories off of the system root directory. This will be a recurring theme, so remember this.</span></p><p><span style="color: rgb(0,0,0);">From an unprivileged command prompt, let's see what we can do:</span><br/><span class="confluence-embedded-file-wrapper"><img class="confluence-embedded-image" draggable="false" src="https://vuls.cert.org/confluence/download/attachments/91750423/mkdir_urlescape.png?version=1&modificationDate=1624279602130&api=v2" data-image-src="https://vuls.cert.org/confluence/download/attachments/91750423/mkdir_urlescape.png?version=1&modificationDate=1624279602130&api=v2" data-unresolved-comment-count="0" data-linked-resource-id="91750404" data-linked-resource-version="1" data-linked-resource-type="attachment" data-linked-resource-default-alias="mkdir_urlescape.png" data-base-url="https://vuls.cert.org/confluence" data-linked-resource-content-type="image/png" data-linked-resource-container-id="91750423" data-linked-resource-container-version="2" alt=""></span><br/>Success!</p><p><span style="color: rgb(43,43,43);">We can dig a little deeper in Process Explorer by selecting the file access and pressing Ctrl-K to get the call stack:<br/><span class="confluence-embedded-file-wrapper"><img class="confluence-embedded-image" draggable="false" src="https://vuls.cert.org/confluence/download/attachments/91750423/vmware_xxe.png?version=1&modificationDate=1624279602113&api=v2" data-image-src="https://vuls.cert.org/confluence/download/attachments/91750423/vmware_xxe.png?version=1&modificationDate=1624279602113&api=v2" data-unresolved-comment-count="0" data-linked-resource-id="91750405" data-linked-resource-version="1" data-linked-resource-type="attachment" data-linked-resource-default-alias="vmware_xxe.png" data-base-url="https://vuls.cert.org/confluence" data-linked-resource-content-type="image/png" data-linked-resource-container-id="91750423" data-linked-resource-container-version="2" alt=""></span><br/></span></p><p><span style="color: rgb(0,0,0);">Here we can see that the file access is triggered by <strong>VGAuthService.exe + 0x110d9</strong>, and along the way there is a call to <strong>xmlLoadExternalEntity()</strong>.</span></p><p><span style="color: rgb(0,0,0);">Putting all of the pieces together here, we have a privileged process that attempts to load a file that does not exist because the path is URL encoded. Since an unprivileged user can create this path, this now turns into a case where an unprivileged user can influence a privileged process. In this particular case, the consequences are only an <span style="color: rgb(255,0,0);"><a href="https://owasp.org/www-community/vulnerabilities/XML_External_Entity_(XXE)_Processing" class="external-link" rel="nofollow">XML External Entity (XXE)</a></span> vulnerability. But we're also just getting warmed up.</span></p><h4 id="FindingPrivilegeEscalationVulnerabilitiesinWindowsusingProcessMonitor-POSIXpaths">POSIX paths</h4><p><span style="color: rgb(43,43,43);">If an application uses a POSIX-style path on a Windows machine, this path is normalized to a Windows style path. For example, if a Windows application attempts to access the<span> </span></span><strong>/usr/local/</strong><span style="color: rgb(43,43,43);"><span> </span>directory, the path will be interpreted as<span> </span></span><strong>C:\usr\local\</strong><span style="color: rgb(43,43,43);">. And as described above, this is a path that an unprivileged user can create on Windows.</span></p><p><span style="color: rgb(43,43,43);">Here is a Process Monitor log of a system with a fully-patched security product installed:<br/><span class="confluence-embedded-file-wrapper confluence-embedded-manual-size"><img class="confluence-embedded-image" draggable="false" height="159" src="https://vuls.cert.org/confluence/download/attachments/91750423/posix_usr_local_ssl.png?version=1&modificationDate=1624279602097&api=v2" data-image-src="https://vuls.cert.org/confluence/download/attachments/91750423/posix_usr_local_ssl.png?version=1&modificationDate=1624279602097&api=v2" data-unresolved-comment-count="0" data-linked-resource-id="91750406" data-linked-resource-version="1" data-linked-resource-type="attachment" data-linked-resource-default-alias="posix_usr_local_ssl.png" data-base-url="https://vuls.cert.org/confluence" data-linked-resource-content-type="image/png" data-linked-resource-container-id="91750423" data-linked-resource-container-version="2" alt=""></span><br/></span></p><p><span style="color: rgb(43,43,43);">Using a publicly-known technique for achieving<span> </span><span style="color: rgb(255,0,0);"><a href="https://blog.mirch.io/2019/06/10/cve-2019-12572-pia-windows-privilege-escalation-malicious-openssl-engine/" class="external-link" rel="nofollow">code execution via openssl.cnf</a></span>, we can now demonstrate code execution via running<span> </span><strong>calc.exe</strong><span> </span>with SYSTEM privileges from a limited user account:<br/><span class="confluence-embedded-file-wrapper"><img class="confluence-embedded-image" draggable="false" src="https://vuls.cert.org/confluence/download/attachments/91750423/posix_path_calc.png?version=1&modificationDate=1624279602077&api=v2" data-image-src="https://vuls.cert.org/confluence/download/attachments/91750423/posix_path_calc.png?version=1&modificationDate=1624279602077&api=v2" data-unresolved-comment-count="0" data-linked-resource-id="91750407" data-linked-resource-version="1" data-linked-resource-type="attachment" data-linked-resource-default-alias="posix_path_calc.png" data-base-url="https://vuls.cert.org/confluence" data-linked-resource-content-type="image/png" data-linked-resource-container-id="91750423" data-linked-resource-container-version="2" alt=""></span><br/></span></p><h4 id="FindingPrivilegeEscalationVulnerabilitiesinWindowsusingProcessMonitor-Useofalibrarythatloadsfromanunexpectedpath"><span style="color: rgb(43,43,43);">Use of a library that loads from an unexpected path</span></h4><p><span style="color: rgb(43,43,43);">In some cases, a developer may have done nothing wrong other than using a library that happens to have load from a location that can be influenced by an unprivileged Windows user. For example, here's a Process Monitor log of an application that attempts to access the path<span> </span><strong>C:\CMU\bin\sasl2</strong>:<br/><span class="confluence-embedded-file-wrapper"><img class="confluence-embedded-image" draggable="false" src="https://vuls.cert.org/confluence/download/attachments/91750423/unexpected_library_path.png?version=1&modificationDate=1624279602060&api=v2" data-image-src="https://vuls.cert.org/confluence/download/attachments/91750423/unexpected_library_path.png?version=1&modificationDate=1624279602060&api=v2" data-unresolved-comment-count="0" data-linked-resource-id="91750408" data-linked-resource-version="1" data-linked-resource-type="attachment" data-linked-resource-default-alias="unexpected_library_path.png" data-base-url="https://vuls.cert.org/confluence" data-linked-resource-content-type="image/png" data-linked-resource-container-id="91750423" data-linked-resource-container-version="2" alt=""></span><br/></span></p><p><span style="color: rgb(43,43,43);">If we look at the call stack, we can see that this access is likely triggered by the<span> </span><strong>libsasl.dll</strong><span> </span>library:<br/><span class="confluence-embedded-file-wrapper"><img class="confluence-embedded-image" draggable="false" src="https://vuls.cert.org/confluence/download/attachments/91750423/unexpected_library_path_stack.png?version=1&modificationDate=1624279602043&api=v2" data-image-src="https://vuls.cert.org/confluence/download/attachments/91750423/unexpected_library_path_stack.png?version=1&modificationDate=1624279602043&api=v2" data-unresolved-comment-count="0" data-linked-resource-id="91750409" data-linked-resource-version="1" data-linked-resource-type="attachment" data-linked-resource-default-alias="unexpected_library_path_stack.png" data-base-url="https://vuls.cert.org/confluence" data-linked-resource-content-type="image/png" data-linked-resource-container-id="91750423" data-linked-resource-container-version="2" alt=""></span><br/></span></p><p><span style="color: rgb(0,0,0);">And sure enough, if we look at the code for libsasl, we can see a <span style="color: rgb(255,0,0);"><a href="https://github.com/cyrusimap/cyrus-sasl/blob/eeb935a9198172aede242c77b0e0dafe9312db10/win32/include/config.h#L117" class="external-link" rel="nofollow">hard-coded reference to the path <strong>C:\CMU\bin\sasl2</strong></a></span>.</span></p><p><span style="color: rgb(0,0,0);">As an unprivileged user, we can create the directory and place whatever code we want there. Once again, we have calc.exe executing with SYSTEM privileges. All from an unprivileged user account.</span><br/><span class="confluence-embedded-file-wrapper"><img class="confluence-embedded-image" draggable="false" src="https://vuls.cert.org/confluence/download/attachments/91750423/unexpected_library_path_calc.png?version=1&modificationDate=1624279602027&api=v2" data-image-src="https://vuls.cert.org/confluence/download/attachments/91750423/unexpected_library_path_calc.png?version=1&modificationDate=1624279602027&api=v2" data-unresolved-comment-count="0" data-linked-resource-id="91750410" data-linked-resource-version="1" data-linked-resource-type="attachment" data-linked-resource-default-alias="unexpected_library_path_calc.png" data-base-url="https://vuls.cert.org/confluence" data-linked-resource-content-type="image/png" data-linked-resource-container-id="91750423" data-linked-resource-container-version="2" alt=""></span></p><h4 id="FindingPrivilegeEscalationVulnerabilitiesinWindowsusingProcessMonitor-Useofpathsthatonlyexistonadeveloper'ssystem">Use of paths that only exist on a developer's system</h4><p><span style="color: rgb(43,43,43);">Sometimes a program may contain references to paths that only exist on the developer's system. As long as the software functions properly on systems that do not have such a directory, then this attribute may not be recognized unless somebody is looking. For example, this software looks for a plugins subdirectory in the<span> </span></span><strong>C:\Qt\</strong><span style="color: rgb(43,43,43);"><span> </span>directory:<br/><span class="confluence-embedded-file-wrapper confluence-embedded-manual-size"><img class="confluence-embedded-image" draggable="false" height="153" src="https://vuls.cert.org/confluence/download/attachments/91750423/qt_dev_path.png?version=1&modificationDate=1624279602007&api=v2" data-image-src="https://vuls.cert.org/confluence/download/attachments/91750423/qt_dev_path.png?version=1&modificationDate=1624279602007&api=v2" data-unresolved-comment-count="0" data-linked-resource-id="91750411" data-linked-resource-version="1" data-linked-resource-type="attachment" data-linked-resource-default-alias="qt_dev_path.png" data-base-url="https://vuls.cert.org/confluence" data-linked-resource-content-type="image/png" data-linked-resource-container-id="91750423" data-linked-resource-container-version="2" alt=""></span></span></p><p><span style="color: rgb(43,43,43);">I'll skip some steps for the sake of brevity, but after a bit of investigation we see that we can achieve code execution by placing a special library in the appropriate directory:<br/><span class="confluence-embedded-file-wrapper"><img class="confluence-embedded-image" draggable="false" src="https://vuls.cert.org/confluence/download/attachments/91750423/qt_dev_path_calc2.png?version=1&modificationDate=1624279601990&api=v2" data-image-src="https://vuls.cert.org/confluence/download/attachments/91750423/qt_dev_path_calc2.png?version=1&modificationDate=1624279601990&api=v2" data-unresolved-comment-count="0" data-linked-resource-id="91750412" data-linked-resource-version="1" data-linked-resource-type="attachment" data-linked-resource-default-alias="qt_dev_path_calc2.png" data-base-url="https://vuls.cert.org/confluence" data-linked-resource-content-type="image/png" data-linked-resource-container-id="91750423" data-linked-resource-container-version="2" alt=""></span><br/></span></p><p><span style="color: rgb(43,43,43);">Looking further into the Qt development platform, this type of vulnerability is a known issue. The vulnerability was<span> </span><span style="color: rgb(255,0,0);"><a href="https://codereview.qt-project.org/gitweb?p=qt%2Fqttools.git;a=commit;h=c2952ff8df1e18fe0120d8b29901b0b794afccc7" class="external-link" rel="nofollow">patched</a></span><span> </span>more than 5 years ago, but it never received a CVE. Software may be vulnerable to privilege escalation if it was built with a Qt version from before this patch was introduced or the developer did not use<span> </span><span style="color: rgb(255,0,0);"><a href="https://doc.qt.io/qt-5/windows-deployment.html" class="external-link" rel="nofollow">windeployqt</a></span><span> </span>to patch out the<span> </span><strong>qt_prfxpath</strong><span> </span>value stored in<span> </span><strong>Qt5core.dll</strong>.</span></p><h3 id="FindingPrivilegeEscalationVulnerabilitiesinWindowsusingProcessMonitor-UnexpectedACLsappliedtopathsbeingused"><span style="color: rgb(43,43,43);">Unexpected ACLs applied to paths being used</span></h3><p><span style="color: rgb(0,0,0);">Most cases of an unexpected path being accessed by an application can be exploited because of a simple fact: unprivileged users can create subdirectories off of the Windows system root directory. Finding and exploiting software that fails to properly set ACLs requires just a bit more investigation.</span></p><p><span style="color: rgb(0,0,0);">Most of the ACL issues related to Windows software is related to one concept:</span><br/><span style="color: rgb(0,0,0);">Software that executes from a subdirectory of <strong>C:\Program Files\</strong> or <strong>C:\Program Files (x86)\</strong> has secure ACLs <strong>by default</strong> by virtue of inheritance. For example, consider the case where I install my software to <strong>C:\Program Files\WD\</strong>. Unprivileged users will not be able to modify the contents of the WD subdirectory because its parent directory of <strong>C:\Program Files\</strong> cannot be written to by unprivileged processes, and the <strong>WD</strong> subdirectory by default will inherit its parents permissions.</span></p><h4 id="FindingPrivilegeEscalationVulnerabilitiesinWindowsusingProcessMonitor-UsingtheC:\ProgramData\directorywithoutexplicitlysettingsACLs"><span style="color: rgb(0,0,0);">Using the C:\ProgramData\ directory without explicitly settings ACLs</span></h4><p><span style="color: rgb(0,0,0);">The <span style="color: rgb(255,0,0);"><a href="https://docs.microsoft.com/en-us/windows-hardware/customize/desktop/unattend/microsoft-windows-shell-setup-folderlocations-programdata" class="external-link" rel="nofollow">ProgramData</a></span> directory by design can be written to without elevated permissions. As such, any subdirectory that has been created in the ProgramData directory will by default be writable by unprivileged users. Depending on <strong>how</strong> an application uses its ProgramData subdirectory, a privilege escalation may be possible if the ACLs for the subdirectory are not explicitly set.</span></p><p><span style="color: rgb(0,0,0);">Here we have a popular application that has a scheduled update component that runs from the C:\ProgramData\ directory:</span><br/><span class="confluence-embedded-file-wrapper confluence-embedded-manual-size"><img class="confluence-embedded-image" draggable="false" height="172" src="https://vuls.cert.org/confluence/download/attachments/91750423/programdata_missing_dll.png?version=1&modificationDate=1624279601973&api=v2" data-image-src="https://vuls.cert.org/confluence/download/attachments/91750423/programdata_missing_dll.png?version=1&modificationDate=1624279601973&api=v2" data-unresolved-comment-count="0" data-linked-resource-id="91750413" data-linked-resource-version="1" data-linked-resource-type="attachment" data-linked-resource-default-alias="programdata_missing_dll.png" data-base-url="https://vuls.cert.org/confluence" data-linked-resource-content-type="image/png" data-linked-resource-container-id="91750423" data-linked-resource-container-version="2" alt=""></span></p><p><span style="color: rgb(43,43,43);">This is a straightforward potential case of<span> </span></span><span style="color: rgb(255,0,0);"><a href="https://attack.mitre.org/techniques/T1574/001/" class="external-link" rel="nofollow">DLL hijacking</a></span><span style="color: rgb(43,43,43);">, which is made possible due to lax ACLs on the directory from which the software runs. Let's plant a crafted msi.dll there and see what we can accomplish:<br/><span class="confluence-embedded-file-wrapper"><img class="confluence-embedded-image" draggable="false" src="https://vuls.cert.org/confluence/download/attachments/91750423/programdata_msi_calc.png?version=1&modificationDate=1624279601953&api=v2" data-image-src="https://vuls.cert.org/confluence/download/attachments/91750423/programdata_msi_calc.png?version=1&modificationDate=1624279601953&api=v2" data-unresolved-comment-count="0" data-linked-resource-id="91750414" data-linked-resource-version="1" data-linked-resource-type="attachment" data-linked-resource-default-alias="programdata_msi_calc.png" data-base-url="https://vuls.cert.org/confluence" data-linked-resource-content-type="image/png" data-linked-resource-container-id="91750423" data-linked-resource-container-version="2" alt=""></span></span></p><p><span style="color: rgb(0,0,0);">There's our calc.exe, executing with SYSTEM privileges. These problems seem a bit too prevalent. And easy to exploit.</span></p><p><span style="color: rgb(0,0,0);">It's worth noting that DLL hijacking isn't our only option for privilege escalation. <strong>Any</strong> user-writable file that is used by a privileged process introduces the possibility of introducing a privilege escalation vulnerability. For example, here's a popular program that checks for a user-creatable text file to direct its privileged auto-update mechanism. As we can see here, the presence of a crafted text file can lead to arbitrary command execution. In our case, we have it launch calc.exe:</span><br/><span class="confluence-embedded-file-wrapper"><img class="confluence-embedded-image" draggable="false" src="https://vuls.cert.org/confluence/download/attachments/91750423/programdata_txt_calc.png?version=1&modificationDate=1624279601937&api=v2" data-image-src="https://vuls.cert.org/confluence/download/attachments/91750423/programdata_txt_calc.png?version=1&modificationDate=1624279601937&api=v2" data-unresolved-comment-count="0" data-linked-resource-id="91750415" data-linked-resource-version="1" data-linked-resource-type="attachment" data-linked-resource-default-alias="programdata_txt_calc.png" data-base-url="https://vuls.cert.org/confluence" data-linked-resource-content-type="image/png" data-linked-resource-container-id="91750423" data-linked-resource-container-version="2" alt=""></span></p><h4 id="FindingPrivilegeEscalationVulnerabilitiesinWindowsusingProcessMonitor-Installingtoasubdirectoryoffofthesystemroot">Installing to a subdirectory off of the system root</h4><p><span style="color: rgb(43,43,43);">An installer that places an application by default to a directory off of the system root must set appropriate ACLs to remain secure. For example, Python 2.7 installs to<span> </span></span><strong>C:\python27\</strong><span style="color: rgb(43,43,43);"><span> </span>by default:<br/><span class="confluence-embedded-file-wrapper"><img class="confluence-embedded-image" draggable="false" src="https://vuls.cert.org/confluence/download/attachments/91750423/python27_install_dir.png?version=1&modificationDate=1624279601920&api=v2" data-image-src="https://vuls.cert.org/confluence/download/attachments/91750423/python27_install_dir.png?version=1&modificationDate=1624279601920&api=v2" data-unresolved-comment-count="0" data-linked-resource-id="91750416" data-linked-resource-version="1" data-linked-resource-type="attachment" data-linked-resource-default-alias="python27_install_dir.png" data-base-url="https://vuls.cert.org/confluence" data-linked-resource-content-type="image/png" data-linked-resource-container-id="91750423" data-linked-resource-container-version="2" alt=""></span></span></p><p><span style="color: rgb(43,43,43);">The default ACLs for this directory allow unprivileged users to modify the contents of this directory. What might we be able to do with this? We can try the standard DLL hijacking technique:<br/><span class="confluence-embedded-file-wrapper confluence-embedded-manual-size"><img class="confluence-embedded-image" draggable="false" height="148" src="https://vuls.cert.org/confluence/download/attachments/91750423/python27_dll_hijacking.png?version=1&modificationDate=1624279601900&api=v2" data-image-src="https://vuls.cert.org/confluence/download/attachments/91750423/python27_dll_hijacking.png?version=1&modificationDate=1624279601900&api=v2" data-unresolved-comment-count="0" data-linked-resource-id="91750417" data-linked-resource-version="1" data-linked-resource-type="attachment" data-linked-resource-default-alias="python27_dll_hijacking.png" data-base-url="https://vuls.cert.org/confluence" data-linked-resource-content-type="image/png" data-linked-resource-container-id="91750423" data-linked-resource-container-version="2" alt=""></span><br/></span></p><p><span style="color: rgb(43,43,43);">But we don't even need to be that clever. We can simply replace any file in the<span> </span><strong>C:\python27\</strong><span> </span>directory as an unprivileged user:<br/><span class="confluence-embedded-file-wrapper confluence-embedded-manual-size"><img class="confluence-embedded-image" draggable="false" height="146" src="https://vuls.cert.org/confluence/download/attachments/91750423/python27_exe_replacing.png?version=1&modificationDate=1624279601883&api=v2" data-image-src="https://vuls.cert.org/confluence/download/attachments/91750423/python27_exe_replacing.png?version=1&modificationDate=1624279601883&api=v2" data-unresolved-comment-count="0" data-linked-resource-id="91750418" data-linked-resource-version="1" data-linked-resource-type="attachment" data-linked-resource-default-alias="python27_exe_replacing.png" data-base-url="https://vuls.cert.org/confluence" data-linked-resource-content-type="image/png" data-linked-resource-container-id="91750423" data-linked-resource-container-version="2" alt=""></span><br/></span></p><h4 id="FindingPrivilegeEscalationVulnerabilitiesinWindowsusingProcessMonitor-Allowinguser-specifiedinstallationdirectorieswithoutsettingsACLs"><span style="color: rgb(43,43,43);">Allowing user-specified installation directories without settings ACLs</span></h4><p><span style="color: rgb(43,43,43);">Many installers are secure because of inheritance of secure ACLs from C:\Program Files\. However any installer that allows a user to choose their own installation directory must explicitly set ACLs in the target location. Sadly, in my testing I've found that it is very rare for an installer to explicitly set ACLs. Let's take a look at the Microsoft SQL Server 2019 installer, for example:<br/><span class="confluence-embedded-file-wrapper"><img class="confluence-embedded-image" draggable="false" src="https://vuls.cert.org/confluence/download/attachments/91750423/sqle2019_install.png?version=1&modificationDate=1624279601863&api=v2" data-image-src="https://vuls.cert.org/confluence/download/attachments/91750423/sqle2019_install.png?version=1&modificationDate=1624279601863&api=v2" data-unresolved-comment-count="0" data-linked-resource-id="91750419" data-linked-resource-version="1" data-linked-resource-type="attachment" data-linked-resource-default-alias="sqle2019_install.png" data-base-url="https://vuls.cert.org/confluence" data-linked-resource-content-type="image/png" data-linked-resource-container-id="91750423" data-linked-resource-container-version="2" alt=""></span><br/></span></p><p><span style="color: rgb(43,43,43);">Does the installer set ACLs to the directory where it installs the software?<br/><span class="confluence-embedded-file-wrapper"><img class="confluence-embedded-image" draggable="false" src="https://vuls.cert.org/confluence/download/attachments/91750423/sqle2019_copy_file.png?version=1&modificationDate=1624279601847&api=v2" data-image-src="https://vuls.cert.org/confluence/download/attachments/91750423/sqle2019_copy_file.png?version=1&modificationDate=1624279601847&api=v2" data-unresolved-comment-count="0" data-linked-resource-id="91750420" data-linked-resource-version="1" data-linked-resource-type="attachment" data-linked-resource-default-alias="sqle2019_copy_file.png" data-base-url="https://vuls.cert.org/confluence" data-linked-resource-content-type="image/png" data-linked-resource-container-id="91750423" data-linked-resource-container-version="2" alt=""></span><br/></span></p><p><span style="color: rgb(43,43,43);">What happens when SQL Server 2019 starts?<br/><span class="confluence-embedded-file-wrapper"><img class="confluence-embedded-image" draggable="false" src="https://vuls.cert.org/confluence/download/attachments/91750423/sqle2019_calc.png?version=1&modificationDate=1624279601827&api=v2" data-image-src="https://vuls.cert.org/confluence/download/attachments/91750423/sqle2019_calc.png?version=1&modificationDate=1624279601827&api=v2" data-unresolved-comment-count="0" data-linked-resource-id="91750421" data-linked-resource-version="1" data-linked-resource-type="attachment" data-linked-resource-default-alias="sqle2019_calc.png" data-base-url="https://vuls.cert.org/confluence" data-linked-resource-content-type="image/png" data-linked-resource-container-id="91750423" data-linked-resource-container-version="2" alt=""></span><br/></span></p><p><span style="color: rgb(43,43,43);">Microsoft SQL Server 2019, as well as just about any Windows application that allows you to choose where to install it, might be vulnerable to privilege escalation simply based on what directory it is installed to.</span></p><p><br/></p><h2 id="FindingPrivilegeEscalationVulnerabilitiesinWindowsusingProcessMonitor-Defensesagainstprivilegeescalation">Defenses against privilege escalation</h2><h3 id="FindingPrivilegeEscalationVulnerabilitiesinWindowsusingProcessMonitor-Remove"Createfolders"permissiononsystemrootforunprivilegedusers">Remove "Create folders" permission on system root for unprivileged users</h3><p><span style="color: rgb(43,43,43);">The simplest defense against many of the attacks outlined above is to remove the permission to create folders off of the system root directory:<br/><span class="confluence-embedded-file-wrapper"><img class="confluence-embedded-image" draggable="false" src="https://vuls.cert.org/confluence/download/attachments/91750423/ntfs_prevent_create_folder.png?version=1&modificationDate=1624279601773&api=v2" data-image-src="https://vuls.cert.org/confluence/download/attachments/91750423/ntfs_prevent_create_folder.png?version=1&modificationDate=1624279601773&api=v2" data-unresolved-comment-count="0" data-linked-resource-id="91750422" data-linked-resource-version="1" data-linked-resource-type="attachment" data-linked-resource-default-alias="ntfs_prevent_create_folder.png" data-base-url="https://vuls.cert.org/confluence" data-linked-resource-content-type="image/png" data-linked-resource-container-id="91750423" data-linked-resource-container-version="2" alt=""></span></span></p><h3 id="FindingPrivilegeEscalationVulnerabilitiesinWindowsusingProcessMonitor-DonotinstallsoftwareoutsideofC:\ProgramFiles\"><span style="color: rgb(43,43,43);">Do not install software outside of C:\Program Files\</span></h3><p><span style="color: rgb(43,43,43);">If software is installed to any location other than<span> </span>C:\Program Files\<span> </span>or<span> </span>C:\Program Files (x86)\, you are relying on the installer to explicitly set ACLs for it to be secure. You can avoid needing to make this leap of faith by only installing software to recommended program locations.</span></p><h3 id="FindingPrivilegeEscalationVulnerabilitiesinWindowsusingProcessMonitor-Testandfortifyyourownsystems"><span style="color: rgb(43,43,43);">Test and fortify your own systems</span></h3><p><span style="color: rgb(43,43,43);">You can test your own platforms for privilege escalation vulnerabilities using the Process Monitor filter and techniques described above. For any file locations that are determined to be insecure, you can manually lock down those directories so that unprivileged users cannot modify those locations. For any vulnerabilities that you discover, we recommend contacting the affected vendors to notify them of the vulnerabilities so that they can be fixed for everyone. In cases where the vendor communications are unproductive, the CERT/CC may be able to<span> </span><span style="color: rgb(255,0,0);"><a href="https://www.kb.cert.org/vuls/report/" class="external-link" rel="nofollow">provide assistance</a></span>.</span></p>
</div>
<div style="padding: 10px 0;">
<a href="https://vuls.cert.org/confluence/pages/viewpage.action?pageId=91750423">View Online</a>
</div>
</div>user-9a25e2021-06-21T04:00:00Z