Fortinet Zéro

Les acteurs du cyberespionnage continuent de cibler les technologies qui ne prennent pas en charge les solutions de détection et de réponse aux points finaux (EDR) telles que les pare-feu, les appareils IoT, les hyperviseurs et les technologies VPN (par exemple Fortinet, SonicWall, Pulse Secure et autres). Mandiant a enquêté sur des dizaines d'intrusions dans la base industrielle de la défense (DIB), le gouvernement, la technologie et les organisations de télécommunications au fil des ans, où des groupes présumés liés à la Chine ont exploité des vulnérabilités de jour zéro et déployé des logiciels malveillants personnalisés pour voler les informations d'identification des utilisateurs et maintenir un accès à long terme aux environnements des victimes.

Nous observons souvent des opérateurs de cyberespionnage exploitant des vulnérabilités zero-day et déployant des logiciels malveillants personnalisés sur des systèmes exposés à Internet comme vecteur d'attaque initial. Dans cet article de blog, nous décrivons des scénarios dans lesquels un acteur suspecté d'avoir un lien avec la Chine avait probablement déjà accès aux environnements des victimes, puis a déployé des portes dérobées sur les solutions Fortinet et VMware afin de maintenir un accès permanent aux environnements. Cela impliquait l'utilisation d'une vulnérabilité locale zero-day dans FortiOS (CVE-2022-41328) et le déploiement de plusieurs familles de logiciels malveillants personnalisés sur les systèmes Fortinet et VMware. Mandiant a publié les détails de l'écosystème des logiciels malveillants VMware en septembre 2022.

À la mi-2022, Mandiant, en collaboration avec Fortinet, a enquêté sur l'exploitation et le déploiement de logiciels malveillants sur plusieurs solutions Fortinet, notamment FortiGate (pare-feu), FortiManager (solution de gestion centralisée) et FortiAnalyzer (gestion des journaux, analyse et plate-forme de création de rapports). Les étapes suivantes décrivent généralement les actions entreprises par l'auteur de la menace :

Mandiant attribue cette activité à UNC3886, un groupe que nous soupçonnons d'avoir un lien avec la Chine et qui est associé au nouveau cadre de logiciels malveillants de l'hyperviseur VMware ESXi divulgué en septembre 2022. Au moment des compromissions de l'hyperviseur ESXi, Mandiant a observé que l'UNC3886 se connectait directement depuis les appareils FortiGate et FortiManager aux portes dérobées VIRTUALPITA à plusieurs reprises.

Mandiant soupçonne que les appareils FortiGate et FortiManager ont été compromis en raison des connexions à VIRTUALPITA à partir des adresses IP de gestion Fortinet. De plus, les appareils FortiGate avec le mode de conformité FIPS (Federal Information Processing Standards) activé n'ont pas pu démarrer après un redémarrage ultérieur. Lorsque le mode FIPS est activé, une somme de contrôle du système d'exploitation est comparée à la somme de contrôle d'une image propre. Étant donné que le système d'exploitation a été falsifié par l'auteur de la menace, la comparaison de la somme de contrôle a échoué et les pare-feu FortiGate n'ont pas pu démarrer de manière protectrice. Avec l'aide de Fortinet, Mandiant a acquis une image médico-légale de ces appareils défaillants, incitant à la découverte du port ICMP frappant la porte dérobée CASTLETAP.

Plusieurs composants de l'écosystème Fortinet ont été ciblés par UNC3886 avant d'être déplacés latéralement vers l'infrastructure VMWare. Ces composants et leurs versions associées, au moment de la compromission, sont répertoriés comme suit :

Mandiant a observé deux cycles de vie d'attaque distincts où l'auteur de la menace a abusé des technologies Fortinet pour établir un accès au réseau. Le premier s'est produit lorsque l'auteur de la menace a initialement eu accès à l'écosystème Fortinet alors que l'appareil FortiManager était exposé à Internet.

Au cours de ce cycle de vie d'attaque, comme le montre la figure 1, des portes dérobées déguisées en appels d'API légitimes (THINCRUST) ont été déployées sur les appareils FortiAnalyzer et FortiManager. Une fois la persistance établie sur les deux appareils, des scripts FortiManager ont été utilisés pour déployer des portes dérobées (CASTLETAP) sur les appareils FortiGate. Mandiant a observé des connexions SSH entre les appareils Fortinet et les serveurs ESXi, suivies de l'installation de bundles d'installation vSphere malveillants contenant des portes dérobées VIRTUALPITA et VIRTUALPIE. Cela a permis à l'acteur de la menace d'accéder de manière persistante aux hyperviseurs et a permis à l'attaquant d'exécuter des commandes sur des machines virtuelles invitées.

Mandiant n'a aucune preuve qu'une vulnérabilité zero-day est utilisée pour obtenir un accès initial ou déployer les VIB malveillants au moment de la rédaction de cet article. VIRTUALPITA et VIRTUALPIE ont été discutés plus en détail dans un précédent article de blog Mandiant publié en septembre 2022.

