Microsoft published last year both a security advisory and a security bulletin about Windows Authenticode Signature Verification.
- Changes in Windows Authenticode Signature Verification: https://technet.microsoft.com/library/security/2915720
- Vulnerability in Windows Could Allow Remote Code Execution (2893294) https://technet.microsoft.com/en-us/library/security/ms13-098.aspx
- KB2893294 http://support.microsoft.com/kb/2893294 (see the known issues)
- MS13-098: Update to enhance the security of Authenticode http://blogs.technet.com/b/srd/archive/2013/12/10/ms13-098-update-to-enhance-the-security-of-authenticode.aspx
The security bulletin was revised on May 21, 2014 to announce that the deadline of June 10 was postponed to August 12, 2014.
Two deadlines on June 10 breaking Windows was a bit confusing for customers and support teams, so the Marketing department changed the deadline… I’m kidding, of course 😉
I reported the above new cut-off date to the pachmanagement.org mailing list and some questions were raised about how to activate the certificate padding check and what tools should be used to test.
I replied that:

Now, I’d like share my experience, develop and illustrate what I wrote in the above message.
My test computer is Windows 7 x64 machine with PowerShell 3.0 installed.
Get-HotFix -Id "KB2893294"
Prerequisites: Like Didier Stevens, I’ve two “Chrome installers” that I renamed.
# Download the latest version of sigcheck Invoke-WebRequest -Uri http://live.sysinternals.com/sigcheck.exe -OutFile .\sigcheck.exe Unblock-File .\sigcheck.exe # Download the AnalyzePESig tool and extract it manually Invoke-WebRequest -Uri https://didierstevens.com/files/software/AnalyzePESig_V0_0_0_3.zip -OutFile .\AnalyzePESig_V0_0_0_3.zip

Note that the Get-AuthenticodeSignature reports both portable executable (PE) installers as signed and the trust verifying events are logged into the Certificate API v2 log.

Idem for sigcheck from Mark Russinovich

I’ve created locally an Applocker policy with default rules and added a deny rule on the certificate found in the installer. Note that when I test the file against the applocker execution rules, it reports that its execution would be denied based on the publisher rule I introduced.
This step is documented in the security advisory
Here’s how I’ve enabled it with PowerShell based on the information found in the above advisory:
if (-not(Test-Path -Path "HKLM:\Software\Microsoft\Cryptography\Wintrust\Config" -PathType Container)) {
try {
New-Item -Path HKLM:\Software\Microsoft\Cryptography\Wintrust\Config -ItemType Container -Force -ErrorAction Stop
New-ItemProperty -Path HKLM:\Software\Microsoft\Cryptography\Wintrust\Config -Name EnableCertPaddingCheck -Value 1 -PropertyType String -ErrorAction Stop
if ([System.Environment]::Is64BitOperatingSystem) {
if (-not(Test-Path -Path "HKLM:\Software\Wow6432Node\Microsoft\Cryptography\Wintrust\Config" -PathType Container)) {
New-Item -Path HKLM:\Software\Wow6432Node\Microsoft\Cryptography\Wintrust\Config -ItemType Container -Force -ErrorAction Stop
New-ItemProperty -Path HKLM:\Software\Wow6432Node\Microsoft\Cryptography\Wintrust\Config -Name EnableCertPaddingCheck -Value 1 -PropertyType String -ErrorAction Stop
}
}
} catch {
Write-Warning -Message "Failed to create registry key because $($_.Exception.Message)"
}
}
Get-Service -Name CryptSvc -Verbose | Stop-Service -Verbose -Force -PassThru | Start-Service -PassThru -Verbose
A computer restart isn’t actually needed, you can only restart the Cryptographic Services. The Applocker service will be also restarted as it depends on the cryptographic services.
# Enable verbose diagnostic logging.
# Add a DWORD (32-bit) value DiagLevel with value of 0x00000005
Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Services\Crypt32' -Name "DiagLevel" -Type DWORD -Value 5
# Add a QWORD (64-bit) value DiagMatchAnyMask with value of 0x00ffffff
Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Services\Crypt32' -Name "DiagMatchAnyMask" -Type QWORD -Value 0x00ffffff
# Enable CAPI2 operational logging
$log = New-Object -TypeName System.Diagnostics.Eventing.Reader.EventLogConfiguration -ArgumentList "Microsoft-Windows-CAPI2/Operational"
$log.isEnabled = $true
try {
$log.SaveChanges()
} catch {
Write-Warning -Message "Failed to save changes because $($_.Exception.Message)"
}
Get-Service -Name CryptSvc -Verbose | Stop-Service -Verbose -Force -PassThru | Start-Service -PassThru -Verbose
Here’s a screenshot of the installer I’ve that has the certificate issue:

Here’s the difference with the one that hasn’t the certificate padding issue:

Now when I use the Get-AuthenticodeSignature with verbose CAPI2 logging enabled, verify trust events are reported both for either a failure or a success
Get-AuthenticodeSignature C:\Chrome.CertPaddingIssue.exe Get-AuthenticodeSignature C:\Chrome.Signed.exe

Idem for sigcheck.

To measure the impact on the local applocker policy, I do:
Get-AppLockerPolicy -Local | Test-AppLockerPolicy -Path C:\Chrome.Signed.exe Get-AppLockerPolicy -Local | Test-AppLockerPolicy -Path C:\Chrome.CertPaddingIssue.exe
… and get the following result.

In other words, the explicit deny rule based on certificate won’t prevent the C:\Chrome.CertPaddingIssue.exe to be executed anymore. Only the implicit rule deny for everyone will block it because it’s stored in a location that isn’t listed in an explicit allow or deny rule.

$HT = @{ ErrorAction = "SilentlyContinue" }
$AMHT = @{ Type = "NoteProperty" ; PassThru = $true ; Force = $true }
$FilterHT = @{ FilterHashTable = @{ LogName = "Microsoft-Windows-CAPI2/Operational" ; Id = 81 }}
Get-WinEvent @FilterHT @HT | ForEach-Object -Process {
$xml = ([xml]($_.toXML()))
$_ | Add-Member -Name ProcessName -Value ($xml.Event.UserData.WinVerifyTrust.EventAuxInfo.ProcessName) @AMHT |
Add-Member -Name Result -Value ($xml.Event.UserData.WinVerifyTrust.Result.value) @AMHT |
Add-Member -Name FilePath -Value ($xml.Event.UserData.WinVerifyTrust.FileInfo.FilePath) -Force -MemberType NoteProperty
$msg = 'The WinVerifyTrust check performed by process {0} on file {1} ended with result {2}' -f $_.ProcessName,$_.FilePath,$_.Result
$_ | Add-Member -Name Message -Value $msg @AMHT
}

Note that when the certificate padding check is enabled, the WinVerifyTrust function returns a 0x800B0100 value, which means “No signature was present in the subject”.
Another more recent post on this subject:
http://blogs.msdn.com/b/ieinternals/archive/2014/09/04/personalizing-installers-using-unauthenticated-data-inside-authenticode-signed-binaries.aspx
Pingback: SigFlip - A Tool For Patching Authenticode Signed PE Files (Exe, Dll, Sys ..Etc) Without Invalidating Or Breaking The Existing Signature - Hacker Gadgets
Pingback: SigFlip – A Tool For Patching Authenticode Signed PE Files (Exe, Dll, Sys ..Etc) Without Invalidating Or Breaking The Existing Signature - Latest Hacking News Today - HakTechs