Jouer à Cacher

Nov 03, 2023

21 octobre 2022

Dans la partie 1, nous avons expliqué ce que sont les enclaves Intel SGX et comment elles profitent aux auteurs de ransomwares. Dans la partie 2, nous explorons une mise en œuvre hypothétique étape par étape et décrivons les limites de cette méthode.

Regardez cette démonstration d'attaque en direct pour voir comment la plateforme CrowdStrike Falcon® et l'équipe de détection et de réponse gérée CrowdStrike Falcon Complete™ protègent contre les ransomwares.

Dans cette section, nous construisons un exemple étape par étape d'un ransomware qui utilise des enclaves pour le chiffrement asymétrique. Le ransomware est divisé en deux parties :

Les extraits de code présentés ici proviendront du noyau normal de l'application (main.c) ou de l'enclave (enclave.c). L'enclave générera une paire de clés RSA, scellera la clé privée et chiffrera les données de la victime à l'intérieur de l'enclave à l'aide de l'API Intel SGX. Voyons comment cela se fait et comment le cœur de l'application interagit avec l'enclave.

Tout d'abord, le noyau régulier de l'application initialise les ressources nécessaires à l'exécution du rançongiciel, y compris la création et la configuration de l'enclave. Pour charger l'enclave, on utilise la fonction sgx_create_enclave(), de sgx_urts.lib.1 Le prototype de la fonction est :

Les arguments de cette fonction représentent certains des attributs de l'enclave, tels que le mode de compilation ou des informations sur les chargements précédents. Par exemple, sgx_launch_token_t est une structure opaque qui représente le jeton de lancement de l'enclave. Les informations de jeton contiennent des informations sur l'enclave tout au long de son exécution et peuvent être enregistrées pour faciliter les chargements futurs de l'enclave.

Figure 1. Extrait du code créant l'enclave (Cliquez pour agrandir)

Une fois l'enclave chargée, le noyau normal de l'application peut exécuter un ECALL pour démarrer le processus de génération de clé.

À l'intérieur de l'enclave, la génération de clé est basée sur le SDK Intel SGX appelé sgx_tcrypto.lib. Il s'agit d'une API documentée qui peut être appelée directement depuis l'enclave. Sous le capot, l'API est basée sur d'autres bibliothèques cryptographiques développées par Intel : les Integrated Performance Primitives (Intel® IPP) et la bibliothèque cryptographique Intel® Software Guard Extensions SSL (Intel® SGX SSL),2 toutes deux basées sur OpenSSL .

La première étape de ce processus consiste à générer des composants RSA pour les clés privées et publiques à partir de l'enclave à l'aide de la fonction sgx_create_rsa_key_pair(). Il s'agit d'un appel préliminaire, effectué avant les appels de fonction qui créent des clés, utilisé afin de générer des composants conformes à la taille de module de clé RSA et à l'exposant public prédéfinis.

Figure 2. Extrait de code générant les composants des clés RSA (Cliquez pour agrandir)

A partir de ces composants de clé RSA, nous utilisons la fonction sgx_create_rsa_pub1_key() pour générer la clé publique RSA qui sera utilisée pour chiffrer les fichiers de la victime.

Figure 3. Extrait de code créant la clé publique RSA (Cliquez pour agrandir)

La prochaine étape logique serait généralement de générer la clé privée, comme nous l'avons fait avec la clé publique. Dans ce cas, cependant, nous n'avons pas encore besoin de la clé privée, car la clé privée ne sera utilisée qu'à des fins de déchiffrement, si la victime se conforme aux exigences des auteurs du rançongiciel. Pour le moment, nous avons juste besoin de stocker et de masquer en toute sécurité les composants de la clé privée pour permettre une récupération future. À cette fin, nous utilisons la méthode de scellement des données pour nous assurer que la clé privée peut être écrite et stockée chiffrée sur le disque, sans jamais apparaître en texte clair dans la mémoire régulière du système d'exploitation.

Une façon de procéder consiste à générer la clé privée, puis à la sceller directement sur le disque, mais nous ne procéderons pas de cette manière. Considérez le prototype de fonction du SDK3 Intel SGX qui génère la clé privée illustrée ci-dessous.

