Utilisez [**Trickest**](https://trickest.com/?utm_source=hacktricks&utm_medium=text&utm_campaign=ppc&utm_term=trickest&utm_content=race-condition) pour créer et **automatiser des flux de travail** facilement grâce aux **outils communautaires les plus avancés** au monde.\
Apprenez et pratiquez le Hacking AWS :<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">\
Apprenez et pratiquez le Hacking GCP : <imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
* Consultez les [**plans d'abonnement**](https://github.com/sponsors/carlospolop) !
* **Rejoignez le** 💬 [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe telegram**](https://t.me/peass) ou **suivez-nous sur****Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Partagez des astuces de hacking en soumettant des PRs aux** [**HackTricks**](https://github.com/carlospolop/hacktricks) et [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) dépôts github.
Pour obtenir une compréhension approfondie de cette technique, consultez le rapport original sur [https://portswigger.net/research/smashing-the-state-machine](https://portswigger.net/research/smashing-the-state-machine)
Le principal obstacle pour tirer parti des conditions de course est de s'assurer que plusieurs requêtes sont traitées en même temps, avec **très peu de différence dans leurs temps de traitement—idéalement, moins de 1 ms**.
* **HTTP/2** : Prend en charge l'envoi de deux requêtes sur une seule connexion TCP, réduisant l'impact du jitter réseau. Cependant, en raison des variations côté serveur, deux requêtes peuvent ne pas suffire pour une exploitation cohérente de la condition de course.
* **Synchronisation du 'Dernier Octet' HTTP/1.1** : Permet l'envoi préalable de la plupart des parties de 20-30 requêtes, en retenant un petit fragment, qui est ensuite envoyé ensemble, atteignant simultanément le serveur.
L'envoi subséquent des cadres retenus devrait aboutir à leur arrivée dans un seul paquet, vérifiable via Wireshark. Cette méthode ne s'applique pas aux fichiers statiques, qui ne sont généralement pas impliqués dans les attaques RC.
Comprendre l'architecture de la cible est crucial. Les serveurs frontaux peuvent acheminer les requêtes différemment, affectant le timing. Le réchauffement préventif des connexions côté serveur, par le biais de requêtes sans conséquence, pourrait normaliser le timing des requêtes.
Des frameworks comme le gestionnaire de session PHP sérialisent les requêtes par session, obscurcissant potentiellement les vulnérabilités. Utiliser différents jetons de session pour chaque requête peut contourner ce problème.
Si le réchauffement de la connexion est inefficace, déclencher intentionnellement les délais de limite de taux ou de ressources des serveurs web par un afflux de requêtes fictives pourrait faciliter l'attaque à paquet unique en induisant un délai côté serveur propice aux conditions de course.
* **Tubo Intruder - attaque à paquet unique HTTP2 (1 point de terminaison)** : Vous pouvez envoyer la requête à **Turbo intruder** (`Extensions` -> `Turbo Intruder` -> `Send to Turbo Intruder`), vous pouvez changer dans la requête la valeur que vous souhaitez forcer pour **`%s`** comme dans `csrf=Bn9VQB8OyefIs3ShR2fPESR0FzzulI1d&username=carlos&password=%s` puis sélectionner le **`examples/race-single-packer-attack.py`** dans le menu déroulant :
* **Tubo Intruder - attaque à paquet unique HTTP2 (Plusieurs points de terminaison)** : Dans le cas où vous devez envoyer une requête à 1 point de terminaison et ensuite plusieurs à d'autres points de terminaison pour déclencher le RCE, vous pouvez modifier le script `race-single-packet-attack.py` avec quelque chose comme :
* Pour **limit-overrun**, vous pourriez simplement ajouter la **même requête 50 fois** dans le groupe.
* Pour **connection warming**, vous pourriez **ajouter** au **début** du **groupe** quelques **requêtes** vers une partie non statique du serveur web.
* Pour **delaying** le processus **entre** le traitement **d'une requête et une autre** en 2 étapes de sous-états, vous pourriez **ajouter des requêtes supplémentaires entre** les deux requêtes.
* Pour un RC **multi-endpoint**, vous pourriez commencer à envoyer la **requête** qui **va à l'état caché** et ensuite **50 requêtes** juste après qui **exploite l'état caché**.
* **Script python automatisé** : L'objectif de ce script est de changer l'email d'un utilisateur tout en le vérifiant continuellement jusqu'à ce que le token de vérification du nouvel email arrive à l'ancien email (c'est parce que dans le code, on voyait un RC où il était possible de modifier un email mais d'avoir la vérification envoyée à l'ancien car la variable indiquant l'email était déjà peuplée avec le premier).\
Lorsque le mot "objetivo" est trouvé dans les emails reçus, nous savons que nous avons reçu le token de vérification de l'email changé et nous mettons fin à l'attaque.
Avant la recherche précédente, voici quelques charges utiles utilisées qui essayaient simplement d'envoyer les paquets aussi rapidement que possible pour provoquer un RC.
* **Repeater :** Consultez les exemples de la section précédente.
* **Intruder :** Envoyez la **demande** à **Intruder**, définissez le **nombre de threads** sur **30** dans le **menu Options** et sélectionnez comme charge utile **Null payloads** et générez **30.**
C'est le type de condition de course le plus basique où **les vulnérabilités** qui **apparaissent** dans des endroits qui **limitent le nombre de fois que vous pouvez effectuer une action**. Comme utiliser le même code de réduction dans un magasin en ligne plusieurs fois. Un exemple très simple peut être trouvé dans [**ce rapport**](https://medium.com/@pravinponnusamy/race-condition-vulnerability-found-in-bug-bounty-program-573260454c43) ou dans [**ce bug**](https://hackerone.com/reports/759247)**.**
Exploiter des conditions de course complexes implique souvent de tirer parti d'opportunités brèves pour interagir avec des sous-états machine cachés ou **non intentionnels**. Voici comment procéder :
* Commencez par identifier les points de terminaison qui modifient ou interagissent avec des données critiques, telles que les profils d'utilisateur ou les processus de réinitialisation de mot de passe. Concentrez-vous sur :
* **Stockage** : Préférez les points de terminaison qui manipulent des données persistantes côté serveur plutôt que celles qui gèrent des données côté client.
* **Action** : Recherchez des opérations qui modifient des données existantes, qui sont plus susceptibles de créer des conditions exploitables par rapport à celles qui ajoutent de nouvelles données.
* **Clé** : Les attaques réussies impliquent généralement des opérations basées sur le même identifiant, par exemple, le nom d'utilisateur ou le jeton de réinitialisation.
* Testez les points de terminaison identifiés avec des attaques de condition de course, en observant toute déviation par rapport aux résultats attendus. Des réponses inattendues ou des changements dans le comportement de l'application peuvent signaler une vulnérabilité.
* Réduisez l'attaque au nombre minimal de requêtes nécessaires pour exploiter la vulnérabilité, souvent juste deux. Cette étape peut nécessiter plusieurs tentatives ou de l'automatisation en raison du timing précis impliqué.
La précision dans le timing des requêtes peut révéler des vulnérabilités, surtout lorsque des méthodes prévisibles comme les horodatages sont utilisées pour les jetons de sécurité. Par exemple, générer des jetons de réinitialisation de mot de passe basés sur des horodatages pourrait permettre des jetons identiques pour des requêtes simultanées.
* Utilisez un timing précis, comme une attaque par paquet unique, pour faire des requêtes de réinitialisation de mot de passe simultanées. Des jetons identiques indiquent une vulnérabilité.
* Demandez deux jetons de réinitialisation de mot de passe en même temps et comparez-les. Des jetons correspondants suggèrent un défaut dans la génération de jetons.
Vérifiez ce [**PortSwigger Lab**](https://portswigger.net/web-security/logic-flaws/examples/lab-logic-flaws-insufficient-workflow-validation) pour voir comment **payer** dans un magasin et **ajouter un article supplémentaire** que vous **n'aurez pas besoin de payer**.
L'idée est de **vérifier une adresse e-mail et de la changer en une autre en même temps** pour découvrir si la plateforme vérifie la nouvelle adresse modifiée.
Selon [**cette recherche**](https://portswigger.net/research/smashing-the-state-machine), Gitlab était vulnérable à une prise de contrôle de cette manière car il pourrait **envoyer** le **jeton de vérification d'e-mail d'un e-mail à l'autre**.
Si **2 écritures différentes** sont utilisées pour **ajouter****des informations** dans une **base de données**, il y a une petite portion de temps où **seules les premières données ont été écrites** dans la base de données. Par exemple, lors de la création d'un utilisateur, le **nom d'utilisateur** et le **mot de passe** peuvent être **écrits** et **ensuite le jeton** pour confirmer le compte nouvellement créé est écrit. Cela signifie que pendant un court instant, le **jeton pour confirmer un compte est nul**.
Par conséquent, **enregistrer un compte et envoyer plusieurs requêtes avec un jeton vide** (`token=` ou `token[]=` ou toute autre variation) pour confirmer le compte immédiatement pourrait permettre de c**onfirmer un compte** où vous ne contrôlez pas l'e-mail.
Le pseudo-code suivant est vulnérable à une condition de course car pendant un très court instant, le **2FA n'est pas appliqué** pendant que la session est créée :
Il existe plusieurs [**fournisseurs OAUth**](https://en.wikipedia.org/wiki/List\_of\_OAuth\_providers). Ces services vous permettront de créer une application et d'authentifier les utilisateurs que le fournisseur a enregistrés. Pour ce faire, le **client** devra **permettre à votre application** d'accéder à certaines de ses données à l'intérieur du **fournisseur OAUth**.\
Donc, jusqu'ici, c'est juste une connexion classique avec google/linkedin/github... où vous êtes invité avec une page disant : "_L'application \<InsertCoolName> souhaite accéder à vos informations, voulez-vous l'autoriser ?_"
Le **problème** apparaît lorsque vous **l'acceptez** et envoie automatiquement un **`authorization_code`** à l'application malveillante. Ensuite, cette **application abuse d'une Condition de course dans le fournisseur de service OAUth pour générer plus d'un AT/RT** (_Token d'authentification/Token de rafraîchissement_) à partir du **`authorization_code`** pour votre compte. En gros, elle va abuser du fait que vous avez accepté l'application pour accéder à vos données pour **créer plusieurs comptes**. Ensuite, si vous **arrêtez de permettre à l'application d'accéder à vos données, une paire d'AT/RT sera supprimée, mais les autres resteront valides**.
Une fois que vous avez **obtenu un RT valide**, vous pourriez essayer de **l'abuser pour générer plusieurs AT/RT** et **même si l'utilisateur annule les autorisations** pour l'application malveillante d'accéder à ses données, **plusieurs RT resteront valides.**
Dans [**WS\_RaceCondition\_PoC**](https://github.com/redrays-io/WS\_RaceCondition\_PoC), vous pouvez trouver un PoC en Java pour envoyer des messages websocket en **parallèle** afin d'abuser des **Conditions de course également dans les Web Sockets**.
Apprenez et pratiquez le hacking AWS :<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">\
Apprenez et pratiquez le hacking GCP : <imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
* Consultez les [**plans d'abonnement**](https://github.com/sponsors/carlospolop) !
* **Rejoignez le** 💬 [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe telegram**](https://t.me/peass) ou **suivez-nous sur****Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Partagez des astuces de hacking en soumettant des PRs aux** [**HackTricks**](https://github.com/carlospolop/hacktricks) et [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) dépôts github.
Utilisez [**Trickest**](https://trickest.com/?utm_source=hacktricks&utm_medium=text&utm_campaign=ppc&utm_term=trickest&utm_content=race-condition) pour créer facilement et **automatiser des workflows** alimentés par les **outils communautaires les plus avancés** au monde.\