FIX MSDT Vulnerability using SCCM and Intune | CVE-2022-30190

Let’s check how to FIX MSDT Vulnerability using SCCM and Intune (CVE-2022-30190). You can use Intune or SCCM or Group Policy to fix this vulnerability Microsoft Support Diagnostic Tool (MSDT) URL protocol.

The CVE-2022-30190 Vulnerability is to deal with Windows Support Diagnostic Tool via MS Office files. A remote code execution vulnerability exists when MSDT is called using the URL protocol from a calling application such as Word.

You can use the SCCM application to fix the Remote Code Execution Vulnerability as discussed in the second part of this post -> SCCM To Fix New Remote Code Execution Vulnerability In MSHTML Component. The Group Policy or Intune Settings Catalog are the two options to disable the access to run Troubleshooting Wizards.

I have shared a similar fix for remote code execution vulnerability in the MSHTML component, and a similar fix with Intune is also available -> Deploy the registry fix using Intune Win32 App.

Another method can be used to fix similar vulnerabilities using SCCM CI and Baseline. The method uses Powershell Script for File Detection in User Profile and Rerun Discovery Script.

Read More -> Guidance for CVE-2022-30190 Microsoft Support Diagnostic Tool Vulnerability – Microsoft Security Response Center

What is MSDT?

Microsoft Support Diagnostic Tool (MSDT) collects information from hosts running Microsoft Windows client and Windows Server to send to Microsoft Support. This is one of the common tools used for troubleshooting office 365 applications such as Word, Excel, etc.

Manual FIX to MSDT Vulnerability

You can manually fix the MSDT vulnerability using the registry as explained below. The registry is going to disable the MSDT URL protocol. Follow these steps to disable:

1. Run Command Prompt as Administrator.
2. To back up the registry key, execute the command “reg export HKEY_CLASSES_ROOT\ms-msdt MSDT_URL_Protocol.reg“
3. Execute the command to delete registry key ms-msdt from registry “reg delete HKEY_CLASSES_ROOT\ms-msdt /f”.

You can revert the workaround by restoring the registry keys, as mentioned in the following step.

1. Run Command Prompt as Administrator.
2. To restore the registry key, execute the command “reg import  MSDT_URL_Protocol.reg” 

Intune Settings Catalog Policy to FIX MSDT Vulnerability

Let’s check Intune Settings Catalog Policy to FIX MSDT Vulnerability. You can also use the Win32 app deployment method to fix this vulnerability using the registry fix method.

I recommend using the Settings catalog policy to fix the MSDT vulnerability issue. Follow the steps to create and deploy the fix to the Azure AD Device group.

• Sign in to the Microsoft Endpoint Manager admin center
• Select Devices > Configuration profiles > Create profile.
• Select Platform: Windows 10 and later and Profile
• Select Settings catalog (preview). Click on Create button.
• Enter the Name of the Policy and Description.
  • Disable MSDT Troubleshooting and Diagnostics

You can click on the Next button to continue and select the settings.

The following Intune policy setting allows users to access and run the troubleshooting tools that are available in the Troubleshooting Control Panel and to run the troubleshooting wizard to troubleshoot problems.

From the Configuration settings page, select Add settings. Try searching Troubleshooting and Diagnostics from the Search box under Settings Picker and click on the Search button.

• Click on Administrative Templates/System/Troubleshooting and Diagnostics/Scripted Diagnostics.
• Select the settings name -> Troubleshooting: Allow users to access and run Troubleshooting Wizard.
• Enable the Slider to disable the access to run the Troubleshooting wizard.

You need to click on the NEXT button to continue with the creation and deployment (assignment of the policy).

If you enable or do not configure this policy setting, users can access and run the troubleshooting tools from the Troubleshooting Control Panel.

NOTE! – If you disable this policy setting, users cannot access or run the troubleshooting tools from the Control Panel. Note that this setting also controls a user’s ability to launch standalone troubleshooting packs such as those found in .diagcab files.

You need to configure another more accurate policy to disable MSDT tool functionality rather than all troubleshooting wizards. I would recommend testing both the policies and take a collective decision.

• Microsoft Support Diagnostic Tool: Turn on MSDT interactive communication with a support provider.

This policy setting configures the interactive communication of the Microsoft Support Diagnostic Tool (MSDT) with the support provider. MSDT gathers diagnostic data for analysis by support professionals. If you enable this policy setting, users can use MSDT to collect and send diagnostic data to a support professional to resolve a problem.

By default, the support provider is set to Microsoft Corporation. If you disable this policy setting, MSDT cannot run in support mode, and no data can be collected or sent to the support provider.

Try searching Microsoft Support Diagnostic Tool from the Search box under Settings Picker and click on the Search button.

• Click on Administrative Templates/System/Troubleshooting and Diagnostics/Microsoft Support Diagnostic Tool.
• Select the settings name ->Microsoft Support Diagnostic Tool: Turn on MSDT interactive communication with a support provider.
• Enable the slider to disable the access to run the MSDT in support mode.

UPDATE from Jimmy‘s comment below: Q: Is configuring the GPO setting Computer Configuration – Administrative Templates – System – Troubleshooting and Diagnostics – Microsoft Support Diagnostic Tool\”Troubleshooting: Allow users to access recommended troubleshooting for known problems” to “Disabled” another workaround?

A: No, enabling or disabling this group policy has no effect on the vulnerable part of Troubleshooter functionality, so it is not a viable workaround.

Group Policy Method to FIX MSDT Vulnerability

