Lors de l’exécution d’un exécutable en provenance d’Internet, tout le monde a déjà été confronté à ce genre d’avertissements:
Ces fichiers binaires ne sont pas signés numériquement et, en conséquence, Windows affiche un avertissement concernant les potentiels risques de sécurité que l’utilisateur encourt en les exécutants. Mais, quelle est la réelle signification de cela ?
Signature de Code et Signature Numérique
Une signature numérique peut être insérée dans n’importe quel fichier exécutable (.exe, .msi, etc.), librairie (.dll) ou pilote (.sys) de manière à vérifier leur authenticité et intégrité.
Cette signature comprend un certificat numérique contenant de nombreuses informations telles que l’éditeur du logiciel, la date à laquelle le fichier a été signé, la durée de validité de la signature et bien d’autres.
Un certificat de signature de code peut être obtenu via une Autorité de Certification (AC) telle que Verisign pour environ deux cents dollars par an. Du point de vue de l’AC, octroyer un certificat signifie qu’elle accorde sa confiance à l’éditeur du logiciel et, par extension, que les fichiers signifiés par le certificat sont de confiance.
Les fichiers binaires non signés ne sont pas forcément malicieux, mais l’absence de signature numérique signifie que l’intégrité du fichier ne peut pas être garantie et que, par conséquent, il est possible qu’il ait été altéré de façon malicieuse ou distribué par un éditeur illégitime.
Comme nous l’avons vu ci-dessus, la confiance est le coeur de la signature de code. Les Autorités de Certification doivent être certaines de ne pas octroyer de certificats de signature de code à des concepteurs de malware. Ainsi, avant tout octroi, une vérification des antécédents du demandeur est effectuée de manière à vérifier la légitimité de la demande.
Les certificats de signature de code existent sous deux formes : Standard et Extended Validation (EV). Les certificats EV présentent un bien plus haut niveau de crédibilité et nécessitent des vérifications importantes pour être octroyés. Ils sont également bien plus onéreux et ne peuvent pas être partagés sur plusieurs ordinateurs.
Exemple
Examinons un logiciel contenant une signature numérique. Dans cet exemple, nous nous focaliserons sur Adlice PEViewer Portable x64 (RogueKillerPE64.exe). A l’exécution, l’avertissement est différent :
L’éditeur du logiciel est reconnu en tant que «Adlice » et, si vous cliquez sur le lien, le certificat numérique confirmant la validité de la signature est affiché.
En utilisant l’utilitaire Microsoft SignTool, il est possible d’obtenir des informations supplémentaires sur la chaine de confiance:
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
En lisant de bas en haut, nous pouvons affirmer que l’Editeur du logiciel est, comme nous l’avons vu au-dessus, « Adlice » and que le certificat a été octroyé par l’AC DigiCert en utilisant le certificat « DigiCert SHA2 Assured ID Code Signing CA » qui à été lui-même généré à partir du certificat « DigiCert Assured ID Root CA ».
Le certificat numérique contient également le hash du fichier (SHA1 hash). Le contenu de ce champ est utilisé pour déterminer si le fichier a été altéré en le comparant avec le hash du fichier courant. Si les valeurs des deux hashes ne sont pas équivalentes, le système détecte l’altération, invalidant la signature et affichant un avertissement :
Malware et Signature de Code
Depuis plusieurs années, Microsoft encourage fortement les développeurs à signer numériquement leurs produits. Avec l’arrivée de Windows Vista et la propagation des rootkits Windows, les drivers noyau ne peuvent être chargés que s’ils sont signés.
Peux-ton ainsi faire aveuglément confiance aux fichiers numériquement signés ? La réponse est non. Il existe des malware qui ont été numériquement signés. Par exemple, cet échantillon de Ransomware Razy est signé par un certificat octroyé par l’Autorité de Certification Comodo.
Les Autorités de Certification peuvent être abusées par des requêtes spécialement conçues pour passer les vérifications, mais le plus souvent, les malware numériquement signés utilisent des certificats volés à des développeurs ou des organisations.
Le vol de certificats est bien sûr préjudiciable aux utilisateurs qui pourraient être infectés en faisant confiance à un exécutable auquel ils n’auraient pas dû, mais également à l’organisation victime du vol, en raison du coût administratif et de la mauvaise réputation.
Les certificats de signature de code doivent être protégés par mot de passe et stocké à un emplacement sûr.
Changements de politique
Changement dans la politique de Signature de Code dans Windows 10 Anniversary Edition (1607) et son implication sur les outils Adlice. Avec la sortie de Windows 10 version 1607, Microsoft impose à présent que les drivers noyaux soient signés avec des certificats EV.
Comme nous l’avons vu plus haut, les certificats EV sont davantage sécurisés car les prérequis pour les obtenir sont importants et la probabilité qu’ils soient volés est pratiquement nulle étant donné qu’ils sont liés au matériel (HSM). Cependant, leurs prix est un inconvénient majeur pour les développeurs indépendants et les petites sociétés. Adlice Software est dans cette situation.
Depuis 2014, RogueKiller utilise du code noyau pour détecter efficacement les rootkits. Etant donné que nous n’utilisons pas de certificat EV, le chargement du driver noyau de RogueKiller peut échouer sur les versions de Windows 10 1607 et supérieures. L’outil continuera de fonctionner, mais ses capacités seront réduites.
Si vous vous trouvez dans ce cas de figure et désirez que le driver se charge, il est nécessaire de désactiver Secure Boot.
Conclusion
La signature de code est une approche très prometteuse pour protéger les utilisateurs des contenus malveillants, pour authentifier l’éditeur d’un exécutable et pour protéger un fichier contre des modifications non-désirées.
Pour le moment, une signature numérique ne signifie pas forcément qu’un fichier est sûr. Si, dans le futur les certificats EV devenaient abordables et plus facile à obtenir, il se pourrait que cela devienne une vérité.
