/

CERTCyberVulnérabilité

Vulnérabilité : CVE-2020-0601, dans le Crypto API de Windows (CRYPT32.DLL)

Une vulnérabilité de type usurpation d’identité (spoofing) a été découverte dans la façon dont la bibliothèque cryptographique de Windows (crypt32.dll) valide les certificats composés de courbes elliptiques (ECC).
Une exploitation réussie de cette faille pourrait mener à des attaques de « l’homme du milieu » (MitM) ou encore déchiffrer des données confidentielles. Seuls Windows 10, Windows Server 16 et 19 sont concernés par cette vulnérabilité.

Exécution d’un cheval de Troie signé avec un exploit de la CVE-2020-0601

 

Bulletin de sécurité TEHTRIS

Un attaquant pourrait notamment exploiter cette vulnérabilité en signant un code malveillant et en le faisant apparaître comme provenant d’une source légitime. L’utilisateur n’aurait alors aucun moyen de savoir que le fichier était en fait malveillant car la signature numérique apparaîtrait comme provenant d’une autorité de certification reconnue.

Tout logiciel dépendant de la fonction CertGetCertificateChain() de cette librairie pour s’assurer que le certificat est d’autorité reconnue pourrait alors être incapable de le faire correctement et ainsi être trompé dans la détermination de l’authenticité de cette chaîne de certification.

La bibliothèque concernée par cette faille (crypt32.dll) a été introduit par Microsoft il y a une vingtaine d’années (sous Windows NT 4.0). Toutefois, les anciennes versions de Windows ne sont pas concernées car elles rejettent nativement des courbes elliptiques dotées de paramètres.

Systèmes affectés

  • Windows 10
  • Windows Server 2016 and 2019

Remédiations / Mises à jour

Afin de remédier à la CVE-2020-0601, Il est nécessaire de mettre à jour votre système d’exploitation avec les derniers patchs de sécurité disponibles sur le site de Microsoft.

Pour ce faire, il est conseillé de forcer la mise à jour en écrivant « mise à jour » dans la barre de recherche et en sélectionnant « rechercher des nouvelles mises à jour ». Le système va alors automatiquement procéder à la recherche des dernières mises à jour et les effectuer si nécessaire.

Recommandations et réponse de TEHTRIS

Détection de l’attaque avec le TEHTRIS EDR

TEHTRIS EDR intègre désormais une nouvelle capacité afin de détecter les tentatives d’exploitation de la vulnérabilité CVE-2020-0601 via une analyse poussée des signatures des logiciels et une validation cryptographique sophistiquée pour comprendre qu’un binaire a été construit pour abuser de la faille en question.

Au moment de l’écriture de ces lignes, il s’agit du tout premier EDR (Endpoint Detection and Response) dans le monde avec une telle option puisqu’elle offre la possibilité de trouver l’attaque sur des machines Windows qui n’ont pas encore été mises à jour, avec l’ancienne version de CRYPT32.DLL vulnérables.

Cette fonctionnalité offre plusieurs possibilités aux utilisateurs de TEHTRIS EDR

    • Avoir une souplesse dans le calendrier des mises à jour de Windows, notamment sur les infrastructures ayant des contraintes particulières au niveau production.
    • Avoir la capacité de détecter les tentatives d’attaques grâce à une centralisation simple et une visibilité des logs au niveau de la console unifiée de la TEHTRIS XDR Platform
    • Avoir la possibilité d’effectuer des sessions de hunting et de forensics grâce aux outils associés de la TEHTRIS XDR Platform. Un responsable sécurité voudra lancer une autopsie d’une machine essayant une attaque CVE-2020-0601 car il s’agit d’une preuve comme quoi un intrus a réussi à obtenir un premier niveau d’accès.

 

Figure 0

Identification des postes vulnérables

Le produit TEHTRIS EDR possède un module de recherche de vulnérabilités. Il peut ainsi identifier les postes vulnérables à cette faille (Figure 1). Les équipes de cybersécurité peuvent ainsi suivre le déploiement des mises à jour et identifier les zones à risque en terme de politique de Patch Management.

 

Figure 1

Génération et récupération des journaux d’évènements Windows

Devant l’importance de l’impact de la faille CVE-2020-0601, Microsoft a développé un patch qui va générer une entrée dans le journal d’évènements afin d’offre la possibilité de détecter une exploitation de cette vulnérabilité. Ces nouveaux journaux d’évènements Windows font partie d’un catalogue nommé « Microsoft-Windows-Audit-CVE ou Audit-CVE ». Sur un Windows non mis à jour, l’attaque ne sera pas détectée.

Malheureusement, sur des systèmes Windows non patchés, l’attaque ne pourra pas être détectée par Windows (mais TEHTRIS EDR peut le faire pour vous).
Dès la sortie des annonces de la part de Microsoft, une action rapide a été mise en place par TEHTRIS afin de récupérer ces journaux d’événements Windows et de les intégrer au module SIEM tactique intégré dans TEHTRIS EDR, pour les serveurs et les postes de travail. (Figure 2).

Figure 2

L’équipe de Recherche et Développement de TEHTRIS a analysé la nouvelle version de la librairie crypt32.dll afin de comprendre comment étaient générés les nouveaux messages d’erreurs. L’idée était de comprendre ce fonctionnement pour générer rapidement un log de ce type.

Debug et reverse sur la nouvelle dll

