LoJax: le premier rootkit UEFI connu utilisé dans une campagne malveillante

Sednit Cybergroup, également connu sous le nom de ART28, Strontium et Fancy Bear, fonctionne depuis au moins 2004. On pense que le groupe est à l'origine d'une série de cyberattaques résonnantes. Certaines entreprises de l'IB et le ministère américain de la Justice ont appelé Sednit responsable du piratage du Comité national démocrate avant les élections américaines de 2016. On attribue au groupe le piratage du réseau mondial de télévision TV5Monde, la fuite de courriels de l'Agence mondiale antidopage (AMA) et d'autres incidents. Sednit a de nombreux objectifs et une large gamme d'outils, dont certains que nous avons déjà documentés précédemment, mais pour la première fois dans ce travail, nous décrirons en détail l'utilisation du rootkit UEFI.

Brève revue

Nous avons constaté qu'au moins depuis le début de 2017, Sednit utilise une version trojanisée de l'ancien agent utilisateur du programme pour protéger les appareils contre le vol par le développeur d'Absolute Software - LoJack. L'outil a attiré l'attention des professionnels de la sécurité de l'information en raison de l'utilisation du module UEFI / BIOS comme mécanisme pour assurer la persistance. Nous avons appelé la version trojanisée de ce programme LoJax .

La présence d'outils Sednit bien connus dans les systèmes infectés ainsi que des échantillons LoJax, ainsi que le fait que certains serveurs de commandes utilisés par des agents de Troie faisaient auparavant partie de l'infrastructure Sednit, nous permettent d'associer de manière fiable un rootkit UEFI à ce groupe.

En collaboration avec les agents LoJax, des outils de lecture du micrologiciel du système UEFI ont été découverts et, dans l'un des cas, cet outil pouvait vider, patcher et réécrire une partie de la mémoire flash SPI du système. L'objectif ultime de l'outil est d'installer un module UEFI malveillant dans un système dont la protection SPI flash est vulnérable ou mal configurée.

Le module UEFI est responsable de l'implémentation de l'agent LoJax dans le système; il s'agit du premier rootkit UEFI identifié du groupe Sednit. Comme il se trouve dans le micrologiciel du système, il peut survivre à la réinstallation de Windows et au remplacement du disque dur.

Il y a eu au moins un cas où ce rootkit a été installé avec succès dans la mémoire flash SPI du système. Selon nos informations, il s'agit du premier rootkit UEFI découvert dans la nature.

Présentation

Sednit utilise un certain nombre de familles de logiciels malveillants. Une description détaillée des outils de groupe fréquemment utilisés que nous avons fournis dans le rapport .

Nous suivons l'activité de Sednit depuis plusieurs années et avons publié de nombreux rapports sur le travail du groupe - des descriptions des vulnérabilités zero-day aux programmes personnalisés tels que Zebrocy . Les composants décrits dans ce rapport forment un groupe distinct.

Les rootkits UEFI ont déjà été décrits dans des rapports de sociétés de sécurité de l'information. Par exemple, rkloader, qui figurait dans une présentation sur la fuite de données dans l'équipe de piratage, et DerStarke, un implant en téléchargement macOS EFI / UEFI, à partir de documents Vault7 , sont connus . Nous sommes conscients de l'existence de ces outils, cependant, aucun rapport de compromis UEFI n'a été émis par les rootkits.

Maintenant, nous avons non seulement prouvé l'utilisation d'un micrologiciel dans la nature avec le module UEFI LoJax malveillant, mais nous avons également trouvé toute la gamme d'outils qui étaient probablement utilisés pour l'installer. Il est intéressant de noter que Sednit utilise le kit de démarrage DownDelph, qui a été utilisé en 2013 et 2014 pour maintenir Downdelph, l'une des portes dérobées Sednit de première étape. L'idée est similaire, mais dans la nouvelle version d'UEFI, l'utilisation de bootkits n'est plus possible. Ainsi, ces deux composants diffèrent considérablement dans leur comportement.

Ce travail est divisé en trois sections. Dans la première, nous analyserons les premières études sur la sécurité LoJack / Computrace et le potentiel d'utilisation malveillante du programme. La deuxième section est consacrée au processus de recherche, qui nous a finalement conduit au rootkit UEFI. Enfin, dans la troisième section, nous décrivons en détail les différents composants LoJax et comment ils assurent la persistance dans le système même après la réinstallation de Windows et le remplacement du disque dur.

Attribution

Alors que de nombreux fournisseurs ont déjà fait des déclarations concernant le groupe Sednit dans le passé, ESET ne détermine en aucun cas son appartenance géopolitique. Depuis la publication de l'étude 2016, notre position n'a pas changé. Déterminer la source d'une cyberattaque sur la base d'une approche scientifique est une tâche complexe qui dépasse le cadre des compétences des spécialistes ESET. Ce que nous appelons le «groupe Sednit» n'est qu'un ensemble de logiciels et une infrastructure réseau associée que nous ne pouvons pas associer avec autorité à une organisation particulière.

Buts

Au cours de l'étude, nous avons trouvé un petit nombre d'images LoJax différentes. Sur la base de nos données de télémétrie et d'une étude d'autres programmes Sednit découverts dans la nature, nous sommes convaincus que ce module particulier a été rarement utilisé en comparaison avec d'autres outils. Les objectifs étaient principalement des organisations étatiques situées dans les Balkans, en Europe centrale et orientale.

Premières recherches sur l'informatique / LoJack

LoJack - logiciel pour protéger les ordinateurs contre le vol et la perte, développé par Absolute Software Corporation. Les premières versions de l'agent sont appelées Computrace. Comme le nom précédent l'indique, après avoir activé le service, l'ordinateur peut accéder à son serveur de commande - le propriétaire sera informé de l'emplacement de l'appareil en cas de perte ou de vol.

La section ci-dessous décrit l'ancienne architecture LoJack. Seule l'ancienne version du logiciel a été piratée par des cybercriminels, nous allons donc nous concentrer sur elle. De plus, Absolute Software a publié en mai 2018 une déclaration indiquant que les vulnérabilités décrites ci-dessous n'affectent pas le fonctionnement des dernières versions de leurs agents.

