Condition de concurrence dans les applications Web

TL; DR Cet article décrit des astuces impopulaires sur les conditions de compétition qui ne sont pas couramment utilisées dans ce type d'attaque. Sur la base des résultats de nos recherches, nous avons créé notre propre framework pour les attaques racepwn.

Vasya veut transférer 100 dollars qu'il a sur son compte, Petya. Il va dans l'onglet des transferts, conduit le surnom de Petin dans le champ avec le montant des fonds à transférer - le nombre 100. Ensuite, clique sur le bouton de transfert. Les données à qui et combien sont envoyées à l'application Web. Que peut-il se passer à l'intérieur? Que doit faire le programmeur pour que tout fonctionne correctement?

• Vous devez vous assurer que le montant est disponible pour Vasya pour le transfert.

Il est nécessaire d'obtenir la valeur du solde actuel de l'utilisateur, s'il est inférieur au montant qu'il souhaite transférer, lui en parler. Compte tenu du fait que notre site n'accorde pas de prêts et ne devrait pas avoir un solde négatif.

• Soustraire le montant à transférer du solde de l'utilisateur

Il est nécessaire de noter le solde de l'utilisateur actuel, moins le montant transféré. C'était 100, c'est devenu 100-100 = 0.

• Ajoutez au solde de l'utilisateur Petya le montant qui a été transféré.

Petya, au contraire, était 0, il est devenu 0 + 100 = 100.

• Affichez un message à l'utilisateur qu'il est bien fait!

Lors de l'écriture de programmes, une personne prend les algorithmes les plus simples, qu'elle combine en un seul tracé, qui sera le script du programme. Dans notre cas, la tâche du programmeur est d'écrire la logique des transferts d'argent (points, crédits) d'une personne à une autre dans une application web. Guidé par la logique, vous pouvez créer un algorithme composé de plusieurs vérifications. Imaginez que nous venons de supprimer tout ce qui est inutile et compilé un pseudocode.

 (. >= _)  .=.-_ .=.+_ ()  () 

Mais tout irait bien si tout se passait à son tour. Mais un site peut servir de nombreux utilisateurs en même temps, et cela ne se produit pas dans un seul thread, car les applications Web modernes utilisent le multitraitement et le multithreading pour le traitement parallèle des données. Avec l'avènement du multithreading, les programmes ont une vulnérabilité architecturale amusante - condition de concurrence (ou condition de concurrence).

Imaginez maintenant que notre algorithme fonctionne simultanément 3 fois.

Vasya a encore 100 points sur son solde, mais d'une manière ou d'une autre, il s'est tourné vers l'application Web en trois threads en même temps (avec un minimum de temps entre les demandes). Les trois flux vérifient si l'utilisateur est Petya et vérifient si Vasya a suffisamment d'équilibre pour le transfert. Au moment où l'algorithme vérifie le solde, il est toujours égal à 100. Une fois la vérification terminée, 100 est soustrait du solde actuel 3 fois et Pete est ajouté.

Qu'avons-nous? Vasya a un solde négatif sur son compte (100 - 300 = -200 points). Dans l'intervalle, Petya a 300 points, bien qu'en fait il devrait être de 100. C'est un exemple typique de l'exploitation d'une condition de course. C'est comparable au fait que plusieurs personnes passent sur un seul passage à la fois. Voici une capture d'écran de cette situation de 4lemon



La condition de concurrence peut être dans des applications multithreads, ainsi que dans les bases de données dans lesquelles elles fonctionnent. Pas nécessairement dans les applications Web, par exemple, il s'agit d'un critère commun pour l'escalade de privilèges dans les systèmes d'exploitation. Bien que les applications Web aient leurs propres caractéristiques pour un fonctionnement réussi, je veux en parler.

Fonctionnement typique des conditions de course

Un hacker entre dans une salle de narguilé, une quête et un bar, et pour lui - vous avez une condition de course! Omar Ganiev

Dans la plupart des cas, un logiciel multithread est utilisé en tant que client pour vérifier / faire fonctionner la condition de concurrence. Par exemple, Burp Suite et son outil Intruder. Ils ont mis une requête HTTP pour la répétition, installé de nombreux flux et allumé le déluge. Comme par exemple dans cet article . Ou dans celui-ci . Il s'agit d'une méthode assez efficace, si le serveur autorise l'utilisation de plusieurs threads pour sa ressource, et comme ils le disent dans les articles ci-dessus, si cela ne fonctionne pas, essayez à nouveau. Mais le fait est que dans certaines situations, cela peut ne pas être efficace. Surtout si vous vous souvenez comment ces applications accèdent au serveur.

Qu'y a-t-il sur le serveur

