Remediating CVE-2022-29072 7-zip Windows Privilege Escalation Vulnerability

-

The current version and some earlier versions of 7-Zip have a security vulnerability which could allow hackers to escalate privileges. The zero-day referred to as CVE-2022-29072 exploits the misconfiguration of 7z.dll. Hackers can gain unauthorized access to systems when a file with the .7z extension is placed within the Help > Contents area. The command then runs as a child process under the 7zFM.exe process.

At present, 7-Zip has not released a security update to address this vulnerability, which means that all current versions of 21.07 are vulnerable. Luckily there is a workaround available to mitigate the vulnerability and through this blog, I will cover the remediation steps of implementing this workaround using ConfigMgr. 

Workaround for mitigation

To remedy this vulnerability, 7-zip.chm file in the 7-Zip installation directory needs to be deleted. This way the help section of 7-zip becomes unusable and the attackers cannot exploit it any further. 

I have created simple .vbs scripts to detect and delete the 7-zip.chm file using Compliance settings in ConfigMgr. Through compliance settings, you can manage configuration and settings on the devices in your organization. It includes configuration items (CI) which stores the defined specific information and a configuration baseline that evaluates the CIs you create.

Scripts being used are -

Detection x64 -

dim filesys
Set filesys = CreateObject("Scripting.FileSystemObject")
If filesys.FileExists("C:\Program Files\7-Zip\7-zip.chm") Then
WScript.Echo "File exists"
Else
WScript.Echo "File does not exist"
End If

Detection x86 -

dim filesys
Set filesys = CreateObject("Scripting.FileSystemObject")
If filesys.FileExists("C:\Program Files (x86)\7-Zip\7-zip.chm") Then
WScript.Echo "File exists"
Else
WScript.Echo "File does not exist"
End If

Remediation x64 -

dim filesys
Set filesys = CreateObject("Scripting.FileSystemObject")
If filesys.FileExists("C:\Program Files\7-Zip\7-zip.chm") Then
filesys.DeleteFile "C:\Program Files\7-Zip\7-zip.chm"
End If

Remediation x86 -

dim filesys
Set filesys = CreateObject("Scripting.FileSystemObject")
If filesys.FileExists("C:\Program Files (x86)\7-Zip\7-zip.chm") Then
filesys.DeleteFile "C:\Program Files (x86)\7-Zip\7-zip.chm"
End If

Now we will put of this together in Compliance settings in ConfigMgr. I am creating 2 CIs. One for each installer architecture. 

1. On the MECM console, navigate to \Assets and Compliance\Overview\Compliance Settings\Configuration Items.
2. Right click and select Create Configuration Item.
3. Configure the settings as shown below.


Detection:


Remediation:



4. Repeat the same for x86 based CI.


Detection:


Remediation:



5. After creating the CIs, we will now create a baseline. Navigate to \Assets and Compliance\Overview\Compliance Settings\Configuration Baselines.
6. Right click and select Create Configuration Baseline.
7. Configure the settings as shown below.


8. Lastly, deploy the baseline with remediation enabled. Note: I will not recommend setting a recurrence schedule as the vulnerability may get fixed in future releases of 7-zip.


Conclusion

Until a fix is released, implementing the workaround seems like the only option. The .vbs scripts shared in this blog can also be used in Intune or any other other deployment tool.

Comments

Post a Comment

Popular posts from this blog

How to force escrowing of BitLocker recovery keys using Intune

-
Image
Every now and then it so happens that BitLocker recovery keys do not escrow in AAD. The usual culprits are incorrect BitLocker policies and\or the device hardware configuration failing to meet the minimum requirements. The other scenario and something I recently experienced is when everything is setup right and still the recovery key doesn’t escrow in AAD. As I understand, this can happen if the escrow process got interrupted the first time due to network or local devices related issues and the process could not resume. To circumvent this issue, one can simply push a PowerShell script to the devices to force the escrow of the recovery keys to AAD. Here is a script to do so. try{ $BitlockerVol = Get-BitLockerVolume -MountPoint $env:SystemDrive         $KPID=""         foreach($KP in $BitlockerVol.KeyProtector){             if($KP.KeyProtectorType -eq "RecoveryPassword"){                 $KPID=$KP.KeyProtectorId                 break;             }         }        $o
Read more

Intune: Configure Printers for Non-Administrative Users

-
Image
Configuring printers for end users or giving them the ability to do it themselves is a normal requirement for organizations. Now if your users are Administrators, then the configuration can be straight forward, but in case of Non-Administrators there are additional steps required as Non-Administrators will not be able to add a driver in the driver store despite being able to install a printer. In this blog, I will cover the steps that I took to address this requirement using Intune. The setup involves 2 steps -  1. Setup registries. 2. Install the driver and configure the printer Setting up registries – The registries that need to be configured are actually part of a GPO setting – Allow non-administrators to install drivers for these device setup classes It can be found under: Computer Configuration -> Policies -> Administrative Templates -> System -> Driver Installation I used a Powershell script to set the values and wrapped it in a Win32 application. $Path1
Read more

Prevent users from running certain programs or applications on Windows endpoints using Intune

-
Image
  When it comes to blocking or preventing users from running an application on Windows devices, one normally uses App locker policy, Windows Defender Application Control and not so new but pretty useful method called Defender Vulnerability management within Microsoft 365 Defender Portal. A recent question on the Tech Community Microsoft forum prompted me to look for all possible alternatives. I started reminiscing over the legacy GPO policies and that is when I stumbled upon the policy  Don’t run specified Windows applications  located under User Administrative Templates - The policy setting does come with its own caveat - " This policy setting only prevents users from running programs that are started by the File Explorer process. It does not prevent users from running programs, such as Task Manager, which are started by the system process or by other processes. Also, if users have access to the command prompt (Cmd.exe), this policy setting does not prevent them from starting pr
Read more