Hack the box – Sherlocks (forensic) : découverte et solution de Meerkat

I. Présentation

On se retrouve dans cet article pour une nouvelle solution de l'un des challenges d'investigation numérique/forensic nommés Sherlocks et mis à disposition par la plateforme Hack The Box. Je vous propose ici ma démarche permettant de solutionner le Sherlocks Meerkat, de difficulté "Facile".

Cet article sera notamment l'occasion de comprendre comment peut se dérouler concrètement une cyberattaque, et quels sont les modes opératoires des attaquants et analystes en cybersécurité

Cette solution est publiée en accord avec les règles d'Hack The Box et ne sera diffusée que lorsque le Sherlocks en question sera indiqué comme "Retired".

Technologies abordées	Linux, bash, web, JSON, HTTP
Outils utilisés	Wireshark, sublime text, jsbeautifier

Retrouvez tous nos articles Hack The Box via ce lien :

• IT-Connect - Articles Hack The Box

II. Découverte de l'archive

Dans le cadre de cette investigation, un contexte et une archive sont mis à disposition :

Nous commençons donc par ouvrir l'archive fournie. À l'intérieur, un fichier Wireshark ainsi qu'un fichier JSON :

Le fichier JSON est en format condensé, ou minifié. On peut le rendre plus lisible en faisant l'opération inverse à l'aide de js-beautify :

$ sudo apt install jsbeautifier 
$ cat meerkat-alerts.json |js-beautify > beautified-meerkat-alerts.json

Voilà qui est mieux !

Je ne sais pas vraiment de quel outil viennent ces données, mais il s'agit vraisemblablement d'une solution de sécurité réseau ou d'un IDS (Intrusion Detection System). On y voit différentes données relatives à des alertes de sécurité portant sur des flux réseau (IP destination, source, ports, etc.).

III. Investigation numérique : le cas Meerkat

A. Tâche n°1: l'application web

• Énoncé - Task 1 : We believe our Business Management Platform server has been compromised. Please can you confirm the name of the application running?

La première tâche consiste à retrouver le nom de l'application compromise. J'ai commencé par isoler les signatures dans les alertes depuis le fichier JSON afin d'avoir une vue synthétique de celles-ci :

On voit ici que plusieurs alertes référencent l'application Bonitasoft. La solution de sécurité semble avoir reconnu l'exploit ou l'attaque et l'avoir assigné à une CVE. Si l'on s'intéresse à la capture réseau avec l'outil d'analyse réseau Wireshark et que l'on applique un filtre sur le protocole HTTP, on peut voir que l'application bonita apparaît rapidement :

Astuce au passage : pour appliquer rapidement un filtre Wireshark sur un élément très spécifique d'un paquet, on peut effectuer un clic droit sur l'élément en question puis Apply as Filter :

B. Tâche n°2 : identifiants utilisés

• Énoncé - Task 2 : We believe the attacker may have used a subset of the brute forcing attack category - what is the name of the attack carried out?

Il s'agit de retrouver le nom de l'attaque opérée sur l'application, en sachant qu'elle a un lien avec le brute force et les mots de passe. Commençons par nous renseigner sur les attaques existantes et leurs noms exacts auprès de la référence en la matière, le framework MITRE ATT&CK :

On se doute donc que l'attaque va être l'une de celles-ci. Nous pouvons essayer d'analyser les paquets HTTP du fichier PCAP pour en savoir plus (Filtre wireshark : HTTP). S’il s'agit d'une attaque concernant l'authentification, les requêtes qui nous intéressent sont les requêtes POST (à moins que l'application soit vraiment très ancienne, à l'époque où les identifiants transitaient en paramètre GET...). Améliorons notre filtre Wireshark :

Nous pouvons voir que plusieurs requêtes POST ont été faites, chacune avec des identifiants bien précis, soit l'identifiant qui semble être celui par défaut (install:install), soit une adresse mail avec un mot de passe. On observe notamment qu'il n'y a jamais deux fois le même username de testé, il ne s'agit pas d'une attaque par brute force. L'attaquant semble savoir à l'avance quel mot de passe va avec quelle adresse mail.

