Microsoft Support Diagnostic Toolkit (msdt.exe) exploitable - CVE-2022-30190 (CVSS3 = 7.8)

UPDATE: June 14 - Microsoft has updated the information on the relevant page: "The update for this vulnerability is in the June 2022 cumulative Windows Updates. Microsoft strongly recommends that customers install the updates to be fully protected from the vulnerability. Customers whose systems are configured to receive automatic updates do not need to take any further action."

Discovered and reported more than a month ago (Apr 12), the 'Follina' vulnerability (assigned CVE-2022-30190) is a remote code execution (RCE) vulnerability and is known to impact all Windows versions which still receive security updates (versions above Windows 7 and Server 2008) - see below for searching for these assets in Axonius. This means that a successful attack could result in code executing locally on a victim system.

The vulnerability is currently known to be exploited by attackers in the wild.

 

The vulnerability is in the MS Windows Diagnostic Toolkit, and has been associated with MS Office, since that's the typical delivery mechanism (think phishing attack with .docx or RTF attachment). However, Office365 client is not vulnerable, and neither are documents loaded in 'protected mode'. It has been demonstrated to be triggered through PowerShell access to msdt.exe so this brings Windows Server into perspective too.

The Diagnostic Tool is part of the Windows operating system, used in conjunction with Microsoft Support, and is thus designed to operate 'unguided' - and requires access to the Internet, so has a URI scheme built in: ms-msdt which is the route to exploitation.

 

3rd party guidance

Microsoft released guidance on May 30: https://msrc-blog.microsoft.com/2022/05/30/guidance-for-cve-2022-30190-microsoft-support-diagnostic-tool-vulnerability/ on how to deal with the existence of the URL schema.

 

The PwnDefend article: https://www.pwndefend.com/2022/05/30/office-microsoft-support-diagnostic-tool-msdt-vulnerability-follina/ has a lot of detail about the process of exploitation and for remediation, this can be accomplished via a GPO:

To mitigate the exploit

Group Policy

You can disable this via GPO (which is a fully supported method vs the reg hacks)

you do this via registry:

 

reg add “HKLM\\SOFTWARE\\Policies\\Microsoft\\Windows\\ScriptedDiagnostics” /t REG_DWORD /v EnableDiagnostics /d 0

 

or via the GUI (locally) or via GPMC etc. in a domain environment.

 

Using Axonius to help

To start, we need to find all Windows devices (servers and desktop releases) which are currently supported.

  1. Using the Search Wizard we select using Aggregated data for 'OS Type = Windows', and
  2. Add a new line, search Aggregated for 'OS Full OS String, and use a regex \[0123689\]'

These are all the machines that need to have some mitigation applied (see above, and other internet resources)

We can get more specific by including Office as a qualifier for remediation since we know that Office is the primary initial access vector.

 

  1. Add aggregated 'Installed Software: Software Name contains Office' as the next line.

 

There is a comprehensive use-case for finding unsupported OS (based on build number) here:

https://docs.axonius.com/docs/finding-obsolete-devices 

 

With Tenable / Qualys / other vulnerability assessment tooling

When adapters are able to bring CVE details into Axonius, we can easily search directly for machines (assuming that they've been scanned recently in order to trigger the report) for aggregated data in Vulnerable Software: CVE ID = CVE-2022-30190.

 

The difficulty is knowing that the entirety of the asset base has been covered with the Vulnerability Assessment tooling.

0

Comments

0 comments

Please sign in to leave a comment.

Didn't find what you were looking for?

New post