Reconstruction d’OS non chiffrés : Analyse post-exploitation

Reconstruction d’OS non chiffrés : Analyse post-exploitation

Rappel : L’article qui va suivre contient des techniques et méthodes qui peuvent s’avérer être illégales et dangereuses si elles sont utilisées à mauvais escient. Ce tutoriel ne doit en aucun cas être utilisé contre un particulier, une entreprise, une organisation à but non lucratif ou une administration publique de quelconque pays. Je me dédouane de toute responsabilité en cas de problèmes ou d’incidents de quelque nature que ce soit après le visionnage de cet article.

**FOR EDUCATIONAL PURPOSES ONLY**

0. Introduction

Le chiffrement des disques durs est une pratique fondamentale pour protéger les données sensibles des entreprises et des utilisateurs individuels. En effet, en cas de vol de la machine (virtuelle/physique) les données ne peuvent pas être accessibles sans la clé de déchiffrement appropriée. En outre, cette technique est également devenue un élément-clé de certaines conformités réglementaires dans de nombreux secteurs. Dans cet article, nous allons aborder l’analyse et la reconstruction de machines virtuelles (VMs) suite à un scénario d’attaque fictif ayant impacté un serveur de sauvegarde contenant des fichiers de disque virtuel au format .vmdk non chiffré (à tout hasard : p).

I. Scenario :

Un attaquant a été en capacité de récupérer plusieurs fichiers de disques virtuels après avoir eu accès à un serveur de sauvegarde utilisant le protocole ISCSi. Il souhaite les analyser afin de vérifier si oui ou non il pourrait accéder à des données confidentielles.

Voici les deux fichiers suivants :

  • Ubuntu : Ubuntu-22.04-Crash-Test-Do-Not-Update.vmdk
  • Windows Server : DC-cl1.vmdk

Afin de faciliter la rédaction de cet artice, je vais utiliser exclusivement des fichiers .vmdk (fichier de disque virtuel utilisé par les machines virtuelles qui ont vocation à être « cross-platforme »)

II. Pour une machine linux

J’effectue la démonstration avec une VM Ubuntu 22.04

A. Analyse des fichiers (Lecture seulement)

Depuis un hôte Windows, avec le logiciel 7ZIP, je peux facilement ouvrir le fichier .vmdk qui n’est autre qu’un « fichier conteneur » dédié aux stockages des données de la VM :

Les 3 fichiers « .img » représente chaque partition du système d’exploitation. La plus intéressante étant « 2.img » qui est le (fichier le plus grand) qui contient l’ensemble des données de l’OS.

Suite à l’ouverture de celui-ci j’accède directement à la racine du système de fichier. Il est donc possible de consulter n’importe quel dossiers/fichiers sans aucune restriction.

Ici, par exemple, j’accède à un fichier « témoin » stocké dans /root que j’avais précédemment créé en guise de test.

B. Reconstruction de la VM et bypass de l’authentification

Je vais effectuer cette manipulation avec Virtualbox, mais cela est faisable aussi sur VMware Workstation. (dans mon cas j’ai rencontré des petits soucis aléatoires de m*rde avec VMware Workstation 17 Sous Linux…)

Lors de la création de la VM, passez en mode « Expert » afin d’avoir une vue un peu plus détaillé. Ajouter un disque virtuel existant (Use an existing virtual hard disk file) afin que la futur VM se base sur ce disque pour démarrer.

Une fois les paramétrages préliminaires effectués, démarrez la VM et saisissez au plus vite la combinaison de touches shift+echap afin d’afficher le menu de démarrage nommé « GRUB » si l’OS que vous essayez de reconstruire n’affiche pas ce menu par défaut au boot.

Rappel : Séquence de démarrage d’un ordinateur – Exemple avec un OS basé sur Linux

Ensuite, appuyez sur la touche ‘e’ pour modifier les paramètres de grub de manière temporaire,et ainsi modifier le comportement de l’amorçage du kernel.

Descendez à la fin du fichier et localisez le bou de ligne « ro quiet splash $vt_handoff« 

Remplacez ce bout de ligne par : rw init=/bin/bash. Enregistrez les modifications avec la touche F10. Cela aura d’ailleurs pour effet de reprendre la séquence de démarrage de la VM.

Cette action va faire booter le système dans un mode « spécial » appellé : Mono-utilisateur (root, le seul, l’unique, le vrai)

J’obtiens donc un shell root en lecture/écriture (d’ou l’instruction rw init=/bin/bash plus haut).

En cas d’échec, remonter le système de fichiers de force (je n’ai jamais eu à la faire pour ma part lors de mes tests) :

mount / -o remount,rw

Il ne me reste plus qu’à changer les mots de passe de(s) utilisateur(s) en question(s). Pour ma part je vais changer le mdp de « user » (qui a des droits sudo) et de root.