Chaque thread établit une connexion TCP, envoie des données, attend une réponse, ferme la connexion, s'ouvre à nouveau, envoie des données, etc. À première vue, toutes les données sont envoyées simultanément, mais les requêtes HTTP elles-mêmes peuvent ne pas arriver de manière synchrone et sont incohérentes en raison de la nature de la couche de transport, de la nécessité d'établir une connexion sécurisée (HTTPS) et de résoudre le DNS (pas dans le cas de burp) et de nombreuses couches abstractions qui transmettent des données avant d'être envoyées à un périphérique réseau. En matière de millisecondes, cela peut jouer un rôle clé.

Pipelining HTTP

Vous pouvez rappeler HTTP-Pipelining, dans lequel vous pouvez envoyer des données à l'aide d'un seul socket. Vous pouvez voir par vous-même comment cela fonctionne en utilisant l'utilitaire netcat (vous avez GNU / Linux, non?).

En fait, vous devez utiliser Linux pour de nombreuses raisons, car il existe une pile TCP / IP plus moderne, qui est prise en charge par les noyaux du système d'exploitation. Le serveur est probablement aussi dessus.

Par exemple, exécutez nc google.com 80 et insérez-y les lignes

 GET / HTTP/1.1 Host: google.com GET / HTTP/1.1 Host: google.com GET / HTTP/1.1 Host: google.com 

Ainsi, au sein d'une même connexion, trois requêtes HTTP seront envoyées et vous recevrez trois réponses HTTP. Cette fonctionnalité peut être utilisée pour réduire le temps entre les demandes.

Qu'y a-t-il sur le serveur

