[PENTESTING] [Database] MS-SQL Audit

Après notre aventure théorique sur l'OWASP, je reviens sur le blog pour un post technique. Et pour ce "comeback", je vous propose dans un premier temps de nous attaquer à un élément du S.I très sensible : les bases de données ! En effet, c'est ici que nous trouverons souvent les données les plus confidentielles ... Plus précisément, nous allons prendre pour exemple les bases de type MS-SQL.

1 - Mission: MS-SQL

Le post présente une technique qui n'est pas supposée être la meilleure, ni être exhaustive. Le but ici est de voir une façon de faire. Au risque de me répéter, mais c'est très important, ce qui est présenté ci-dessous ne peut être réalisé qu'au sein de son propre réseau ou dans un cadre légal (avec autorisation de la compagnie auditée).

Avant d'entrer dans le sujet, il faut savoir que ce type de tests est plus approprié aux tests d'intrusion internes. Si jamais une telle base était accessible depuis Internet, je vous laisse imaginer la criticité du problème !

Pour terminer, le client OSQL, utilisé dans la suite, est fourni gratuitement sur le site de Microsoft dans le package MSDE. La connexion vers la serveur se fait ainsi :

osql.exe /S ip_serveur|nom_serveur /U nom_utilisateur /P mot_de_passe

2 - Repérage de notre cible

2.1/ Trouver les serveurs MS-SQL

Par défaut, les bases MS-SQL utilisent les ports :

• TCP/1433
• UDP/1434

NMAP peut donc nous permettre de trouver les serveurs MS-SQL présents sur le réseau audité (par exemple, sur le réseau 172.16.XXX.XXX) :

nmap -v -sV -sS -p 1433 -oN NMAP_MS-SQL.txt 172.16.0.0/16

Ou mieux :

nmap -sV -sS -p 1433 172.16.0.0/16 | grep "open" -B 3 > nmap_mssql_list.txt

Cette méthode simple est tout de même limitée car si l'administrateur n'utilise pas le port par défaut, nous passons à côté de notre cible !

2.2/ Prise d'information sur les serveurs MS-SQL

Il existe plusieurs outils pour obtenir des informations sur les serveurs MS-SQL audités. Nous montrons ici l'exemple de SQLRecon :


Le but est de connaître les numéros de version notamment pour éventuellement jouer un exploit si le serveur de base de données n'est pas maintenu à jour.


3 - Compromission de la cible

3.1/ Juste une question de compte ...

Une base de données MS-SQL a un compte administrateur appelé par défaut sa. Ce compte doit donc être protégé spécifiquement. Cependant, il arrive qu'il soit configuré avec le mot de passe ... vide ou sa ! Les credentials par défaut peuvent donc très simplement fournir un accès total à la base de données.

Si les comptes par défaut ne donnent pas de résultats positifs, nous pouvons tenter une attaque par dictionnaire. Pour cela, il existe l'outil SQLPing3cl :


Nous avons auparavant :

• rempli le fichier user.txt avec les noms de compte possible (ex : sa) ;
• rempli le fichier pass.txt avec la liste de mots de passe (sinon, il existe des tonnes de fichiers préconçus sur le Net contenant les mots du dictionnaire ;).

Un de nos serveurs a le mot de passe sa (extrait de l'output) ...

172.XXX.XXX.XXX,1433,NOM_Serveur,MSSQLSERVER,8.00.194,8.0.766,8.00.760,,No,(UDP)ServerName;NOM_Serveur;InstanceName;MSSQLSERVER;IsClustered;No;Version;8.00.194;tcp;1433;np;\\Nom_Serveur\pipe\sql\query;; (SA)Server present but blank SA login failed (BruteForce)**** Brute force attempt successful! User:sa Pass:sa ****,UDP TCP SA BruteForce

3.2/ Regarder les vulnérabilités !

Si malgré tous vos efforts vous n'obtenez pas le mot de passe du compte sa, il faut se retourner vers un site de veille sécurité pour trouver une faille exploitable selon la version trouvée (cf. point 2.2/).


4 - Système touché !

Il faut savoir qu'une base de données tourne par défaut avec les droits Local System. Alors imaginez que la base de données est compromise et que vous puissiez exécuter des commandes arbitraires ... ce serait avec les droits NT AUTHORITY/SYSTEM !

Or, par défaut, MS-SQL bénéficie de ce qu'on appelle des procédures stockées. Ces dernières permettent d'augmenter significativement la puissance d'une base de données. En effet, cela permet de nombreuses actions prédéfinies très utiles pour l'administrateur ... ou pour l'attaquant. La procédure qui nous intéresse ici est xp_cmdshell.

4.1/ Activer une procédure stockée

Il est possible que la procédure que nous souhaitons - xp_cmdshell - ne soit pas activée. Pour le savoir, tenter une connexion vers la base et essayer de lancer la procédure stockée de la manière suivante :

> xp_cmdshell 'ipconfig'
> go

Si vous n'avez pas d'erreur, comme sur l'image suivante, passez tout de suite à l'étape 4.2/


Sinon, suivez les instructions ci-dessous permettent l'activation de la procédure :


4.2/ Lancement de commandes

Nous allons poursuivre notre attaque en créant un compte sur le système hôte :

> xp_cmdshell 'net user jer001 M1ssion_pass /add'
> go

Nous vérifions avec les commandes suivantes :

> xp_cmdshell 'net user'
> go

Notre compte est ajouté !


5 - Aller plus loin

Arrivé à ce stade, nous avons été suffisamment loin dans la compromission du serveur. Cependant, il est nécessaire d'être exhaustif dans le cadre d'un pentest. Un serveur qui a pu être compromis de la sorte n'a pas bénéficié du hardening adéquat et par conséquent, souffre certainement de nombreuses vulnérabilités. Cela peut se vérifier par des tests complémentaires. Notamment, nous pouvons nous aider du script SQL SQLVulscan. Voici une liste non exhaustive de vulnérabilités qu'il permet de trouver :

• Privilège du compte de service ;
• Méthode d'authentification ;
• Liste des procédure stockées ;
• Présence des bases de données par défaut ;
• Présence des accès "invité" ;
• Présence de comptes sans mot de passe ;
• etc.

Pour le lancer, utiliser la commande suivante :

c:\>osql.exe /S 192.168.0.12 /U sa /P BDD_PASS /i SQLvulscan.sql

Et comme toujours, have fun!