L'attaquant a donc forcément récupéré ces informations avant de procéder à son attaque. Il s'agit donc d'une attaque par Credential Stuffing où l'attaquant utilise des identifiants valides qu'il a récupéré précédemment (achat sur le darknet, campagne de phishing, etc.).

C. Tâche n°3 : utilisation d'une CVE

• Énoncé - Task 3 : Does the vulnerability exploited have a CVE assigned - and if so, which one?

Ici, il faut revenir sur les alertes de sécurité récupérées dans le format JSON, la CVE en question est déjà identifiée :

L'attaquant a exploité la CVE-2022-25237.

D. Tâche n°4 : contournement de filtre

• Énoncé - Task 4 : Which string was appended to the API URL path to bypass the authorization filter by the attacker's exploit?

D'après la question, l'attaquant aurait modifié l'URL durant son attaque sur l'API afin de contourner un filtrage en place. Voyons cela dans la capture réseau.

Nous pouvons voir qu'après plusieurs tentatives d'authentification infructueuses, l'attaquant parvient à trouver une combinaison valide puisqu'il atterrit sur l'API. On peut notamment observer que toutes les URL comportent un ;i18ntranslation. J'ai du mal à voir l'intérêt d'ajouter cette chaîne de caractère, mais cela semble être en relation avec la CVE exploitée.

E. Tâche n°5 : attaque par brute force

• Énoncé - Task 5 : How many combinations of usernames and passwords were used in the credential stuffing attack?

Ici, Il s'agit de compter le nombre de tentatives d'authentification différentes effectuées par l'attaquant dans le cadre de son attaque par Credential stuffing. Pour ce faire, j'ai appliqué le filtre suivant sur Wireshark :

http.request.uri == "/bonita/loginservice"

Il me permet de n'afficher que les paquets qui contiennent une requête vers /bonita/loginservice, correspondant à la page de login. J'ai ensuite effectué un tri par taille (Length) afin de pouvoir ignorer rapidement toutes les tentatives d'authentification avec install:install (qui font donc tous la même taille : 105 octets). Ceux-ci n'entrent pas dans le cadre d'une attaque par Credential Stuffing, puisqu'il s'agit d'un mot de passe par défaut, et non volé.

En sélectionnant les paquets restants, Wireshark m'indique que j'en ai 59 :

J'en enlève 3 car l'attaquant a fait 4 tentatives d'authentification avec les mêmes identifiants, qui ne comptent donc que pour 1, cela fait donc 56 identifiants.

F. Tâche n°6 : identifiant valide

• Énoncé - Task 6 : Which username and password combination was successful?

Nous avons un aperçu de la réponse via nos analyses précédentes. En affichant uniquement les requêtes POST dans Wireshark, on remarque qu'après plusieurs tentatives d'authentification, l'attaquant commence à requêter d'autres points d'entrée, signe que son attaque par brute force a abouti :

Ici, il ne faut pas oublier de trier nos paquets par ordre d'interception, et non plus par taille. En sélectionnant l'authentification juste avant la requête sur l'URL /bonita/API/pageUpload, on obtient les identifiants avec lesquels l'attaquant est parvenu à s'authentifier :

[email protected]:g0vernm3nt

G. Tâche n°7 : utilisation d'un site tiers

• Énoncé - Task 7 : If any, which text sharing site did the attacker utilise?

Il semble ici que l'attaquant ait utilisé un site de partage de fichiers pour échanger des données avec la cible compromise. Qui dit requête web, dit souvent requête DNS, utilisons un filtre Wireshark sur les requêtes DNS de type 1 (A, c'est-à-dire les requêtes name to IPv4):

Le site utilisé par l'attaquant est pastes.io !

H. Tâche n°8 : script de persistance