passwd user 
passwd # Modifie le mdp de l'utilisateur courant (root) :p 

Note : Vu que « user » dispose de droits sudo, j’aurais pu me passer de changer directement le mdp de root.

Une fois que vous avez changé le(s) mot(s) de passe, redémarrer « de force » le système avec :

reboot -f 

Le système va alors booter « normalement » et vous pourrez vous connecter avec le(s) nouveau(x) mdp associé(s) au(x) compte(s).

III. Pour une machine Windows

J’effectue la démonstration avec une VM Windows server 2022

A. Analyse des fichiers (Lecture seulement)

Même principe qu’avec un système d’exploitation basé sur Linux, ouvrer le fichier « disque virtuel (.vmdk) » avec 7zip (ou équivalent)

Sélectionnez le fichier « Basic Data Partition » qui contient le système de fichiers racine d’un OS Windows.

De nouveau, ici vous avez accès en lecture seulement aux fichiers. Même si vous n’avez pas de droits d’écriture, vous avez quand même la capacité de copier les fichiers, ce qui va être fort utile pour l’étape suivante.

B. Dump du fichier NTDS.dit

Pour rappel, le fichier NTDS.dit est la « base de données » de l’Active Directory qui stocke les informations d’identification et de sécurité des utilisateurs, des groupes et des ordinateurs. (hashes…)

En accédant au répertoire Windows\NTDS depuis 7zip, je suis en capacité de récupérer le fameux fichier NTDS.dit en le copiant.

Afin d’extraire les données de ce fichier, il me faut absolument disposer des deux fichiers connexes Windows\System32\SECURITY et Windows\System32\SYSTEM. Pourquoi allez-vous me dire ?

Et bien voici la réponse :p

Comme dit précédement, lorsqu’un contrôleur de domaine Active Directory est installé, les informations d’identification des utilisateurs sont stockées dans un fichier appelé NTDS.dit. Ce fichier est protégé par une clé de chiffrement stockée dans les fichiers SYSTEM et SECURITY.

Pour accéder au contenu du fichier NTDS.dit, il est donc nécessaire d’extraire la clé de chiffrement à partir des fichiers SYSTEM et SECURITY. Cette clé de chiffrement est utilisée pour déchiffrer le contenu du fichier NTDS.dit et donc récupérer les informations d’identification des utilisateurs.

Copiez donc ces deux fichiers au sein du même répertoire que celui ou vous avez stocké NTDS.dit

Depuis l’utilitaire secretdump (de la suite impacket) qui de mémoire est un outil natif présent dans les versions récentes de Kalilinux, vous pouvez extraire les haches de tous les utilisateurs du domaine avec la commande suivante :

/usr/bin/impacket-secretsdump -system SYSTEM -security SECURITY -ntds ntds.dit local
Et voilà !

C. Reconstruction de la VM et bypass de l’authentification

Même principe que plus haut à quelques différences près. Lors de la création de la VM, passez en mode « Expert » afin d’avoir une vue un peu plus détaillé. Ajouter un disque virtuel existant (Use an existing virtual hard disk file) afin que la futur VM se base sur ce disque pour démarrer.

Puis, dans les paramètres de la VM, ajoutez un disque de démarrage. Vu que l’OS cible est Windows Server, il est recommandé pour éviter tout bug, d’utiliser un fichier ISO (récent) qui correspond à la version du système. (Ici Windows Server 2022)

Une fois que vous avez branché celui-ci à la VM, vous pouvez démarrer la VM et utiliser la touche de boot F12 pour choisir ce périphérique de démarrage

Ou alors modifier directement l’ordre de boot dans les paramètres système de la VM

Dès lors que vous êtes arrivé sur le menu initial de l’installation de Windows (suite au boot du fichier .ISO), ajustez votre clavier et cliquez sur suivant.

Puis, cliquez sur « Réparer L’ ordinateur »

Cela va vous afficher le « menu bleu » de Windows. Cliquez sur Dépannage

Puis sur « Invite de commande »

Un terminal va alors s’ouvrir. Grâce à celui-ci, il va être possible de pouvoir effectuer quelques opérations permettant a posteriori de modifier le mot de passe de n’importe quel utilisateur du système.

Dans un premier temps, il convient avec l’utilitaire diskpart d’assigner une lettre au « Volume 1 » du disque 0 (celui-ci en comporte 4 comme l’image le montre). Ce « Volume 1 » contient les données du système. Depuis peu, aucune lettre lui est assignée par défaut. (sur les nouvelles versions)

Suivez les étapes ci-dessous

Entrer sur la partition en question à l’aide de la lettre que vous lui avez assignée. Dirigez-vous vers le dossier Windows\System32.

