WinVerifyTrust Vulnerability

Opting into this stricter verification behavior causes the WinVerifyTrust function to perform strict Windows Authenticode signature verification for PE files

Taken from Microsoft's article, available here

This vulnerability has been around for some time (December 2013) and was updated again in April 2023, and is now found as a Cyber Essentials failing vulnerability, due to its increased CVSS Scores.

REGISTRY FIX

Create a WinVerifyEnable.reg file with the text below and import into the Registry 

Windows Registry Editor Version 5.00  
[HKEY_LOCAL_MACHINE\Software\Microsoft\Cryptography\Wintrust\Config]   
"EnableCertPaddingCheck"="1"

[HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\Cryptography\Wintrust\Config] 
"EnableCertPaddingCheck"="1"

Either double click the file or execute the commandline

reg import winverifyenable.reg

POWERSHELL SCRIPT

# Define the registry key path and value name
$regPath = "HKLM:\Software\Microsoft\Cryptography\Wintrust\Config"
$valueName = "EnableCertPaddingCheck"
$regPath2 = "HKLM:\Software\Wow6432Node\Microsoft\Cryptography\Wintrust\Config"
$valueName2 = "EnableCertPaddingCheck"

# Check if the registry key exists
if (!(Test-Path $regPath)) {
  # Create the registry key if it doesn't exist
  New-Item -Path $regPath -Force | Out-Null
}

# Check if the registry value exists
if (!(Test-Path "$regPath\$valueName")) {
  # Create the registry value if it doesn't exist
  New-ItemProperty -Path $regPath -Name $valueName -Value 1 -PropertyType String | Out-Null
}

# Output the registry value data
Get-ItemProperty -Path $regPath -Name $valueName

# Check if the registry key exists
if (!(Test-Path $regPath2)) {
  # Create the registry key if it doesn't exist
  New-Item -Path $regPath2 -Force | Out-Null
}

# Check if the registry value exists
if (!(Test-Path "$regPath2\$valueName")) {
  # Create the registry value if it doesn't exist
  New-ItemProperty -Path $regPath2 -Name $valueName2 -Value 1 -PropertyType String | Out-Null
}

# Output the registry value data
Get-ItemProperty -Path $regPath2 -Name $valueName2

What is the result of opting into the stricter verification behavior?

Opting into the stricter verification behavior causes the WinVerifyTrust function to perform strict Windows Authenticode signature verification for PE files. After you opt in, PE files will be considered "unsigned" if Windows identifies content in them that does not conform to the Authenticode specification. This may impact some installers. If you are using an installer that is impacted, Microsoft recommends using an installer that only extracts content from validated portions of the signed file.

Vulnerability Description

A remote code execution vulnerability exists in the way that the WinVerifyTrust function handles Windows Authenticode signature verification for portable executable (PE) files. An anonymous attacker could exploit the vulnerability by modifying an existing signed executable file to leverage unverified portions of the file in such a way as to add malicious code to the file without invalidating the signature. An attacker who successfully exploited this vulnerability could take complete control of an affected system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights.

If a user is logged on with administrative user rights, an attacker who successfully exploited this vulnerability could take complete control of an affected system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights.

Exploitation of this vulnerability requires that a user or application run or install a specially crafted, signed PE file. An attacker could modify an existing signed file to include malicious code without invalidating the signature. This code would execute in the context of the privilege in which the signed PE file was launched.

In an email attack scenario, an attacker could exploit this vulnerability by sending a user an email message containing the specially crafted PE file and convincing the user to open the file.

In a web-based attack scenario, an attacker would have to host a website that contains a specially crafted PE file. In addition, compromised websites and websites that accept or host user-provided content could contain specially crafted content that could be used to exploit this vulnerability. An attacker would have no way to force users to visit a website that is hosting the specially crafted PE file. Instead, an attacker would have to convince users to visit the website, typically by getting them to click a link in an email message or Instant Messenger message that directs them to the attacker's website.