Comme vous le savez, le code exécuté dans l'enclave est sérieusement limité dans ses fonctionnalités. Il ne peut pas effectuer d'appels système. Il ne peut pas effectuer d'opérations d'E/S. Il ne connaît pas l'adresse de base du segment de code de l'application hôte. Il ne peut pas utiliser de jmp ni appeler le code de l'application hôte. Il n'a aucune idée de la structure de l'espace d'adressage qui régit l'application hôte (par exemple, quelles pages sont mappées ou quel type de données se trouvent sur ces pages). Il ne peut pas demander au système d'exploitation de lui mapper une partie de la mémoire de l'application hôte (par exemple, via /proc/pid/maps). Les tentatives naïves de lecture aveuglément d'une région de mémoire arbitraire d'une application hôte, sans parler des tentatives d'écriture, conduiront tôt ou tard (très probablement la première) à l'arrêt forcé du programme enclave. Cela se produit chaque fois que la région d’espace d’adressage virtuel demandée par l’enclave est inaccessible à l’application hôte.

Compte tenu de ces dures réalités, un auteur de virus sera-t-il capable d’utiliser les enclaves SGX pour atteindre ses objectifs malveillants ?

– Hack pour sonder les adresses pour voir si elles peuvent être lues
– Hack pour sonder les adresses pour l’écriture
– Hack pour rediriger le flux de contrôle
– Qu’est-ce que les trois hacks listés ci-dessus donnent au méchant ?
– Comment le méchant utilise ces hacks pour créer du ranzowari

Sur la base de tout ce qui précède, il est généralement admis qu'une enclave n'est capable que de servir l'application hôte et qu'elle ne peut pas exercer sa propre initiative, y compris malveillante. Cela signifie que les enclaves n’ont aucune valeur pratique pour les auteurs de virus. Cette hypothèse hâtive est l'une des raisons pour lesquelles la protection SGX est asymétrique : le code de l'application hôte ne peut pas accéder à la mémoire de l'enclave, tandis que le code de l'enclave peut lire et écrire sur n'importe quelle adresse mémoire de l'application hôte.

Par conséquent, si un code d'enclave malveillant était capable d'effectuer des appels système arbitraires au nom de l'application hôte, d'exécuter du code arbitraire en son nom, d'analyser la mémoire de l'application hôte et d'y trouver des chaînes ROP abusives, il pourrait prendre le contrôle total de l'application hôte, en mode furtif. Il peut non seulement voler et crypter les fichiers des utilisateurs, mais également agir au nom de l'utilisateur. Par exemple, envoyez des e-mails de phishing en son nom ou menez des attaques DoS. Sans craindre même les mécanismes de protection les plus modernes, tels que la pile de canaris et la désinfection des adresses.

Nous allons vous montrer quelques hacks que les attaquants utilisent pour surmonter les limitations décrites ci-dessus afin de tirer parti de SGX à leurs propres fins malveillantes : les attaques ROP. Soit pour exécuter du code arbitraire déguisé en processus d'application hôte (semblable au processus creux, qui est souvent utilisé par les logiciels malveillants), soit pour déguiser un logiciel malveillant prêt à l'emploi (pour sauver son logiciel malveillant de la persécution par les antivirus et autres mécanismes de défense).

Pirater pour sonder les adresses pour voir si elles peuvent être lues

Étant donné que l'enclave ne sait pas quelles plages de l'espace d'adressage virtuel sont accessibles à l'application hôte et que l'enclave est forcée de se terminer lorsqu'elle tente de lire une adresse inaccessible, l'attaquant est confronté à la tâche de trouver un moyen de détecter une erreur. analyser avec tolérance l’espace d’adressage. Trouvez un moyen de cartographier les adresses virtuelles disponibles. Le méchant résout ce problème en utilisant à mauvais escient la technologie TSX d'Intel. Utilise l'un des effets secondaires de TSX : si la fonction d'accès à la mémoire est placée dans une transaction TSX, alors les exceptions résultant de l'accès à des adresses invalides sont supprimées par TSX sans atteindre le système d'exploitation. Si une tentative est faite pour accéder à une adresse mémoire invalide, seule la transaction en cours est abandonnée, et non l'intégralité du programme de l'enclave. Que. La TSX permet à une enclave d'accéder en toute sécurité à n'importe quelle adresse à partir d'une transaction - sans risque d'effondrement.