Le programme Computrace a attiré l'attention des professionnels de la sécurité de l'information car il a utilisé une méthode inhabituelle pour assurer la persistance. Son but est de se protéger contre le vol, donc la résistance à la réinstallation du système d'exploitation et au remplacement du disque dur est importante pour lui - tout cela est implémenté dans le module UEFI / BIOS qui peut survivre après ces actions. La solution est préinstallée dans le firmware d'une partie importante des ordinateurs portables de différents fabricants, l'utilisateur n'a qu'à activer cette fonction. L'activation peut être effectuée dans le BIOS, comme indiqué dans la figure ci-dessous.


Figure 1. Activation de Computrace dans le BIOS

L'un des premiers rapports de mise en œuvre de LoJack / Computrace a été publié en 2009. L'architecture globale du produit, le vidage du module UEFI / BIOS de l'agent utilisateur sur le disque et la façon dont l'agent communique avec un serveur Web contrôlé par Absolute Software ont été décrits. Le diagramme peut être compris à partir de la figure ci-dessous.


Figure 2. Mécanisme de persistance LoJack (environ 2008)

Voici une description des étapes répertoriées ci-dessus:

1. S'il est activé, le module UEFI / BIOS est exécuté au démarrage. Il essaie de trouver la partition FAT / FAT32 / NTFS. Ensuite, à l'aide du pilote NTFS, il crée une sauvegarde du fichier autochk.exe et écrase son contenu avec le dropper, qui est responsable de l'installation du composant agent utilisateur. Le fichier autochk.exe est un fichier exécutable Windows qui est lancé à un stade précoce du démarrage du système pour vérifier les dommages possibles sur le disque dur.

2. Lorsque le autochk.exe modifié démarre, son objectif principal est d'implémenter le mini-agent rpcnetp.exe et de l'ajouter en tant que service afin qu'il démarre à chaque redémarrage. La dernière étape de ce composant consiste à restaurer la version d'origine de autochk.exe .

3. Mini-agent rpcnetp.exe - un petit fichier exécutable dont le but est d'assurer le fonctionnement de l'agent principal. Si l'agent principal ne fonctionne pas, rpcnetp.exe essaie de se connecter au serveur de commandes Absolute Software C&C pour le télécharger et l'exécuter. Tout d'abord, le mini-agent fera une copie de lui-même, puis apportera des modifications à l'en-tête PE pour le convertir en DLL. Cette bibliothèque est ensuite chargée en mémoire, appelle le processus svchost.exe et y injecte la DLL. Ensuite, le processus Internet Explorer iexplore.exe démarre et la DLL y est injectée. Ce dernier processus sera ensuite utilisé pour la communication sur Internet. L'injection de mini-agents Computrace dans des processus tiers se trouve souvent dans les logiciels malveillants et est rarement associée à des logiciels légitimes.

4. Un agent entièrement fonctionnel est maintenant en cours d'exécution sur le système et peut utiliser les fonctions Computrace pour le suivi et la récupération.

Une description de ce processus et du protocole réseau impliqué entre le mini-agent et le serveur C&C a été publiée en 2014. En raison de l'absence d'un mécanisme d'authentification, si les attaquants contrôlent le serveur avec lequel le mini-agent communique, ils peuvent le forcer à télécharger du code arbitraire. Il existe plusieurs mécanismes qui permettent aux attaquants de contacter directement le mini-agent. Le plus important pour nous utilise la méthode d'obtention de l'adresse du serveur C&C par le mini-agent. En fait, ces informations sont stockées dans le fichier de configuration dans le fichier exécutable lui-même.


Figure 3. Fichier de configuration de déchiffrement partiel LoJack chiffré à droite

La figure montre le fichier de configuration du mini-agent LoJack. La méthode de «chiffrement» utilisée est un XOR simple avec une clé à un octet. La clé 0xB5 est la même pour tous les mini-agents étudiés. Comme le montre la figure, le domaine C&C est spécifié dans le fichier. Les quatre octets précédents contiennent l'adresse IP du serveur C&C. En l'absence de validation sur le contenu du fichier de configuration, les attaquants disposant d'autorisations d'écriture dans %WINDIR% peuvent modifier son contenu afin que le mini-agent communique avec leur serveur de commandes, au lieu d'être légitime. En comprenant le protocole réseau, vous pouvez effectuer le téléchargement du mini-agent et exécuter du code arbitraire. Ces risques sont connus depuis longtemps, mais jusqu'à récemment, le mécanisme n'était pas utilisé dans la pratique.

LoJack se transforme en LoJax

En mai 2018, les échantillons Trobor du mini-agent LoJack, rpcnetp.exe, ont été décrits sur le blog Arbor Network. Leurs paramètres réseau codés en dur ont été modifiés de sorte que des échantillons malveillants établissent une connexion avec le serveur C&C de l'attaquant au lieu du serveur légitime Absolute Software. Certains des domaines trouvés dans les exemples cheval de Troie ont été rencontrés plus tôt - ils ont été utilisés fin 2017 comme domaines de serveur C & C pour SedUploader, la porte dérobée de la première étape du cybergroupe Sednit. La figure ci-dessous montre un exemple de configuration modifiée dans l'un des mini-agents LoJax.


Figure 4. A gauche, un fichier de configuration légitime, à droite, un fichier modifié

Les différences entre les agents légitimes et les agents de Troie sont extrêmement faibles, presque toutes sont données ci-dessus. Les exemples de mini-agents LoJax que nous avons pu trouver sont des versions trojanisées du même exemple de mini-agent Computrace, rpcnetp.exe . Ils ont tous des horodatages de compilation identiques et seulement quelques dizaines d'octets diffèrent de l'original. Outre les modifications apportées au fichier de configuration, il existe des différences dans les variables de temporisation qui déterminent les intervalles entre les connexions au serveur C&C.

Au moment de la publication, nous avons trouvé divers mini-agents LoJax utilisés dans des attaques contre diverses organisations dans les Balkans, en Europe centrale et orientale, mais nous n'avions aucune idée de la façon de les installer. Une explication évidente serait d'installer en utilisant l'une des célèbres portes dérobées Sednit. N'oubliez pas que LoJack, en tant qu'outil bien établi, a été ajouté à la liste blanche par de nombreux fournisseurs d'antivirus. Ainsi, même si dans cette campagne, seul un mini-agent a été utilisé qui n'a pas survécu après la réinstallation de Windows, il avait quand même un avantage - il était moins susceptible d'être détecté comme malware. Mais que faire si le compromis était encore plus profond et que les attaquants tentaient de copier LoJack pour accéder au firmware du système?