Le deuxième cycle de vie d'attaque s'est produit lorsque les appareils FortiManager avaient mis en place des listes de contrôle d'accès (ACL) réseau pour restreindre l'accès externe au seul port TCP 541 (protocole FortiGate à FortiManager). Au cours de ce cycle de vie d'attaque, comme le montre la figure 2, l'auteur de la menace a déployé un utilitaire de redirection du trafic réseau (TABLEFLIP) et une porte dérobée inversée (REPTILE) sur l'appareil FortiManager pour contourner les nouvelles ACL. Grâce aux règles de redirection établies par l'utilitaire TABLEFLIP, l'auteur de la menace a pu accéder à la porte dérobée REPTILE directement depuis Internet pour un accès continu à l'environnement.

Les détails techniques qui suivent décrivent le chemin d'attaque emprunté par l'auteur de la menace lorsque le FortiManager a été initialement exposé à Internet.

L'analyse de Mandiant a identifié que lors de la connexion initiale au FortiManager, l'auteur de la menace a ajouté du code de porte dérobée python à un fichier de structure Web légitime. Mandiant a classé cette nouvelle famille de logiciels malveillants comme THINCRUST.

L'acteur de la menace a modifié le fichier légitime /usr/local/lib/python3.8/proj/util/urls.py pour inclure un appel d'API malveillant supplémentaire, show_device_info, qui peut être vu dans la figure 3. Cela a permis à l'acteur de la menace d'interagir avec la porte dérobée THINCRUST via des requêtes POST à ​​l'URI "/p/util/show_device_info".

Lorsqu'une requête POST était envoyée à l'URL show_device_info, elle passait la requête à la fonction get_device_info dans /usr/local/lib/python3.8/proj/util/views.py. La fonction get_device_info contenait la porte dérobée THINCRUST permettant à l'auteur de la menace d'exécuter des commandes, d'écrire des fichiers sur le disque et de lire des fichiers à partir du disque en fonction des cookies fournis dans la requête POST, comme illustré à la figure 4.

La fonction get_device_info reposait sur la présence de deux (2) cookies, FGMGTOKEN et DEVICEID, dans les requêtes POST. Le cookie FGMGTOKEN est chiffré avec une clé RSA codée en dur dans views.py et contient une clé RC4 qui déchiffre les commandes reçues via le cookie DEVICEID. Le résultat décrypté de DEVICEID était un dictionnaire codé JSON avec les clés 'id' et 'key'. Comme le montre le tableau 1, la valeur 'id' déterminait l'action à exécuter dans la porte dérobée, et la valeur "key" contenait une chaîne qui servait d'arguments pour l'action en cours d'exécution.

IDENTIFIANT

Commande

1

Exécutez la ligne de commande stockée dans 'key'

2

Écrivez le contenu de la requête HTTP dans le fichier stocké dans 'key'. Le contenu est crypté RC4

3

Lire le contenu du fichier stocké dans 'clé' et transférer le contenu chiffré RC4 au client

Alors que la plupart des fichiers dans views.py avaient le décorateur @login_required qui leur était appliqué [les décorateurs sont toutes les fonctions (syntaxe pour appeler le décorateur : @) qui étendent le comportement d'une autre fonction sans modifier explicitement le code], la fonction malveillante get_device_info a utilisé le module python Django natif du système pour ajouter un décorateur @csrf_exempt à la fonction, comme illustré à la figure 5. jeton pour s'exécuter avec succès.

Mandiant a identifié qu'une variante de cet appel d'API malveillant était également présente sur un appareil FortiAnalyzer. Alors que la fonction de porte dérobée dans views.py, get_device_info, était la même que FortiManager, l'appel d'API utilisé pour accéder à la porte dérobée a été remplacé par /p/utils/fortigate_syslog_send sur l'appareil FortiAnalyzer, comme le montre la figure 6.

Une fois la persistance établie sur les appareils FortiManager et FortiAnalyzer avec la porte dérobée THINCRUST, l'auteur de la menace a déployé des scripts FortiManager sur plusieurs pare-feu FortiGate. Cette activité a été enregistrée dans l'elog FortiGate, comme illustré à la figure 7.

vd="root"type="event"subtype="system"level="notice" logdesc="Télécharger et exécuter un script"user="Fortimanager_Access"ui="fgfmd"msg=" Utilisateur Fortimanager_Access via fgfmd télécharger et exécuter le script : -- OK"

L'auteur de la menace a supprimé ces scripts FortiManager de l'appareil FortiManager avant qu'ils ne puissent être récupérés pour analyse, mais la corrélation de plusieurs types de journaux d'événements montre que les scripts ont profité d'une vulnérabilité de traversée de chemin (CVE-2022-41328). La vulnérabilité a été exploitée par l'auteur de la menace à l'aide de la commande execute wireless-controller hs20-icon upload-icon (comme illustré à la figure 8). Cette commande permettait à l'auteur de la menace d'écraser des fichiers légitimes dans un répertoire système normalement restreint. Normalement, la commande execute wireless-controller hs20-icon upload-icon est utilisée pour télécharger des fichiers .ico (fichiers d'icônes) d'un serveur vers un pare-feu FortiGate à l'aide du protocole de transfert de fichiers ("FTP") ou du protocole de transfert de fichiers trivial ("TFTP"), où ils peuvent être utilisés dans les portails d'inscription en ligne HotSpot 2.0 (OSU). HotSpot 2.0 est une technologie qui permet aux appareils de basculer de manière transparente entre les données cellulaires et le Wi-Fi public.