• Énoncé - Task 8 : Please provide the file hash of the script used by the attacker to gain persistent access to our host.

Ici, il s'agit de retrouver un script déposé par l'attaquant afin d'établir une persistance sur le système compromis. Nous pouvons nous intéresser aux échanges réseau effectués par l'attaquant, qui sont en clair :

On retrouve assez rapidement une commande wget qui a permis à l'attaquant de télécharger un script depuis le site pastes.io. Ce qui nous permet de nous-même le télécharger pour récupérer son hash md5.

Attention : en condition réelle, le téléchargement et surtout l'analyse des outils de l'attaquant doivent être réalisés sur des plateformes faites pour, déconnectées d'internet et du réseau interne de l'entreprise.

I. Tâche n°9 : clé publique SSH

• Énoncé - Task 9 : Please provide the file hash of the public key used by the attacker to gain persistence on our host.

En analysant le contenu du script, on remarque qu'il a cherché à ajouter sa clé publique dans le fichier authorized_keys de l'utilisateur ubuntu :

Là aussi, sa clé est téléchargée depuis le site pastes.io, ce qui nous permet de la récupérer :

J. Tâche n°10 : modification d'un compte utilisateur

• Énoncé - Task 10 : Can you confirmed the file modified by the attacker to gain persistence?

Nous avons déjà la réponse grâce à la lecture du script de l'attaquant :

/home/ubuntu/.ssh/authorized_keys

Passons à la tâche suivante !

K. Tâche n°11 : MITRE ATT&CK

• Énoncé - Task 11 : Can you confirm the MITRE technique ID of this type of persistence mechanism?

De retour sur le framework MITRE ATT&CK, connaissant déjà ce framework à force de l'utiliser, je retrouve facilement l'attaque en question :

Et voilà ! Nous sommes arrivés au bout de l'exercice d'investigation :

IV. Résumé de l'attaque

Au cours de cette investigation, nous avons découvert que l'attaquant a opéré au préalable de l'attaque une récupération d'identifiants et de mots de passe valides par un moyen inconnu. Il a ensuite effectué une attaque par brute force avec ces identifiants sur l'application BonitaSoft en exploitant notamment la CVE-2022-25237 pour contourner les protections de la page d'authentification. Une fois authentifié, l'attaquant a déposé une backdoor par l'intermédiaire du site pastes.io, puis il est parvenu à ajouter sa clé SSH publique dans le répertoire personnel de l'utilisateur ubuntu. Enfin, il est parvenu à accéder en SSH au serveur compromis.

Pour aller jusqu'au bout de la démarche, voici les TTP (Tactics, Techniques and Procedures) utilisés :

TTP (MITRE ATT&CK)	Détails
T1589.001 - Gather Victim Identity Information: Credentials	Collection d'identifiants valides concernant l’entité attaquée par un moyen inconnu
T1110.004 - Brute Force: Credential Stuffing	Attaque par brute force sur la page d'authentification avec les identifiants récupérés
T1608.002 - Stage Capabilities: Upload Tool	Téléchargement et exécution d'un script par l'intermédiaire d'un site web en ligne (pastes.io)
T1098.004 - Acount Manipulation: SSH Authorized Keys	Ajout d'une clé publique SSH dans le home de l'utilisateur ubuntu.
T1021.004 - Remote Services: SSH	Connexion au serveur SSH compromis

V. Notions abordées

Nous allons à présent mettre en avant les principales notions et apprentissages de cet exercice, aussi bien pour l'attaquant que pour les défenseurs ou l'analyste. Il ne s'agit pas d'un point de vue complet, n'hésitez pas à améliorer ce contenu en donnant votre avis dans les commentaires :).

A. Côté analyste

Maîtrisez Wireshark : cet outil regorge de fonctionnalités avancées que nous n'avons fait qu'effleurer ici, mais les connaître donne un avantage certain et permet d'aller beaucoup plus vite lors d'une analyse.