Chasser le composant de niveau inférieur

Nous avons enregistré des attaques LoJax visant plusieurs organisations dans les Balkans, en Europe centrale et orientale. Dans chacun d'eux, nous avons réussi à trouver des traces de logiciels malveillants Sednit, notamment:

• SedUploader, porte dérobée du premier étage
• XAgent, la porte dérobée phare de Sednit
• Xtunnel, un outil proxy réseau qui peut transférer tout trafic réseau entre un serveur C&C sur Internet et un ordinateur de destination sur un réseau local

Nous avons trouvé des traces d'outils Sednit dans la plupart des systèmes étudiés qui sont devenus des cibles LoJax, ainsi que dans quelques systèmes où seul LoJax était présent. On peut supposer que dans certains cas, LoJax a été utilisé comme un outil séparé, probablement comme porte dérobée supplémentaire pour restaurer l'accès des opérateurs Sednit au réseau.

La porte dérobée XAgent dépose généralement des modules supplémentaires dans un système compromis, il vient donc immédiatement à l'esprit que les échantillons LoJax ont été livrés de la même manière, sans aucun autre mécanisme. On pourrait supposer que Sednit n'a emprunté qu'un mini-agent à la solution LoJack. Cependant, peu de temps après le début de l'analyse, nous avons trouvé plusieurs preuves indiquant que la source d'inspiration était un peu plus étendue.

Pilote RWEverything (RwDrv) et info_efi.exe

Les premières preuves ont été trouvées grâce à un outil personnalisé de cybercriminels qui, une fois exécutés, ont déchargé des informations sur les paramètres du système de niveau inférieur dans un fichier texte. L'outil a été découvert avec quelques échantillons LoJax. La figure suivante montre un fragment du fichier info_efi.exe de cet outil sous le nom logique info_efi.exe .


Figure 5. Extrait des journaux de fichiers générés par info_efi .exe

Pour lire ce type d'informations, l'outil inclut un pilote appelé RwDrv.sys . Le pilote du noyau est livré avec RWEverything , un utilitaire gratuit disponible sur le réseau qui peut être utilisé pour lire des informations sur presque tous les paramètres de niveau inférieur, y compris l'interface PCI Express, la mémoire, les ROM optionnelles PCI, etc. Le pilote du noyau est un logiciel légitime et est signé avec un certificat valide.


Figure 6. Certificat de signature de code RwDrv.sys

RWEverything est livré avec une interface utilisateur graphique qui vous permet d'accéder à toutes ces informations.


Figure 7. Capture d'écran de l'interface RWEverything

La découverte de l'outil info_efi été le premier signe qu'un module UEFI LoJax pouvait exister. Lorsque vous essayez de mettre à jour le micrologiciel du système, il est important d'avoir des informations sur son fournisseur, sa version, etc. Compte tenu des vulnérabilités qui permettent aux processus utilisateur d'accéder et de modifier le contenu de la mémoire flash SPI où les modules UEFI sont stockés, l'obtention des données du microprogramme du système est la première étape d'une attaque réussie.

Le dernier indice qui nous a permis de trouver le premier rootkit UEFI du groupe Sednit était deux outils - pour vider la mémoire flash SPI et pour y écrire.

Dump SPI Flash

La première pièce du puzzle était un fichier appelé ReWriter_read.exe . Il contenait tout le code nécessaire pour vider le flash SPI du système à l'aide du pilote RwDrv.sys , RwDrv.sys . Pour que le pilote de périphérique effectue les opérations nécessaires, l'outil de vidage doit envoyer les codes de contrôle d'E / S corrects (IOCTL). Alors que RwDrv.sys prend en charge de nombreux codes IOCTL différents, l'outil de vidage et l'outil d'écriture décrits dans cette section et la section suivante n'en utilisent que quatre.

RwDrv.sys: codes IOCTL pris en charge:

0x22280c - écrit dans la zone mémoire allouée aux E / S
0x222808 - lit la zone de mémoire allouée pour l'entrée-sortie
0x222840 - lit dword dans le registre de configuration PCI spécifié
0x222834 - écrit un octet dans le registre de configuration PCI spécifié

ReWriter_read crée d'abord un service avec le RwDrv.sys noyau RwDrv.sys et écrit les informations de configuration UEFI / BIOS, les valeurs correspondantes des trois champs contenus dans le registre de gestion du BIOS (BIOS_CNTL): BIOS Lock Enable (BLE), BIOS Write Enable (BIOSWE) et SMM BIOS Désactiver la protection en écriture (SMM_BWP). Bien que ReWrite_read n'utilise pas ces valeurs, dans les sections suivantes, nous expliquerons pourquoi ces champs présentent un intérêt pour cet outil.

La tâche suivante de l'outil consiste à obtenir l'adresse de base de la zone de mémoire du BIOS dans SPI et sa taille. Ces informations sont contenues dans le registre de l'interface SPI principale en tant que région primaire du BIOS Flash. Tous les registres sont affichés en mémoire dans le bloc de registre complexe racine (RCRB), dont l'adresse de base peut être obtenue en lisant le registre de configuration PCI souhaité. ReWriter_read obtient cette adresse en utilisant RwDrv IOCTL 0x22840 et en lisant le retrait correct (dans notre cas, 0xF0). Dès que l'adresse de base de la zone BIOS et sa taille sont connues, l'outil de vidage lit le contenu correspondant de la mémoire flash SPI et l'écrit dans un fichier sur le disque. Le processus de lecture de la mémoire flash SPI est illustré dans la figure suivante. Les définitions des abréviations sont données dans le glossaire ci-dessous.


Figure 8. La séquence de lecture de la mémoire flash SPI

En plus des deux premières étapes, exécutées une seule fois, les opérations sont répétées dans un cycle jusqu'à ce que toutes les données de la mémoire flash SPI aient été lues. Le processus est également bien décrit ici . ReWriter_read valide ensuite la taille de l'image fusionnée. Il analyse le descripteur de mémoire d'image pour obtenir une gamme de zones BIOS, Gigabit Ethernet (GbE) et Management Engine (ME). L'ajout des dimensions de ces trois zones permet à l'outil de vidage de calculer l'intégralité du contenu du flash SPI. Si la taille correspond à la taille obtenue en lisant la zone de registre Flash du BIOS principal, l'image est considérée comme correcte.

