Les vulnérabilités d'injection SQL se produisent chaque fois que l'entrée est utilisé dans la construction d'une requête SQL sans avoir été dûment contrainte ou désinfectés. L'utilisation de SQL dynamique (la construction de requêtes SQL par concaténation de chaînes de caractères) ouvre la porte à ces vulnérabilités. L'injection SQL permet à un attaquant d'accéder aux serveurs SQL. Il permet l'exécution de code SQL avec les privilèges de l'utilisateur utilisé pour se connecter à la base de données.

Le serveur MySQL a quelques particularités de sorte que certains exploits ont besoin d'être spécialement conçus pour cette application. C'est l'objet du présent article.

Pour tester la présence d'une vulnérabilité d'injection SQL dans une base de données MySQL, il y a un certain nombre d'attaques qui peuvent être réalisées en fonction de la version de MySQL et les privilèges des utilisateurs sur les SGBD.

MySQL est livré avec au moins quatre versions qui sont utilisés dans en production.

3.23.x, 4.0.x, 4.1.x et 5.0.x. Chaque version présente un ensemble de caractéristiques attachées au numéro de version.

• Depuis la version 4.0: UNION
• Depuis la version 4.1: Les sous-requêtes
• Depuis la version 5.0: Les procédures stockées, les fonctions stockées et la vue nommée INFORMATION_SCHEMA
• Depuis la version 5.0.2: Triggers

Il convient de noter que pour les versions avant MySQL 4.0.x, seules les attaques booléennes ou par injection aveugles basées sur le temps pouvaient être utilisées, puisque la fonctionnalité sous-requête ou les déclarations Union n'étaient pas appliquées.

A partir de maintenant, nous supposerons qu'il existe une vulnérabilité d'injection SQL classique, qui peut être déclenchée par une demande similaire à celle décrite dans la section sur le dépistage du SQL Injection.

http://www.example.com/page.php?id=2

Avant de prendre avantage des fonctionnalités de MySQL, il doit être pris en considération la façon dont les chaînes peuvent être représentés dans un requête, car souvent les applications Web échappent les simples quotes.

Une manière d'échapper les simple quotes est la suivante:

'A string with \'quotes\// //

