Tag: pkcs7

CAB & Certificates SDK Documentation

Having already completed the SDK documentation of our core modules, we have started documenting our file format modules and just finished the first two.

Namely, we have documented the API for parsing Microsoft Cabinet files.

And we have documented our comprehensive API for parsing certificate files in both DER and PEM encodings.

We’ll continue documenting our file format modules in the upcoming months.

Certificates Support

In the upcoming 5.5 version of Cerbero Suite and the 2.5 version of Cerbero Engine we support certificate formats. While Cerbero Suite already lets you inspect certificates inside binaries, now it can load them directly from disk and also lets you inspect each individual ASN1 object.

Both DER and PEM encodings for certificates are supported.

You can inspect all types of certificates, including X509, PKCS7 and PKCS12.

We have also exposed the code to our Python SDK in order to make the programmatic parsing of certificates a simple task.

For example, enumerating every ASN1 object in a certificate takes just a few lines of code:

from Pro.Core import *
from Pro.Certificates import *

def main():
    obj = proCoreContext().currentScanProvider().getObject()
    class Visitor(DERObjectVisitor):
        def Visit(self, obj, oi):
            print(oi.offset, oi.content_size)
            return 0
    v = Visitor()
    obj.VisitObjects(v)

main()

We’ll be fully documenting the Pro.Certificates module this year.

Microsoft Authenticode

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:

  1. When kernel-mode drivers are loaded
  2. 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.
  3. When an application requires admin privileges.

Point two is a weak security measure for the following reasons:

  1. 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.
  2. 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)
  3. 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.

Windows certificate dialog

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.

Microsoft Authenticode – A valid digital signature

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:

Microsoft Authenticode – An invalid digital signature

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:

  1. Windows NTFS Alternate Data Streams, from Symantec
  2. Mark of the Web, from MSDN