Patch du firmware UEFI

La deuxième pièce du puzzle était un fichier appelé ReWriter_binary.exe . Ce fichier contient des preuves que Sednit est arrivé au firmware. Le fichier contient le code pour appliquer le correctif de l'image UEFI téléchargée et réécrire la version trojanisée dans la mémoire flash SPI. Dans cette section, nous décrivons la structure de ce fichier binaire.

Une fois le contenu de la mémoire flash déchargé et vérifié par l'outil ci-dessus, un module UEFI malveillant est ajouté à l'image. Pour ce faire, l'image UEFI doit être analysée pour mettre en évidence les informations nécessaires.

Les données stockées dans l'image UEFI sont décomposées en volumes via le système de fichiers (FFS). Comme son nom l'indique, il s'agit d'un système de fichiers spécial pour stocker les images du micrologiciel. Les volumes contiennent des fichiers avec des GUID. Chaque fichier se compose généralement de nombreuses sections, dont l'une contient le PE / COFF exécutable réel, qui est une image UEFI. Ci-dessous, une capture d'écran de UEFITool , un projet open source pour travailler avec des images de firmware UEFI, pour une compréhension plus simple du circuit.


Figure 9. Exemple d'une image de micrologiciel UEFI chargée dans UEFITool

ReWriter_binary analyse tous les volumes de micrologiciel trouvés dans la zone BIOS SPI de la mémoire flash et recherche des fichiers spécifiques:

• IP4Dxe (8f92960f-2880-4659-b857-915a8901bdc8)
• NtfsDxe (768bedfd-7b4b-4c9f-b2ff-6377e3387243)
• SmiFlash (bc327dbd-b982-4f55-9f79-056ad7e987c5)
• Noyau DXE

Figure 10. Résultat de l'utilisation du décompilateur Hex-Rays dans les volumes du micrologiciel

Ip4Dxe et NtfsDxe sont des pilotes DXE. Dans le micrologiciel UEFI, les pilotes DXE sont des images PE / COFF créées soit pour l'abstraction matérielle, soit pour organiser les services à utiliser par d'autres pilotes DXE ou applications UEFI. Ces pilotes sont détectés et téléchargés par la Fondation DXE via DXE Manager (noyau DXE) à un stade précoce du processus de démarrage. Une fois cette phase terminée, tous les services, tels que le chargeur de système d'exploitation, sont disponibles pour travailler avec les applications UEFI. En règle générale, les pilotes DXE sont stockés dans le même volume. Cependant, le répartiteur DXE peut être séparé.

ReWriter_binary recherche Ip4Dxe uniquement pour déterminer si un volume donné contient des pilotes DXE. Comme nous le décrirons plus loin, ce volume devient un candidat pour l'installation du pilote DXE malveillant. Il recherche également le noyau DXE et ajoute le volume dans lequel il se trouve comme un autre candidat pour un endroit pour enregistrer un rootkit. L'espace libre disponible dans chacun de ces volumes est stocké et utilisé ultérieurement pour vérifier la suffisance de l'ajout d'un pilote malveillant.

NtfsDxe - pilote AMI NTFS DXE. S'il est présent dans le volume du micrologiciel, son emplacement est enregistré et utilisé ultérieurement pour supprimer ce fichier du volume. Dans la section rootkit UEFI, nous verrons pourquoi il supprime ce fichier.

Quant à l'image SmiFlash, les informations qui s'y rapportent sont stockées, mais ne sont utilisées nulle part à Malvari. Fait intéressant, l'image est vulnérable . Par conséquent, nous pensons que les opérateurs Sednit peuvent travailler pour exploiter ces vulnérabilités. Cela peut leur permettre d'écrire même des systèmes correctement configurés dans la mémoire flash SPI. Comme nous le dirons plus loin, dans sa forme actuelle, l'outil ne peut écrire que dans la zone BIOS de systèmes mal configurés ou assez anciens (sur des cartes mères avec des chipsets plus anciens que le Platform Controller Hub, introduit vers 2008).

Une fois les métadonnées nécessaires allouées, ReWriter_binary le vidage de l'image UEFI et ajoute le pilote DXE malveillant. Tout d'abord, il crée l'en-tête du fichier (EFI_FFS_FILE_HEADER). Il sélectionne ensuite le volume de destination en fonction de l'emplacement d'Ip4Dxe et du noyau DXE, ainsi que de l'espace libre disponible sur ces volumes. ReWriter_binary intègre une section compressée contenant une image PE et une section d'interface utilisateur qui définit un nom de fichier lisible par l'homme: SecDxe. La section compressée est ajoutée à l'en-tête du fichier et écrite à la fin du volume, dans l'espace libre. La figure ci-dessous montre la structure - son affichage dans UEFITool.


Figure 11. Vue du fichier SecDxe dans UEFITool

Enfin, si le pilote NtfsDxe est présent dans l'image, il sera supprimé. Le système de fichiers du micrologiciel stocke les fichiers et leur contenu de manière séquentielle, le processus est donc assez simple:

• retrait vers un espace libre à la fin du volume
• 0xFF octets écrits au-dessus de l'image NtfsDxe
• la partie suivante du volume du micrologiciel est copiée, en commençant par l'indentation où se trouvait NtfsDxe
• le reste du système de fichiers est rempli avec des octets 0xFF, c'est-à-dire de l'espace libre

Réécriture du micrologiciel patché dans la mémoire flash SPI

Après avoir correctement modifié l'image du micrologiciel, l'étape suivante consiste à la réécrire dans la mémoire flash SPI. Avant de plonger dans ce processus, nous devons caractériser une partie de la protection en écriture du BIOS qui est importante dans ce cas. Les autres mécanismes existants, tels que le BIOS de protection en écriture de gamme, restent à l'écart car ReWriter_binary ne les vérifie pas.