MySQL interprète les quotes échappées (\') comme des caractères et non comme des métacaractères.

Donc, si l'application fonctionne correctement, elle doit utiliser des chaînes constantes, deux cas sont à distinguer:

• L'application Web échappe les apostrophes ('⇒ \')
• L'application Web n'échappe pas apostrophes ('⇒')

Sous MySQL, il est un moyen standard pour contourner la nécessité de la quote simple, eun utilisant une constante de chaîne de manière la déclarer sans avoir besoin de la simple quote.

Supposons que nous voulons connaître la valeur d'un champ nommé 'mot de passe' avec une condition comme suit: password lique 'A%'

Utilisation des valeurs ASCII en hex concaténé:

password like 0x4125

Utilisation de la fonction CHAR ():

password like CHAR (65,37)

Les onnecteurs de bibliothèques MySQL ne prennent pas en charge plusieurs requêtes séparées par des ';' il n'y a donc aucun moyen d'injecter plusieurs commandes SQL non-homogènes à l'intérieur d'une vulnérabilité d'injection SQL unique comme dans Microsoft SQL Server.

Par exemple, l'injection suivante entraînera une erreur:

1 ; update tablename set code='javascript code' where 1 --

Bien sûr, la première chose à savoir, c'est si il y a SGBD MySQL comme backend.

MySQL serveur dispose d'une fonction qui est utilisée pour permettre à d'autres SGBD d'ignorer la clause dans le dialecte MySQL. Quand un bloc de commentaire ('/ /') contient un point d'exclamation ('/! sql here/') cela signifie que c'est interprété par MySQL, et est considéré comme un bloc de commentaires normaux par d'autres SGBD comme expliqué dans le manuel MySQL. Exemple: <code>1 /! and 1=0 */ </code> Résultat attendu: Si MySQL est présent, la clause à l'intérieur du bloc de commentaire sera interprétée. ### Version ### Il existe trois façons d'obtenir ces informations: * En utilisant la variable globale @@version * En utilisant la fonction [VERSION ()] * En utilisant les empreintes avec un numéro de version en commentaire /!40110 and 1=0*/ ce qui signifie <code>if(version >= 4.1.10) add 'and 1=0' to the query. </code> Qui est équivalent, car le résultat est le même Injection in-band: 1 AND 1=0 UNION SELECT @@version /* Injection aveugle: 1 AND @@version like '4.0%' Résultat attendu: Une chaîne comme ceci: 5.0.22-log ### Connexion utilisateur ### Il existe deux types d'utilisateurs sur lesquels MySQL s'appuie. - [USER()]: l'utilisateur connecté au serveur MySQL. - [CURRENT_USER()]: l'utilisateur interne qui exécute la requête. Il y a une différence entre ceux-ci. La principale est qu'un utilisateur anonyme peut se connecter (si autorisé) avec n'importe quel nom, mais l'utilisateur MySQL interne est un nom vide (). Une autre différence est qu'une procédure stockée ou une fonction stockée est exécutée en tant qu'utilisateur créateur, si cela n'est pas déclaré ailleurs. Cela peut être connu en utilisant CURRENT_USER. Injection in-band: <code>1 AND 1=0 UNION SELECT USER() </code> Injection aveugle: <code>1 AND USER() like 'root%' </code> Résultat attendu: Une chaîne comme ceci: user@hostname ### Nom de la base en cours d'utilisation ### Il existe la fonction native DATABASE() Injection in-band: <code>1 AND 1=0 UNION SELECT DATABASE() </code> Injection en aveugle: 1 AND DATABASE() like 'db%' Résultat attendu: Une chaîne comme ceci: dbname ### INFORMATION_SCHEMA ### Depuis MySQL 5.0 une vue nommée [INFORMATION_SCHEMA] a été créée. Elle nous permet d'obtenir toutes les informations sur les bases, tables et colonnes, ainsi que les procédures et les fonctions. Voici un résumé de quelques vues intéressants. | TablesinINFORMATIONSCHEMA| DESCRIPTION | | ..[skipped]..| ..[skipped].. | | SCHEMATA| Toutes les bases de l'utilisateur (au moins) SELECTpriv | | SCHEMAPRIVILEGES| Les privilèges de l'utilisateur pour chaque DB | | TABLES| Toutes les tables de l'utilisateur (au moins) SELECTpriv | | TABLEPRIVILEGES| Les privilèges de l'utilisateur pour chaque table | | COLUMNS| Toutes les colonnes de l'utilisateur a (au moins) SELECTpriv | | COLUMNPRIVILEGES| Les privilèges de l'utilisateur pour chaque colonne | | VIEWS| Toutes les colonnes l'utilisateur a (au moins) SELECTpriv | | ROUTINES| Procédures et fonctions (nécessite EXECUTEpriv) | | TRIGGERS| déclencheurs (nécessite INSERTpriv) | | USERPRIVILEGES| Privilèges de l'utilisateur connecté | Toutes ces informations peuvent être extraites en utilisant des techniques connues, comme décrit dans la section injection SQL. ## Vecteurs d'attaque ## ### Ecrire dans un fichier ### Si l'utilisateur connecté dispose de privilèges de fichiers et si les apostrophes ne sont pas échappées, la clause 'INTO OUTFILE' peut être utilisée pour exporter des résultats de la requête dans un fichier. <code>Select * from table into outfile '/tmp/file' </code> Remarque: il n'existe aucun moyen de contourner les simples quotes autour d'un nom de fichier. Donc, si il y a désinfection des quotes comme l'échappement (\ ') il n'y aura pas moyen d'utiliser la clause «into outfile ». Ce type d'attaque peut être utilisé comme technique out-of-band pour obtenir des informations sur les résultats d'une requête ou écrire un fichier qui peut être exécuté à l'intérieur du répertoire du serveur web. 'Exemple: <code>1 limit 1 into outfile '/var/www/root/test.jsp' FIELDS ENCLOSED BY '' LINES TERMINATED BY '\n<%jsp code here%>'; </code> Résultat attendu: Les résultats sont stockés dans un fichier détenus par l'utilisateur et le groupe MySQL avec les privilèges rw-rw-rw. Le fichier /var/www/root test.jsp contiendra:
field values <%jsp code here%> ### Lire dans un fichier ### LOAD_FILE est une fonction native qui peut lire dans un fichier si cela est permis par les autorisations du système de fichiers. Si un utilisateur connecté dispose de privilèges FILE, cela pourrait être utilisé pour obtenir le contenu des fichiers. Une désinfection de l'évasion simple quote peut être contournée en utilisant des techniques décrites précédemment. <code>load_file('filename') </code> Résultat attendu: L'ensemble des fichiers seront disponibles pour l'exportation en utilisant des techniques standard. ## Attaque par injection SQL standard ## Dans une injection standard SQL, vous pouvez avoir des résultats affichés directement dans une page comme sortie normale ou comme une erreur MySQL. En utilisant les attaque déjà mentionnées s par injection SQL et les caractéristiques déjà décrites de MySQL, l'injection directe SQL pourrait être facilement réalisée à un niveau dont la profondeur est principalement fonction de la version de MySQL. Une bonne attaque est de connaître les résultats en forçant une fonction / procédure ou le serveur lui-même à lretourner une erreur. Une liste des erreurs générées par MySQL, et en particulier des fonctions natives se trouve dans le Manuel MySQL. ## Injection Out of Band ## l'injection SQL Out of band pourrait être accomplie en utilisant la clause 'INTO OUTFILE' . ## Injection Aveugle ## Pour l'injection SQL aveugle, il y a un ensemble de fonctions natives utiles fournies par le serveur MySQL. * Longueur de chaîne: LENGTH(str) * Extrait une sous-chaîne d'une chaîne donnée: SUBSTRING (chaîne, décalage, nombre de car retourrnés) * Injection basée sur le temps: BENCHMARK et SLEEP BENCHMARK (# ofcycles, actiontobe_performed) La fonction BENCHMARK pourrait être utilisée pour effectuer des attaques temporelles, lorsque l'injection à l'aveugle par des valeurs booléennes ne donne pas de résultats. Voir. La fonction SLEEP() (MySQL> 5.0.x) pour une alternative à la fonction BENCHMARK. Pour une liste complète, reportez-vous au manuel MySQL <code>http://dev.mysql.com/doc/refman/5.0/en/functions.html </code> # Références # ## Livres blancs ## * Chris Anley: “Hackproofing MySQL” - http://www.databasesecurity.com/mysql/HackproofingMySQL.pdf ## Études de cas ## * Zeelock: Blind Injection in MySQL Databases - http://archive.cert.uni-stuttgart.de/bugtraq/2005/02/msg00289.html ## Outils ## * Francois Larouche: Multiple DBMS SQL Injection tool - http://www.sqlpowerinjector.com/index.htm * ilo–, Reversing.org - sqlbftools * Bernardo Damele A. G.: sqlmap, automatic SQL injection tool - http://sqlmap.org/ * Muhaimin Dzulfakar: MySqloit, MySql Injection takeover tool - http://code.google.com/p/mysqloit/ * http://sqlsus.sourceforge.net/