si l'adresse indiquée est disponible application hôte, la transaction TSX est le plus souvent réussie. Dans de rares cas, il peut échouer en raison d'influences externes telles que des interruptions (telles que des interruptions du planificateur), des expulsions de cache ou une modification simultanée d'un emplacement mémoire par plusieurs processus. Dans ces rares cas, le TSX renvoie un code d'erreur indiquant que la panne est temporaire. Dans ces cas-là, il vous suffit de relancer la transaction.

si l'adresse indiquée n'est pas disponible application hôte, TSX supprime l'exception survenue (le système d'exploitation n'est pas averti) et abandonne la transaction. Un code d'erreur est renvoyé au code de l'enclave afin qu'il puisse réagir au fait que la transaction a été annulée. Ces codes d'erreur indiquent que l'adresse en question n'est pas disponible pour l'application hôte.

Cette manipulation du TSX depuis l'intérieur de l'enclave présente une fonctionnalité intéressante pour le méchant : puisque la plupart des compteurs de performances matérielles ne sont pas mis à jour au moment où le code de l'enclave est exécuté, il est impossible de suivre les transactions TSX exécutées à l'intérieur de l'enclave. Ainsi, les manipulations malveillantes du TSX restent totalement invisibles pour le système d'exploitation.

De plus, étant donné que le hack ci-dessus ne repose sur aucun appel système, il ne peut ni être détecté ni empêché en bloquant simplement les appels système ; ce qui donne généralement un résultat positif dans la lutte contre la chasse aux œufs.

Le méchant utilise le hack décrit ci-dessus pour rechercher dans le code de l'application hôte des gadgets adaptés à la formation d'une chaîne ROP. En même temps, il n’a pas besoin de sonder chaque adresse. Il suffit de sonder une adresse de chaque page de l'espace d'adressage virtuel. Sonder les 16 Go de mémoire prend environ 45 minutes (sur un Intel i7-6700K). En conséquence, le méchant reçoit une liste de pages exécutables adaptées à la construction d'une chaîne ROP.

Hack pour sonder les adresses pour l'écriture

Pour mener à bien une version enclavée d'une attaque ROP, un attaquant doit être capable de rechercher des zones de mémoire inutilisées et inscriptibles de l'application hôte. L'attaquant utilise ces emplacements mémoire pour injecter une fausse trame de pile et injecter une charge utile (shellcode). En fin de compte, une enclave malveillante n'est pas en mesure de demander à l'application hôte de s'allouer de la mémoire pour elle-même, mais peut plutôt utiliser à mauvais escient la mémoire déjà allouée par l'application hôte. À condition, bien sûr, qu’il parvienne à trouver de telles zones sans effondrer l’enclave.

Le méchant effectue cette recherche en exploitant un autre effet secondaire du TSX. Tout d'abord, comme dans le cas précédent, il sonde l'adresse pour son existence, puis vérifie si la page correspondant à cette adresse est accessible en écriture. Pour ce faire, le méchant utilise le hack suivant : il place une fonction d'écriture dans une transaction TSX, et une fois celle-ci terminée, mais avant qu'elle ne soit terminée, il abandonne de force la transaction (abandon explicite).

En examinant le code retour d'une transaction TSX, l'attaquant comprend s'il est accessible en écriture. S'il s'agit d'un "avortement explicite", le méchant comprend que l'enregistrement aurait été réussi s'il l'avait suivi jusqu'au bout. Si la page est en lecture seule, alors la transaction se termine par une erreur autre que « abandon explicite ».

