Based on RSA’s PKCS7 standard, Authenticode is the technology developed by Microsoft to digitally certify programs and drivers on Windows. Trusted signatures guarantee that the certificate owner is indeed the author of the signed executable, and also that the data itself has not been tampered with by anyone else.
In a default configuration scenario, the operating system considers these signatures during all but three events:
- When kernel-mode drivers are loaded
- When executable images that derive directly from content downloaded using Internet Explorer (or any other third-party browser which supports it) are written to disk.
- When an application requires admin privileges.
Point two is a weak security measure for the following reasons:
- Even if the right browser is used, there’s still no guarantee that the verification request (because it is by no means mandatory) is honored by the operating system unless the UAC privilege elevation dialog is invoked (either via manifest or using the “Run as Administrator” menu item). It’s important to note that if the Authenticode signature can’t be verified, the dialog being shown to the user is the same as the one for unsigned executables. At this point, there is no way to distinguish from unsigned (no code signature) and untrusted programs (invalid code signature) using the UAC dialog alone.
- Once an application has been authorized by a user and his certificate store, no checks are performed when it is moved to another system (even if the new certificate store can’t validate the Authenticode signature)
- The whole mechanism heavily relies on the file system being used; copying unauthorized files to a non-NTFS file system (which happens quite a lot, considering the vast majority of USB drives are using FAT32) doesn’t preserve the alternate data streams created by browser.
Also the verification is not self evident if done manually using Windows Explorer, as the properties dialog doesn’t show the validity of the certificate until the user clicks the “Details” button. This is highly misleading, because the user might get a false sense of security by just checking whether the executable contains a digital signature.
The upcoming version 0.8.6 of the Profiler introduces support for this technology, allowing users to very quickly access and verify code signing information.
The following screenshot shows a perfectly valid digital signature; all the certificates taken from the Authenticode data have been successfully used to build a trust chain that validates the PKCS7 using the system store, which means that those at the root of the tree have been directly validated by the Windows Certificate Store.
As you can see, the risk factor is set to zero, since the validity of the publisher has been determined. This behavior can be changed from the Risk panel of the options: it is not on by default!
For comparison, the following screenshot shows how an invalid digital certificate is displayed:
In this case the hash is no longer what expected, issuing both a digest and an invalid certificate errors.
Countersignatures are of course supported and I think you’ll be pleased with how fast our implementation is.
Additional resources: