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 sites Web et de services piratés, comme les infâmes hacks Sony. Vous êtes-vous déjà demandé comment ils procédaient?
Ces groupes utilisent un certain nombre d’outils et de techniques, et même si nous n’essayons pas de vous donner un manuel pour le faire vous-même, il est utile de comprendre ce qui se passe. Deux des attaques dont vous entendez régulièrement parler sont le «déni de service (distribué)» (DDoS) et les «injections SQL» (SQLI). Voici comment ils fonctionnent.
Image de 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 requêtes à la fois que les ressources du serveur sont surchargées, le système se bloque simplement et s'arrête. Le but et le résultat d'une attaque DDoS réussie sont que les sites Web du serveur cible ne sont pas disponibles pour légitimer les demandes de trafic.
Comment ça marche?
La logistique d'une attaque DDoS peut être mieux expliquée par un exemple.
Imaginez qu'un million de personnes (les attaquants) se réunissent dans le but d'entraver les activités de la société X en supprimant leur centre d'appels. Les attaquants se coordonnent pour que mardi à 9 heures, ils appellent tous 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 gérer un million d'appels à la fois, de sorte que toutes les lignes entrantes seront bloquées par les attaquants. Le résultat est que les appels des clients légitimes (c'est-à-dire ceux qui ne sont pas les attaquants) ne passent pas parce que le système téléphonique est bloqué pour gérer les appels des attaquants. Donc, en substance, la société X est potentiellement en train de perdre des affaires en raison des demandes légitimes qui ne peuvent pas passer.
Une attaque DDoS sur un serveur Web fonctionne exactement de la même manière. Comme il n'y a pratiquement aucun moyen de savoir quel trafic provient des demandes légitimes par rapport aux attaquants jusqu'à ce que le serveur Web traite la demande, ce type d'attaque est généralement très efficace.
Exécuter l'attaque
En raison de la nature de «force brute» d'une attaque DDoS, vous devez disposer de nombreux ordinateurs tous coordonnés pour attaquer en même temps. En revisitant notre exemple de centre d'appels, cela exigerait que tous les attaquants sachent à la fois appeler à 9 heures du matin et appeler à ce moment-là. Bien que ce principe fonctionne certainement lorsqu'il s'agit d'attaquer un serveur Web, il devient beaucoup plus facile lorsque des ordinateurs zombies, au lieu de véritables ordinateurs habités, sont utilisés.
Comme vous le savez probablement, il existe de nombreuses variantes de logiciels malveillants et de chevaux de Troie qui, une fois sur votre système, sont inactifs et parfois «téléphonent à la maison» 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 du matin. Ainsi, avec une seule mise à jour de l'emplacement d'origine du malware respectif, un seul attaquant peut coordonner instantanément des centaines de milliers d'ordinateurs compromis pour effectuer une attaque DDoS massive.
La beauté de l'utilisation d'ordinateurs zombies réside non seulement dans son efficacité, mais aussi dans son anonymat, car l'attaquant n'a pas du tout à 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ées à une sécurité de base de données défectueuse. Le résultat d'une attaque réussie peut aller de l'usurpation d'identité d'un compte 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.
Exécuter l'attaque
Chaque fois que vous vous connectez à un site Web et que vous 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 comme celle-ci:
SELECT UserID FROM Users WHERE UserName = 'myuser' AND Password = 'mypass';
Remarque: les valeurs de chaîne dans une requête SQL doivent être placées entre guillemets simples, c'est pourquoi elles apparaissent autour des valeurs saisies par l'utilisateur.
Ainsi, la combinaison du nom d'utilisateur saisi (myuser) et du mot de passe (mypass) doit correspondre à une entrée dans la table Users pour qu'un UserID soit renvoyé. S'il n'y a pas de correspondance, aucun ID utilisateur n'est renvoyé et les informations de connexion ne sont donc pas valides. Bien qu'une implémentation particulière puisse différer, la mécanique est assez standard.
Examinons maintenant un modèle de requête d'authentification que nous pouvons remplacer par les valeurs saisies par l'utilisateur sur le formulaire Web:
SELECT UserID FROM Users WHERE UserName = '[user]' AND Password = '[pass]'
À première vue, cela peut sembler une étape simple et logique pour valider facilement les utilisateurs, mais si une simple substitution des valeurs saisies par l'utilisateur est effectuée sur ce modèle, il est susceptible d'une attaque SQLI.
Par exemple, supposons que «myuser’–» soit entré dans le champ du nom d’utilisateur et que «incorrectpass» 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 Users WHERE UserName = 'myuser' - 'AND Password =' incorrectpass '
Une clé de cette déclaration est l'inclusion des deux tirets
(--)
. Il s'agit du jeton de commentaire de début pour les instructions SQL, donc 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 comme:
SELECT UserID FROM Users WHERE UserName = 'monutilisateur'
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 avons pu nous connecter en tant que «myuser» sans connaître le mot de passe respectif. Cet acte de manipulation de la requête pour produire des résultats inattendus est une attaque par injection SQL.
Quels dommages peut-on faire?
Une attaque par injection SQL est causée par un codage d'application négligent et irresponsable et est complètement évitable (ce que nous couvrirons dans un instant), cependant l'étendue des dommages qui peuvent ê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, l'application doit fournir une connexion à la base de données (notez que ceci est différent de la connexion d'un utilisateur au site Web lui-même). Selon les autorisations requises par l'application Web, ce compte de base de données respectif peut nécessiter n'importe quoi, de l'autorisation de lecture / écriture dans les tables existantes uniquement à l'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 le voir en saisissant, par exemple,
"votreutilisateur '-", "admin' -"
ou tout autre nom d'utilisateur, nous pouvons instantanément nous connecter 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 réellement cet utilisateur, nous avons donc un accès complet au compte respectif. Les autorisations de base de données ne fourniront pas de filet de sécurité pour cela car, généralement, 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 ait le contrôle total de sa base de données respective qui donne la possibilité 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 pourraient avoir besoin de ce type d'autorisation. Ce n’est pas automatiquement une mauvaise chose qu’un contrôle total soit accordé.
Donc, pour illustrer les dommages qui peuvent être causés dans cette situation, nous utiliserons l'exemple fourni dans la bande dessinée ci-dessus en entrant ce qui suit dans le champ du nom d'utilisateur:
"Robert '; DROP TABLE Utilisateurs; -".
Après une simple substitution, la requête d'authentification devient:
SELECT UserID FROM Users WHERE UserName = 'Robert'; DROP TABLE Users; - 'AND Password =' Incorrectpass '
Remarque: le point-virgule 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 comme:
SELECT UserID FROM Users WHERE UserName = 'Robert'Utilisateurs DROP TABLE
Donc, juste comme ça, nous avons utilisé une attaque SQLI pour supprimer toute la table Users.
Bien sûr, bien pire peut être fait car, en fonction des autorisations SQL autorisées, l'attaquant peut modifier les valeurs, vider les tables (ou toute la base de données elle-même) dans un fichier texte, créer de nouveaux comptes de connexion ou même détourner l'ensemble de l'installation de la base de données.
Empêcher une attaque par injection SQL
Comme nous l'avons mentionné à plusieurs reprises précédemment, une attaque par injection SQL est facilement évitable. L'une des règles cardinales du développement Web est que vous ne faites jamais aveuglément confiance aux entrées de l'utilisateur comme nous l'avons fait lorsque nous avons effectué 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 nettoyer (ou échapper) vos entrées. Le processus de désinfection est en fait assez trivial car il ne fait essentiellement que gérer les caractères entre guillemets simples en ligne de manière appropriée afin qu'ils ne puissent pas être utilisés pour terminer prématurément une chaîne à l'intérieur d'une instruction SQL.
Par exemple, si vous souhaitez rechercher "O’neil" dans une base de données, vous ne pouvez pas utiliser de substitution simple car le guillemet simple après le O entraînerait la fin prématurée de la chaîne. Au lieu de cela, vous la 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 fasse précéder chaque guillemet d'un symbole \. Donc "O’neal" serait assaini comme "O \ 'neil".
Ce simple acte d'assainissement empêche pratiquement une attaque SQLI. Pour illustrer, revenons à nos exemples précédents et voyons les requêtes résultantes lorsque l'entrée utilisateur est nettoyée.
myuser '-
/
mauvaise passe
:
SELECT UserID FROM Users WHERE UserName = 'myuser \' - 'AND Password =' incorrectpass '
Étant donné que le guillemet simple après monutilisateur 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 '-".
En outre, étant donné que 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 '; Utilisateurs DROP TABLE; -
/
mauvaise passe
:
SELECT UserID FROM Users WHERE UserName = 'Robert \'; DROP TABLE Users; - 'AND Password =' Incorrectpass '
En échappant simplement le guillemet simple après Robert, le point-virgule et les tirets sont contenus dans la chaîne de recherche UserName de sorte que la base de données recherchera littéralement
"Robert '; DROP TABLE Utilisateurs; -"
au lieu d'exécuter la suppression de 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 été l'inspiration de plusieurs «outils de piratage» disponibles gratuitement et conçus pour les exploiter.
Certains types d'attaques, comme DDoS, ne peuvent pas être facilement évités tandis que d'autres, comme SQLI, le peuvent. Cependant, les dommages qui peuvent être causés par ces types d'attaques peuvent aller d'un inconvénient à une catastrophe selon les précautions prises.