Renommer le programme utilman.exe en utilman.exe.old et copiez le programme cmd.exe vers le fichier utilman.exe. Ce tour de « passe passe », va vous permettre d’ouvrir un terminal avec des droits d’administrateur lors de l’affichage de l’écran de verrouillage de l’OS en cliquant sur l’icône « Facilité d’accès » / « Ease of Access »

Eteignez la machine, puis rallumez la.

C.1 Cas spécial – Système d’exploitation installé avec UEFI

Si lors du démarrage de celle-ci, vous obtenez le message suivant FATAL: INT18: BOOT FAILURE, cela indique très probablement que vous essayez de booter sur un système d’exploitation supportant EFI/UEFI, mais que vous n’avez pas activé ce mode.

Éteignez de force, et allez dans les paramétrages du système de la VM afin de cocher l’option enable EFI (Spécial Oses only)

Quelques petits rappels sur EFI/UEFI afin que les choses soient un peu plus claires :

EFI (Extensible Firmware Interface) et UEFI (Unified Extensible Firmware Interface) sont tous deux des normes de firmware utilisées pour initialiser le matériel de l’ordinateur et lancer le système d’exploitation. La principale différence entre les deux est que UEFI est une version améliorée et plus récente d’EFI.

EFI a été introduit par Intel en 2000 pour remplacer le BIOS (Basic Input/Output System), qui était utilisé pour initialiser le matériel et lancer le système d’exploitation depuis les années 1980. Il a été conçu pour être plus flexible et extensible que le BIOS, avec la possibilité de charger des pilotes et des applications supplémentaires avant le lancement du système d’exploitation.

UEFI comprend toutes les fonctionnalités d’EFI, mais avec des améliorations telles que la prise en charge de disques durs de plus de 2 To, la compatibilité avec les interfaces graphiques pour une meilleure interface utilisateur, la possibilité de démarrer à partir d’un réseau et une sécurité améliorée.

L’option « Enable EFI (special OSes only) » dans VirtualBox permet donc d’activer le support de l’EFI/UEFI pour les machines virtuelles. En effet, même si depuis ces dernières années de plus en plus d’OS s’installe par défaut via UEFI, il y a encore beaucoup d’OS qui s’installe en mode « BIOS » par défaut (surtout pour les distributions open source).

Si vous cochez cette option, cela signifie que vous souhaitez que votre machine virtuelle utilise l’EFI / UEFI pour démarrer le système d’exploitation. Cela peut être nécessaire pour certains systèmes d’exploitation plus récents qui requièrent l’EFI / UEFI pour démarrer.

Avant de redémarrer, n’oubliez pas changer l’ordre de boot par défaut (si vous l’avez changé) comme ça vous démarrerez directement sur le disque contenant l’OS et non sur l’ISO monté as a DVD.

Une fois que tout est bon, démarrez la machine. Depuis l’écran de verrouillage du système appuyez sur l’icône afin d’exécuter non pas le processus utilman.exe « lui-même » mais cmd.exe que nous avons copié en utilman.exe, pour qu’un terminal privilégié puisse se déclencher lorsque vous cliquez sur l’icône en question.

Pro Tips : Maximiser votre fenêtre, car il se peut que le terminal ne s’affiche pas correctement.

Sur windows 11, le logo ci-dessus a été remplacé par un petit « petit bonhomme »

Un terminal « privilégié » devrait apparaître.

Voici les commandes que vous allez devoir saisir afin de reset le(s) mdp de n’importe quels utilisateurs (en fonction de votre contexte, les commandes sont à adapter)

Si par défaut le compte administrator (local) n’a pas été renommé, vous pouvez reset son mot de passe avec :

net user administrator 123+aze

Pour reset le compte administrator (du domaine) :

net user administrator 123+aze /domain

Après avoir effectué ce(s) actions, vous pouvez alors accéder à la session de l’utilisateur(s) de votre choix.

IV. Conclusion

Le chiffrement des partitions système (windows ou linux) est la solution pour remédier à ce problème de sécurité majeure mais que beaucoup beaucoup de personnes igniore. Cela permetra de protéger les données stockées sur vos machines en les rendant illisibles sans la clé de déchiffrement appropriée (chiffrement symétrique). Alternativement, vous pouvez utiliser les fonctions de « chiffrement de VM » que proposent certains hyperviseurs comme les éditeurs VMware, ou Oracle.

++

Geoffrey

Geoffrey Sauvageot-Berland

Related Posts

Exfiltrer des données depuis une session meterpreter (Post Exploitation)

Exfiltrer des données depuis une session meterpreter (Post Exploitation)

Reverse/Bind shell – Quésaco

Reverse/Bind shell – Quésaco

Configurer le service RDP facilement pour Ubuntu 22.04

Configurer le service RDP facilement pour Ubuntu 22.04

Analyser la sécurité de vos images docker avec Trivy (mais pas que !)

Analyser la sécurité de vos images docker avec Trivy (mais pas que !)

No Comment

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.