Le serveur Web recevra les demandes séquentiellement (mot-clé) et traitera les réponses par ordre de priorité. Cette fonctionnalité peut être utilisée pour attaquer en plusieurs étapes (quand il est nécessaire d'effectuer séquentiellement deux actions dans le minimum de temps) ou, par exemple, pour ralentir le serveur dans la première requête afin d'augmenter le succès de l'attaque.
Astuce - vous pouvez empêcher le serveur de traiter votre demande en chargeant son SGBD, surtout si INSERT / UPDATE est utilisé. Des demandes plus lourdes peuvent «ralentir» votre charge, il est donc plus probable que vous gagniez cette course.

Fractionner une requête HTTP en deux parties

Tout d'abord, rappelez-vous comment la requête HTTP est générée. Eh bien, comme vous le savez, la première ligne est la version de la méthode, du chemin et du protocole:

GET / HTTP/1.1

Voici les en-têtes avant le saut de ligne:

Host: google.com
Cookie: a=1
Mais comment le serveur Web sait-il que la requête HTTP est terminée?

Regardons un exemple, entrez nc google.com 80 , et là

GET / HTTP/1.1
Host: google.com GET / HTTP/1.1
Host: google.com , après avoir appuyé sur ENTRÉE, rien ne se passera. Cliquez à nouveau - vous verrez la réponse.

Autrement dit, pour que le serveur Web accepte la demande HTTP, deux sauts de ligne sont nécessaires. Une requête valide ressemble à ceci:

GET / HTTP/1.1\r\nHost: google.com\r\n\r\n

S'il s'agissait de la méthode POST (n'oubliez pas Content-Length), la requête HTTP correcte serait la suivante:

POST / HTTP/1.1
Host: google.com
Content-Length: 3

a=1

ou

POST / HTTP/1.1\r\nHost: google.com\r\nContent-Length: 3\r\n\r\na=1

Essayez d'envoyer une demande similaire à partir de la ligne de commande:

 echo -ne "GET / HTTP/1.1\r\nHost: google.com\r\n\r\n" | nc google.com 80 

En conséquence, vous recevrez une réponse, car notre demande HTTP est terminée. Mais si vous supprimez le dernier \ n caractère, vous n'obtiendrez pas de réponse.

En fait, de nombreux serveurs Web doivent simplement utiliser \ n comme transfert, il est donc important de ne pas échanger \ r et \ n, sinon d'autres astuces risquent de ne pas fonctionner.

Qu'est-ce que ça donne? Vous pouvez ouvrir simultanément de nombreuses connexions à une ressource, envoyer 99% de votre requête HTTP et laisser le dernier octet non envoyé. Le serveur attendra que vous atteigniez le dernier saut de ligne. Une fois qu'il sera clair que la partie principale des données a été envoyée, envoyez le dernier octet (ou plusieurs).

Ceci est particulièrement important lorsqu'il s'agit d'une demande POST volumineuse, par exemple, lorsque le téléchargement de fichiers est nécessaire. Mais même dans une petite demande, cela a du sens, car la livraison de quelques octets est beaucoup plus rapide que simultanément des kilo-octets d'informations.

Délai avant l'envoi de la deuxième partie de la demande

Selon les recherches de Vlad Roskov , il est non seulement nécessaire de diviser la demande, mais il est également judicieux de faire un délai de plusieurs secondes entre l'envoi de la partie principale des données et la dernière. Et tout cela parce que les serveurs Web commencent à analyser les demandes avant même de les recevoir dans leur intégralité.

Qu'y a-t-il sur le serveur

Par exemple, lors de la réception des en-têtes de requête HTTP, nginx commencera à les analyser, mettant en cache la requête défectueuse. Lorsque le dernier octet arrive, le serveur Web prend la demande partiellement traitée et l'envoie directement à l'application, réduisant ainsi le temps de traitement des demandes, ce qui augmente la probabilité d'une attaque.

Comment y faire face

Tout d'abord, c'est bien sûr un problème architectural, si vous concevez correctement une application web, vous pouvez éviter de telles courses.

En règle générale, les méthodes de contrôle d'attaque suivantes sont utilisées:

• Utilisez des verrous .

L'opération bloque l'accès à l'objet verrouillé dans le SGBD jusqu'à ce qu'il soit débloqué. D'autres se tiennent debout et attendent sur la touche. Il est nécessaire de travailler correctement avec les serrures, pour ne rien bloquer de superflu.

• Ils régissent l' isolement des transactions .

Transactions ordonnées (sérialisables) - assurez-vous que les transactions seront effectuées de manière strictement séquentielle, mais cela peut affecter les performances.

• Des sémaphores Mutex (hehe) sont utilisés.

Prenez quelque chose (par exemple etcd). Au moment de l'appel des fonctions, une entrée avec une clé est créée, s'il n'était pas possible de créer une entrée, alors elle existe déjà et la demande est interrompue. À la fin du traitement de la demande, l'enregistrement est supprimé.

Et en général, j'ai aimé la vidéo d'Ivan the Hard Worker sur les verrous et les transactions, très informative.

Fonctions de session en condition de course

L'une des caractéristiques des séances peut être qu'elle interfère en soi avec l'exploitation de la course. Par exemple, en PHP, après session_start (), un fichier de session est verrouillé et son déverrouillage ne se produit qu'à la fin du script (s'il n'y a pas eu d'appel à session_write_close ). Si un autre script qui utilise une session est appelé à ce moment, il attendra.

Pour contourner cette fonctionnalité, vous pouvez utiliser une astuce simple - pour vous authentifier autant de fois que nécessaire. Si l'application Web vous permet de créer plusieurs sessions pour un seul utilisateur, il vous suffit de collecter tous les PHPSESSID et de faire de chaque requête son propre identifiant.

Proximité du serveur

Si le site sur lequel vous souhaitez opérer la condition de concurrence est hébergé dans AWS - prenez la voiture dans AWS. Si dans DigitalOcean - apportez-le là.

Lorsque la tâche est d'envoyer des requêtes et de minimiser l'intervalle d'envoi entre elles, la proximité immédiate avec le serveur web sera sans aucun doute un plus.

Après tout, il y a une différence lors du ping vers le serveur 200 et 10 ms. Et si vous avez de la chance, vous pouvez même vous retrouver sur le même serveur physique, alors ce sera un peu plus facile de voler :)

Pour résumer

Pour une condition de course réussie, vous pouvez appliquer diverses astuces pour augmenter les chances de succès. Envoyez plusieurs demandes persistantes en une seule, ce qui ralentit le serveur Web. Divisez la demande en plusieurs parties et créez un délai avant l'envoi. Réduisez la distance au serveur et le nombre d'abstractions à l'interface réseau.

À la suite de cette analyse, avec Michail Badin, nous avons développé l'outil RacePWN

Il se compose de deux éléments:

• Bibliothèque C librace, qui envoie un grand nombre de requêtes HTTP au serveur dans les plus brefs délais et en utilisant la plupart des fonctionnalités de l'article

• Utilitaires racepwn, qui accepte la configuration json et dirige généralement cette bibliothèque

RacePWN peut être intégré à d'autres utilitaires (par exemple, dans Burp Suite), ou vous pouvez créer une interface Web pour gérer les vols (vous ne pouvez toujours pas mettre la main dessus). Profitez-en!

Mais en réalité, il y a encore de la place pour se développer et vous pouvez vous rappeler HTTP / 2 et ses perspectives d'attaque. Mais pour le moment, HTTP / 2, la plupart des ressources n'ont qu'une demande de mandataire avant vers le bon vieux HTTP / 1.1.

Peut-être connaissez-vous d'autres subtilités?

L'original