Cependant, la commande execute wireless-controller hs20-icon upload-icon souffrait de deux problèmes. La commande n'a pas validé le type de fichier en cours de téléchargement et était susceptible d'un exploit de traversée de répertoire permettant à un acteur malveillant disposant de privilèges de super administrateur de télécharger un fichier inférieur à 65 535 octets vers n'importe quel emplacement du système de fichiers. Cela signifie qu'en dehors des contraintes de taille de la commande, un acteur malveillant pourrait remplacer n'importe quel fichier système légitime sur le pare-feu FortiGate.

L'exploitation réussie de la vulnérabilité (CVE-2022-41328) n'est pas enregistrée dans les elogs FortiGate. Au moment de l'exécution du script FortiManager, les elogs ont enregistré les tentatives infructueuses de l'auteur de la menace pour écraser le fichier système /bin/lspci à l'aide de cet exploit, illustré à la figure 8.

Fortinet a confirmé que l'exploitation de cette commande n'avait pas été vue avant ces événements et a attribué la désignation CVE-2022-41328. Fortinet a réussi à répliquer l'exploit en utilisant la syntaxe vue dans les événements de commande ayant échoué.

D'autres preuves à l'appui d'une tentative d'exploitation ont été trouvées dans les événements des journaux FortiGuard avec "file_transfer: TFTP.Server.Buffer.Overflow repeated X times" dans le champ msg. Ces événements ont montré des connexions entre les pare-feu FortiGate et l'appareil FortiAnalyzer, où le contenu du paquet comprenait la chaîne de traversée de répertoire lscpi, comme le montre la figure 9. Une chaîne de traversée de répertoire avec le nœud de nom de fichier a également été référencée dans un événement similaire, qui est un autre binaire dans le répertoire /bin/ d'un appareil FortiGate 6.2.7, mais Mandiant a seulement observé l'acteur de la menace remplaçant le binaire lscpi avec succès.

PFBBVFRFUk5TPiAAATsuLi88L1BBVFRFUk5TPgo8VVJJPiA8L1VSST4KPEhFQURFUj4gPC9IRUFERVI+CjxCT0RZPiA8L0JPRFk+CjxQQUNLRVQ+IAABLi4vLi4vLi4vLi4vLi4vLi4vYmluL2xzcGNpAG9jdGV0ADwvUE FDS0VUPg==

Base 64 décodée

..../../../../../../bin/lspci.octet.

Mandiant a examiné les listes de fichiers de plusieurs pare-feu FortiGate à la recherche de versions modifiées de /bin/lspci en fonction des commandes ayant échoué vues dans les journaux FortiGate. Au total, deux variantes de /bin/lspci ont été identifiées ; une version autonome du binaire et une version liée symboliquement à /bin/sysctl. Fortinet a confirmé que /bin/lspci devrait toujours être un binaire autonome.

Les entrées de liste de fichiers pour /bin/lspci et /bin/sysctl sur les pare-feu FortiGate compromis contenaient des horodatages similaires qui ne correspondaient pas aux autres fichiers binaires légitimes sur les machines FortiGate. De plus, la taille du fichier pour /bin/sysctl sur le pare-feu FortiGate compromis était beaucoup plus importante que celle signalée sur les appareils non compromis.

Dans des circonstances normales, la commande "diagnostiquer le matériel lscpi" est utilisée pour répertorier les périphériques PCIe connectés au pare-feu FortiGate, mais une fois que l'acteur de la menace a remplacé le binaire lspci légitime par un lien symbolique, la commande de diagnostic peut exécuter le fichier sysctl que l'acteur de la menace a modifié à la place.

Les extraits de liste de fichiers dans la Figure 10 et la Figure 11 mettent en évidence les différences entre les versions originales et modifiées de /bin/lspci et /bin/sysctl présentes sur les pare-feu FortiGate.

COMPROMIS-FGT101F # fnsysctl ls -la /bin

...

lrwxrwxrwx 1 root root 9 Oct 18 13:09 lldptx -> /bin/init

lrwxrwxrwx 1 root root 9 Oct 18 13:09 lnkmtd -> /bin/init

lrwxrwxrwx 1 racine racine 11 octobre 19 05:11 lspci -> /bin/sysctl

lrwxrwxrwx 1 root root 9 Oct 18 13:09 lted -> /bin/init

lrwxrwxrwx 1 root root 9 Oct 18 13:09 memuploadd -> /bin/init

...

-rwxr-xr-x 1 racine racine 1478216 Oct 19 05:11 sysctl

...

NON COMPROMIS-FGT101F # fnsysctl ls -la /bin

...

lrwxrwxrwx 1 0 0 Ven 2 sept. 12:07:55 2022 9 lldptx -> /bin/init

lrwxrwxrwx 1 0 0 Gratuit 2 sept. 12:07:55 2022 9 lnkmtd -> /bin/init

-rwxr-xr-x 1 0 0 Ven 2 sept. 12:07:55 2022 131736 lspci

lrwxrwxrwx 1 0 0 Gratuit 2 sept. 12:07:55 2022 9 lted -> /bin/init

lrwxrwxrwx 1 0 0 Gratuit 2 sept. 12:07:55 2022 9 memuuploadd -> /bin/init

...

-rwxr-xr-x 1 0 0 Ven 2 sept. 12:07:55 2022 251480 sysctl

...

