SQLi, l’immortelle attaque par injection !

Hey geeks, je suis de retour avec une nouvelle attaque……!Mmm, je pense qu’elle n’est pas si nouvelle que ça, mais bref, on dit que c’est une attaque qui ne meurt pas, ça fait 15 ans qu’elle est en tête de liste top 10 vulnérabilité selon owasp.

Juste pour l’histoire, le premier qui a révéler cette attaque étais jeff forristal dans le “hacker zine phrack”.

Aussi le hacker avec le pseudo “w0rm” le responsable du hack du journal de wall street dit “c’est la méthode la plus facile pour hacker”!.

Ainsi, Worldhealth orginization et US federal agencies ont eux aussi subi des attaques de types SQLi (SQL injection) et qui leur a coûté cher, car l’attaque a révélé toutes les informations confidentielles de leurs agents.

Vous voyez donc que cette attaque est très sérieuse et peut toucher des organisations mondiales que tout le monde croit que ce sont des systèmes intouchables, pour se rendre compte à la fin qu’avec “un simple hack” on peut les démolir.

N.B : c’est w0rm qui a dit que SQLi est un simple hack pas moi, ne me prenez pas pour un hacker !, mais attention, car cette “citation” est un peu vielle, les applications web moderne utilisent des technologies de sécurité plus sophistiqués pour se protéger, dont les APIs!.    Résultat : les attaques de type injection ont fortement baisser vu la difficulté de leur exploitation, car ça requiert de plus en plus de compétences pour les exploités,

Le langage SQL  :

La plupart des applications web de nos jours utilisent des bases de données (Data Bases) afin de stocker les différentes informations nécessaires pour leurs fonctionnements,

Pour l’exemple, Disons que vous avez un site web où vous vendez des chaussettes de toutes sortes (ne riez pas, c’est un bon marché de business 😂), donc vous avez besoin d’une base de données qui doit contenir :

• Les comptes de votre clientèle, leurs informations personnelles et les mots de passe.

• La description et le prix de chaque produit, marque et qualité.

• Les commandes, l’état des comptes, les détailles de payement.

•……etc.

En outre, pour que l’application puisse travailler avec la DB (Data Base) il lui faut un langage spécial, d’ou la naissance de SQL “structured query language” : un langage qui peut manipuler la DB.

Supposant que je suis un client, et je veux acheter une nouvelle paire de chaussettes, je dois me connecter d’abord à mon compte, et tout en haut s’affiche une barre de recherche qui me permet de chercher le produit selon la marque, la qualité et le prix voulu, sachant que tout le catalogue est au sein de la DB.

Admettons que j’ai cherché la marque “Mitrale”, et bien l’application va synthétiser une requête (ou query) comme celle-ci en SQL:

SELECT marque, qualité, prix FROM chaussette WHERE marque='Mitrale'

Cette requête va inciter la DB à vérifier chaque rangée de la table chaussette et en extraire tous les produit qui ont “Mitrale” comme marque, pour que l’application les prend et me les affiche dans une jolie page HTML.

NOTE : J’ai fait exprès de colorer les apostrophes en rouge, car ils ont une importance extrême dans cette faille donc restez concentrer 😎.

Rappel sur le langage SQL :

Je vais vous faire un petit rappel, histoire de rafraîchir la mémoire, mais comme son nom l’indique, c’est un rappel pas un cours 😛.

N.B : le cours sur PHP et SQL est indispensable pour tout hackingeek, si vous ne l’avez pas encore fait, je vous recommande fortement ce livre, il est facile, pratique et vous pouvez le terminer en un mois, voir moins si vous êtes motivé à hacker.

Mais je vais expliquer comme-ci vous n’avez pas encore fait le cours, donc voici à quoi ça ressemble à une table au sein d’une base de données :

Et pour en créer une et manager les informations qu’elle contient, on va devoir utiliser SQL pour qu’il nous effectue les tâches voulues,

Il n’y a rien de difficile dans ce langage, car c’est de l’anglais ! oui oui, je vous assure il n’y a rien de spéciale, et si vous êtes fâché avec l’anglais vous n’avez qu’à apprendre les mots clé que je vais vous présenter.

N.B : c’est dur de l’entendre, mais si vous ne comprenez pas l’anglais, il y a de forte chance que vous n’alliez pas loin dans ce domaine, car nos ressources sont écrites en anglais, les grands hackers parlent l’anglais, le hacking lui-même est en anglais donc faites des effort and speak english 😎.

Commande	Son job
CREATE	crée des bases de données et des tables.
SELECT	récupérer des informations de la BD.
UPDATE	modifier des données qui se trouve déja sur la table.
INSERT	insérer une donnée dans la DB.
DELETE	supprimer des données de la table.
DROP	Supprimer une BD ou une table pour à jamais.

Voilà, c’est une liste non-exhaustive des fonctionnalités que vous pouvez utiliser lors de l’utilisation de SQL, il y en a d’autre plus sophistiqués et qu’on les utilise dans des tâches plus avancées, mais cette liste nous suffiras largement pour illustrer quelques exemples d’attaque SQLi……let’s do it 😁.

Derrière les coulisses de SQLi :

Pour comprendre l’attaque, je vais revenir à mon exemple de chaussette, et voici le code que l’application a générer pour récupérer les données que recherchais :

SELECT * FROM chaussetes WHERE marques='Mitrales'

NOTE : le “ * ” est appelé JOKER qui signifie en code “ tous ”,
Je vous passe le code PHP qui traite ma demande, analysez le :

<?php

$stockID = $_GET["entrée_utlisateur"];

$SQL= "SELECT * FROM chaussete WHERE ID=" . $stockID;

