Qu’est que Microsoft Authenticode ?
Authenticode est une mesure de sécurité pour les fichiers exécutables et les fichiers catalogue Windows. Cette mesure permet de s’assurer de la fiabilité de la source et de vérifier que les fichiers n’ont pas été falsifiés. Authenticode repose sur les technologies suivantes : Public Key Cryptography Standards (PKCS) #7 (spécification de clé chiffrée), PKCS #10 (formats de demande de certificat), X.509 (spécification de certificat), les fonctions de hachage cryptographiques Secure Hash Algorithm (SHA) et les algorithmes de hachage MD5.
Comment ça marche ?
En gros, comme vous pouvez le voir dans l’image ci-dessous, Authenticode ajoute un certificat numérique à la fin du fichier. Les valeurs en gris, qui correspondent à la somme de contrôle (Checksum) et au décalage de la table des certificats (Certificate Table) dans l’en-tête des répertoires de données (Data Directories), ne sont pas prises en compte pour la création de la signature Authenticode. Ainsi, vous pouvez par exemple modifier la valeur de la somme de contrôle du fichier sans que cela n’invalide la signature numérique.
Contourner Authenticode
Vous souvenez-vous du dernier article expliquant pourquoi vous ne devriez pas utiliser l’algorithme MD5 comme fonction de hachage ? Si la réponse est oui, vous comprenez sans doute pourquoi ce n’est pas une bonne idée non plus de l’utiliser pour la signature de code. Il est possible de générer un fichier malveillant ayant le même algorithme MD5 qu’un fichier sain : si le programme sain, signé numériquement, utilise le hachage MD5 pour la signature de code et qu’un auteur de logiciels malveillants utilise l’attaque par collision ou la technique plus poussée de la collision à préfixe choisi, il peut alors créer un fichier malveillant avec le même algorithme MD5 que celui du fichier authentique. Une fois que cela est en place, l’auteur de logiciels malveillants peut simplement copier et coller la signature depuis le programme authentique vers le logiciel malveillant et ce dernier aura la signature valide du fournisseur d’origine.
Pour une illustration de ce concept, vous pouvez consulter le site Internet suivant :
https://blog.didierstevens.com/2009/01/17/playing-with-authenticode-and-md5-collisions/
Supposons que vous n’utilisiez pas l’algorithme MD5 pour signer le code de vos programmes, il existe encore d’autres moyens pour ajouter ou modifier des données dans un fichier signé sans en altérer la validité. Des circonstances honnêtes peuvent amener un fournisseur de bonne foi à vouloir modifier légèrement l’exécutable binaire sans modifier le certificat numérique. Vous vous demandez sans doute quelles sont ces circonstances. Prenons l’exemple d’un fournisseur qui propose des programmes d’installation personnalisés à ses clients. L’exécutable binaire pour le programme d’installation est le même pour tous les clients, mais le fournisseur souhaite qu’il contienne également des informations personnalisées comme le nom d’utilisateur du client ou d’autres détails. Le fournisseur pourrait signer numériquement chaque programme d’installation pour chaque client, mais s’il a des milliers de téléchargements par jour, les signer tous représenterait une tâche très longue et coûteuse en ressources informatiques.
Il existe actuellement deux techniques connues pour ajouter des données à un binaire signé numériquement sans invalider le certificat :
- le remplissage de structure de certificat
- les attributs invalidés
Le remplissage de structure de certificat revient à ajouter des données juste après la section PKCS#7 de la table des certificats d’attribut. En général, le volume des données PCKS#7 est inférieur à la taille requise pour le contenir (définie dans une structure WIN_CERTIFICATE) et l’espace restant est rempli avec des fichiers de zéro octet. Au lieu d’y stocker des fichiers vides, ce petit espace peut servir à enregistrer des données supplémentaires, et la signature demeure valide.
La technique des attributs invalidés : les certificats numériques contiennent plusieurs identificateurs d’objet (OID) utilisés pour identifier les données contenues dans le certificat. Par exemple, pour obtenir l’heure de la signature, vous pouvez localiser l’objet avec l’identificateur = « 1.2.840.113549.1.9.5 » car il correspond à l’objet szOID_RSA_signingTime qui contient les données demandées. Il est conçu de sorte à accepter de nouveaux objets avec de nouveaux identificateurs dans le futur et vous pouvez en tirer parti pour créer de nouveaux identificateurs non standard qui contiendront les données que vous souhaitez. Il suffit simplement de l’initialiser avec des fichiers de zéro octets puis d’injecter les données personnalisées pour chaque client. Là encore, la signature demeure également valide.
En réalité, aucune de ces approches ne devrait être utilisée pour plusieurs raisons. Peut-être même qu’elles cesseront de fonctionner dans le futur. Si vous utilisez toutefois l’une des deux, vous devez faire très attention aux données que vous stockez dans ces zones. Il nous a été rapporté le cas d’un développeur qui a utilisé la technique du remplissage de structure de certificat pour stocker différentes URL servant à télécharger et installer son logiciel. Un pirate en a profité pour modifier les URL dans le but de télécharger et installer un logiciel malveillant, tout en conservant la validité du certificat de l’éditeur d’origine.
Actuellement, comme cela est prescrit dans le bulletin de sécurité MS13-098, vous pouvez désactiver la validation pour les signatures avec remplissage de certificat en modifiant tout simplement une entrée de registre… Une manipulation qui deviendra peut-être un paramétrage par défaut dans le futur.
Pour la science !
