What is Microsoft Authenticode?
Authenticode is a security measure for windows executable files and catalog files. It can be used to assure the trust of the source and that the files were not tampered with. It relies on the following technologies: Public Key Cryptography Standards (PKCS) #7 (encrypted key specification), PKCS #10 (certificate request formats), X.509 (certificate specification), Secure Hash Algorithm (SHA), and MD5 hash algorithms.
How does it work?
As you can see in the picture below, Authenticode basically adds a digital certificate at the end of the file. The values in gray (Checksum and the Certificate Table offset in the Data Directories header) are not taken into account to create the Authenticode signature. So for example, you can change the checksum value of the file and the digital signature will still be valid.
Circumventing Authenticode
Remember the last article about why you shouldn’t use MD5 for your hashing purposes? If you do, you should also understand why it is not a good idea to use it for code signing. It is possible to generate a malware file that has the same MD5 as a clean one: If the clean, digitally signed program uses MD5 hashing for code signing and the malware author uses the Collision Attack or the more expensive Chosen Prefix Collision method, he would be able to create a malware file whose MD5 is the same as the genuine one. With this in place, the malware author can simply copy and paste the signature from the genuine program to the malware and the malware will have a valid signature from the original vendor.
You can see a proof of concept on this web site:
https://blog.didierstevens.com/2009/01/17/playing-with-authenticode-and-md5-collisions/
Assuming that you will not use MD5 to sign the code of your programs, there are some other ways to add or change data in a signed file without breaking the validation. And there are some honest circumstances in which a genuine vendor will even want to slightly modify the binary executable without changing the digital certificate. You might be wondering what circumstances these can be. Let’s look at an example: A vendor who provides customized installers to their clients; the binary executable for the installer is the same for all the clients but the vendor might also want it to contain some custom information like the username of the client or something else. The vendor could digitally sign each installer for each client, but if that vendor has thousands of downloads every day, signing them all would be a very time-consuming, computationally expensive task.
There are currently two known techniques to add data to a digitally signed binary without invalidating the certificate:
- Certificate Structure Padding
- Invalidated Attributes
Certificate Structure Padding means adding the data just after the PKCS#7 part of the Attribute Certificate Table. Usually, the PCKS#7 data is actually less than the size specified to contain it (defined in a WIN_CERTIFICATE structure), so usually the remaining space is filled with zero bytes. This little space can be used to save some extra data instead of zero bytes, and the signature will still remain valid.
The Invalidated Attributes technique: Digital certificates contain several Object IDs (OIDs) used to identify the data contained in the certificate. For example, to get the signing time of a signature, you can locate the object with the ID = “1.2.840.113549.1.9.5” as it corresponds to the szOID_RSA_signingTime object, which contains the requested data. It’s designed in such a way that in the future, there can be new objects with new OIDs so you can leverage this to create new nonstandard OIDs to hold the data you want. One just needs to initialize it with zero bytes and afterwards inject the custom data for each client and the signature will also remain valid.
None of these two approaches should actually be used for several reasons and maybe they will also cease to work in the future. If you do use either of them however, you should be very cautious with the data you store in these areas. There was a case of a developer who used the Certificate Structure Padding technique to store different URLs to download and install his software. Malware leveraged it to change the URLs to download and install malware, all the while maintaining the validity of the original publisher certificate!
Currently as stated in MS13-098, you can disable the validation for the signatures with certificate padding by simply changing a registry entry … maybe in the future this will be a default.
For science!
