Authenticode and Weak Certificate Chains

Recently, someone attempted to download a deprecated version of the Windows Script debugger. This tool was used to debug scripts prior to the introduction of more powerful, modern tools like those that are built into IE8 and later. The user emailed me when they encountered a very surprising outcome:

image

After clicking the Run button, the download proceeds, but then the user sees the message: <filename> was reported as unsafe.

image

The obvious question is “Who or what reported this file as unsafe?”

Many people might assume that this is a SmartScreen warning, but it’s not. When SmartScreen blocks a piece of known-malware, it takes all the credit, as you can see in this screenshot:

image

So, if it’s not SmartScreen, where is the warning coming from?

The answer is that the “<filename> was reported as unsafe” message occurs when the WinVerifyTrust API reports that there’s a problem with a downloaded file’s digital signature. Pretty straightforward. You’d might see this error if you tried to open an incompletely-downloaded file, for instance.

However… If you look at the signature in Windows Explorer, everything looks okay:

image

In particular, you’ll notice that the signature is marked OK at the top, and there’s a Timestamp at the bottom, which allows the signature to remain valid even after the certificate expires. However, that timestamp is twelve years old… this is a very old file.

Now, if you click the View Certificate button, and you’re a regular reader of my blog, you’ll might be able to spot the problem:

image

See it?

The problem is that the certificate itself is signed using the MD2 hash algorithm. This algorithm has known vulnerabilities and is not safe to use for untrusted content delivered over insecure networks. To that end, as I’ve mentioned in passing a couple of times on this blog, Internet Explorer 8+ on Windows 7 SP1+ no longer accepts Authenticode signatures that use the MD2 or MD4 hashing algorithms in the certificate chain. (MD2 and MD4 on the root itself isn’t a worry, because the root itself is installed on the machine). This restriction is enforced by passing the WTD_DISABLE_MD2_MD4 flag to WinVerifyTrust, instructing it to reject signatures that use either of these weak algorithms on the certificate chain. For the time being, Windows Explorer itself permits use of MD2 and MD4 in the signatures of locally-installed files, since the primary threat in today’s environment comes from code delivered using the Web.

In the real world, downloads that are signed using deprecated algorithms prove to be quite uncommon, because relatively few software vendors were signing their packages in the late 1990s when MD2 and MD4 were in use. We’ve identified a few ancient installers on Microsoft’s Download Center that will need to be removed or re-signed using current certificates and newer algorithms (e.g. SHA-1) to present a stronger defense against skilled attackers that might try to spoof a digital signature.

-Eric