L'analyse du fichier JSON a été réalisée à coup de grep, mais sur un fichier plus conséquent l'utilisation de jq ou d'autres parseurs JSON en ligne de commande pourrait devenir intéressante.

B. Côté défense

L'attaquant a opéré une attaque par credential stuffing, ce qui signifie soit :

• que les utilisateurs ont été piégés par un phishing préalable à l'attaque, auquel cas il faut améliorer la sensibilisation des utilisateurs
• soit que les identifiants ont été récupérés sur une autre application compromise, auquel cas les utilisateurs réutilisent leurs identifiants entre les applications, ce qui n'est pas une bonne pratique. L'implémentation d'un 2FA peut également être recommandée.

La compromission initiale ayant été réalisée en exploitant la CVE-2022-25237 (authentication/authorization bypass vulnerability), il peut également être recommandé de mettre en place et d'appliquer une politique de mise à jour (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).

Le fait qu'un serveur ait un accès direct et non restreint à internet est un danger certain. On voit ici que l'attaquant a pu importer des outils, des scripts et sa clé publique très rapidement et sans contraintes particulières. C'est pourquoi il est recommandé de limiter au strict nécessaire l'accès à internet des serveurs.

L'exposition directe du serveur à internet et notamment de son service d'administration (SSH) apporte une porte d'entrée supplémentaire à l'attaquant. Après avoir compromis l'application web et ajouté sa clé publique dans les authorized_keys d'un utilisateur, celui-ci a pu se connecter en SSH et se servir du serveur compromis comme d'un rebond vers le réseau interne.

L'ANSSI recommande dans la directive n°23 de son guide d'hygiène de "Cloisonner les services visibles depuis internet du reste du système d’information" pour limiter les possibilités de rebond. Il est également recommandé de ne pas exposer de ports d'administration directement sur Internet, mais d'y accéder en interne, si nécessaire après l'établissement d'une connexion VPN.

On peut également noter que l'utilisateur qui fait tourner le service web ne devrait pas avoir les droits d'écriture dans le home d'un utilisateur. Dans ce cas, il peut être recommandé de vérifier les permissions d'exécution de l'application web sur le serveur Linux compromis, par exemple utiliser le compte www-data et s'assurer qu'il n'a pas de droits d'accès trop permissifs en dehors de ses répertoires web.

Je vous recommande vraiment de vous intéresser au framework MITRE ATT&CK, il permet de rapidement catégoriser une attaque, la définir, mais aussi d'obtenir des informations supplémentaires sur les outils pouvant être utilisés, des recommandations, des informations pour améliorer la détection ou identifier des groupes d'attaquants (APT) en relation avec une attaque.

C. Côté attaquant

Pour être plus discret, l'attaquant aurait pu étaler son attaque par brute force sur plusieurs heures ou jours, potentiellement avec des IP différentes. Il est en effet plus difficile de corréler des évènements sur une telle durée (à moins qu'un filtre sur l'IP du serveur ciblé soit appliqué, mais la taille des fichiers à analyser doit être conséquente). N'étant pas moi-même analyste SOC/Forensic, je suis preneur de vos retours sur cette méthode :).

L'attaquant aurait également pu procéder à des opérations ne nécessitant pas le dépôt de fichier sur le système avec des commandes en one-line, pourquoi pas obfusquées. Le fait de laisser ses fichiers/scripts indéfiniment sur une plateforme publique facilite également la compréhension de l'attaque et pourquoi pas l'identification de l'attaquant. Cela apparaît toutefois comme réaliste dans le cadre d'attaques en masse ou automatisées, toutes les machines compromises retrouveront alors les scripts et backdoors sur un seul et même point.

VI. Conclusion

J'espère que cet article vous a plu ! Au-delà de la résolution du challenge, il est toujours intéressant de savoir tirer parti de ces exercices pour s'améliorer et en extraire le maximum d'apprentissage. N'hésitez pas à utiliser les commentaires et le Discord pour partager votre avis ! 🙂

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