Notez que la valeur de la clé privée est écrite sur un vide ** mais sous le capot, la structure réelle utilisée est une structure EVP_PKEY, une structure complexe qui provient de la bibliothèque OpenSSL.

Figure 4. Extrait de code définissant la structure EVP_PKEY, de la bibliothèque openssl (Cliquez pour agrandir)

Par conséquent, si nous voulions sceller la clé privée, nous aurions besoin d'utiliser la structure EVP_PKEY. Néanmoins, l'architecture de développement d'enclave n'est pas conçue pour importer facilement des bibliothèques externes, donc l'utilisation directe de la bibliothèque Open SSL serait fastidieuse. Sinon, nous pourrions tenter de recréer la structure à partir de zéro, mais cela nécessiterait plusieurs opérations d'analyse. Compte tenu de la complexité du stockage de la clé privée dans la structure appropriée, il est beaucoup plus facile de sauvegarder les composants de la clé privée et de créer la clé privée ultérieurement. Pour soutenir ce processus, nous avons créé une structure pour collecter les composants de la clé privée.

Figure 5. Extrait de code définissant la structure PrivateKey (Cliquez pour agrandir)

Nous avons maintenant les moyens de sceller les composants de la clé privée pour un futur déchiffrement potentiel. Nous utiliserons les mêmes valeurs produites lorsque nous avons généré les composants clés et les affecterons aux champs appropriés dans notre structure PrivKeyComp personnalisée. Une fois la structure correctement configurée, nous pouvons sceller les composants de la clé privée avec sgx_seal_data_ex(), à partir de sgx_tservice.lib.4

Figure 6. Extrait du code scellant les composants de la clé privée RSA (Cliquez pour agrandir)

Ici, nous utilisons sgx_seal_data_ex(), la version étendue de sgx_seal_data(), qui nous permet d'utiliser la politique MRENCLAVE. Nous avons choisi cette politique car elle garantit que les autres enclaves signées par les auteurs de la même enclave ne pourront pas accéder aux données scellées. Si la signature de l'enclave de l'attaquant était volée, elle pourrait être utilisée pour desceller les données.

Une fois scellés, les composants de la clé privée peuvent être renvoyés au cœur normal de l'application et écrits sur le disque.

À partir de ce point, nous avons deux options pour chiffrer les données de la victime. La première option consiste à renvoyer la clé publique au cœur normal de l'application et à chiffrer les fichiers de la victime en dehors de l'enclave. L'autre option consiste à conserver la clé publique à l'intérieur de l'enclave et à utiliser les fonctions de l'API Intel SGX pour chiffrer les données de la victime. Ce dernier est plus complexe qu'un processus de chiffrement classique en dehors de l'enclave, mais nous utiliserons cette méthode pour démontrer les possibilités de programmation SGX.

La partie non fiable de l'application est en charge de l'ouverture et de la lecture du dossier de la victime. Pour obtenir les données chiffrées qui seront générées dans l'enclave, nous devons initialiser le tampon de sortie dans le noyau normal de l'application. Sinon, le tampon généré dans la mémoire protégée ne pourra pas être envoyé vers l'espace non approuvé.

Le cryptage est effectué avec la fonction sgx_rsa_pub_encrypt_sha256(), qui exécute un schéma de cryptage RSA-OAEP avec SHA-256. Cela calcule une opération de cryptage et d'encodage pour les tampons, qui est limitée à la taille du module RSA n, et aboutit à un tampon de même longueur. Dans ce cas, étant donné un module RSA n de 256 octets, le tampon de sortie de sgx_rsa_pub_encrypt_sha256() aura une longueur de 256 octets.5 Ainsi, nous allouons un tampon de 256 octets pour le tampon de sortie qui contiendra les données chiffrées.

Ensuite, nous enverrons ce tampon de sortie avec le tampon contenant les données à chiffrer.

Figure 7. Extrait de code cryptant le contenu d'un fichier, du principal (Cliquez pour agrandir)

