Dans cet article, je partagerai mon approche du développement d’une automatisation personnalisée pour faciliter la recherche sur les classes d’attaques sous-estimées et (espérons-le) repousser les limites de la sécurité Web.

À titre d’exemple concret, je m’appuierai sur mes recherches de Briser la machine à états : le véritable potentiel des conditions de course au Web. Si vous ne l’avez pas déjà vu, le Enregistrement DEFCON de cette présentation est maintenant disponible et vaut probablement le détour.

Identifier l’opportunité

Pensez-vous qu’il est possible de créer un scanner capable de détecter automatiquement les sites Web conditions de course? J’ai d’abord rejeté l’idée, car les conditions de concurrence que j’ai trouvées nécessitaient de déclencher des interactions complexes et authentifiées en plusieurs étapes avec des sites Web et de repérer des effets secondaires subtils.

Au cours de cette recherche, j’ai remarqué que les conditions de concurrence se produisent souvent en clusters. Ils jaillissent de bibliothèques et de frameworks fragiles, donc si vous en repérez un sur un site Web, il est probable que d’autres se cachent à proximité. Cela signifiait que la détection automatisée des conditions de concurrence pouvait être utile même si les races détectées étaient elles-mêmes inoffensives.

J’ai décidé que cette idée méritait d’être explorée en raison de ma familiarité avec le sujet, de nouveaux outils sous la forme d’attaque par paquet unique et d’un banc d’essai qui me permettait d’essayer le concept en un jour ou deux.

Évitez de trop vous engager

Lorsque l’on tente d’automatiser quelque chose de délicat, un piège courant est d’essayer d’en automatiser trop et de ne finalement parvenir à rien d’utile. Pour éviter cela, j’aime examiner ma méthodologie de test manuel et identifier la plus petite et la plus précoce étape que je pourrais vraisemblablement automatiser. Voici le processus de test manuel que j’utilise pour les conditions de course :

Puisque la phase de « prévision » concerne uniquement l’efficacité, nous pouvons l’ignorer et simplement essayer d’automatiser la phase de « sonde ». Le but de cette phase est d’utiliser un lot de requêtes concurrentes pour déclencher une « anomalie » et prouver qu’un point de terminaison peut avoir un sous-état.

Acceptez l’inattendu

J’ai écrit du code pour envoyer une requête dix fois de manière séquentielle, puis la renvoyer dix fois en moins de 1 ms en utilisant l’attaque par paquet unique. Je m’attendais à ce que sur un site Web sujet à la course, les requêtes simultanées puissent déclencher une réponse d’erreur 50X.

À ce stade, j’aurais pu améliorer l’efficacité et réduire les faux positifs en ciblant uniquement les points finaux d’apparence dynamique et en signalant uniquement les réponses avec des codes 50X. Cependant, les meilleures découvertes de la recherche proviennent souvent de résultats inattendus. Cela signifie qu’il est important d’éviter d’écrire vos attentes dans le code. J’ai délibérément laissé de la place à des résultats inattendus en testant toutes les demandes observées, quel que soit leur objectif, et en signalant toute différence de code d’état.

En matière de recherche, je préfère avoir des faux positifs plutôt que des faux négatifs.

Facilitez l’itération

Cette approche entraîne inévitablement un flot de faux positifs au départ. Il est donc crucial que les améliorations itératives se fassent sans douleur.

J’ai implémenté cela dans une extension Burp Suite et, comme banc d’essai, j’ai utilisé un fichier de projet contenant la page d’accueil et les ressources d’environ 30 000 sites Web dotés de programmes de primes de bogues. Pour plus de détails sur cette configuration, consultez Casser la lentille.

Pour une exécution complète, je sélectionne simplement toutes les requêtes dans le proxy, je fais un clic droit et je lance l’analyse. Il donne la priorité aux domaines plus courts, de sorte que les résultats sur des cibles de premier plan ont tendance à apparaître rapidement.

Automatisez votre tri

En général, je trie manuellement une petite partie des résultats, puis j’analyse mon processus de tri et je l’automatise. En traitant les résultats, je me suis retrouvé :

• Ignorer les résultats où les demandes cruciales viennent d’expirer
• Ignorer les résultats avec 429 codes d’état car ce ne sont que des limites de débit
• Ignorer les résultats avec 502/503 car ceux-ci indiquent des délais d’attente du back-end
• Essayer des requêtes séquentielles supplémentaires après le lot simultané
• Ajout de cache-busters pour filtrer le comportement du cache

La mise en œuvre de ce processus de filtrage dans mon scan-check et sa réexécution m’ont laissé un certain nombre de résultats prometteurs :

