Le 23 mai 2023, Barracuda a annoncé une vulnérabilité (CVE-2023-2868) dans son appliance Email Security Gateway qui a été exploitée dans la nature dès le mois d'octobre 2022. Le 15 juin 2023, Mandiant a publié une analyse détaillée des activités et des acteurs de la menace impliqués dans la campagne qui exploitait activement CVE-2023-2868. Par la suite, l'équipe Emerging Threats de Proofpoint a publié une règle de détection Suricata (SID 2046280) pour détecter les tentatives d'exploitation de la vulnérabilité signalée. Au cours d'une réunion avec un client Vectra AI , une inquiétude a été soulevée sur le fait que la règle existante pourrait ne pas fonctionner comme prévu. Après avoir effectué des tests initiaux, nous avons constaté que la règle ne parvenait pas à alerter sur un exploit de démonstration spécifique, malgré la livraison réussie de la charge utile de l'exploit.
Nous avons analysé la règle et l'exploit connexe et identifié la lacune de détection spécifique, qui était causée par un ordre non déterministe du contenu lié à l'exploit dans la charge utile de l'exploit (plus de détails sont fournis dans la section "Un bref aperçu de l'exploit de la preuve de concept" ci-dessous). Une fois la faille identifiée, nous avons pu réécrire une règle afin de fournir la couverture de détection nécessaire. Après avoir soumis nos conclusions à l'équipe EmergingThreats de Proofpoint, celle-ci a publié une nouvelle règle de détection M2. Ce rapport explique le processus d'analyse et de rédaction des règles utilisé pour la règle de détection M2 qui a permis d'éliminer le faux négatif confirmé.
TL;DR
La règle ET de Proofpoint est défectueuse en raison d'une hypothèse intégrée selon laquelle tout le monde suit les règles, même ceux qui ne le font pas. Dans cette analyse, nous avons rencontré une archive TAR manipulée qui glisse une charge utile au-delà de la règle de détection ET pour CVE-2023-2868 parce que l'auteur de l'exploit n'a pas suivi les règles. Et même si une règle de détection améliorée est en place, le problème demeure : si nous rencontrons demain une autre structure de fichier manipulée, pourrait-elle à nouveau contourner les règles de détection de l'ET ?
1. Anatomie de CVE-2023-2868
Le rapport de Mandiant fournit une explication de la vulnérabilité, mais pour plus de commodité, nous l'avons résumée dans l'illustration ci-dessous. Comme vous pouvez le voir, certaines versions de Barracuda Email SecurityAppliance sont vulnérables à une faille d'injection.
Afin d'identifier cette charge utile malveillante, l'équipe de recherche sur les menaces émergentes a mis au point une salle de détection qui recherche les "'`" (guillemet simple, coche arrière) et les "`'" (coche arrière, coche simple) dans des types de paquets particuliers. (coche arrière, guillemet simple) dans certains types de paquets. Comme nous le verrons, leur méthode d'élaboration des règles a permis à certaines preuves de concept de ne pas être détectées.
2. Un bref aperçu de l'exploit de validation du concept
En nous penchant sur l'exploit de démonstration de la vulnérabilité (PoC), disponible ici, nous avons commencé à identifier la charge utile sous-jacente utilisée qui devrait déclencher la règle de détection des menaces émergentes. Comme indiqué ci-dessous, la variable "CMD" utilise la même structure de commande de base que celle décrite dans le rapport de Mandiant :
Notez que la variable "PAYLOAD" commence par un guillemet simple et une coche et que la variable "CMD" se termine par une coche et un guillemet simple. C'est ce qui déclenchera l'injection de commande.
Un regard sur le PoC over the wire dans l'hexagone
Voici le résultat d'une représentation hexadécimale de l'archive tar générée contenant la charge utile présentée ci-dessus :
"PAYLOAD", qui sont les modèles d'injection, sont surlignés en rouge. La chaîne de commande assignée à la variable "CMD" est surlignée en bleu :]
Observez, tout en haut de l'archive, que des restes de la variable CMD sont présents, ainsi que les motifs d'injection \x60\x27 (coche arrière, guillemets simples). Nous reviendrons sur cette partie importante plus tard.
Structure normale d'une archive Tar
Avant de plonger dans les défauts de la règle de détection, il est important de comprendre la structure d'une archive tar normale. Les archives tar sont organisées en blocs de 512 octets. Fondamentalement, le format d'une archive tar est le suivant :
- L'"en-tête" contient le nom du fichier, ainsi que quelques métadonnées supplémentaires.
- Le "contenu" contient les données réelles du fichier.
Un coup d'œil sur une archive Tar normale dans l'hexagone
Une archive Tar "normale" est un fichier créé par un utilitaire qui suit les règles et respecte le format TAR des systèmes UNIX ou le format USTAR défini par la norme POSIX 1003.1. Ceci est un dump hexadécimal d'une archive tar normale contenant trois fichiers normaux nommés 1, 2 et 3, en utilisant l'utilitaire tar :
Nous pouvons voir le fichier nommé 1, suivi de quelques codes d'octets, puis le contenu du fichier "hello 1", suivi du fichier nommé 2 et ainsi de suite. Il est clair que l'utilitaire de création d'archives tar place les données d'en-tête et de contenu dans l'ordre décroissant des noms de fichiers. En d'autres termes, il est attentif aux règles dictées par la norme de format de fichier et les respecte.
Il convient de noter que la structure du fichier est différente de celle générée par l'exploit et présentée dans la première section. L'exploit PoC contient une série de commandes dans l'en-tête au lieu de noms de fichiers comme prévu. Pour rendre cela possible, l'auteur de l'exploit a dû faire preuve d'un peu d'ingéniosité.
Dissection de l'exploit R7
L'exploit écrit par l'équipe de Rapid7 Security Researcher comporte une partie dédiée, avec des commentaires, sur la classe Ruby "TarWriter" :
Cet exploit annule les vérifications de la taille des noms de fichiers effectuées à l'origine par la fonction "split_name()" :
3 instructions "if" ont été supprimées de la fonction originale. Ces 3 instructions soulèvent la question "TooLongFileName" (nom de fichier trop long) pour vérifier si :
1. Le chemin d'accès au fichier est trop long
2. Le nom du fichier est trop long
3. Le chemin de base du fichier est trop long
Si l'on examine la charge utile de l'exploit et que l'on compte les caractères, on obtient 129 octets :
D'après le code du PoC, si la commande à exécuter est supérieure à 100 octets, elle sera répartie sur plusieurs "entrées de fichier" dans l'archive tar. Nous mettons "entrées de fichier" entre guillemets car l'archive tar malveillante ne contient pas réellement de fichiers - elle contient une séquence d'échappement et des commandes intégrées que l'attaquant souhaite exécuter.
En revoyant le fichier hexadécimal de l'archive tar malveillante, nous pouvons maintenant comprendre pourquoi la première entrée de l'archive tar est un `' (coche arrière, guillemet simple) et la fin de la variable CMD, qui devrait se trouver à la fin de la commande.
Étant donné que la commande dépasse la limite de 100 octets imposée à la structure des noms de fichiers pour l'en-tête d'un fichier, la commande a été divisée en deux entrées de fichier, la deuxième entrée de fichier ne contenant que la terminaison p"`' (lettre p, guillemet double, guillemet arrière, guillemet simple). Cette entrée de fichier apparaît au début de l'archive tar parce que le contenu de l'archive tar est trié par ordre décroissant et qu'une chaîne p"`' (lettre p, guillemet double, guillemet arrière, guillemet simple) précède une chaîne '`s (guillemet simple, guillemet arrière, lettre s) lorsqu'elle est triée dans l'ordre décroissant :
Alors que l'ordre dans une archive tar est cohérent, l'ordre de la séquence d'échappement et du contenu des commandes de la charge utile de l'exploit n'est pas déterministe du point de vue de la règle de détection, car l'ordre varie en fonction de la longueur combinée et des caractères utilisés dans les commandes incorporées dans la charge utile.
3. Explication de haut niveau de la règle de détection :
Une fois que nous avons mieux compris la vulnérabilité, ce qu'il faut pour l'exploiter, et confirmé les modèles à discriminer dans l'exploitation, nous avons porté notre attention sur la règle de détection du fichier emerging-exploit.rules :
Pour simplifier, cette règle recherche trois modèles :
1. Tous les paquets SMTP provenant de n'importe où, destinés à n'importe quel serveur SMTP contenu dans le mappage$SMTP_SERVERS. Notez que par défaut, Suricata associe $SMTP_SERVERS à $HOME_NET, de sorte que tout serveur SMTP interne sera couvert par la règle.
a. Qui contient une pièce jointe d'archive tar valide ; la pièce jointe doit correspondre aux numéros magiques d'une archive TAR.
b. Il contient les deux motifs "|27 60|" et "|60 27|".
Les mots-clés recherchés sont la représentation hexadécimale des caractères ASCII suivants : "`" (guillemet simple, coche arrière) et "`'" (coche arrière, guillemet simple). (coche arrière, guillemet simple). Les caractères "'`" (guillemet simple, tic-tac arrière) sont utilisés pour déclencher l'exécution de la commande comme expliqué précédemment. Voici la représentation hexadécimale de l'exploit avec les trois motifs mis en évidence que la règle de détection recherche :
En revenant à la règle, nous constatons qu'il existe également un paramètre "distance" et un paramètre "à l'intérieur" qui peuvent être associés pour affiner une règle. Les paramètres sont utilisés comme suit :
- Distance : place le curseur à l'endroit où commencer l'analyse.
- Distance : 0 signifie que le motif peut se trouver n'importe où après la correspondance précédente +0 octet. Donc juste après \x27\x60 dans notre exemple ci-dessus.
- Dans : Limite la distance à laquelle la règle doit s'appliquer après le dernier match.
- A l'intérieur de : 500 signifie qu'il n'y aura de correspondance que si le contenu correspond à la charge utile dans un rayon de 500 octets.
Les paramètres "within" et "distance" sont expliqués dans la documentation de Suricata.
4. Défauts observés dans la règle originale comparée à notre exploit
Comme le dit l'adage, "une image vaut mille mots", un extrait ci-dessous montre comment la règle de détection se comporte dans l'exploit Rapid7 :
Cet extrait de la règle :
Le vidage ci-dessus montre facilement pourquoi la règle de détection ne se déclenche jamais : dans notre échantillon, elle ne trouvera jamais l'autre motif car il est placé au début de l'archive.
5. Variante de la règle de détection M2 pour cet exploit non détecté
À la lumière des résultats ci-dessus, une nouvelle règle de détection M2, révision 2, a été publiée le 29 septembre par l'équipe Emerging Threats de Proofpoint sous le numéro SID 2048146 :
Voici un aperçu de ce que la règle de détection M2 vérifie, en utilisant la même représentation hexagonale du même exploit d'archive tar que précédemment :
6. Résolution
À la lumière des lacunes évidentes de la règle ET originale de Proofpoint (SID 2046280), il apparaît clairement que le fait de s'appuyer uniquement sur des règles et des normes fixes a ses limites dans le paysage en constante évolution de la cybersécurité. La sagesse intemporelle du général MacArthur, "Les règles sont surtout faites pour être enfreintes", nous rappelle brutalement que les acteurs malveillants exploiteront n'importe quelle vulnérabilité, y compris les ensembles de règles rigides.
Grâce à cette analyse, nous avons pu observer un exemple frappant des limites de cette approche, via la manipulation d'une structure d'archive TAR qui a permis à une charge utile d'échapper à la détection initiale de l'ET pour la CVE-2023-2868. Cet événement souligne l'urgence d'adopter une stratégie de sécurité plus adaptable et plus dynamique.
Alors que nous nous tournons vers l'avenir, il est impératif de nous éloigner de la rigidité et d'adopter un paradigme de sécurité plus holistique et proactif. Au lieu de nous contenter de réfléchir aux probabilités d'une nouvelle violation des règles, nous devrions nous efforcer activement d'améliorer nos mesures de cybersécurité en faisant évoluer en permanence nos mécanismes de détection et de défense. En reconnaissant les limites des règles fixes, nous pouvons mieux nous préparer à un avenir incertain où les cybermenaces évoluent continuellement. Ce faisant, nous pouvons renforcer notre posture de sécurité et mieux nous protéger contre les acteurs malveillants qui cherchent constamment à contourner les règles. L'adoption d'une stratégie qui va au-delà de la seule dépendance à l'égard des technologies fondées sur des règles s'aligne non seulement sur l'approche multicouche de la défense en profondeur, mais incite également le lecteur à adopter les stratégies les plus efficaces actuellement, y compris le modèle de confiance zéro.
Afin de fournir une recommandation immédiatement applicable, nous proposons les conseils suivants :
Pour les déploiements de Suricata qui utilisent le fichier emerging-all.rules et qui ont une gestion automatisée des mises à jour des jeux de règles, la règle de détection révisée devrait déjà être en place, en supposant que l'outil de mise à jour a été exécuté après le 29/9/23. Pour vérifier que le jeu de règles actuellement appliqué contient la règle de détection révisée, recherchez "2048146" dans vos fichiers de jeux de règles locaux. Si le SID 2048146 n'est présent dans aucun des jeux de règles actuellement appliqués, mettez à jour les jeux de règles avec la dernière source disponible de Emerging Threats.
Calendrier :
- 19/9/23 : Soumission des conclusions via le portail de l'ET. Je n'ai reçu aucun accusé de réception.
- 21/9/23 : Envoi d'un courriel à support@emergingthreats.net afin d'enregistrer la soumission et d'informer l'équipe Emerging Threat de la politique de divulgation responsable de Google qui sera suivie ici.
- 21/9/23 : ET Security Researcher m'a répondu par e-mail et a accepté de publier une version M2 de la règle de détection dans le cadre de sa publication quotidienne, aujourd'hui à 19 heures (heure française).
- 9/21/23 : Remarqué que la règle de détection de la variante M2 récemment publiée ne déclenche pas d'alerte contre l'exploit R7.
- 21/9/23 : Envoi d'un courriel à un chercheur d'ET Security au sujet de la non-détection de la charge utile de l'exploit avec la règle de détection M2 récemment publiée.
- 9/29/23 : Une révision 2 de la règle de variante M2 a été publiée à 7PM ET et détecte avec succès la charge utile de l'exploit R7.
Référence:
Documentation de Suricata : https://docs.suricata.io/en/suricata-6.0.1/rules/payload-keywords
html#withinhttps://docs.suricata.io/en/suricata-6.0.1/rules/payload-keywords.html#distance
Github POC exploit : https://github.com/cfielding-r7/poc-cve-2023-2868/blob/main/poc_cve_2023_2868.rb
Exploit expliqué : https://www.mandiant.com/resources/blog/barracuda-esg-exploited-globally
Règle de l'ET : http://rules.emergingthreats.net/open/suricata-5.0/emerging-all.rules