Nul besoin d’utiliser Internet Explorer pour que son héritage vous ait rendu vulnérable à LogCrusher et OverLog, deux vulnérabilités Windows découvertes par l’équipe du laboratoire de détection des menaces de Varonis.
Microsoft a cessé de prendre en charge Internet Explorer le 15 juin 2022. Cependant, le fait qu’IE soit profondément ancré dans l’écosystème Windows impacte la sécurité et la stabilité des systèmes d’exploitation Windows actuels.
L’une des fonctionnalités de l’intégration d’IE et de Windows est un journal d’événements spécifique à Internet Explorer présent sur tous les systèmes d’exploitation Windows actuels. Il possède un ensemble distinct d’autorisations qui permettent deux exploits sur les systèmes Windows :
LogCrusher, qui permet à n’importe quel utilisateur du domaine de faire planter à distance l’application Journal d’événements de n’importe quelle machine Windows sur le domaine.
OverLog, qui provoque une attaque par déni de service (DoS) à distance en remplissant l’espace disque de n’importe quelle machine Windows sur le domaine.
Dans cet article, nous expliquerons comment fonctionnent ces deux exploits et nous détaillerons leur déroulement respectif. Dans le cadre de nos recherches, nous avons rapidement révélé ces vulnérabilités à Microsoft, qui a publié un correctif partiel le 11 octobre 2022. Nous exhortons tous les utilisateurs à corriger leurs systèmes.
MS-EVEN entre en scène
Protocole Microsoft Event Log Remoting Protocol
Ces exploits (LogCrusher et OverLog) utilisent tous deux des fonctions du protocole MS-EVEN (Microsoft Event Log Remoting Protocol), qui permet de manipuler à distance les journaux d’événements d’une machine.
Ce qu’en dit Microsoft :
Le protocole de manipulation à distance du journal d’événement est un protocole basé sur RPC qui expose les méthodes d’appel de procédure à distance (RPC) pour lire les événements, à la fois dans les journaux d’événements en direct et dans les journaux d’événements de sauvegarde sur des ordinateurs distants.
Handle sur un journal Internet Explorer
OpenEventLogW est une fonction d’API Windows qui permet à un utilisateur d’ouvrir un Handle pour un journal d’événements spécifique sur une machine locale ou distante.
Cette fonction est utile pour les services qui peuvent l’utiliser pour lire, écrire et effacer les journaux d’événements pour les machines distantes, sans avoir à se connecter manuellement aux machines en question.
La fonction nécessite deux paramètres :
lpUNCServerName : nom de la machine distante ou NULL dans le cas d’une connexion locale.
IpSourceName : le journal d’événements spécifique vers lequel ouvrir le Handle.
Par défaut, les utilisateurs sans privilège d’administration ne peuvent obtenir de Handle pour les journaux d’événements des autres machines. La seule exception à cette règle est l’ancien journal « Internet Explorer », qui existe dans toutes les versions de Windows et possède son propre descripteur de sécurité qui remplace les autorisations par défaut.
Le descripteur de sécurité du journal d’événements Internet Explorer se trouve dans la ruche du registre : HKLM\SYSTEM\CurrentControlSet\Services\EventLog\Internet Explorer
Analysons la chaîne du descripteur de sécurité : CustomSD = O:BAG:SYD:(A;;0x07;;;WD)S:(ML;;0x1;;;LW)
Vous avez vu ? Tout est dit dans la ligne DiscretionaryACL !
Cette ACL permet à tout utilisateur d’y lire et d’y écrire des journaux. C’est-à-dire qu’un attaquant peut obtenir un Handle sur le journal, vers chaque machine Windows du domaine, à partir de n’importe quel utilisateur du domaine.
Cela prépare le terrain pour nos deux exploits.
LogCrusher
Un bug logique d’ElfClearELFW
ElfClearELFW est une fonction MS-EVEN qui permet aux administrateurs d’effacer et de sauvegarder à distance les journaux d’événements.
La fonction nécessite deux paramètres :
LogHandle : Handle de journal dans lequel la fonction OpenEventLog est déjà ouverte.
BackupFileName : un pointeur vers une structure de chaîne Unicode qui indique l’emplacement de la sauvegarde du journal d’événements avant qu’il ne soit effacé.
Malheureusement, la fonction ElfClearELFW présente un fâcheux bug lors de la validation de la saisie. Celle-ci s’attend à ce que la structure BackupFileName revienne à zéro, mais lorsque le pointeur vers la structure est NULL, le processus plante.
Déroulement de l’attaque
En combinant ces deux fonctions, il est facile de comprendre le déroulé d’une attaque de LogCrusher. On appelle la fonction OpenEventLog pour le journal d’événements d’Internet Explorer sur la machine victime :
Handle = OpenEventLog(<Machine victime>, "internet explorer") Ensuite, on appelle la fonction ElfClearELFW avec le Handle renvoyé et NULL comme paramètre de BackupFileName :
ElfClearELFW(Handle, NULL)Et le tour est joué. Nous venons tout simplement de faire planter le journal d’événements sur la machine de la victime.
Par défaut, le service Journal d’événements essaiera de redémarrer deux fois de plus. La troisième fois, il restera éteint pendant 24 heures.
Une démonstration de LogCrusher qui fait planter le service Journal d’événements à plusieurs reprises jusqu’à ce qu’il arrête de redémarrer.
D’accord. Mais quel est l’impact ?
En fait, de nombreux contrôles de sécurité reposent sur le fonctionnement normal du service Journal d’événements.
- Sans journaux, les contrôles de sécurité ne servent à rien.
- Dans certains cas, les produits de contrôle de sécurité sont rattachés au service ! Cela signifie que lorsqu’il plante définitivement, le produit plante également.
- Par la suite, cela peut permettre à un attaquant d’utiliser tout type d’exploit généralement détecté en toute impunité, car de nombreuses alertes ne se déclencheront même pas.
Vérification PowerShell du journal d’événements en défaut.
Une impression de déjà-vu ?
Autre découverte intéressante : il se trouve que le bug de la fonction ElfClearELFW a été découvert il y a deux ans et signalé à Microsoft par un chercheur surnommé « limbenjamin ».
À l’époque, il n’était pas possible d’exploiter le bug à partir d’un compte utilisateur normal non-administrateur (et d’Internet Explorer). L’impact n’était donc pas clair et Microsoft a décidé de ne pas le corriger.
OverLog
Avec cette attaque, nous avons pu utiliser la même méthodologie et le même Handle du journal d’événements d’Internet Explorer, avec une autre vulnérabilité de la fonction BackupEventLogW pour provoquer un déni de service permanent pour chaque machine Windows.
Selon Microsoft, la fonction BackupEventLogW :
Ce qu’en dit Microsoft :
Enregistre le journal d’événements spécifié dans un fichier de sauvegarde. La fonction n’efface pas le journal d’événements.
...La fonction BackupEventLog échoue avec l’erreur ERROR_PRIVILEGE_NOT_HELD si l’utilisateur ne possède pas le privilège SE_BACKUP_NAME.
Le bug ici est encore plus simple, et bien qu’il soit indiqué dans la documentation que l’utilisateur qui effectue la sauvegarde doit disposer du privilège SE_BACKUP_NAME, cela n’est pas validé dans le code. Ainsi, chaque utilisateur peut sauvegarder des fichiers sur une machine distante s’il a un accès en écriture à un dossier sur cette machine.
Déroulement de l’attaque
- Obtenir un Handle vers le journal d’événements d’Internet Explorer sur la machine victime (comme précédemment).
- Écrire des journaux arbitraires dans le journal (chaînes aléatoires ; longueurs différentes).
- Sauvegarder le journal dans un dossier inscriptible sur la machine (par exemple : « c:\windows\tasks ») sur lequel chaque utilisateur du domaine dispose d’une autorisation d’écriture par défaut.
- Répéter le processus de sauvegarde jusqu’à ce que le disque dur soit plein et que l’ordinateur cesse de fonctionner.
- La machine victime ne peut plus écrire dans pagefile (mémoire virtuelle), ce qui la rend inutilisable.
Réponse et recommandations de Microsoft
Microsoft a choisi de ne pas corriger complètement la vulnérabilité LogCrusher sous Windows 10 (les systèmes d’exploitation les plus récents ne sont pas affectés).
Depuis la mise à jour du Patch Tuesday du 11 octobre 2022 de Microsoft, le paramètre d’autorisation par défaut, qui permettait aux utilisateurs non administrateurs d’accéder au journal d’événements d’Internet Explorer sur les machines distantes a été restreint aux administrateurs locaux, ce qui réduit considérablement le risque de dommages.
Bien que cette mesure réponde à cet ensemble spécifique d’exploits ciblés sur le journal d’événements d’Internet Explorer, le risque demeure que d’autres journaux d’événement d’applications, accessibles par les utilisateurs, soient utilisés dans des attaques.
Nous recommandons à tous les utilisateurs de systèmes potentiellement vulnérables d’appliquer le correctif fourni par Microsoft et de surveiller toute activité suspecte.
Calendrier
Chronologie du signalement des vulnérabilités et correspondance pertinente :
24/05/2022
Les vulnérabilités OverLog et LogCrusher ont été soumises au Microsoft Security Response Center (MSRC).
2/06/2022
Le MSRC a confirmé « OverLog » et a changé son statut pour « en développement ».
25/07/2022
Le MSRC a clôturé « LogCrusher ». Il a déclaré avoir classé cette vulnérabilité comme moyennement grave, car elle nécessite un accès administrateur et une interaction manuelle pour être exploitée.
26/07/2022
Nous avons renvoyé un e-mail au MSRC, mentionnant spécifiquement que le rapport d’origine indiquait que la vulnérabilité pouvait être exploitée par l’utilisateur du domaine dans la configuration Windows par défaut. Nous n’avons pas reçu de réponse de la part du MSRC.
11/10/2022
Patch Tuesday — La vulnérabilité a été nommée CVE-2022-37981 et corrigée.
25/10/2022
Article de blog publié.
What you should do now
Below are three ways we can help you begin your journey to reducing data risk at your company:
- Schedule a demo session with us, where we can show you around, answer your questions, and help you see if Varonis is right for you.
- Download our free report and learn the risks associated with SaaS data exposure.
- Share this blog post with someone you know who'd enjoy reading it. Share it with them via email, LinkedIn, Reddit, or Facebook.