Cette manipulation du TSX présente une autre fonctionnalité intéressante pour le méchant (outre l'impossibilité de suivre via des compteurs de performances matériels) : puisque toutes les commandes d'écriture en mémoire ne sont validées que si la transaction réussit, forcer la transaction à se terminer garantit que la cellule mémoire sondée reste inchangé.

Pirater pour rediriger le flux de contrôle

Lorsqu'il effectue une attaque ROP depuis une enclave - contrairement aux attaques ROP traditionnelles - l'attaquant peut prendre le contrôle du registre RIP sans exploiter les bogues du programme attaqué (débordement de tampon ou quelque chose comme ça). Un attaquant peut directement écraser la valeur du registre RIP stocké sur la pile. Il peut notamment remplacer la valeur de ce registre par sa propre chaîne ROP.

Cependant, si la chaîne ROP est longue, l'écrasement d'une grande partie de la pile de l'application hôte peut entraîner une corruption des données et un comportement inattendu du programme. Le méchant, qui cherche à mener son attaque en secret, n'est pas satisfait de cet état de fait. Par conséquent, il crée un faux cadre de pile temporaire pour lui-même et y stocke sa chaîne ROP. Le faux cadre de pile est placé dans un emplacement de mémoire inscriptible aléatoire, laissant la vraie pile intacte.

Qu'est-ce que les trois hacks énumérés ci-dessus donnent au méchant ?

(1) Premièrement, l’enclave malveillante via pirater pour sonder les adresses pour voir si elles peuvent être lues, – recherche dans l'application hôte les gadgets ROP abusables.

(2) Puis par hack pour sonder les adresses pour l'écriture, – une enclave malveillante identifie les zones de la mémoire de l’application hôte adaptées à l’injection d’une charge utile.

(3) Ensuite, l'enclave crée une chaîne ROP à partir des gadgets découverts à l'étape (1) et injecte cette chaîne dans la pile d'applications hôte.

(4) Enfin, lorsque l'application hôte rencontre la chaîne ROP créée à l'étape précédente, la charge utile malveillante commence à s'exécuter - avec les privilèges de l'application hôte et la possibilité d'effectuer des appels système.

Comment un méchant utilise ces hacks pour créer des ranzowari

Après que l'application hôte transfère le contrôle à l'enclave via l'un des ECALL (sans soupçonner que cette enclave est malveillante), l'enclave malveillante recherche de l'espace libre dans la mémoire de l'application hôte pour injecter du code (en prenant comme espaces libres ces séquences de cellules qui est rempli de zéros). Puis à travers pirater pour sonder les adresses pour voir si elles peuvent être lues, – l'enclave recherche des pages exécutables dans l'application hôte et génère une chaîne ROP qui crée un nouveau fichier nommé « RANSOM » dans le répertoire courant (dans une attaque réelle, l'enclave crypte les fichiers utilisateur existants) et affiche un message de rançon. Dans le même temps, l’application hôte croit naïvement que l’enclave ajoute simplement deux nombres. A quoi cela ressemble-t-il dans le code ?

Pour faciliter la perception, introduisons quelques mnémoniques à travers les définitions :

Nous sauvegardons les valeurs d'origine des registres RSP et RBP afin de restaurer le fonctionnement normal de l'application hôte après l'exécution du payload :

Nous recherchons un cadre de pile approprié (voir le code de la section « hack pour rediriger le flux de contrôle »).

Trouver des gadgets ROP appropriés :

Trouver un endroit pour injecter la charge utile :

Nous construisons une chaîne ROP :

C'est ainsi que la technologie SGX d'Intel, conçue pour contrer les programmes malveillants, est exploitée par des malfaiteurs pour atteindre des objectifs opposés.

Source: habr.com