CISA KEV Breakdown
  • September 30, 2022
  • Ryan Cribelar

September 30 – 3 New Vulns | CVE-2022-41082, CVE-2022-41040 and CVE-2022-36804

In this CISA KEV Breakdown, CISA has added two Microsoft Exchange vulnerabilities, a Microsoft Exchange RCE and a Microsoft Exchange SSRF, as well as a Bitbucket API RCE.

The two Exchange CVEs relate to an unresolved fix applied to the ProxyShell chain first disclosed by Orange Tsai in August of 2021, the barrier being authentication to achieve exploitation. Ensure all Exchange servers, including hybrid, are properly mitigated with workarounds you can find in Microsoft’s blog post. At time of writing there is no patch available for the Exchange vulnerabilities. At time of writing this vulnerability chain continues to target specific organizations in small number and evidence of mass exploitation appears minimal.

wdt_ID CVE ID Vendor Software Exploitation Result Due Date EPSS Probability EPSS Percentile cvssV3 GreyNoise
1 CVE-2022-41082 Microsoft Exchange Server Remote Code Execution 10/21/2022 0.09891 0.94171 8.8 30 attempts
2 CVE-2022-41040 Microsoft Exchange Server Server-Side Request Forgery 10/21/2022 0.02288 0.80754 8.8 30 attempts
3 CVE-2022-36804 Atlassian Bitbucket Server and Data Center Remote Code Execution 10/21/2022 0.78622 0.99438 8.8 3 attempts
CVE ID Vendor Software Exploitation Result Due Date EPSS Probability EPSS Percentile cvssV3 GreyNoise

Notable Vulnerability Additions

CVE-2022-41082, CVE-2022-41040 (ProxyNotShell) | Microsoft Exchange RCE, Exchange SSRF

Dubbed ProxyNotShell by Kevin Beaumont, the two-chain pair of vulnerabilities affecting Microsoft Exchange servers 2019 and below exploiting the previously known ProxyShell vulnerability chain exists due to the fact that the barrier for exploitation was strictly a layer of authentication. Using the same SSRF/RCE pair, an authenticated attacker can leverage CVE-2022-41040 to execute code via CVE-2022-41082. The vulnerabilities were declared zero days due to the fact that the GTSC report as well as the Zero Day Initiative confirmed the findings worked on the latest patch of Exchange.

If users have implemented the URL string block observed in previous attempts to exploit ProxyShell, specifically “.*autodiscover\.json.*\@.*Powershell.*“, this should contain any potential external attempts to exploit the vulnerability chain. Steps to do so can be found in Microsoft’s report below. For any interested threat hunters, detection methods for Defender for Endpoint and Azure Sentinel can be utilized when triaging historical IIS logs.

GreyNoise has issued a blog detailing their findings regarding ProxyNotShell as well as more information surrounding their observed exploitation attempts.

Jared Semrau of Mandiant concludes that exploitation is likely to not be seen at mass-scale for these vulnerabilities as “this is a very specific attack vector that isn’t something that is going to be easily done at scale, especially now that workarounds are out there to prevent exploitation.”

As of 10/03/2022 it appears some users are reporting the above detection URL string can be bypassed to allow for successful exploitation. Nucleus recommends adding the string “.*autodiscover\.json.*Powershell.*” as a URL filter as well. Specifically, the ‘@’ character in the first string creates for too small of a detection pattern. You can find more details in this PoC video made by GTSC

As of 10/05/2022 a bypass to the mitigation for ProxyNotShell was discovered by user @honoki in which applying the URL filter input to “{REQUEST_URI}” is ineffective against encoded characters. It is recommended to change the input to “{UrlDecode:{REQUEST_URI}}” excluding quotes to mitigate the bypass.

Security Advisory:

CVE-2022-36804 | Bitbucket API RCE

An RCE vulnerability in Bitbucket API endpoints was discovered due to a similar RCE bounty found in GitHub Enterprise which utilized git option injection to successfully execute code. It is important to note that if you access Bitbucket via a domain, it is hosted by Atlassian and you are not affected by the vulnerability.

The vulnerability dubbed CVE-2022-36804 was disclosed by AssetNote’s Maxwell Garrett on July 19 with a fix by Atlassian issued on August 24. The writeup goes into great detail as to how root cause analysis can confirm the exact technique needed to properly issue executable commands, as well as providing a great example to the fact that security issues across different technologies can exist in a similar capacity so long as underlying mechanisms are the same or near to. At time of writing there currently stands a count of 1617 public facing hosts according to Shodan that could be vulnerable to this RCE.

Security Advisory:

To get a better understanding of each component of our Breakdown, including what we determine to be a notable release, please see our Frequently Asked Questions section below. Also be sure to follow Nucleus Security on Twitter and LinkedIn where we will be posting each time a new Breakdown is released.

← September 23, 2022 CISA Kev Breakdown

Click here to expand our CISA KEV Breakdown Frequently Asked Questions
  • What makes for a notable addition?
    • A notable addition can arise from many different characteristics. If a particular vulnerability is notable to the security community or a subset of the security community or if the EPSS score reveals notable information about the vulnerability, this can constitute further analysis. It may also be the case that a particular vulnerability shines a light on everyday users and we will highlight important information and key takeaways to ensure users and readers have easy access to actionable information.
  • When is the Breakdown released?
    • We aim to have our analysis of each KEV update posted within 24 hours of the time in which the Catalog is updated. See CISA’s full catalog here
  • I am not bound by BOD 22-01 or federal regulations, why should the KEV concern me?
    • CISA encourages all organizations to utilize the Catalog as an attribute in your vulnerability prioritization framework. Organizations looking to lessen the scope on known dangerous vulnerabilities and make a goal to remediate them can understand where they currently stand against what CISA has confirmed as exploited vulnerabilities in the wild. See CISA’s section on “How should organizations use the KEV catalog?” here.
  • What is EPSS?
    • EPSS is the Exploit Prediction Scoring System. It is an open, data-driven effort for estimating the likelihood (probability) that a software vulnerability will be exploited in the wild. See the EPSS home page on FIRST for more information here.
  • What is the difference between EPSS probability and EPSS percent?
    • EPSS probability is the risk calculated by the model when determining the perceived threat of the vulnerability itself. Percentage is a relative comparison of the rest of the CVEs within the given sample. While the probability only changes upon refreshing the results from the model, the percentage can change purely based on the CVE sample given. In the case of the Breakdown, we use the percentage given by the pool of all CVEs with given EPSS data. Scores may vary post-release of the post given new information about the vulnerabilities and their perceived threat. For more information on applying and understanding EPSS data, see this article on the FIRST website, as well as their FAQ page.
  • What is GreyNoise?
    • GreyNoise is a platform that collects, analyzes, and labels data on IPs that scan the internet and saturate security tools with noise. Through their sensor network, GreyNoise observes vulnerability exploitation attempts for vulnerabilities that are exploited in the wild over the Internet. These are arguably vulnerabilities that should be at the very top of your priority list to remediate.
  • Why are GreyNoise exploitation attempts only observed on ~20% of KEV vulnerabilities?
    • Exploitation of many vulnerabilities in the CISA KEV will not be observed for many reasons that GreyNoise does a good job of explaining in this post. For example:
      • The vulnerability may not be remotely exploitable
      • Vulnerability exploitation may require authentication (and result in privilege escalation)
      • The impacted software may not be exposed to the internet
      • Mass scanning/exploitation is not occurring yet