Call4Cloud

Protocol Nightmare on Elmstreet: The Dream CVE-2022-30190

This blog will be about me trying to protect my Windows 10 Pro devices to make sure they aren’t vulnerable to the nasty CVE-2022-30190 bug AKA Follina but I rather called it the Protocol Nightmare.

Somehow it reminds me of the Printer Nightmare bug(s) from some time ago. I am mentioning it because just a few days after the Follina CVE was released another Zero Day popped up that also makes use of the MSDT.exe. This additional Zero-day is called “DogWalk”

I am going to divide this blog into multiple parts

  1. Introduction
  2. Possible Solutions
  3. Settings Catalog Error
  4. Search-MS Protocol

1. Introduction

I guess the CVE-2022-30190 Follina bug doesn’t need much introduction but a little bit couldn’t do any harm I guess.

🔃 Security Update Guide – Loading – Microsoft

Looking at the MSRC link above, it’s telling us “A remote code execution vulnerability exists when MSDT is called using the URL protocol from a calling application such as Word. An attacker who successfully exploits this vulnerability can run arbitrary code with the privileges of the calling application. The attacker can then install programs, view, change, or delete data, or create new accounts in the context allowed by the user’s rights.”

Let me explain in some simple words what a URL protocol does. For example, when accessing an https: URL it will launch a nice browser, when accessing msdt: URL it will launch the msdt.exe process. This CVE abuses the Microsoft Support Diagnostic Tool MSDT.EXE

Like I was telling you in the beginning, just after this Zero-day arrived, the “DogWalk” Zero-Day arrived! This bug will try to copy an executable file to the Windows startup folder when the target opens a maliciously .diagcab file. This CAB file includes a Mark-of-the-Web (MOTW) but because it’s a CAB file it won’t be blocked and you won’t be warned!

2. Possible Solutions

Luckily we have multiple solutions to make sure our devices aren’t vulnerable to the MS-MSDT issue. I am going to explain 4 of them

2.1 Deleting the MSDT URL

When looking at Microsoft their official statement, they are telling us to disable the MSDT URL protocol to make sure our devices are not vulnerable

Graphical user interface, text, application, email

Description automatically generated

When choosing this path, we can simply disable this MSDT url with a nice PowerShell script. In my opinion, it’s not the nicest option but it gets the job done!

Detection Script

New-PSDrive -PSProvider registry -Root HKEY_CLASSES_ROOT -Name HKCR -ErrorAction SilentlyContinue | out-null
try {
    Get-Item HKCR:\ms-msdt -ErrorAction Stop
    Write-host "MS-MSDT exists. Remediate."
    Exit 1
}
catch {
    Write-host "MS-MSDT doesn't exist. No action needed."
    Exit 0
}

Remediation script

$regBkpPath = "C:\Intune\RegBackup\"

if ( -not (Test-Path $regBkpPath)) {
    New-Item -Path $regBkpPath -ItemType Directory
}

Invoke-Command {reg export 'HKCR\ms-msdt' $regBkpPath\msmsdtBkp.reg /y}

New-PSDrive -PSProvider registry -Root HKEY_CLASSES_ROOT -Name HKCR -ErrorAction SilentlyContinue | out-null
Remove-Item -Path 'HKCR:\ms-msdt\*' -Recurse -Force -Confirm:$false
Remove-Item -Path 'HKCR:\ms-msdt\' -Force -Confirm:$false

2.2 Applocker

For as long as I remember we are using Applocker (with DLL and MSI/script rules) to make sure all of the devices are secured!. To do so we are using our own baseline.

Deploy Applocker to Intune with PowerShell (call4cloud.nl)

In this baseline, we made sure the msdt.exe is excluded from the default Windows allow path

Graphical user interface, text, application

Description automatically generated

Another possibility would be to explicitly block the MSDT process by creating a new publisher rule as shown below to make sure access to MSDT.exe is always blocked!

Graphical user interface, text, application, Word

Description automatically generated

When this baseline is deployed to your devices and you are trying to open that bad MSDT process you will be prompted with the “this app has been blocked by your system administrator” message

Graphical user interface, text

Description automatically generated

Please Note: Of course, you could do the same with Windows Defender Application Control (WDAC) but somehow I still prefer a good configured Applocker setup.

2.3 ASR Rules

I am hoping that all of you are already using Attack Surface Reduction and have configured the required rules to make sure some important stuff is secured. If not please read my blog about the Magnificent ASR Rules first

When you need to protect your device against CVE-2022-30190, you could also configure this ASR rule to make sure your device is safe: d4f940ab-401b-4efc-aadc-ad5f3c50688a AKA Block all Office applications from creating child processes

That specific rule makes sure that it blocks child processes from being created in the Office Apps. When the ASR rule kicks in, a nice new event 1121 will show up in the Windows Defender event log.

When this action is blocked, you are also protected but in my opinion, it is not the best option out there. Because the issue arent the Office Apps it are the protocol handlers themselves!

When configuring ASR Rules please beware that ASR rules could also break some of your Office Addons or Plugins so please make sure you Audit first!

2.4 Intune Settings Catalog