• Assortiment de codes curieux 50X et 307
• Un serveur Web qui émet une réponse cryptique « 501 non implémenté » affirmant qu’il ne prend pas en charge les requêtes GET lorsque vous utilisez l’attaque par paquet unique.
• Un site Web qui déclenche une requête côté serveur vers un système back-end à des fins de SSO. L’attaque par paquet unique a surchargé le back-end et déclenché un message d’erreur révélant l’URL complète.
• Un autre serveur qui émettait par intermittence une réponse de 400 requêtes incorrectes lorsqu’il recevait des requêtes synchronisées. Ceci est curieux car cela suggère qu’il peut y avoir une condition de concurrence critique dans l’analyse de leur demande, ce qui pourrait permettre une attaque de désynchronisation.

Malheureusement, aucun de ces éléments ne m’a laissé une voie claire à suivre autre qu’une enquête manuelle approfondie, pour laquelle je n’avais pas eu le temps avant la conférence que je visais (Nullcon Goa).

Abuser des gadgets

Ce dont j’avais besoin, c’était d’une approche capable de détecter les comportements manifestement dangereux. Mais quelle situation de concurrence dangereuse pouvez-vous détecter directement à partir de la page d’accueil d’un site ? Eh bien, de temps en temps, j’ai vu des rapports faisant état d’applications et de caches se mélangeant et envoyant des réponses aux mauvaises personnes ou servant de la mémoire brute. L’exemple le plus célèbre est bien sûr Saignement nuageux.

Comment savoir si nous avons reçu une réponse destinée à quelqu’un d’autre ? En tant qu’humain, c’est facile, et un LLM pourrait probablement le dire au prix de performances épouvantables, mais c’est une question délicate pour une automatisation grossière au niveau des regex.

C’est là que les gadgets entrent en jeu. Les gadgets sont des fonctionnalités utiles présentes sur certains sites Web qui facilitent la détection des vulnérabilités. Nous pouvons nous appuyer sur des gadgets pour explorer rapidement et facilement si un concept vaut la peine d’investir plus de temps. S’appuyer sur des gadgets pour la détection des vulnérabilités entraînera de nombreux faux négatifs, mais pendant les premières étapes de la recherche, cela vaut la peine de faire un compromis sur la vitesse de développement. .

De nombreux sites Web intègrent des données sur la demande de l’utilisateur afin de l’exposer au JavaScript côté client. Cela inclut généralement l’adresse IP de l’utilisateur et les propriétés de la demande telles que l’URL et l’agent utilisateur. Sur les sites contenant ce type de gadget, j’ai pu détecter les vulnérabilités liées aux fuites d’informations raciales en plaçant un paramètre « canari » unique dans chaque requête, puis en analysant chaque réponse pour voir si elle contenait un canari provenant d’une requête différente.

Cette approche a initialement signalé de nombreux sites Web, mais la plupart d’entre eux ont simplement subi un empoisonnement du cache via un chaîne de requête sans clé.

Après avoir filtré l’empoisonnement du cache et d’autres comportements de « stockage Canary » via quelques ajustements supplémentaires du code, de véritables découvertes sont restées. Le meilleur exemple était un certain site Web où, grâce à une condition de concurrence critique, vous pouviez obtenir les URL auxquelles les utilisateurs en direct accédaient simplement en récupérant à plusieurs reprises la page d’accueil :

window.PAGE_STATE={…{"params":{"utm_souce":"bing",…

C’était parfait pour Nullcon ; J’ai assemblé quelques diapositives et publié les vérifications numérisées dans Scanner alimenté par une barre oblique inverse. Vous pouvez l’installer via le BApp Store, et parcourir le code sur Github.

Emballer

Comme nous l’avons vu, l’analyse orientée recherche est très différente de la construction d’un scanner normal. Soyez donc prudent lorsque vous appliquez ces conseils à d’autres cas d’utilisation.

Si vous souhaitez vous essayer à l’automatisation personnalisée, le nouvelle fonctionnalité BChecks dans Burp Suite est conçu pour rendre cet extra accessible.

Si vous avez trouvé cela utile, vous apprécierez peut-être également la présentation Chasse aux vulnérabilités évasives : trouver des failles que d’autres ignorent où j’aborde l’automatisation de la recherche sous un angle différent.

Dans mon prochain article, je continuerai sur le thème des conditions de concurrence et regarderai au-delà de HTTP/2 pour explorer quels autres protocoles prennent en charge l’attaque par paquet unique.

Retour à tous les articles