La plateforme utilise plusieurs mécanismes de sécurité pour bloquer les tentatives d'écriture non autorisées dans la zone du BIOS. Je dois dire que ces mécanismes ne sont pas activés par défaut. Le firmware est responsable de leur configuration correcte. Ces configurations sont présentées dans le registre de contrôle du BIOS (BIOS_CNTL). Il contient le bit BIOS Write Enable (BIOSWE), qui doit être réglé sur «1» afin d'écrire dans la zone BIOS de la mémoire flash SPI. Étant donné que la plate-forme ne doit permettre aucune tentative d'écriture dans la zone du BIOS, il y a un bit de plus dans BIOS_CNTL pour protéger BIOSWE - c'est le BIOS Lock Enable (BLE). Lorsqu'il est défini, le mécanisme doit bloquer le bit BIOSWE et laisser la valeur égale à "0". Cependant, la solution présente une vulnérabilité. Lorsqu'une demande vient de changer le bit BIOSWE à «1», le bit BIOSWE à «1», et seulement après que la plate-forme interrompt la tâche à l'aide de System Management Interrupt (SMI), le code de ce SMI remet le bit BIOSWE à «0».

Il existe de nombreux problèmes dans cette version de la solution.Premièrement, le processeur SMI est laissé aux développeurs de firmware. Par conséquent, si ce code n'est pas implémenté dans le firmware, le bit BLE est inutile, car le bit BIOSWE ne sera pas remis à "0". Deuxièmement, dans ce cas, nous avons une « vulnérabilité de condition de concurrence » qui nous permet de contourner complètement ce mécanisme, même si le gestionnaire SMI est correctement implémenté. Pour exploiter cette vulnérabilité, un attaquant doit exécuter un thread qui définit en continu le BIOSWE sur «1», tandis qu'un autre thread doit écrire des données dans la mémoire flash SPI. Selon les travaux de Kallenberg et Wojtchuk, cette attaque fonctionne sur des processeurs multicœurs et peut également être utilisée avec succès sur des processeurs monocœur avec la technologie Hyper-Threading activée.

Pour résoudre ce problème, un nouveau mécanisme de protection configuré via BIOS_CNTL a été ajouté à la plateforme. Il est introduit dans la famille des chipsets du Intel Platform Controller Hub (PCH). Si le bit de configuration est défini, la désactivation de la protection en écriture du BIOS SMM (SMM_BWP) autorisera l'écriture dans la zone du BIOS uniquement si tous les cœurs sont en mode de gestion du système (SMM) et que le BIOSWE est défini sur "1". Cela protège efficacement le système de la «vulnérabilité de condition de concurrence» décrite ci-dessus. Cependant, comme dans le cas de BLE, SMM_BWP doit être activé du côté du firmware. Par conséquent, le micrologiciel dans lequel ces mécanismes sont mal configurés laisse le système à risque d'accorder des droits d'écriture non autorisés à la zone du BIOS.

ReWriter_binarylit le contenu du registre de contrôle du BIOS pour sélectionner le chemin correct.

Il vérifie d'abord si BIOSWE est défini. Si c'est le cas, il entre dans la phase d'enregistrement. Si BIOSWE est désactivé, il vérifie la valeur du bit BLE. S'il n'est pas installé, il modifie la valeur du bit BIOSWE et commence à enregistrer le firmware corrigé. Si le bit BLE est défini, il vérifie l'état désactivé SMM_BWP et applique la "vulnérabilité de condition de concurrence critique" décrite ci-dessus. Si le bit SMM_BWP est défini, l'opération échoue. La figure ci-dessous illustre le processus.


Figure 12. L'arbre de décision pendant le processus d'enregistrement

En supposant que le fichier analysé particulier a été ReWriter_binaryutilisé pour déployer le rootkit UEFI, nous pouvons conclure que le micrologiciel a mal configuré la protection en écriture du BIOS ou que le chipset de la machine victime est plus ancien que le Platform Controller Hub.

ReWriter_binaryJe n'ai pas pu remplacer le firmware UEFI sur un système moderne bien réglé. Cependant, lors de la recherche d'une image UEFI SmiFlash vulnérable, l'analyse des volumes de micrologiciel UEFI suggère que les attaquants pourraient également travailler avec des techniques de protection de contournement d'écriture du BIOS plus avancées .

De manière très similaire à la procédure de lecture, l'écriture dans la mémoire flash SPI se produit:


Figure 13. Séquence d'écriture dans la mémoire flash SPI

En plus des deux premières étapes, qui ne sont effectuées qu'une seule fois, ces opérations sont répétées dans un cycle jusqu'à ce que toutes les informations soient écrites dans la mémoire flash SPI .

Une fois le processus d'enregistrement terminé, le contenu de la mémoire flash SPI est déchargé à nouveau dans un fichier image.bin. Le même contrôle d'intégrité qui a été effectuéReWriter_read, s'exécute sur une nouvelle image fusionnée. Ensuite, l'image lue dans la mémoire flash SPI est comparée à l'image corrigée en mémoire.

Si des octets sont différents, leur adresse est écrite dans le journal. La présence ou l'absence de différences n'affecte pas la progression du malware. Ces informations ne sont enregistrées que pour que les opérateurs comprennent ce qui se passe.

À l'étape finale, la clé de Registre est définie sur:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\BootExecute = “autocheck autochk *”

Ensuite, le service RwDrv est arrêté et supprimé. Il est important que la valeur de cette ligne soit affectée à la clé de registre Windows, car le rootkit UEFI recherche exactement cette ligne pour la modifier et exécuter son composant au démarrage de Windows. Nous en parlerons plus en détail lorsque nous décrirons le rootkit UEFI et ses composants.

Analyse technique LoJax

L'outil de vidage, de correction et d'écriture sur la mémoire flash SPI est personnalisé pour une image de micrologiciel spécifique et ne peut être utilisé sur aucun système. Dans ce cas, le module UEFI complet peut être distingué. La première chose que nous avons faite après avoir reçu ce module a été d'étudier les données de télémétrie pour savoir si elles avaient été vues auparavant. Pour cela, nous avons dû compter sur le nouveau scanner UEFI, qui peut scanner le firmware du système. Nous avons constaté que le module UEFI du groupe Sednit a été installé au moins une fois dans le système, ce qui signifie que ce rootkit est réellement utilisé dans la nature.