L'enclave reçoit les tampons et utilise la clé publique qui a été générée précédemment pour effectuer le chiffrement. Cela se fait en trois étapes. La première étape consiste à appeler sgx_rsa_pub_encrypt_sha256() pour obtenir la taille du tampon chiffré résultant. Une fois la taille retournée, nous vérifions qu'elle correspond à 256 octets (la taille que nous avons allouée au buffer de sortie). Si cela correspond, nous effectuons un deuxième appel à sgx_rsa_pub_encrypt_sha256() pour obtenir les données chiffrées dans le tampon de sortie.

Figure 8. Extrait de code cryptant le contenu d'un fichier, de l'enclave (Cliquez pour agrandir)

Enfin, le noyau régulier de l'application remplace le contenu du fichier d'origine par le contenu crypté, renvoyé par l'enclave.

La même logique s'applique au processus de déchiffrement. Les données scellées sont envoyées à l'enclave, qui les descelle avec sgx_unseal_data() et stocke les composants de la clé privée dans la variable globale PrivKeyComp. Les données chiffrées sont envoyées à l'enclave, construit la clé privée en utilisant la variable globale PrivKeyComp comme paramètres pour sgx_create_rsa_priv2_key(), puis déchiffre les données avec la fonction sgx_rsa_priv_decrypt_sha256(). Les données déchiffrées sont ensuite renvoyées au noyau normal de l'application, qui remplace les fichiers chiffrés par le texte clair d'origine.

Comme nous l'avons établi, l'utilisation d'enclaves présente des avantages considérables, tels que la garantie que les cibles des ransomwares ne pourront pas récupérer leurs clés de déchiffrement. Cependant, cette tactique présente également des limites considérables, ce qui explique sa prévalence limitée dans les attaques de ransomwares.

Premièrement, les enclaves ont des spécifications matérielles strictes. Étant donné que SGX est une technologie propriétaire, elle nécessite un processeur Intel. Bien qu'AMD dispose d'une technologie équivalente appelée ARM TrustZone, le code compilé à partir des bibliothèques Intel SGX ne fonctionnera pas sur les processeurs non Intel. De plus, seuls certains modèles de processeurs Intel prennent en charge SGX, car Intel a déconseillé la fonctionnalité pour les 11e et 12e générations de processeurs de bureau.6 Comme dernière exigence matérielle, la fonctionnalité Intel SGX doit être activée à partir du BIOS, ce qui n'est pas fait par défaut.

Compte tenu de toutes ces exigences, la probabilité qu'un système ciblé puisse exécuter un binaire à l'aide d'enclaves est très faible. De plus, comme l'utilisation de la technologie SGX peut ne pas être activée sur tous les systèmes infectés, les chances de réussir à infecter une cible sont considérablement faibles, en particulier par rapport aux méthodes de ransomware plus courantes.

Plus tôt dans ce blog, nous avons expliqué que les enclaves doivent suivre un processus de vérification pour être compilées en mode de publication. Néanmoins, une enclave compilée en mode débogage peut toujours être exécutée sur une machine compatible Intel SGX si les bibliothèques requises sont importées avec le binaire malveillant. La taille des binaires nécessaires à l'attaque serait bien plus grande que celle d'un binaire de ransomware classique, mais un tel scénario est plausible.

De plus, si les attaquants ont l'intention d'utiliser une enclave en mode de publication, ils peuvent ne pas être détectés par le processus de vérification d'Intel si l'enclave ne semble générer qu'une paire de clés RSA et recevoir des tampons pour chiffrer et sceller les données. Dans une telle situation, comment Intel déterminerait-il si l'enclave sert à des fins malveillantes ?

Des chercheurs de l'Université de technologie de Graz affirment qu'"Intel n'inspecte pas et ne signe pas les enclaves individuelles, mais place plutôt des clés de signature sur liste blanche à utiliser à la discrétion des développeurs d'enclaves pour signer des enclaves arbitraires."7 Ils citent l'exemple d'un étudiant indépendant qui a terminé avec succès le processus d'Intel pour obtenir une clé de signature. Cela soulève la question de savoir si les auteurs de logiciels malveillants pourraient utiliser des enclaves en passant par le processus de liste blanche d'Intel.