Let’s check the Group Policy settings to FIX MSDT Vulnerability. This method is not documented as part of an official workaround. This could be because this group policy setting will disable all the troubleshooting tools from the control panel/settings app.

This policy setting configures how troubleshooting for known problems can be applied on the device and lets administrators configure how it’s applied to their domains/IT environments.

• Not configuring this policy setting will allow the user to configure how troubleshooting is applied.
• Enabling this policy allows you to configure how troubleshooting is applied on the user’s device.
• Disabling the policy disables all the troubleshooting tools on the device.

You can launch GPEDIT.MSC tool and navigate to Configuration -> Administrative Templates -> System -> Troubleshooting and Diagnostics -> Scripted Diagnostics node.

Select the DISABLED option as shown in the below screenshot for the policy called Troubleshooting: Allow users to access recommended troubleshooting for known problems.

Read More -> Step by Step guide to create a Group Policy and deploy it to the OU.

Another policy setting, Microsoft Support Diagnostic Tool: Configure Execution Level, determines the execution level for Microsoft Support Diagnostic Tool. Microsoft Support Diagnostic Tool (MSDT) gathers diagnostic data for analysis by support professionals.

If you disable this policy setting, MSDT cannot gather diagnostic data. This will help to fix the issue with MSDT vulnerability.

UPDATE from Jimmy‘s comment below: Q: Is configuring the GPO setting Computer Configuration – Administrative Templates – System – Troubleshooting and Diagnostics – Microsoft Support Diagnostic Tool\”Troubleshooting: Allow users to access recommended troubleshooting for known problems” to “Disabled” another workaround?

A: No, enabling or disabling this group policy has no effect on the vulnerable part of Troubleshooter functionality, so it is not a viable workaround.

SCCM Application Method to FIX Vulnerability

You need to use the SCCM application model to deploy the batch file to all the devices. You can then use SCCM CI to track the vulnerability. You can use the following script.

• Launch ConfigMgr Console
• Navigate to \Software Library\Overview\Application Management\Applications
• Right Click on the Applications node
• Select Create Application
• Select the option called “Manually specify the application information. “
• Click on the Next button and enter the name and other details of the application.

You can use the following batch file to fix the vulnerability with MSDT. Save the following as MSDT_FIX.cmd.

MD C:\Windows\Temp\MSDT
PUSHD C:\Windows\Temp\MSDT
reg export HKEY_CLASSES_ROOT\ms-msdt MSDT_URL_Protocol.reg
reg delete HKEY_CLASSES_ROOT\ms-msdt /f
@echo 1.0>C:\Windows\Temp\MSDT\Ver1.0.txt

Using the following blog post, How To Create Deploy Adobe Acrobat Application Using SCCM ConfigMgr Easiest Method, you can continue creating the application. Ensure you have saved the registry file as mentioned in the above section. You can use the following command as an installation program.

• Enter the name of the application you want to deploy – FIX MSDT Vulnerability
• Enter the Publisher Name – HTMD
• Click on the NEXT to continue
• Click on Browse in the Software Center tab to select the Software Center ICON for this FIX.
• Click on the Next button once the FIX ICON is uploaded

On the Deployment Types page, you need to provide the following details. Deployment Types include information about the installation method and the source files for the application.

• Click on ADD button to configure the FIX MSDT Vulnerability application.

Specify the settings for this deployment type. Type of the Application – Script Installer. Manually specify the deployment type information option will be automatically selected.

Specify general information for this deployment type

• Deployment Type Name – FIX MSDT Vulnerability.
• Language – Select English.
• Click on the NEXT button to continue.

You need to provide the content location. In this scenario, it’s only the CMD file created above. This CMD file contains a batch file to delete the registry key that causes the vulnerability.

• Content Location -> \ADMEMCM\Source\Package Source\FIX MSDT
• Install Program -> MSDT_FIX.cmd
• Click on the NEXT button to continue.

Specify the Detection Method of this deployment type. I have to select the file name created as part of the batch file script. The file path and name are below -> FIX MSDT Vulnerability using SCCM and Intune CVE-2022-30190 6Ver1.0.txt.

• Click on Add Clause to add the detection method.
• Setting Type -> File System.
• Type -> File.
• Path -> %Windir%\Temp\MSDT
• File or Folder Name -> Ver1.0.txt
• Click on the OK and then the NEXT buttons to continue.

You can select installation behavior as install this application for System. You can configure the rest of the settings as shown in the below screenshot.

The following is the summary of the SCCM Application to fix MSDT Vulnerability. You can distribute the content to the DPs and then deploy it to the Device Collection.

 General Information:
•	Name: FIX MSDT Vulnerability
•	Technology: Technology: Script Installer
•	Administrator comments:
•	Languages:
 
 Content:
•	Content location: \\ADMEMCM\Source\Package Source\FIX MSDT
•	Persist in client cache: No
•	Installation program: MSDT_FIX.cmd
•	Installation start in:
 
 Detection Method:
 
 User Experience:
•	Installation behavior: Install for system
•	Login requirement: Whether or not a user is logged on
•	Installation priority: Hidden
•	Allow users to interact with this program: No
•	Maximum allowed run time (minutes): 120
•	Estimated install time (minutes): 0
 
 Requirements:
 
 Dependencies:

Author

Anoop is Microsoft MVP! He is a Solution Architect in enterprise client management with over 17 years of experience (calculation done in 2018) in IT. He is Blogger, Speaker, and Local User Group Community leader. His main focus is on Device Management technologies like SCCM 2012, Current Branch, and Intune. He writes about technologies like SCCM, SCOM, Windows 10, Azure AD, Microsoft Intune, RMS, Hyper-V, etc.