Explications sur les attaques DDoS et injections SQL

Dans la plupart des articles concernant le Hack vous avez en général un suivi des attaques perpétrées par différents groupes comme les Anonymous, LulzSec et AntiSec. Et vous avez sûrement entendu aussi parlé des sites web et plateformes qui ont été piraté comme Sony en début d'année par exemple. Mais êtes-vous au courant des procédés employés pour faire tomber ces services?

Il y a de nombreux outils et de techniques que certains hackers utilisent pour arriver à leur fin mais je ne vous donnerai pas tout ça clé en main. Ici je vais vous expliquer brièvement le principe de fonctionnement des deux attaques les plus connues sur le web.

• Les attaques DDoS : (Distributed) Denial of Service
• Les injections SQL ou SQLi

Un Denial of Service (aussi appelée Distributed Denial of Service ou DDoS), se traduit par attaque par déni de service. Ce genre d'attaque a pour but de rendre indisponible un service. Ici je prendrai comme exemple (d'après le schéma ci-dessus) une attaque d'un serveur web en inondant son réseau afin d'empêcher son fonctionnement. Vous l'avez compris, l'objectif et la réussite d'une attaque DDoS est de rendre inopérant le site web pour tout le monde.

Pour une attaque DDoS, tout est question de logistique.
Et rien de tel qu'un exemple pour vous expliquer tout ça

Prenez un bon million de personnes malveillantes qui se réunissent dans le but de saboter les affaires de la société X en utilisant son centre d'appels. Ces personnes vont coordonner leur action disons vendredi à 10h pour appeler tous en même temps la société X. Celle-ci sera alors assaillie de millions d'appels téléphoniques et ne pourra probablement pas les gérer. Le résultat est que les clients légitimes voulant appeler cette société auront du mal à la joindre.

Une attaque DDoS sur un serveur web fonctionne exactement de la même façon. En effet, il n'y a pratiquement aucun moyen de savoir si le trafic généré provient de requêtes légitimes ou de hackers. C'est un type d'attaque en général très efficace mais qui demande de gros moyens suivant le serveur ciblé.

Une attaque DDoS fonctionne pour ainsi dire comme un brute force. Vous aurez donc besoin d'un assez grand nombre d'ordinateurs tous coordonnées pour attaquer en même temps.
D'après l'exemple que je vous ai cité avec le centre d'appels téléphoniques, vous imaginez bien qu'il ait plutôt difficile de piloter directement plusieurs milliers d'ordinateurs pour attaquer un serveur. C'est là que les machines zombies entrent en jeu.

Comme vous le savez probablement, il existe une multitude de malwares et troyens qui une fois installés sur un système sommeillent en attendant les instructions du hacker l'ayant créé.
Une de ces instruction pourrait par exemple être d'envoyer de multiples requêtes vers un serveur web. Et donc un seul hacker qui aurait infecté quelques milliers d'ordinateurs pourrait utiliser ceux-ci pour perpétrer son attaque.

Avec l'utilisation de plusieurs machines zombies il est en général très difficile de remonter à la source de ce genre d'attaque car le hacker n'est pas obligé d'utiliser sa propre machine pour exécuter son action (à part contrôler les machines zombies mais cela va de soit).

Une injection SQL est un exploit, c'est-à-dire une faille de sécurité dans une application étant connectée à une base de données. En général ce genre de failles tire parti des mauvaises techniques de programmation de certains développeurs.
Cette attaque permet de compromettre une base de données voir même un serveur si l'utilisateur utilisant la base de données a des droits systèmes. Mais contrairement à une attaque DDoS une attaque SQLi peut être facilement évitable si une application web est correctement programmée.

Quand vous voulez vous connecter sur un site web, vous entrez votre nom d'utilisateur et votre mot de passe. Pour tester ces paramètres, l'application web fera une requête de ce type :

SELECT user_id FROM users WHERE username='myuser' AND password='mypass';

A noter que les variables de type String doivent être entourées de guillemets simples.