Une autre possibilité pour les auteurs de rançongiciels serait de voler une signature légitime. Cela ajoute un autre niveau de complexité à l'attaque, mais cela a été fait dans le passé. Dans ce cas, dès que l'attaque est détectée et signalée à Intel, Intel révoque la signature d'enclave utilisée de la liste blanche, empêchant le chargement de l'enclave malveillante. Que la signature soit volée ou acquise légitimement, le risque de découverte croît rapidement dès que la campagne de rançongiciel est lancée, posant la question de la durée de validité de la signature.

Pour offrir plus de flexibilité dans l'utilisation des enclaves, Intel a lancé en 2018 l'alternative de contrôle de lancement flexible.8 Cette fonctionnalité permet à des tiers de contrôler quelles enclaves peuvent être chargées sur des machines correctement configurées, en contournant le processus de vérification d'Intel. Il nécessite que les machines ciblées prennent en charge et activent la fonction de contrôle de lancement flexible, configurée dans le BIOS de chaque machine. Cette approche nécessite d'avoir accès au BIOS avant l'infection et de disposer des droits d'administrateur pour configurer l'environnement, ce qui ajoute de la complexité à l'attaque.

Au sein de l'enclave, le code est exécuté dans un contexte spécifique, ce qui entraîne une exécution plus lente que dans un environnement de système d'exploitation standard. Plus le ransomware met du temps à s'exécuter, plus l'utilisateur est susceptible d'être alerté d'une activité suspecte et d'avoir le temps d'y réagir, ce qui compromet davantage les chances de mener une attaque réussie.

Intel ne considère pas les attaques par canal latéral comme faisant partie du modèle de menace SGX. Le guide du développeur Intel® Software Guard Extensions9 indique : « Intel SGX ne fournit pas de protection explicite contre les attaques par canal latéral. Il incombe au développeur de l'enclave de résoudre les problèmes d'attaque par canal latéral.

Cela implique qu'il existe des moyens d'observer ce qui se passe à l'intérieur d'une enclave et donc potentiellement d'intercepter la clé de déchiffrement, soulignant en outre que l'utilisation d'enclaves est loin d'être infaillible et a été divulguée avec succès dans le passé, ce qui est discuté dans l'article « SGAxe : Comment SGX échoue dans la pratique."10

Il existe également des limites à la sécurité de la clé scellée écrite sur le disque.

Le guide du développeur d'Intel indique : "Les enclaves, quel que soit le nombre de threads de confiance définis, ne doivent pas être conçues en supposant que l'application non fiable invoquera les fonctions de l'interface ISV en suivant un ordre spécifique. Une fois l'enclave initialisée, un attaquant peut invoquer n'importe quel Fonction d'interface ISV, organisez les appels dans n'importe quel ordre et fournissez tous les paramètres d'entrée. Gardez ces stratagèmes à l'esprit pour éviter d'ouvrir une enclave aux attaques."11

Une question récente sur le forum de la communauté d'Intel a demandé si différentes applications utilisent la même enclave, à laquelle Intel a répondu : "Il n'existe aucun moyen intégré d'empêcher une application non fiable de charger l'enclave d'une autre". binaire utilisé dans une attaque de ransomware et la clé privée scellée, ils pourraient être en mesure de recréer une application qui interagit avec l'enclave pour lui faire desceller la clé privée, à tout le moins en mode débogage.

En pratique, la création d'une telle application nécessite l'importation du fichier enclave .edl, contenant la définition des ECALLs. Puisqu'il est peu probable que ce fichier soit importé dans les binaires de l'attaque, la seule option serait de reconstituer le fichier .edl, ce qui pourrait être encore plus compliqué si les attaquants obscurcissaient les binaires de l'enclave.

Dans un scénario où la clé privée a été scellée à l'aide de la politique MRSIGNER, la sécurité de la clé scellée est encore plus remise en question. Si les enquêteurs médico-légaux sont en mesure de récupérer la signature de l'auteur de l'enclave, ils pourraient recréer une enclave signée de la même manière avec le support d'Intel et faire en sorte que cette nouvelle enclave descelle les données. En effet, puisque les données ont été scellées à l'aide de la signature de l'auteur de l'enclave, une autre enclave portant la même signature pourrait les desceller.