The last option I am going to show you would be to use a Settings Catalog in Intune to configure the scripted diagnostics. When disabling the possibility to allow users to access and run the troubleshooting wizard you are also making sure your device is secured.

A picture containing text

Description automatically generated

When you have blocked access to these kinds of wizards (msdt.exe) you will notice you will be prompted with the message that an error occurred and error code: 0x80070005

Graphical user interface, text, application

Description automatically generated

3. Settings Catalog Error

We were already using Applocker on all of our devices but better safe than sorry so I decided to push this settings catalog to our devices.

After a while, the first devices began to check-in and received this policy but as shown below some of them were giving us an error

Taking a closer look at that message, I noticed it was the famous 65000 not applicable error.

Graphical user interface, text, application, email

Description automatically generated

It’s the same licensing error I was telling about in this 65000 Days Of Night blog

That’s odd because if I remember correctly Mike Danoski told us, they removed the applicability filter on the service side

Graphical user interface, text, application

Description automatically generated

The only requirement would be to have a device with the March 2022 update installed as shown below

Graphical user interface, text, application, email

Description automatically generated

To be sure my device was up to date I opened WINVER. As shown below my Windows 11 Business build is 22000.675.

Graphical user interface, text, application, email

Description automatically generated

Like I was telling in that 65000 blog I wrote, I needed to make sure the required ADMX registry key are available.

Graphical user interface, application, Word

Description automatically generated

Luckily, as shown above, that isn’t my issue…. Mmm, could it still be that licensing error?? I opened the DeviceManagement-enterprise-Diagnostics-Provider event log to check it out.

Graphical user interface, application

Description automatically generated

Noooo!! The same 0x82b00006, Policy is rejected by licensing error! Sarcasm on: It’s a good thing we also have Windows Enterprise devices that are still enterprise… Sarcasm Off

When looking at the same Settings catalog report, that enterprise device has the succeeded status.

I have reached out to the IntuneSupport team and Mike Danoski to make them aware of this issue. It looks like these settings do work on Windows Pro devices, but when using Microsoft 365 business premium you got yourself a nice Windows Business Device.

Hopefully, it will be resolved within a few days so we can also make use of this setting on Windows Business devices

4. The Search-MS Protocol

The search-ms URI protocol allows applications to launch custom searches on a device. Just as with the MSDT protocol, it can be abused with the Office Apps

The PowerShell remediation script I showed you earlier focuses on the MS-MSDT Protocol but because this blog is becoming the Protocol Nightmare blog I will also show you how to fix the search-ms protocol nightmare.

Detection Script

New-PSDrive -PSProvider registry -Root HKEY_CLASSES_ROOT -Name HKCR -ErrorAction SilentlyContinue | out-null
try {
    Get-Item HKCR:\search-ms -ErrorAction Stop
    Write-host "Search-MS exists. Remediate."
    Exit 1
}
catch {
    Write-host "Search-MS doesn't exist. No action needed."
    Exit 0
}

Remediation Script


$regBkpPath = "C:\Intune\RegBackup\"

if ( -not (Test-Path $regBkpPath)) {
    New-Item -Path $regBkpPath -ItemType Directory
}

Invoke-Command {reg export 'HKCR\search-ms' $regBkpPath\searchmsBkp.reg /y}

New-PSDrive -PSProvider registry -Root HKEY_CLASSES_ROOT -Name HKCR -ErrorAction SilentlyContinue | out-null
Remove-Item -Path 'HKCR:\search-ms\*' -Recurse -Force -Confirm:$false
Remove-Item -Path 'HKCR:\search-ms\' -Force -Confirm:$false

When this remediation has run, people who are using or abusing this protocol will end up with the error that the protocol search-ms does not have a registered program

Conclusion

In this blog, I showed you the options you have to make sure your device is protected against the ms-msdt and the search-ms Protocol Nightmare.

In my opinion, when looking at the options I gave you to block the available I prefer the Applocker method as it blocks the whole MSDT.exe process!

Hopefully, when we all have implemented a fix by now we can sit back and enjoy our #MEMBEER

Beer Gif - IceGif

8 thoughts on “Protocol Nightmare on Elmstreet: The Dream CVE-2022-30190

  1. I just saw your post on Linkedin; You should include “out-null” to avoid a loop, otherwise it will always try to execute the remediation, as there is an output with New-PSDrive.

    Example:
    New-PSDrive -PSProvider registry -Root HKEY_CLASSES_ROOT -Name HKCR -ErrorAction SilentlyContinue | out-null

    1. Hi… I noticed the same indeed… Someone else was also mentioning the error .. I adjusted the script.. thanx for noticing it

  2. Imho the easiest way to nullify this exploit is just to use a GPO or Intune to disable the troubleshooting tool. No scripts to test, no reg keys to eventually have to reverse, and obviously easier to push through change control.

    1. Hi..

      That’s indeed true. just as I was explaining in the blog… But with windows 10 business that settings catalog doesn’t (yet) seem to be working.

  3. Hello, When i have copied the script and run, however the script finds the Reg msdt but then stops as if the switch “remediate” is not not connecting to the next cmd

Leave a Reply

Your email address will not be published. Required fields are marked *

42  +    =  46