Outre les différences d'heure et de taille de modification, la sortie de la commande de liste de fichiers fnsysctl ls -l /bin affichait plusieurs champs dans différents formats et dans un ordre différent. Cela est probablement dû au fait que l'acteur de la menace a remplacé /bin/sysctl et a donc modifié la fonctionnalité du shell sur le pare-feu FortiGate. Les modifications apportées au système de fichiers FortiOS ne sont pas persistantes, de sorte que les fichiers n'ont pas pu être récupérés pour analyse.

Par défaut, les appareils Fortinet exécutant FortiOS ont une archive sur le disque intitulée rootfs.gz dans la partition /data/. Au démarrage, ce fichier est monté en tant que système de fichiers racine. Cela signifie que si des modifications sont apportées à l'image montée, les modifications ne seront pas persistantes à moins qu'elles ne soient écrites dans l'archive rootfs.gz. Les pare-feu FortiGate ne prennent pas en charge les fichiers exportés depuis le système de fichiers monté pendant l'exécution. Étant donné que les modifications apportées à /bin/lspci et /bin/sysctl n'ont pas été écrites dans l'archive rootfs.gz, elles n'ont pas été installées de manière persistante et n'ont pas pu être analysées davantage.

Mandiant s'est coordonné avec Fortinet pour obtenir une image médico-légale des pare-feu FortiGate compromis et mieux identifier le contenu attendu des appareils. En comparant l'image médico-légale du pare-feu FortiGate compromis à une version connue, Fortinet a identifié un micrologiciel contenant un cheval de Troie contenant une porte dérobée persistante. Mandiant fait référence à la porte dérobée comme une nouvelle famille de logiciels malveillants nommée CASTLETAP.

L'analyse des pare-feux FortiGate a identifié un fichier malveillant supplémentaire /bin/fgfm. L'analyse de /bin/fgfm a déterminé qu'il s'agissait d'une porte dérobée passive, nommée CASTLETAP, qui écoutait un paquet ICMP spécialisé pour l'activation. L'auteur de la menace a probablement nommé le fichier « fgfm » dans une tentative de déguiser la porte dérobée en service légitime « fgfmd » qui facilite la communication entre les pare-feu FortiManager et FortiGate.

Une fois exécuté, CASTLETAP a créé un socket brut pour détecter le trafic réseau. CASTLETAP a ensuite filtré et XOR décodé une chaîne d'activation magique de 9 octets dans la charge utile d'un paquet de requête d'écho ICMP. Le tableau 2 montre les chaînes magiques interprétées par CASTLETAP et leurs actions résultantes.

Corde Magique

Description

1qaz@WSXa

Analysez les informations C2 de la charge utile ICMP et connectez-vous via SSL.

hpaVAj2FJ

Tue le processus CASTLETAP.

Pour décoder les informations C2 dans le paquet ICMP, une clé XOR à un octet a été dérivée de l'horodatage Epoch pour décrypter les données de charge utile. Cela signifiait que la norme de codage changeait chaque jour. La figure 12 montre la formule qui a été utilisée pour calculer la clé XOR.

((année + 1900 + mois * (année + 1900)) * date) % 255

Le tableau 3 définit la structure de charge utile du paquet ICMP attendu par CASTLETAP.

Index/plage d'octets

Description de la section de charge utile

<0x00-0x01>

<0x01-0x02>

<0x02-0x0c>

<0x0c-0x10>

<0x10-0x15>

Lorsque l'adresse IP et le port du C2 ont été analysés à partir du paquet d'activation, CASTLETAP a lancé une connexion au C2 via un socket SSL. Une fois cette connexion établie, CASTLETAP s'attendait à ce que le serveur C2 initie une poignée de main avec la séquence de 16 octets illustrée à la figure 13, renvoyant la même séquence en réponse.

0x58, 0x90, 0xAE, 0x86, 0xF1, 0xB9, 0x1C, 0xF6, 0x29, 0x83, 0x95, 0x71, 0x1D, 0xDE, 0x58, 0x0D

Une fois connecté au C2, CASTLETAP peut accepter plusieurs types de commandes via SSL, comme indiqué dans le tableau 4.

Commande

Description

0x1

Télécharger le fichier (à la victime)

0x2

Télécharger le fichier (de la victime)

0x3

Générez un shell de commande basé sur la boîte occupée, sinon revenez à un shell de commande normal.

0x4

Continuer à recevoir

0x5

Réception complète

