Comment les pirates s'emparent de sites Web avec SQL Injection et DDoS
Même si vous n'avez suivi que vaguement les événements des groupes de hackers Anonymous et LulzSec, vous avez probablement entendu parler de piratage de sites Web et de services, comme le fameux piratage Sony. Avez-vous déjà demandé comment ils le font?
Ces groupes utilisent un certain nombre d'outils et de techniques, et bien que nous n'ayons pas pour objectif de vous fournir un manuel pour le faire vous-même, il est utile de comprendre ce qui se passe. Deux des attaques que vous entendez régulièrement les utiliser sont “Déni de service (DDoS)” et “Injections SQL” (SQLI). Voici comment ils fonctionnent.
Image par xkcd
Attaque par déni de service
Qu'Est-ce que c'est?
Une attaque de «déni de service» (parfois appelée «déni de service distribué» ou DDoS) se produit lorsqu'un système, dans ce cas un serveur Web, reçoit tellement de demandes à la fois que les ressources du serveur sont surchargées que le système se verrouille simplement. et ferme. L'objectif et le résultat d'une attaque DDoS réussie sont les sites Web du serveur cible ne sont pas disponibles pour les demandes de trafic légitimes..
Comment ça marche?
La logistique d’une attaque DDoS peut être mieux expliquée par un exemple.
Imaginez un million de personnes (les assaillants) se rassemblent dans le but d'entraver les activités de la société X en supprimant leur centre d'appels. Les assaillants se coordonnent pour appeler mardi à 9 heures le numéro de téléphone de la société X. Très probablement, le système téléphonique de la société X ne sera pas en mesure de traiter un million d'appels en même temps, de sorte que toutes les lignes entrantes seront bloquées par les attaquants. Il en résulte que les appels de clients légitimes (c’est-à-dire ceux qui ne sont pas les attaquants) ne sont pas acheminés car le système téléphonique est bloqué et traite les appels des attaquants. La société X risque donc de perdre des clients en raison de l’impossibilité de répondre aux demandes légitimes..
Une attaque DDoS sur un serveur Web fonctionne exactement de la même manière. Dans la mesure où il est pratiquement impossible de savoir quel trafic provient de requêtes légitimes ou non d'attaques tant que le serveur Web n'a pas traité la requête, ce type d'attaque est généralement très efficace..
L'exécution de l'attaque
En raison de la nature «brutale» d'une attaque DDoS, de nombreux ordinateurs doivent être tous coordonnés pour attaquer en même temps. Pour revenir à notre exemple de centre d’appel, il faudrait que tous les attaquants sachent qu’ils doivent appeler à 9 heures et qu’ils appellent à cette heure-là. Ce principe fonctionnera certainement lorsqu'il s'agira d'attaquer un serveur Web, mais il deviendra beaucoup plus facile lorsque des ordinateurs zombies seront utilisés, au lieu des ordinateurs réels..
Comme vous le savez probablement, il existe de nombreuses variantes de programmes malveillants et de chevaux de Troie qui, une fois sur votre système, sont en sommeil et occasionnellement, téléphonez chez vous pour obtenir des instructions. L'une de ces instructions pourrait, par exemple, être d'envoyer des demandes répétées au serveur Web de la société X à 9 heures. Ainsi, avec une seule mise à jour du site d'origine du logiciel malveillant respectif, un seul attaquant peut coordonner instantanément des centaines de milliers d'ordinateurs infectés afin de mener une attaque de DDoS massive..
La beauté d'utiliser des ordinateurs zombies réside non seulement dans son efficacité, mais également dans son anonymat, car l'attaquant n'a pas réellement besoin d'utiliser son ordinateur pour exécuter l'attaque..
Attaque par injection SQL
Qu'Est-ce que c'est?
Une attaque par «injection SQL» (SQLI) est un exploit qui tire parti de techniques de développement Web médiocres et, généralement associée à une sécurité de base de données défectueuse. Le résultat d'une attaque réussie peut aller de l'emprunt d'identité d'un compte d'utilisateur à une compromission complète de la base de données ou du serveur respectif. Contrairement à une attaque DDoS, une attaque SQLI est complètement et facilement évitable si une application Web est correctement programmée.
L'exécution de l'attaque
Chaque fois que vous vous connectez à un site Web et entrez votre nom d'utilisateur et votre mot de passe, afin de tester vos informations d'identification, l'application Web peut exécuter une requête du type suivant:
SELECT UserID FROM Utilisateurs WHERE UserName = "myuser" AND Password = "mypass";
Remarque: les valeurs de chaîne dans une requête SQL doivent être placées entre guillemets, raison pour laquelle elles apparaissent autour des valeurs entrées par l'utilisateur..
Ainsi, la combinaison du nom d'utilisateur entré (myuser) et du mot de passe (mypass) doit correspondre à une entrée du tableau Utilisateurs pour qu'un identifiant utilisateur puisse être renvoyé. S'il n'y a pas de correspondance, aucun ID utilisateur n'est renvoyé et les informations d'identification de connexion ne sont pas valides. Même si une implémentation particulière peut différer, les mécanismes sont assez standards.
Voyons maintenant une requête d’authentification de modèle à laquelle nous pouvons substituer les valeurs saisies par l’utilisateur sur le formulaire Web:
SELECT UserID FROM Utilisateurs WHERE UserName = "[utilisateur]" AND Password = "[pass]"
À première vue, cela peut sembler une étape simple et logique permettant de valider facilement les utilisateurs. Toutefois, si une simple substitution des valeurs entrées par l'utilisateur est effectuée sur ce modèle, il est sujet à une attaque SQLI..
Par exemple, supposons que «myuser'-» soit entré dans le champ du nom d'utilisateur et que «badpass» soit entré dans le mot de passe. En utilisant une simple substitution dans notre requête de modèle, nous obtiendrions ceci:
SELECT UserID FROM Utilisateurs WHERE UserName = "myuser" - 'AND Password = "falsepass"
Une des clés de cette déclaration est l'inclusion des deux tirets (-). Il s’agit du jeton de commentaire de début pour les instructions SQL. Par conséquent, tout ce qui apparaît après les deux tirets (inclus) sera ignoré. Essentiellement, la requête ci-dessus est exécutée par la base de données en tant que:
SELECT UserID FROM Utilisateurs WHERE UserName = "myuser"
L'omission flagrante ici est l'absence de vérification du mot de passe. En incluant les deux tirets dans le champ utilisateur, nous avons complètement contourné la condition de vérification du mot de passe et nous avons pu nous connecter en tant que «myuser» sans connaître le mot de passe correspondant. Cette action de manipuler la requête pour produire des résultats inattendus est une attaque par injection SQL..
Quel dommage peut être fait?
Une attaque par injection SQL est causée par un codage d'application négligent et irresponsable et est totalement évitable (ce que nous verrons dans quelques instants). Toutefois, l'étendue des dommages pouvant être causés dépend de la configuration de la base de données. Pour qu'une application Web puisse communiquer avec la base de données principale, celle-ci doit fournir un identifiant de connexion à la base de données (remarque, cette opération est différente de celle d'un utilisateur connecté au site Web lui-même). En fonction des autorisations requises par l'application Web, ce compte de base de données respectif peut nécessiter une autorisation d'accès en lecture / écriture dans les tables existantes uniquement à un accès complet à la base de données. Si ce n'est pas clair maintenant, quelques exemples devraient aider à clarifier.
Sur la base de l'exemple ci-dessus, vous pouvez constater que vous entrez, par exemple,, "youruser" - "," admin "-" ou tout autre nom d'utilisateur, nous pouvons nous connecter instantanément au site en tant qu'utilisateur sans connaître le mot de passe. Une fois que nous sommes dans le système, nous ne savons pas que nous ne sommes pas cet utilisateur. Nous avons donc un accès complet au compte correspondant. Les autorisations de base de données ne constituent pas un filet de sécurité pour cela car, en règle générale, un site Web doit avoir au moins un accès en lecture / écriture à sa base de données respective..
Supposons maintenant que le site Web contrôle totalement sa base de données, ce qui lui permet de supprimer des enregistrements, d’ajouter / supprimer des tables, d’ajouter de nouveaux comptes de sécurité, etc. Il est important de noter que certaines applications Web peuvent nécessiter ce type d’autorisation. n'est pas automatiquement une mauvaise chose que le contrôle total est accordé.
Donc, pour illustrer les dégâts pouvant être causés dans cette situation, nous allons utiliser l'exemple fourni dans la BD ci-dessus en entrant ce qui suit dans le champ du nom d'utilisateur: "Robert '; Utilisateurs de DROP TABLE; -". Après une simple substitution, la requête d'authentification devient:
SELECT UserID FROM Utilisateurs WHERE UserName = "Robert"; DROP TABLE Utilisateurs; - 'AND Password = "badpass"
Remarque: le point-virgule est dans une requête SQL est utilisé pour signifier la fin d'une instruction particulière et le début d'une nouvelle instruction.
Qui est exécuté par la base de données en tant que:
SELECT UserID FROM Utilisateurs WHERE UserName = "Robert"DROP TABLE Utilisateurs
Donc, juste comme ça, nous avons utilisé une attaque SQLI pour supprimer la totalité du tableau Utilisateurs.
Bien entendu, il est bien pire que, compte tenu des autorisations SQL accordées, l'attaquant puisse modifier les valeurs, vider les tables (ou l'intégralité de la base de données) en un fichier texte, créer de nouveaux comptes de connexion ou même pirater l'installation complète de la base de données..
Prévenir une attaque par injection SQL
Comme nous l'avons mentionné à plusieurs reprises, une attaque par injection SQL est facilement évitable. L'une des règles fondamentales du développement Web est que vous ne faites jamais confiance aveuglément aux entrées des utilisateurs, comme nous le faisions lorsque nous effectuions une substitution simple dans notre requête de modèle ci-dessus..
Une attaque SQLI est facilement contrecarrée par ce que l'on appelle la désinfection (ou l'échappement) de vos entrées. Le processus de désinfection est en fait assez trivial, car il ne traite que les caractères de citation simple (') en ligne de manière appropriée, de sorte qu'ils ne puissent pas être utilisés pour terminer prématurément une chaîne dans une instruction SQL..
Par exemple, si vous souhaitez rechercher «O'neil» dans une base de données, vous ne pouvez pas utiliser une simple substitution, car une seule citation après le 0 entraînerait la fin prématurée de la chaîne. Au lieu de cela, vous le désinfectez en utilisant le caractère d'échappement de la base de données respective. Supposons que le caractère d'échappement d'un guillemet simple en ligne est précédé d'un guillemet par un symbole \. Donc, "O'neal" serait assaini comme "O \ 'neil".
Ce simple geste d’assainissement empêche quasiment une attaque SQLI. Pour illustrer notre propos, revoyons nos exemples précédents et voyons les requêtes résultantes lorsque la saisie de l'utilisateur est vérifiée..
mon utilisateur-- / mauvaise passe:
SELECT UserID FROM Utilisateurs WHERE UserName = "myuser \" - 'AND Password = "falsepass"
Étant donné que le guillemet simple après que myuser est échappé (ce qui signifie qu'il est considéré comme faisant partie de la valeur cible), la base de données recherchera littéralement le nom d'utilisateur de "myuser" - ". De plus, comme les tirets sont inclus dans la valeur de chaîne et non dans l'instruction SQL elle-même, ils seront considérés comme faisant partie de la valeur cible au lieu d'être interprétés comme un commentaire SQL..
Robert '; DROP TABLE Utilisateurs;-- / mauvaise passe:
SELECT UserID FROM Utilisateurs WHERE UserName = "Robert \"; DROP TABLE Utilisateurs; - 'AND Password = "badpass"
En échappant simplement à la citation simple après Robert, le point-virgule et les tirets sont contenus dans la chaîne de recherche UserName afin que la base de données recherche littéralement "Robert '; Utilisateurs de DROP TABLE; -" au lieu d'exécuter la suppression de la table.
En résumé
Alors que les attaques Web évoluent et deviennent plus sophistiquées ou se concentrent sur un point d’entrée différent, il est important de se rappeler de se protéger contre les attaques éprouvées qui ont inspiré plusieurs «outils de piratage» disponibles gratuitement et conçus pour les exploiter..
Certains types d'attaques, tels que DDoS, ne peuvent pas être facilement évités, tandis que d'autres, tels que SQLI, le peuvent. Cependant, les dommages pouvant être causés par ces types d’attaques peuvent aller d’un inconvénient à catastrophique en fonction des précautions prises.
