When executing software downloaded from Internet, everyone was at least once confronted with such security warnings:
These binaries are not digitally signed and as such, Windows issues a warning about potential security issues of running these. But what does that really mean?
Code Signing and Digital Signature
A digital signature can be inserted in any executable file (.exe, .msi, etc.), library (.dll), or driver (.sys) to verify their authenticity and integrity.
Such file will include a digital certificate which contains information about the software publisher, the date when the signing process took place, the time of validity and much more.
A code signing certificate can be obtained from a reliable Certificate Authority (CA) such as Verisign for about two hundred dollars a year. From the point of view of the CA, granting a certificate means that it trusts the software publisher and thus, the files signed with the certificate can be trusted as well (chain of trust).
On the other hand, unsigned binaries are not necessarily malicious but the absence of a digital signature means that the file integrity cannot be guaranteed and it may have been altered in a malicious way, or distributed by an untrusted publisher.
As we saw above, trust is the core of Code Signing. Certification Authorities have to make sure not to issue signing certificates to malware writers. For this purpose, they make a background check of the requester to check its legitimacy.
Code signing certificates exist in two different classes: Standard and Extended Validation (EV). EV signing certificates have a much higher level of credibility and require an extensive background check to be issued. They are also much more expensive and cannot be shared among computers.
Let’s examine a software containing a digital signature. For this example, we will focus on Adlice PEViewer Portable x64 (RogueKillerPE64.exe). At launch, the warning is different:
The Software Publisher is recognized as “Adlice” and, if you click on the link, the digital certificate with the confirmation of its validity is displayed.
Using Microsoft SignTool utility, we can obtain more information about the chain of trust:
Signature Index: 0 (Primary Signature)
Hash of file (sha1): E63D964581A42E57C6BF711BF89B4D25B8F902AB
Signing Certificate Chain:
Issued to: DigiCert Assured ID Root CA
Issued by: DigiCert Assured ID Root CA
Expires: Mon Nov 10 02:00:00 2031
SHA1 hash: 0563B8630D62D75ABBC8AB1E4BDFB5A899B24D43
Issued to: DigiCert SHA2 Assured ID Code Signing CA
Issued by: DigiCert Assured ID Root CA
Expires: Sun Oct 22 14:00:00 2028
SHA1 hash: 92C1588E85AF2201CE7915E8538B492F605B80C6
Issued to: Adlice
Issued by: DigiCert SHA2 Assured ID Code Signing CA
Expires: Thu Jun 28 14:00:00 2018
SHA1 hash: C8181FABBC35C7B433596F82CE687C6D453DB570
Reading bottom to top, we can state that the Software Publisher (as shown above) is “Adlice” and that that the certificate was issued by DigiCert CA using the “DigiCert SHA2 Assured ID Code Signing CA” certificate which was itself generated using the “DigiCert Assured ID Root CA” certificate, making a three entities long chain of trust.
The digital certificate also contains the checksum of the file (SHA1 hash). The content of this field is used to check the file for unauthorized modifications (integrity check) by comparison with the live file checksum. If both hashes are not equal, the system detects that the file has been altered, invalidating the signature and issuing a warning.
Malware and Code Signing
Since several years, Microsoft has strongly encouraged developers to digitally sign theirs products. With release of Windows Vista and spreading of Windows rootkits, kernel-mode drivers cannot be loaded if not signed.
So, can digitally signed files be blindly trusted? The answer is no. There are malware in the wild that are digitally signed. For example, this sample of Razy Ransomware is signed by a certificate issued by Comodo Certification Authority.
Certification Authorities can be abused with sophisticated crafted requests to pass background check but, most of the time, digitally-signed malware are using signing certificated that are stolen from developers and organisations.
Stolen certificates are detrimental to users who may be infected trusting an executable that should not be, but also to the organisation that was stolen, because of administrative cost and bad reputation.
Signing certificates must be password-protected and kept in a safe place.
Code Signing Policy changes
Code Signing Policy changes in Windows 10 Anniversary Edition (1607) and the implication on Adlice Tools. With the release of Windows 10 version 1607, Microsoft now requires kernel-mode drivers to be signed using EV certificates.
As we saw above, EV certificates are more secure because they need higher levels of requirement to be obtained and because the probability to be stolen is virtually null since they are tied to hardware devices (HSM). However, their high cost is an impediment to independent developers and small companies. We, at Adlice Software, are in this case.
Since 2014, RogueKiller makes use of kernel-mode code to effectively detect rootkits. Because we don’t use an EV signing certificate, RogueKiller kernel-mode driver may fail to load on Windows 10 version 1607 and higher. The tool will still run, but its capabilities will be weakened.
If you face this situation and want the driver to load, disabling Secure Boot is required.
Code signing is an invaluable approach to better protect users from malicious contents, to authenticate the publisher of an executable and to protect a file from unwanted modifications.
For the time being, a digital signature in a file does not mean it’s safe. In the future, if EV certificates become cheaper and more straightforward to obtain, we can make the assumption it could become true.