Lorsqu'une commande était reçue avec succès, la porte dérobée renvoyait la séquence ';7(Zu9YTsA7qQ#vw' comme jeton d'accusé de réception ; cette même chaîne était également envoyée pour signaler la fin de la session.

Une fois CASTLETAP déployé sur les pare-feu FortiGate, l'acteur malveillant s'est connecté aux machines ESXi et vCenter. L'acteur malveillant a déployé VIRTUALPITA et VIRTUALPIE pour établir la persistance, permettant un accès continu aux hyperviseurs et aux machines invitées. Ceci est décrit plus en détail dans le billet de blog, "Bad VIB(E)s Part One: Investigating Novel Malware Persistence Within ESXi Hypervisors."

Les détails techniques qui suivent décrivent le chemin d'attaque emprunté par l'acteur de la menace où le FortiManager a mis en place des listes de contrôle d'accès (ACL) réseau pour restreindre l'accès externe.

Lorsque les ACL ont été implémentées sur l'appareil FortiManager, l'auteur de la menace a perdu l'accès public direct à l'appareil. Pour retrouver l'accès au FortiManager, l'acteur de la menace a pivoté à partir d'un pare-feu FortiGate compromis avec CASTLETAP. L'auteur de la menace a ensuite déployé les trois (3) fichiers malveillants suivants, présentés dans le tableau 5, sur le FortiManager après une reconnexion réussie.

Famille de logiciels malveillants

Chemin du fichier

Description

N / A

/bin/soutien

Lance /bin/auth et /bin/klogd et supprime les deux fichiers avec /bin/support du disque.

TABLEFLIP

/bin/auth

Un utilitaire passif pour configurer la redirection du trafic réseau d'une adresse IP spécifique destinée au FortiManager sur le port TCP 541 vers un autre port spécifié.

REPTILE

/bin/klogd

Un utilitaire de porte dérobée qui écoute un paquet spécialisé pour l'activation.

Le fichier /bin/support (MD5 : 9ce2459168cf4b5af494776a70e0feda) a servi de script de lancement pour exécuter /bin/klogd (variante REPTILE) et /bin/auth (TABLEFLIP). L'attaquant a modifié le fichier de démarrage /etc/init.d/localnet pour exécuter la ligne 'nohup /bin/support &' afin que le script s'exécute à chaque redémarrage du système. Étant donné que le système de fichiers FortiOS en cours d'exécution était une copie éphémère de l'archive rootfs.gz, les fichiers seraient supprimés de la copie éphémère après avoir été chargés en mémoire et persisteraient dans l'archive rootfs.gz, un fichier inaccessible aux utilisateurs sans extraire une image médico-légale. Le contenu de /bin/support peut être vu dans la figure 14.

#!/bin/bash

#cp /bin/sh /bin/top

dormir 30

/bin/klogd

/bin/auth

rm -rf /bin/klogd

rm -rf /nohup.out

rm -rf /bin/support

Pour permettre un accès continu directement depuis Internet, l'auteur de la menace a implémenté TABLEFLIP (MD5 : b6e92149efaf78e9ce7552297505b9d5), un utilitaire de redirection de trafic passif qui écoute sur toutes les interfaces actives les paquets de commandes spécialisés. Avec cet utilitaire en place, et indépendamment des ACL en place, l'auteur de la menace serait en mesure de se connecter directement au FortiManager, comme illustré à la Figure 15.

TABLEFLIP a été configuré pour écouter sur toutes les interfaces actives les paquets TCP et rechercher au début de la charge utile TCP le paquet magique suivant, illustré à la figure 16, pour les paquets destinés au port TCP 541.

17 03 01 01 D8 54 2F 31

Si le nombre magique était trouvé, le logiciel malveillant extrayait une clé XOR du décalage 0xB de la charge utile TCP. Cette clé a été utilisée comme graine pour le déchiffrement séquentiel basé sur XOR. Le décalage de charge utile TCP à partir de 0xC a été déchiffré à l'aide de ce schéma. La figure 17 montre la structure de la charge utile.

structure _payload

{

_DWORD magic_dword1 ;

_DWORD magic_dword2 ;

_BYTE inutilisé[3] ;

_BYTE xor_key ;

commande _DWORD ;

_DWORD IP ;

port _WORD ;

} ;

Le logiciel malveillant a ensuite tenté d'extraire la commande, l'adresse IP et le port de la charge utile. Le Tableau 6 décrit la commande et les actions entreprises lorsqu'une commande a été reconnue.

Commande

Description

0xFFFEFDFC

Activer la redirection du trafic avec l'IP source correspondant à l'IP extraite et au port 541 vers le port de destination extrait

0xFCFDFEFF

Désactiver la redirection du trafic avec l'IP source correspondant à l'IP extraite et au port de destination spécifié

La redirection du trafic a été réalisée en ajoutant des règles iptables sur le système FortiManager, comme illustré à la figure 18. avec l'adresse IP source et le port de redirection spécifiés dans le paquet de commande. iptables a été exécuté pour vérifier si une règle PREROUTING pour cette combinaison IP et port existait déjà. Si la combinaison n'était pas trouvée, une nouvelle règle de redirection était ajoutée dans la chaîne PREROUTING. Les règles sous la chaîne PREROUTING ont été traitées immédiatement une fois que le paquet est reçu sur une interface.

Lorsqu'il était chargé de supprimer la redirection du trafic, TABLEFLIP utilisait la commande grep pour filtrer toutes les lignes de la chaîne PREROUTING contenant l'adresse IP et le port de redirection d'intérêt, en capturant les identifiants de règle appropriés avec awk. Ces identifiants ont été renvoyés à iptables avec xargs pour les supprimer de la chaîne PREROUTING, comme le montre la figure 19.

Pour obtenir un accès persistant sur l'appareil FortiManager, l'auteur de la menace a déployé une porte dérobée avec le nom de fichier /bin/klogd (MD5 : 53a69adac914808eced2bf8155a7512d) que Mandiant appelle REPTILE, une variante d'un rootkit de module de noyau Linux (LKM) accessible au public. Avec l'aide de TABLEFLIP, l'auteur de la menace a réussi à transférer le trafic et à accéder à la porte dérobée REPTILE à l'aide des règles de redirection du trafic iptables.

Une fois exécuté, REPTILE a créé un socket de paquets pour recevoir les paquets OSI de couche 2. Lorsqu'un paquet était reçu, la porte dérobée effectuait la vérification vue dans le pseudocode de la figure 20 pour déterminer si une chaîne magique était présente.

single_byte_xor_key = (mois * année) * jour % 255

index = 2 * data_received_on_port_8[7] ;

data_to_decode_ptr = *((char *)&data[index + 12] + 1)

je = 0

tandis que ( je < strlen(data_to_decode) ) decoded_data[i] = data_to_decode_ptr[i++] ^ single_byte_xor_key;

strncmp(&decoded_data, "mznCvqSBo", 9)

Le tableau 7 montre les chaînes magiques interprétées par REPTILE et leurs actions résultantes.

Corde Magique

Description

mznCvqSBo

Analyser les informations C2 du paquet OSI de couche 2 et s'y connecter via SSL.

hpaVAj2FJ

Tue le processus REPTILE (recherché uniquement si la première chaîne magique n'est pas trouvée)

Semblable à la méthode utilisée par CASTLETAP pour décoder les informations C2, REPTILE a dérivé une clé XOR à un octet de l'horodatage Epoch pour décrypter les données de charge utile, ce qui a entraîné un changement quotidien de la clé de cryptage. La figure 21 montre la formule qui a été utilisée pour calculer la clé XOR.

(mois * (année + 1900)) * jour % 255

Si la chaîne magique "mznCvqSBo" était trouvée, un shell inversé était créé avec l'adresse IP C2 et le port de destination extraits du reste de la charge utile du paquet d'activation. Lorsque la première chaîne magique n'était pas présente, le binaire cherchait la deuxième chaîne magique "hpaVAj2FJ". Si cette deuxième chaîne magique a été trouvée, le processus REPTILE se terminera. Si aucune chaîne magique n'a été trouvée, la porte dérobée a continué à écouter d'autres connexions.

Mandiant a analysé la mémoire système du FortiManager et identifié les commandes de l'acteur malveillant utilisées pour effacer des événements spécifiques contenant l'adresse IP de l'acteur malveillant à partir de plusieurs sources de journal. Les commandes illustrées à la Figure 22 ont été utilisées par l'auteur de la menace pour supprimer les entrées de journal contenant l'adresse IP utilisée pour se connecter à la porte dérobée THINCRUST.

Dans une tentative d'ignorer les contrôles de vérification de signature numérique effectués sur le système de fichiers au démarrage, l'auteur de la menace a ajouté la commande illustrée à la figure 23 à la configuration de démarrage /etc/init.d/localnet dans l'archive rootfs.gz des appareils FortiManager et FortiAnalyzer.

En comparant le compromis /bin/smit (a388ebaef45add5da503e4bf2b9da546) avec une version propre de FortiManager et FortiAnalyzer, le binaire modifié contenait une différence d'un seul octet. L'emplacement modifié dans /bin/smit est exécuté lorsque l'argument de ligne de commande mount est donné au démarrage du système. Normalement, la fonction de montage effectuerait des vérifications de signature numérique OpenSSL 1.1.0 sur les fichiers de la figure 24 par rapport à /data/.fmg_sign, mais cette modification a changé une instruction de saut conditionnel en une instruction de saut inconditionnel qui a toujours sauté les vérifications de signature numérique normalement effectuées sur les fichiers système.

/data/extlinux.sys

/data/extlinux.conf

/data/boot.msg

/data/vmlinuz

/data/rootfse-fe

Étant donné que la commande mount s'exécute avant /etc/init.d/localnet au démarrage du système, la commande dd écrasera le 22 866e octet de /bin/smit avec le caractère "t", ramenant le binaire à un état qui semble n'avoir jamais été altéré, même si le fichier a été haché.

UNC3886 est un groupe de cyberespionnage avancé avec des capacités uniques dans la façon dont ils opèrent sur le réseau ainsi que les outils qu'ils utilisent dans leurs campagnes. UNC3886 a été observé ciblant les technologies de pare-feu et de virtualisation qui ne prennent pas en charge EDR. Leur capacité à manipuler le firmware du pare-feu et à exploiter un zero-day indique qu'ils ont acquis une compréhension plus approfondie de ces technologies. UNC3886 a modifié les logiciels malveillants accessibles au public, ciblant spécifiquement les systèmes d'exploitation *nix.

Un autre groupe de menaces sans rapport avec l'UNC3886, soupçonné de provenir de Chine, a récemment été observé ciblant des vulnérabilités de type « jour zéro » dans Fortinet, comme l'a signalé Mandiant à la mi-janvier 2023. Mandiant continue de rassembler des preuves et d'identifier les chevauchements entre l'UNC3886 et d'autres groupes attribués à l'APT chinois.

L'activité abordée dans ce billet de blog est une preuve supplémentaire que les acteurs avancés de la menace de cyberespionnage tirent parti de toutes les technologies disponibles pour persister et traverser un environnement cible, en particulier les technologies qui ne prennent pas en charge les solutions EDR. Cela représente un défi unique pour les enquêteurs, car de nombreuses appliances réseau manquent de solutions pour détecter les modifications d'exécution apportées au système d'exploitation sous-jacent et nécessitent une implication directe du fabricant pour collecter des images médico-légales. La communication et la collaboration inter-organisationnelles sont essentielles pour fournir à la fois aux fabricants une notification précoce des nouvelles méthodes d'attaque dans la nature avant qu'elles ne soient rendues publiques et aux enquêteurs ayant l'expertise nécessaire pour mieux faire la lumière sur ces nouvelles attaques.

Mandiant recommande aux organisations utilisant ESXi et la suite d'infrastructure VMware de suivre les étapes de renforcement décrites dans cet article de blog afin de minimiser la surface d'attaque des hôtes ESXi.

Remerciements particuliers à Jeremy Koppen, Kirstie Failey, Bryce Bucklin, Jay Smith, Nicholas Luedtke, Ronnie Salomonsen, Nino Isakovic, Charles Carmakal et Fortinet PSIRT pour leur aide dans l'enquête, l'examen technique et la création de détections pour les familles de logiciels malveillants abordées dans cet article de blog. De plus, nous tenons également à remercier Fortinet et VMware pour leur collaboration à cette recherche.

Fortinet a publié deux ressources supplémentaires couvrant CVE-2022-41328 et une analyse de l'activité des attaquants identifiés.

Impact

Évasion de la défense

Accès aux identifiants

Découverte

Collection

Exécution

Commander et contrôler

Mouvement latéral

Taper

Valeurs

Description

Commande FortiGate

exécuter le contrôleur sans fil hs20-icon upload-icon ftp ../../../../../../bin/lspci

Une tentative d'exécution de cette commande ou de commandes similaires contenant une traversée de répertoire indique une tentative d'exploitation de CVE-2022-41328 pour télécharger un fichier dans un répertoire normalement restreint

Commande FortiGate

exécuter le contrôleur sans fil hs20-icon upload-icon tftp ../../../../../../bin/lspci

Une tentative d'exécution de cette commande ou de commandes similaires contenant une traversée de répertoire indique une tentative d'exploitation de CVE-2022-41328 pour télécharger un fichier dans un répertoire normalement restreint

Nom de fichier

/bin/fgfm

Exemple CASTLETAP trouvé sur un appareil FortiGate

Fichier lié symboliquement

/bin/lspci->/bin/sysctl

lspci devrait être un binaire autonome dans les appareils FortiGate. Un lien symbolique suggère qu'une modification a été apportée au système de fichiers

URI

/p/util/show_device_info

Un appel API créé par l'acteur de la menace qui a agi comme une porte dérobée persistante sur les appareils FortiManager

URI

/p/utils/fortigate_syslog_send

Un appel d'API créé par l'acteur de la menace qui a agi comme une porte dérobée persistante sur les appareils FortiAnalyzer

Fonction Python

get_device_info

Une fonction python malveillante ajoutée à /usr/local/lib/python3.8/proj/util/views.py sur les appareils FortiAnalyzer et FortiManager qui a fourni aux pirates une porte dérobée persistante

Nom de fichier

/bin/soutien

Script d'acteur de menace qui lance /bin/auth (TABLEFLIP) et /bin/klogd (REPTILE) et supprime les deux fichiers avec /bin/support du disque

Nom de fichier

/bin/auth

Exemple TABLEFLIP - Un utilitaire passif pour configurer la redirection du trafic d'une adresse IP spécifique destinée au FortiManager sur TCP541 vers un autre port spécifié.

Nom de fichier

/bin/klogd

REPTILE - Un utilitaire de porte dérobée qui écoute un paquet spécialisé pour l'activation

Changement de configuration

printf "t" | dd of=/bin/smit bs=1 count=1 conv=notrunc seek=22866 2>/dev/null

Modification de la configuration apportée à /etc/init.d/localnet sur les appareils FortiAnalyzer et FortiManager pour annuler un binaire après sa modification afin de contourner la vérification de la signature numérique des fichiers système

MD5

9ce2459168cf4b5af494776a70e0feda

Script d'acteur de menace qui lance /bin/auth (TABLEFLIP) et /bin/klogd (REPTILE) et supprime les deux fichiers avec /bin/support du disque

MD5

b6e92149efaf78e9ce7552297505b9d5

Échantillon TABLEFLIP

MD5

53a69adac914808eced2bf8155a7512d

Exemple de variante REPTILE

MD5

a388ebaef45add5da503e4bf2b9da546

/bin/smit modifié

MD5

88711ebc99e1390f1ce2f42a6de0654d

Exemple de réseau local

MD5

e2d2884869f48f40b32fb27cc3bdefff

Échantillon CASTLETAP

MD5

53a69adac914808eced2bf8155a7512d

Exemple de variante REPTILE

MD5

64bdf7a631bc76b01b985f1d46b35ea6

Échantillon THINCRUST

MD5

a86a8fe875a89816e5808588154a067e

Échantillon THINCRUST

MD5

3e43511c4f7f551290292394c4e21de7

Associé à THINCRUST

SHA1

75c092098e3409d366a46fdde6a92ff97d29cee1

Smit échantillon

SHA1

9dca7f1af5752bb007e5cc55acd2511f03049ee5

Échantillon TABLEFLIP

SHA1

8c40fc87fa3b25a559585b10a8ca11c81fb09f75

Échantillon CASTLETAP

SHA1

3109b890901499f7ebb90f8870a7d1617d27e7c9

Exemple de variante REPTILE

SHA1

b8bdaa1bd204a6c710875b0c4265655d1fd37d52

/bin/exemple de support

SHA1

1a077212735617a665a6b631e34a6aedcbc41713

Échantillon THINCRUST

SHA1

d5f8436e9815358e33b8243abda76c9b398943e2

Échantillon THINCRUST

SHA1

8ef5159944d048fe84e51a818c9b11ebcfa98517

Associé à THINCRUST

SHA256

245e4646e5d984c2da4cfe223bb2fae679441bcf42b254fc193ae97dc32af7ad

Exemple de réseau local

SHA256

9fb09fe6db61fbdd19ac9c368e2f64fb9606119649830762fa467719c480ed44

Smit échantillon

SHA256

18afbad17dee0e4330a85b782e8e580c6125d8a7127cda69ad0e2728d505a6f5

Échantillon TABLEFLIP

SHA256

a00fed53b1ece4610c8b52934c20af3667d455f092a77f8d9bc46fdb9047e41a

Échantillon CASTLETAP

SHA256

eb6af99148f0ce5b58e414162ff2b7567b4cf08953862a088996365ff306014b

Exemple de variante REPTILE

SHA256

33c22b2db8c0948c67204485972d2eb856e13dca16132371337fc3534e3df16d

/bin/exemple de support

SHA256

abefe121e5c895bf63be80152ccbe2d7bb5ad985aa3ab989bcb7c0804b90d004

Échantillon THINCRUST

SHA256

2266667af7532a32b9c21c330a9fe56356ca66610e39654804a7262f2af61017

Échantillon THINCRUST

SHA256

4e4c5e5ca588bd84b67a37b654ec522768fa83e535ff795a5c196da8f8b9737d

Associé à THINCRUST

règle M_Hunting_Util_TABLEFLIP_1

{

méta :

auteur = "Mandiant"

description = "Recherche le binaire TABLEFLIP"

md5="b6e92149efaf78e9ce7552297505b9d5"

chaînes :

$z1 = "%1$s.*%2$d" mot complet

$x1 = mot complet "/proc/self/exe"

$x2 = mot complet "socket"

$x3 = "127." mot complet

$x4 = mot complet "iptables -t nat"

$s1 = "iptables -t nat -S PREROUTING | grep %1$s | grep %2$d || iptables -t nat -A PREROUTING -p tcp -s %1$s --dport 541 -j REDIRECT --to-port %2$d"

$s2 = "iptables -t nat -S PREROUTING | tail -n +2 | grep -n -E '%1$s.*%2$d' | awk -F: '{print $1}'| xargs iptables -t nat -D PREROUTING"

condition:

uint32(0) == 0x464c457f et taille de fichier < 5 Mo et @x1 <= @x2 et @x2 <= @x3 et @x3 <= @x4 et ( $z1 ou n'importe lequel de ($s*) )

}

règle M_Hunting_Backdoor_REPTILE_1

{

méta :

auteur = "Mandiant"

description = "Recherche la variante REPTILE de la porte dérobée ELF"

md5="53a69adac914808eced2bf8155a7512d"

chaînes :

$x1 = ";7(Zu9YTsA7qQ#vw"

$x2 = "mznCvqSBo"

$x3 = "hpaVAj2FJ"

$x4 = "%d.%d.%d.%d"

$x5 = "HISTFILE="

$x6 = "TERME"

$x7 = { 58 90 AE 86 F1 B9 1C F6 29 83 95 71 1D DE 58 0D } // extrait de FE_Hunting_Linux_TINYSHELL_2_FEBeta.yara

condition:

uint32(0) == 0x464c457f et tous et #x4 >= 3 et #x6 == 1 et taille de fichier < 15 Mo

}

règle M_Hunting_Backdoor_CASTLETAP_1

{

méta :

auteur = "Mandiant"

description = "Recherche les chaînes observées dans le binaire CASTLETOP ELF"

md5="e2d2884869f48f40b32fb27cc3bdefff"

chaînes :

$x1 = ";7(Zu9YTsA7qQ#vw"

$x2 = "qWWlC0v6yYh2yxu"

$x3 = "1qaz@WSXa"

$x4 = "hpaVAj2FJ"

$x5 = "%d.%d.%d.%d"

$x6 = "HISTFILE="

$x7 = "TERME"

$x8 = "/tmp/busybox"

$x9 = { 58 90 AE 86 F1 B9 1C F6 29 83 95 71 1D DE 58 0D }

condition:

uint16(18) == 183 et

uint16(16) == 0x02 et

uint32(0) == 0x464c457f et 1 de ($x*) et #x5 >= 3 et #x7 == 1 et taille de fichier < 15 Mo

}

règle M_Hunting_Backdoor_CASTLETAP_2

{

méta :

auteur = "Mandiant"

description = "Trouve le modèle d'octet lié à la fonction de décodage XOR"

md5="e2d2884869f48f40b32fb27cc3bdefff"

chaînes :

$x1 = { ?? 14 40 B9 ?? B0 1D 11 ?? 10 40 B9 [5] 0C 40 B9 [5] 1F 80 52 [9] 1F 00 12 }

condition:

uint16(18) == 183 et

uint16(16) == 0x02 et

uint32(0) == 0x464c457f et n'importe lequel d'entre eux et taille de fichier < 15 Mo

}

Lien vers le flux RSS

Les experts Mandiant sont prêts à répondre à vos questions.