Il n'est pas encore établi comment les outils malveillants ont été livrés aux systèmes compromis. Très probablement, d'autres programmes ont été utilisés pour cela - par exemple, XAgent. Les outils de vidage et d'enregistrement ont été trouvés dans le même système, mais à des moments différents - probablement, les opérateurs ont travaillé en plusieurs étapes. Tout d'abord, ils ont déchargé le micrologiciel sur la machine cible, se sont assurés que l'outil pour effectuer des ajustements au programme fonctionnait sans échecs, puis l'ont rechargé et ont corrigé le micrologiciel. Nous n'avons trouvé qu'une seule version de l'outil pour le vidage et l'enregistrement, mais il est possible qu'il existe d'autres versions pour d'autres micrologiciels avec des vulnérabilités qu'ils pourraient trouver.

La figure ci-dessous donne un aperçu du fonctionnement du rootkit UEFI jusqu'au démarrage du système d'exploitation. Tout d'abord, le pilote SecDxe DXE est chargé par le gestionnaire DXE. De cette façon, la fonction de notification pour le groupe d'événements est configurée EFI_EVENT_GROUP_READY_TO_BOOT. Lorsque le micrologiciel est prêt à sélectionner le périphérique de démarrage et à démarrer le chargeur de démarrage, la fonction de notification est appelée. Elle effectue trois actions:

• charge le pilote NTFS DXE intégré pour fournir l'accès et la capacité d'écriture aux partitions NTFS
• écrit deux fichiers sur la partition Windows NTFS: rpcnetp.exe et autoche.exe
• modifie la clé de registre «HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ Session Manager \ BootExecute»: en: «autocheck autochk *»; après: «autocheck autoche *».

Figure 14. Processus de démarrage d'un système infecté par un rootkit UEFI

SecDxe: pilote DXE malveillant

Dans cette section, nous allons révéler la séquence d'événements se produisant dans un système compromis. Nous commençons par une description du rootkit, puis suivons la chaîne d'événements jusqu'à ce que les composants finaux soient déployés au niveau du système d'exploitation.

Le rootkit UEFI de Sednit est un pilote DXE avec un GUID 682894B5-6B70-4EBA-9E90-A607E5676297.

Il n'est pas signé, il ne peut donc pas être exécuté sur un système avec la protection Secure Boot activée. Après le déploiement sur l'un des volumes de micrologiciel, DXE Foundation le télécharge à chaque démarrage du système.

SecDxe est un petit pilote DXE qui fait essentiellement deux choses. Il met en place un protocole spécifique au GUID.832d9b4d-d8d5-425f-bd52-5c5afb2c85dcqui n'est jamais utilisé. Il crée ensuite un événement associé à la fonction de notification. La fonction de notification est configurée pour appeler un signal par groupe EFI_EVENT_GROUP_READY_TO_BOOT. Le signal de ce groupe d'événements provient du gestionnaire de démarrage lorsqu'il est prêt à sélectionner le périphérique à démarrer.


Figure 15. Résultat du décompilateur Hex-Rays passant par le processus de création d'événement

La fonction de notification exploite le comportement malveillant du rootkit UEFI Sednit. Elle écrit des composants dans le système de fichiers Windows NTFS. En règle générale, le micrologiciel UEFI seul fonctionne avec la partition système EFI, de sorte que le pilote NTFS n'est généralement pas inclus. Seuls les systèmes de fichiers FAT sont pris en charge en tant que partitions à télécharger. Par conséquent, le micrologiciel UEFI n'est pas nécessairement fourni avec des pilotes NTFS. Pour cette raison, SecDxe possède son propre pilote NTFS intégré. Ce pilote démarre en premier et se connecte au périphérique de disque. Autrement dit, il s'installe EFI_SIMPLE_FILE_SYSTEM_PROTOCOLsur des périphériques de disque avec des partitions NTFS, y compris ainsi l'accès aux fichiers.

Maintenant que tout est prêt pour l'écriture de fichiers sur les partitions Windows, SecDxe réinitialise rpcnetp.exeet autoche.exe. Il est ensuite rpcnetp.exeinstallé %WINDIR%\SysWOW64sur les versions 64 bits de Windows ou%WINDIR%\System32sur les versions 32 bits. A est autoche.exedéfini sur %WINDIR%\SysWOW64. La figure suivante montre le processus responsable de l'écriture de ces fichiers sur le disque.


Figure 16. Résultat du décompilateur Hex-Rays passant par le processus d'écriture de fichiers sur le disque,

puis SecDxe ouvre un %WINDIR%\System32\config\SYSTEMfichier avec une sauvegarde d'un ensemble de clés de registre HKLM\SYSTEM. Il analyse le fichier jusqu'à ce qu'il trouve 'autocheck autochk *'et remplace 'k'dans 'autochk'le 'e'. Par conséquent, il 'HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\ BootExecute'devient 'autocheck autoche *'. Au prochain démarrage de Windows, autoche.exe sera lancé à la place autochk.exe.

Hacking Team NTFS Driver

Comme indiqué précédemment, le pilote NTFS est intégré au module SecDxe. Il existe des preuves solides que les opérateurs Sednit n'ont pas écrit leur propre pilote, mais ont compilé une copie du pilote NTFS DXE annoncé de l'équipe de piratage.
Leur pilote NTFS utilise le projet ntfs-3g comme noyau. Il s'agit simplement d'un wrapper pour le faire fonctionner en tant que pilote UEFI DXE. Le fichier INF de l'assembly du pilote Hacking Team répertorie lui-même les noms des fichiers de projet ntfs-3g. Les lignes de code du pilote SecDxe NTFS répertorient également bon nombre de ces noms de fichiers: Il est intéressant de noter que le chemin d'accès au projet est le même que celui trouvé dans vector-edk, le projet de développement Hacking Team EFI. Il y a un sous-projet dans vector-edk