$result= MySQL_query($SQL);

$row = MySQL_fetch_assoc($result);        ?>

En fait, quand je tape dans la barre de recherche le mot “Mitrale”, il sera mis dans la variable $stockID qui elle-même appelée par la variable $SQL qui contient la ligne de code SQL.

Ensuite, on utilise la fonction MySQL_query pour envoyer la requête à la DB ou la fonction MySQL_fetch_assoc effectuera la recherche du mot “Mitrale” dans la colonne de “marque” afin de récupérer toutes les rangées qui en contiennent le mot “Mitrale ».

C’est claire que mes entrées n’ont pas été traité et validé, car on les a mis directement dans la requête SQL, et ça, c’est exactement le phénomène qui conduit à l’injection SQL.

Question : mais comment savoir si une application web est vulnérable ? On n’a pas le code de l’application ?

Réponse : vous pouvez tester en entrant des caractères spéciaux comme une apostrophe, et si vous aurez une erreur comme celle-ci, vous déduirez que l’application est vulnérable à SQLi (c’est typique dans les formes basiques seulement) :

Mais pourquoi cette erreur ? Elle survient, car la syntaxe SQL après le mot WHERE nécessite une apostrophe ouvrante et une autre fermante, et si vous entrez une apostrophe et qui ne subit aucune validation, elle va jouer le rôle de la fermante !! Et juste après,  l’interpréteur trouve une autre qui la considère comme ouvrante, donc l’interpréteur (qui est un mec sérieux🤪) voit ce qui s’en suit……il ne trouve rien……il ne comprend rien dans ce souk et il affiche une erreur immédiatement.

Cependant, on a une SQL vulnérabilité et on va devoir l’exploiter pour voir ce que la DB cache, donc devinez ce qui va se passer si je fais rentrer ce petit code dans la barre de recherche :

‘ or ‘1’=’1

Il se transforme dans la variable $SQL en :

SELECT * FROM chaussete WHERE marque=’ ‘ ‘ or ‘1’=’1

Pour que vous pouviez visualiser la syntaxe, j’ai mis les apostrophes originales en rouge, l’interpréteur voit dedans et n’y trouve rien, passe au reste, il trouve une équation 1=1 qui est mathématiquement toujours VRAI donc ce qu’il va faire, c’est…….d’afficher le contenu de toute la table 😈.

Dans le scénario précèdent, l’attaque n’est pas vraiment dangereuses, car le contenu de la table est banal (que des chaussettes !).

Le plus intéressent, c’est de chercher la table qui contient les informations confidentielles de la clientèle 🤠, c’est intéressant non ?,

Pour cela, il faut connaître un mot-clé supplémentaire : UNION sert à concaténer ou mettre bout-à-bout le résultat de plusieurs requêtes utilisant la commande SELECT.

Donc si je balance ce code :

' UNION SELECT table_schema, table_name FROM information_schema.tables WHERE table_name LIKE '%clients%' -- '

NOTE : les “ — ” deux tirets, on les met pour commenter un code et qui vont faire que l’interpréteur néglige le reste de la commande, car ce n’est pas la peine d’interpréter un commentaire.

Ce code va me retourner le nom de la DB (table_schema) et le nom de la table (table_name) qui contient les clients, donc tout ce qui nous reste, c’est de récupérer leurs données par la commande suivante :

'union select client, password FROM business.client -- '

Sachant que business est le nom de DB et client est le nom de la table.

Et j’aurais tous les noms de client en plus de leurs mots de passe.

N.B : les mots de passe au sein de la table son hacher, vous devez utiliser un outil qui permet de dé-hachage, ou tout simplement créez votre propre utile avec python.

Allons assez de théorie, je vais vous chercher un challenge qu’on va résoudre ensemble…….

Voilà, celui de hackthis est un bon coin pour commencer, rendez-vous sur SQLi level_1 dans l’onglet LEVELS, le challenge consiste a accéder à n’importe quel compte utilisateur.

Après quelques tentatives, j’ai eu ce résultat, cela après avoir entré ‘admin :

Analysez bien l’erreur.

Il nous dit qu’il y a une erreur dans la syntaxe suivante : sélectionner tout le contenu de la table users, et choisir la rangé ou username=’admin’ ET password=’ ‘.

L’erreur provient de l’absence du mot de passe, en outre j’ai choisi ‘admin ’, car c’est fort probable qu’il soit dans la table, et puis j’en ai qu’a trouvé son mot de passe !.

En fait, je ne vais pas chercher son mot de passe, au lieu de le faire, je vais entrer une requête dans le champ password qui va tromper l’application, la voici :

Anass'or’1’=’1

Vous pouvez remplacer « Anass » par n’importe quel autre string, ce qui est important c’est l’équation qui doit être toujours VRAI, car l’application va en quelque sorte choisir entre les deux propositions : soit le mot de passe égale a « Anass » est c’est FAUX, soit 1=1 qui est une equation VRAI, donc elle me laisse passer🤣.

N.B : vous pouvez aussi utiliser ce bout de code dans le champ du Username.

Notez qu’il n’y a pas d’apostrophe ouvrante et fermante, car ils sont déjà mis dans la requête de l’application web, c’est pourquoi je vous ai dit de les prêter une importance particulière dans ce type d’attaque, notez aussi qu’il n’y a pas d’espace entre les caractères.

 

Voilà, challenge completed 😉.

 

J’espère que vous avez compris un petit peu l’attaque SQLi, car comme d’habitude je vous donne les bases et je vous laisse approfondir vos connaissances en s’entrainant sur les platformes de CTF, so il reste un deuxième challenge SQLi, changez le en vert 💪.

PEACE.