Bien que chacune de ces limitations ajoute des contraintes à l'attaque, elles peuvent toutes être atténuées. L'activation de la fonction SGX peut être contournée en quelques étapes de pré-infection. Pour faciliter l'utilisation des enclaves, Intel a publié une application d'activation13 qui permet aux utilisateurs d'activer Intel SGX sur des plates-formes compatibles basées sur des processeurs Intel Core, simplement en cliquant sur le bouton "Activer", comme illustré à la Figure 9. L'application doit être exécuté avec des privilèges d'administrateur, mais une approche d'ingénierie sociale pourrait facilement inciter une victime à cliquer sur un bouton d'une application légitime.

Figure 9. Capture d'écran de l'application d'activation des extensions Intel® Software Guard (Cliquez pour agrandir)

Une fois que la fonctionnalité Intel SGX est activée sur le système ciblé, un attaquant peut contourner les exigences de signature en utilisant un binaire enclave compilé en mode débogage pour intégrer des dépendances dans l'attaque. Pour accélérer l'exécution de leur code, ils pourraient utiliser une implémentation multi-threading ou un processus de chiffrement externalisé au sein du noyau régulier de l'application. De plus, si le binaire de l'enclave est complètement supprimé du système infecté après l'attaque, l'attaquant peut être sûr que la clé privée scellée ne sera pas descellée tant qu'il ne l'aura pas autorisé. Enfin, il est très peu probable que des attaques par canaux auxiliaires soient mises en place avant l'infection, ce qui rend hautement improbable qu'elles réussissent à contrecarrer une attaque de ransomware utilisant des enclaves.

La technologie Intel SGX offre aux développeurs une opportunité unique de protéger leur code. Nous avons examiné comment l'architecture des enclaves fournit un environnement propice à la protection des données sensibles et intègre différents mécanismes pour les manipuler en toute sécurité, comme le scellement.

Bien que cela puisse être bénéfique dans les opérations quotidiennes, il peut également être exploité à des fins malveillantes, comme nous l'avons vu avec le cas de la gestion des clés cryptographiques par les auteurs de ransomwares. Les enclaves permettent aux auteurs de rançongiciels de générer en toute sécurité des clés cryptographiques, empêchant les victimes d'attaques de tirer parti de deux des scénarios les plus courants que les auteurs de rançongiciels veulent éviter : la récupération des clés de déchiffrement et la prévention de l'infection avec des cibles hors ligne.

La faible prévalence de l'utilisation des enclaves par les rançongiciels est largement due aux limitations techniques imposées par Intel SGX. Ses exigences matérielles et sa dépréciation pour les futures générations de processeurs réduisent les chances que les systèmes ciblés soient en mesure de répondre à toutes les conditions requises pour l'exécution de l'enclave. De plus, la libération d'une enclave en mode production nécessite de passer par le processus de signature d'Intel, qui, s'il est terminé avec succès, se traduit par une signature qui peut être rapidement révoquée du jour au lendemain, ce qui réduit encore les chances d'exécution réussie du ransomware.

Comme nous l'avons démontré, les auteurs de rançongiciels ne peuvent pas compter exclusivement sur les enclaves pour orchestrer les attaques, mais peuvent bénéficier de leur utilisation pour la gestion des clés cryptographiques. Comme il existe des utilisations légitimes des enclaves, une approche préventive de ces attaques de rançongiciels ne doit pas reposer exclusivement sur la détection de la charge d'une enclave.

Dans le cadre de notre engagement à permettre aux clients d'avoir une visibilité continue sur leur organisation, le capteur CrowdStrike Falcon a une visibilité sur l'utilisation des enclaves et utilise ces données avec la télémétrie des événements pour déterminer si un processus est malveillant et pour répondre aux menaces détectées. En fin de compte, une enclave n'est qu'un indice - rien de plus, rien de moins.

Voyez par vous-même comment la plateforme CrowdStrike Falcon, leader du secteur, protège contre les menaces modernes telles que les ransomwares. Commencez votre essai gratuit de 15 jours dès aujourd'hui.

Inscrivez-vous maintenant pour recevoir les dernières notifications et mises à jour de CrowdStrike.

Détectez, prévenez et répondez aux attaques, même aux intrusions sans logiciels malveillants, à tout moment, grâce à une protection des terminaux de nouvelle génération.