- c:\edk2\NtfsPkg\NtfsDxe\ntfs\inode.c
- c:\edk2\NtfsPkg\NtfsDxe\ntfs\volume.c
- c:\edk2\NtfsPkg\NtfsDxe\ntfs\bootsect.c
- c:\edk2\NtfsPkg\NtfsDxe\ntfs\unistr.c
- c:\edk2\NtfsPkg\NtfsDxe\ntfs\attrib.c
- c:\edk2\NtfsPkg\NtfsDxe\ntfs\mft.c
- c:\edk2\NtfsPkg\NtfsDxe\ntfs\index.c
- c:\edk2\NtfsPkg\NtfsDxe\ntfs\cache.c
- c:\edk2\NtfsPkg\NtfsDxe\ntfs\misc.c
- c:\edk2\NtfsPkg\NtfsDxe\ntfs\dir.c
- c:\edk2\NtfsPkg\NtfsDxe\ntfs\runlist.c
- c:\edk2\NtfsPkg\NtfsDxe\ntfs\logfile.c
- c:\edk2\NtfsPkg\NtfsDxe\ntfs\uefi_io.c
- c:\edk2\NtfsPkg\NtfsDxe\ntfs\ntfsinternal.c
- c:\edk2\NtfsPkg\NtfsDxe\ntfs\mst.c
- c:\edk2\NtfsPkg\NtfsDxe\ntfs\lcnalloc.c
- c:\edk2\NtfsPkg\NtfsDxe\ntfs\compress.c
- c:\edk2\NtfsPkg\NtfsDxe\ntfs\bitmap.c
- c:\edk2\NtfsPkg\NtfsDxe\ntfs\collate.c
- c:\edk2\NtfsPkg\NtfsDxe\ntfs\security.c

NtfsPkgavec une disposition de répertoire absolument identique. Les fichiers source du projet ntfs-3g sont situés sur le même chemin d'adresse. Et bien que les chemins eux-mêmes soient banals, nous pensons que ce n'est pas une simple coïncidence.

En comparant le code source divulgué au réseau avec ce que nous avons obtenu à la sortie du décompilateur Hex-Rays, il devient évident que c'est le même projet. La figure ci-dessous montre un exemple de comparaison d'une fonction NtfsDriverBindingStarttirée de vector-edk/NtfsPkg/NtfsDxe/Ntfs.c. Les commentaires du code HT d'origine sont supprimés pour une meilleure perception. La logique et la séquence des appels de fonction sont identiques. Les deux projets utilisent même une variable (LockedByMe) pour enregistrer un état verrouillé.


Figure 17. Comparaison des résultats en sortie du pilote Sednit du décompilateur Hex-Rays NTFS (à gauche) et du pilote NTFS HT (à droite)

Le code ci-dessus montre les développeurs de l'équipe de piratage, qui n'est pas dans l'open source ntfs-3g. Comme mentionné dans la section ReWriter_binary, lors de l'analyse du système de fichiers du micrologiciel, le fichier exécutable essaie de supprimer le pilote AMI NTFS. Nous voulions comprendre pourquoi il est supprimé au lieu d'être utilisé.

Nous avons analysé le pilote et constaté qu'il ne peut effectuer que des opérations de lecture. Étant donné que l'écriture dans le système de fichiers n'est pas disponible, les développeurs ne pouvaient pas l'utiliser à leurs propres fins. Il est également probable que les opérateurs Sednit aient rencontré des difficultés en raison du fait qu'il existe déjà un autre pilote NTFS dans le firmware, ils ont donc décidé de simplement le supprimer. En plus d'implémenter des capacités de lecture et d'écriture, le pilote Hacking Team ne respecte pas les autorisations de fichier. Par exemple, il peut remplacer un fichier en lecture seule sans provoquer d'erreur.

À ce stade, nous avons déjà décrit diverses opérations de compromis du système effectuées par le rootkit UEFI. Nous avons également discuté des raisons pour lesquelles les opérateurs Sednit ont utilisé le code source vector-edk de la Hacking Team pour développer leur pilote NTFS pour écrire des fichiers sur des partitions NTFS sous Windows. Plus loin dans cet article, nous présenterons une analyse des composants fournis par SecDxe.

autoche.exe vs. autochk.exe

Malicieux est autoche.exeutilisé pour assurer la persistance du mini-agent rpcnetp.exe. Comme vous pouvez le voir sur la figure suivante, il utilise des appels natifs à l'API Windows pour créer un service.


Figure 18. Malicious autoche .exe configure la persistance de rpcnetp.exe

Il convient de noter que le nom du service est le même que celui utilisé par l'agent Computrace légitime. Après avoir créé le service, il restaure la valeur de clé de registre précédente BootExecute.


Figure 19. Le fichier autoche.exe malveillant restaure la valeur d'origine de la clé de registre BootExecute.

Comme le processus se produit au démarrage de Windows, il est peu probable que l'utilisateur remarque une modification de la valeur de la clé.BootExecute. Il convient de noter que dans autoche .exe, certaines similitudes avec le module autochk.exe de Computrace sont visibles, par exemple, les appels d'API appliqués et l'enregistrement des services, mais le reste est assez différent. Le module Computrace est plus grand et il restaure le fichier exécutable d'origine autochk.exeau lieu de modifier la clé de Registre. Il est également responsable du déploiement du mini-agent sur le disque, tandis que LoJax le fait avec le rootkit UEFI.

rpcnetp.exe

Bien que le mini-agent rpcnetp.exepuisse être implémenté par le rootkit UEFI, il est probable que dans la plupart des cas, lorsque nous avons trouvé une version trojanisée de LoJack, le mini-agent n'ait pas utilisé ce composant. Il est probable qu'ils sont partis de considérations opportunistes et n'ont installé le rootkit UEFI que lorsqu'ils en ont eu l'occasion et dans les organisations les plus intéressantes pour eux.

Au cours de l'enquête, nous avons découvert différentes versions du mini-agent LoJax. La liste des indicateurs de compromis montre leurs hachages et les domaines / adresses IP correspondants. Comme nous l'avons déjà dit, tous les échantillons trouvés étaient une version trojanisée du même vieil agent Computrace, compilé en 2008.

Nous n'avons jamais vu un agent LoJax télécharger et installer des modules supplémentaires, mais nous savons qu'une telle fonctionnalité existe. Étant donné que les meilleures qualités de LoJax sont la furtivité et la persistance, il peut certainement être utilisé pour fournir un accès aux ressources clés.

Prévention et récupération des attaques

Pour prévenir une attaque, un écosystème complexe composé de nombreux composants actifs est nécessaire. Le premier mécanisme de sécurité qui pourrait bloquer une telle attaque est Secure Boot. Lorsque Secure Boot est activé, chaque composant du firmware téléchargé à la demande du firmware doit être correctement signé, garantissant ainsi son intégrité. Nous vous recommandons d'activer la fonction Secure Boot, c'est la protection de base contre les attaques sur le firmware UEFI.