Dans le cadre de notre recherche de compatibilité, la décompilation de la DLL a permis de suivre le flot d’exécution pas à pas grâce à des outils comme WinDbg ou encore un outil de reverse engineering (dans ce cas Ghidra) accompagné des symboles de debug (i.e. crypt32.pdb).

Les résultats obtenus à l’aide de WinDbg (Figure 3) permettent d’identifier la fonction responsable de la génération de ces messages d’erreurs : « ChainLogMSRC54294Error».

 

Figure 3

L’étape suivante nous amène à identifier la façon dont les tests de certificats redirigent vers cette fonction.

Dans l’outil de reverse Engineering (Ghidra), on observe que la sortie de CryptVerifyCertificateSignatureEx donne sur un test JNZ (Jump Not Zero) (Figure 4).

 

Figure 4

On souhaite alors éviter ce saut incontrôlé pour aller directement vers le bloc de la fonction recherchée. Deux solutions s’offrent à nous :

– Modifier l’instruction JNZ (qui est sur 2 octets) en JMP (jump) vers l’adresse suivante et donc faire un jmp de 0 ou,

– Transformer l’instruction JNZ en deux opérations NOP (instruction qui indique de ne rien faire sur 1 octet) ce qui nous permet d’arriver à l’adresse suivante.

TEHTRIS R&D a alors décidé d’expérimenter la première solution. Réalisée à l’aide d’un éditeur hexadécimal (ex: HxD) à la bonne adresse, elle retourne le résultat suivant : Figure 5.

 

Figure 5

Pour conclure, cette modification permet donc une identification rapide des évènements d’erreurs générés si la DLL modifiée est chargée par Windows ou si la modification est faite à la volée dans un debugger.

Cyberthreat Intelligence

Afin de pouvoir simuler les attaques, de premières tentatives d’utilisation de la faille (signer un binaire de manière malveillante), ont été réalisées. La question est de savoir ce qu’il se passerait si un tel binaire était vu sur un parc protégé par TEHTRIS EDR…

Prenons l’exemple d’un ransomware signé avec un certificat Windows : d6ab910259c9bc68196aeec3e9ff4864bada22738c02ecf5ada7912ced292d28.

La signature est considérée comme valide par une machine Windows non patchée. (Figure 6)

 

Figure 6

Les outils d’analyse TEHTRIS analysent ce binaire de la même façon qu’un binaire non signé.

Dans ce cas, le résultat de l’analyse indique qu’il s’agit d’un ransomware, détection à 100% pour le score SandBox (Figure 7) et par 21 antivirus sur la base VirusTotal. (Le score VirusTotal est bien inférieur à l’heure actuelle du même binaire non signé).

 

Figure 7

TEHTRIS EDR ne se base pas que sur les signatures pour prendre des décisions. Donc les remédiations appliquées sur les résultats de la TEHTRIS CTI (Cyber Threat Intelligence) resteront identiques même avec un binaire qui abuse de la vulnérabilité CVE-2020-0601.

Règles Snort & Yara​

L’idée est de détecter, dans les données des certificats, celles qui semblent suspectes en identifiant des patterns malveillants. Pour cela, il existe au moins deux possibilités soit au niveau des flux réseau avec des règles SNORT soit au niveau des binaires avec des règles YARA.
L’équipe TEHTRIS R&D s’est concentrée sur la création de règles YARA grâce à l’utilisation des données de la base de la CTI.

La vulnérabilité exploite le fait que l’on puisse définir ses propres paramètres pour les courbes elliptiques. Le but de l’équipe TEHTRIS R&D est de rechercher les certificats qui les utilisent ($ecc), mais qui ne renseignent pas de manière explicite le type de courbes elliptiques utilisé ($p256, $p384, p$521).

Pour cela, on va rechercher en particulier des OID (object identifier) d’objets présents dans les certificats (au format ASN1, encodage DER).

– Par exemple, l’OID suivant indique qu’un certificat utilise les courbes elliptiques :

Pour cela, on va rechercher en particulier des OID (object identifier) d’objets présents dans les certificats (au format ASN1, encodage DER).

– Par exemple, l’OID suivant indique qu’un certificat utilise les courbes elliptiques :

– Si le certificat utilise les ECC et le type de courbe est nommé explicitement (P-384…) alors il est marqué comme SAFE
– Si le certificat utilise les ECC, mais que le type de courbe n’est PAS nommé (i.e. des paramètres customs sont utilisés), alors il est marqué comme UNSAFE

L’équipe TEHTRIS R&D a alors traduit ces caractéristiques en règle YARA suivante :

Attention, les règles YARA peuvent entraîner un certain nombre de détections qui ne s’avèrent pas exactes. Toutes détections liées aux règles YARA doivent être analysées, notamment à cause des aspects distances entre les strings précédentes.

De nombreuses règles de détection SNORT sont disponibles sur Internet. Nous attirons l’attention sur le fait qu’elles ne fonctionnent pas et que des pirates pourraient facilement les contourner, car elles ne ciblent que certains aspects au niveau cryptographique et uniquement un constructeur particulier (Microsoft). A la rédaction de cet article, il n’y a aucune détection générique fiable vue sur Internet pour les NIDS, et nous recommandons l’usage de sondes systèmes plutôt que des sondes réseaux.

Conclusion

Nous avons présenté rapidement plusieurs éléments techniques et nous souhaitons laisser en conclusion un tableau comparatif de la détection de la CVE-2020-0601.

Références