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:

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

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:

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:

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:

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

Comments

• Anonymous
  August 19, 2011
  The comment has been removed

• Anonymous
  August 19, 2011
  +1 The first thing I noticed is the Valid to field on that screenshot.

• Anonymous
  August 19, 2011
  Countersignature should remain good as long as the certs involved chain up to certs that are in the root store - even if those roots have expired.  That's interesting about disallowing MD2 and MD4 if it came from the Internet.  Would that warning go away if you downloaded it from Trusted Sites?

• Anonymous
  August 19, 2011
  @Larry/Roman: I discuss the benefits of Timestamping in an earlier post: blogs.msdn.com/.../authenticode-code-signing-for-developers-for-file-downloads-building-smartscreen-application-reputation.aspx @Aaron: A quick test confirms that IE9's download manager will still run WinVerifyTrust on downloaded executables from the Trusted Zone, even if you ratchet the security level down to Low.

• Anonymous
  August 24, 2011
  The comment has been removed

• Anonymous
  August 24, 2011
  @hashnote: I don't think there's any dispute that SHA-1 is more modern than MD2/MD4. If your point is merely that there are newer hashes than SHA-1, sure, that's absolutely correct. The problem with moving to SHA-2 for everything, however, is that there are a number of legacy platforms that do not support SHA-2, and hence a move to that algorithm will result in a broken scenario.