Comme pour les logiciels, le firmware UEFI doit toujours être mis à jour en temps opportun. Visitez le site Web du fabricant de la carte mère pour vous assurer que vous disposez de la dernière version disponible.

Vous devez également vous assurer que tous vos systèmes sont équipés de chipsets modernes avec le Platform Controller Hub (à partir des chipsets Intel Series 5 et au-delà). Cela garantira que les mécanismes de sécurité fonctionnent contre la «vulnérabilité aux conditions de concurrence», qui, comme nous l'avons indiqué , est présente dans la plate-forme.

Une autre partie de la sécurité du micrologiciel est entre les mains des fournisseurs UEFI / BIOS. Les mécanismes de sécurité fournis par la plateforme doivent être correctement configurés par le firmware du système afin d'assurer véritablement sa protection. Par conséquent, le firmware doit être initialement construit avec une compréhension des mesures de sécurité. Heureusement, de plus en plus de chercheurs en sécurité prêtent attention à la sécurité du firmware, attirant l'attention des fournisseurs. À noter également CHIPSEC, un framework open source qui effectue une évaluation de sécurité de bas niveau pour déterminer si la plateforme est correctement configurée.

L'élimination des conséquences des compromis via le firmware UEFI est une tâche difficile. Il n'existe aucun moyen simple de nettoyer le système contre de telles menaces, et il n'y a pas de produits de sécurité spéciaux qui pourraient tout réparer. Dans le cas décrit ici, pour supprimer le rootkit, il est nécessaire de reflasher la mémoire flash SPI. Cette tâche n'est pas anodine, elle ne convient pas à l'utilisateur moyen. La mise à jour du micrologiciel UEFI peut supprimer le rootkit si toute la zone SPI de la mémoire flash est réécrite. Si le flashage UEFI n'est pas possible, la seule solution est de remplacer la carte mère du système infecté.

Conclusions

Le rootkit UEFI est l'un des outils les plus dangereux et les plus puissants des cybercriminels en raison de sa persistance et de son immunité élevées à réinstaller le système d'exploitation et à remplacer le disque dur, ainsi qu'à la difficulté exceptionnelle de détection et de suppression. Bien que l'image UEFI du système soit difficile à modifier, peu de solutions vous permettent d'analyser les modules UEFI et d'identifier parmi eux les modules malveillants. De plus, nettoyer le firmware UEFI signifie le flasher, ce qui n'est pas tout à fait une opération ordinaire qu'un utilisateur normal ne pourra pas effectuer. Ces avantages expliquent pourquoi les cybergroupes aux ressources illimitées continueront d'attaquer les systèmes UEFI.

Pour toute question concernant ce travail, veuillez contacter menaceintel@eset.com

Nous tenons à remercier ceux qui travaillent sur le projet opensecuritytraining.info. CoursL'introduction au BIOS et au SMM nous a vraiment aidés lorsque nous avons analysé les interactions avec la puce flash SPI.

Glossaire

Voir les spécifications Intel pour une description plus détaillée des abréviations.
- BIOS_CNTL: Registre de contrôle du BIOS
- BIOSWE: Écriture du BIOS activée
- BLE: Verrouillage du BIOS activé
- FADDR: Adresse Flash
- FDATAX: Données Flash de FDATA0 à FDATAN
- FDBC: Nombre d'octets de données Flash
- FGO: Cycle Flash Go
- HSFC: Séquençage matériel Contrôle Flash
- HSFS: État Flash du séquençage matériel
- IOCTL: Contrôle d'entrée / sortie
- PCH: Plateforme de contrôleur de plate-forme
- RCBA: Registre d'adresse de base complexe racine
- RCRB: Bloc de registre complexe racine
- SCIP: Cycle SPI en cours
- SMI: Interruption de la gestion du système
- SMM: Mode de gestion du système
- SMM_BWP: SMM BIOS Write Protect Disable
- SPI: interface périphérique série

Indicateurs de compromis

ReWriter_read.exe

Détection ESET
Win32/SPIFlash.A
SHA-1
ea728abe26bac161e110970051e1561fd51db93b

ReWriter_binary.exe

Détection ESET
Win32/SPIFlash.A
SHA-1
cc217342373967d1916cb20eca5ccb29caaf7c1b

Secdexe

Détection ESET
EFI/LoJax.A
SHA-1
f2be778971ad9df2082a266bd04ab657bd287413

info_efi.exe

Détection ESET
Win32/Agent.ZXZ
SHA-1
4b9e71615b37aea1eaeb5b1cfa0eee048118ff72

autoche.exe

Détection ESET
Win32/LoJax.A
SHA-1
700d7e763f59e706b4f05c69911319690f85432e

EXE Mini Agent

Détection ESET SHA-1
Win32/Agent.ZQE
Win32/Agent.ZTU

1771e435ba25f9cdfa77168899490d87681f2029
ddaa06a4021baf980a08caea899f2904609410b9
10d571d66d3ab7b9ddf6a850cb9b8e38b07623c0
2529f6eda28d54490119d2123d22da56783c704f
e923ac79046ffa06f67d3f4c567e84a82dd7ff1b
8e138eecea8e9937a83bffe100d842d6381b6bb1
ef860dca7d7c928b68c4218007fb9069c6e654e9
e8f07caafb23eff83020406c21645d8ed0005ca6
09d2e2c26247a4a908952fee36b56b360561984f
f90ccf57e75923812c2c1da9f56166b36d1482be

Noms de domaine du serveur de commandes

secao[.]org
ikmtrust[.]com
sysanalyticweb[.]com
lxwo[.]org
jflynci[.]com
remotepx[.]net
rdsnets[.]com
rpcnetconnect[.]com
webstp[.]com
elaxo[.]org

Adresses IP du serveur de commandes

185.77.129[.]106
185.144.82[.]239
93.113.131[.]103
185.86.149[.]54
185.86.151[.]104
103.41.177[.]43
185.86.148[.]184
185.94.191[.]65
86.106.131[.]54

Mini agent DLL

ESET
Win32/Agent.ZQE
SHA-1 Détection
397d97e278110a48bd2cb11bb5632b99a9100dbd
Serveur de commande Noms de domaine
elaxo.org
Adresses IP du serveur de commande
86.106.131[.]54