WinVerifyTrust to check for a specific signature?

I'm implementing a process elevation helper for Windows. It's a program that will run in elevated mode and launch other programs with administrator privileges without displaying additional UAC prompts. For security reasons, I want to make sure only binaries that are digitally signed with my company's Authenticode key can be executed.

The WinVerifyTrust function gets me halfway there, but it only ensures that a binary is signed by some key that is part of Microsoft's chain of trust. Is there a relatively simple way to perform the Authenticode verification AND ensure that it is signed by our private key?

I believe what you're looking for is CryptQueryObject.

With it you should be able to pull the involved certificate out of a PE, and do any additional checks you want.

By way of example, this will get you to a HCRYPTMSG. From there you can use CryptMsgGetParam to pull out whatever you want. I'd hoped to make something more 'robust', but these APIs are pretty hairy insomuch as they require a lot of branching to handle all their return cases.

So, here's a p/invoke-rific c# example (I started in C, but that was basically unreadable):

static class Crypt32
{
    //Omitting flag constants; you can look these up in WinCrypt.h

    [DllImport("CRYPT32.DLL", EntryPoint = "CryptQueryObject", CharSet = CharSet.Auto, SetLastError = true)]
    public static extern bool CryptQueryObject(
        int dwObjectType,
        IntPtr pvObject,
        int dwExpectedContentTypeFlags,
        int dwExpectedFormatTypeFlags,
        int dwFlags,
        out int pdwMsgAndCertEncodingType,
        out int pdwContentType,
        out int pdwFormatType,
        ref IntPtr phCertStore,
        ref IntPtr phMsg,
        ref IntPtr ppvContext);
}

class Program
{
    static void Main(string[] args)
    {
        //Path to executable here
        //  I tested with MS-Office .exe's
        string path = "";

        int contentType;
        int formatType;
        int ignored;
        IntPtr context = IntPtr.Zero;
        IntPtr pIgnored = IntPtr.Zero;

        IntPtr cryptMsg = IntPtr.Zero;

        if (!Crypt32.CryptQueryObject(
            Crypt32.CERT_QUERY_OBJECT_FILE,
            Marshal.StringToHGlobalUni(path),
            Crypt32.CERT_QUERY_CONTENT_FLAG_ALL,
            Crypt32.CERT_QUERY_FORMAT_FLAG_ALL,
            0,
            out ignored,
            out contentType,
            out formatType,
            ref pIgnored,
            ref cryptMsg,
            ref context))
        {
            int error = Marshal.GetLastWin32Error();

            Console.WriteLine((new Win32Exception(error)).Message);

            return;
        }

        //expecting '10'; CERT_QUERY_CONTENT_PKCS7_SIGNED_EMBED
        Console.WriteLine("Context Type: " + contentType);

        //Which implies this is set
        Console.WriteLine("Crypt Msg: " + cryptMsg.ToInt32());

        return;
    }

To get the certificate information from signed code use this:

using System.Security.Cryptography.X509Certificates;
X509Certificate basicSigner = X509Certificate.CreateFromSignedFile(filename);
X509Certificate2 cert = new X509Certificate2(basicSigner);

Then you can get the cert details like this:

Console.WriteLine(cert.IssuerName.Name);
Console.WriteLine(cert.SubjectName.Name);
// etc

these are some of the nastiest APIs I've ever worked with

A word of warning: it's worse than you already thought.

At least since introducing SHA-256 signing (has this always been the case?), it's possible for Authenticode to have multiple signatures. They're not encoded as multiple signatures in the PKCS-7 signature message; instead, they're unauthenticated message attributes of type OID_NESTED_SIGNATURE, each containing another complete PKCS-7 signature message.

WinVerifyTrust will tell you the file is valid if any of the signatures are valid and come from a trusted certificate chain. However it won't tell you which of the signatures was valid. If you then use CryptQueryObject to read the full PKCS-7 message, and only look at the certificate for the primary signature (as in the code samples here and on MSDN), you're not necessarily looking at a verified certificate. The associated signature might not match the executable, and/or the certificate might not have a trusted CA chain.

If you're using the details of the primary signature to validate that the certificate is one your software trusts, you're vulnerable to a situation where WinVerifyTrust is trusting a secondary signature, but your code is checking the primary signature's certificate is what you expected, and you haven't noticed that the signature from the primary certificate is nonsense. An attacker could use your public certificate without owning its private key, combined with some other code-signing certificate issued to someone else, to bypass a publisher check this way.

From Win8 onwards, WinVerifyTrust can optionally validate specific signatures, so you should be able to iterate the signatures to find one that is valid and one that satisfies your requirements.

If you have to be Win7-compatible, though, as far as I know the best you can manage is MsiGetFileSignatureInformation. From experimentation (as for everything else here, the actual documentation is frustratingly woolly), it seems to return the trusted certificate when WinVerifyTrust trusts one. But if there isn't a trusted signature, it returns the primary signature's certificate anyway, so you still have to use WinVerifyTrust to check that first.

Of course there also plenty of possible time-of-check/time-of-use problems here.