Ainsi la combinaison du nom d'utilisateur (myuser) et du mot de passe (mypass) doit correspondre à une ligne dans la table des utilisateurs (users) pour qu'un user_id soit retourné.
Si aucune ligne ne correspond, aucun user_id n'est retourné et de cette façon la connexion avec les identifiants saisis est invalide.

Cependant si un utilisateur rentre une valeur de substitution qui peut être interprétée dans la requête, alors à ce moment-là votre application est sensible à une injection SQL.
Supposons que myuser'-- est entré dans le champs du nom d'utilisateur avec un mot de passe quelconque. Ceci donnerait :

SELECT user_id FROM users WHERE username='myuser'--' AND password='mypass';

La clé de cette requête est l'inclusion des deux tirets (--). C'est en fait le token permettant de mettre en commentaire une requête SQL. Et donc tout ce qui est après ces deux tirets sera ignoré. Ici la requête exécutée sera :

SELECT user_id FROM users WHERE username='myuser'

Comme vous l'avez remarqué le plus flagrant ici est l'omission de la vérification du mot de passe! Et c'est en incluant dans le champs du nom d'utilisateur les deux tirets que le mot de passe est complètement ignoré. C'est ce qu'on appelle une injection SQL.

En imaginant que le site a les pleins pouvoirs sur sa base de donnée alors les conséquences peuvent être assez catastrophiques. Ceci peut donner la possibilité au hacker de supprimer, créer ou modifier des enregistrements en base de données, etc...

Pour illustrer les dommages qui peuvent être occasionnés, prenons cette requête comme exemple :

SELECT user_id FROM users WHERE username='lama'; DROP TABLE users;--' AND password='mypass';

Ici nous avons entré dans le champs de saisie du nom d'utilisateur lama'; DROP TABLE users;--. Le point virgule permet de terminer une déclaration puis d'en créer une nouvelle à la suite. DROP TABLE users; va supprimer la table users de la base de donnée. En gros la requête exécutée en base donnée sera :

SELECT user_id FROM users WHERE username='lama';
DROP TABLE users;

Bien sûr selon les permissions SQL le hacker peut faire bien pire! Comme effacer toute la base de données, créer de nouveaux comptes de connexion, etc...

Une injection SQL peut être facilement contournée en "désinfectant" ou en "échappant" les données. En anglais on peut traduire ces termes par "Sanitize" ou "Escape". De cette façon une chaîne à l'intérieure d'une requête ne pourra être terminée prématurément.

Par exemple pour rechercher le nom d'utilisateur L'ama en base de donnée vous êtes obligé d'échapper le guillemet simple après le L. Vous pouvez donc "désinfecter" cette chaîne en insérant un \.
Revenons à l'exemple d'injection SQL précédent avec la valeur myuser'--.

SELECT user_id FROM users WHERE username='myuser\'--' AND password='mypass';

En échappant le guillemet simple après myuser, la base de donnée recherchera le nom d'utilisateur myuser'--. Ainsi la requête est exécutée entièrement et inclue la deuxième condition sur le mot de passe.

Il existe plusieurs méthodes pour échapper une chaîne dans une requête. En PHP par exemple vous pouvez utiliser la fonction mysql_real_escape_string() pour échapper une chaîne dans une requête.

$sql = "SELECT user_id FROM users ";
$sql .= "WHERE username='" . mysql_real_escape_string("myuser'--") . "' ";
$sql .= "AND password='" . mysql_real_escape_string("mypass") . "'";
$res = mysql_query($sql);

Voilà c'est à peu prés tout ce qu'il faut savoir sur les attaques DDoS et les injections SQL. Et bien que les attaques sur le web évoluent, deviennent de plus en plus sophistiquées ou s'orientent vers d'autres types de vulnérabilités, il est important de se rappeler qu'en général il s'agit d'une négligence du/des développeur(s).

Certains types d'attaques comme DDoS ne peuvent pas être facilement évitées, tandis que d'autres comme les injections SQL peuvent l'être. Cependant les dommages occasionnés par ces types d'attaques peuvent aller d'une simple coupure du serveur (pour les attaques DDoS par exemple) à une corruption complète des données du site.