GromHacks Labs – Les listes de payloads qu'ils ne veulent pas que vous ayez. 1 324 sondes d'injection envoyées depuis le vaisseau mère pour détecter ce qui est injectable dans 20 classes de vuln. Nous n'exploitons pas, nous frappons juste à la porte et voyons qui répond. Chaque payload testé contre de vrais parseurs car les extraterrestres exigent des preuves. Ne faites confiance à aucune entrée. Remettez tout en question !
Vous avez trouvé une payload qui ne fonctionne pas ? Merci d'ouvrir un ticket avec le payload, le contexte cible et ce que vous attendiez. Les pull requests avec des corrections ou de nouveaux payloads sont toujours les bienvenus.
Les recherches sont en cours. Ce projet est en développement actif et sera mis à jour régulièrement avec de nouveaux payloads, des classes de vulnérabilités et des améliorations de validation.
Avertissement : Ces payloads sont fournis uniquement pour des tests de sécurité autorisés, de l'éducation et des fins de recherche. Les auteurs déclinent toute responsabilité en cas d'utilisation abusive ou d'effets indirects. Utilisez-les entièrement à vos risques et périls. En utilisant ce projet, vous acceptez l'entière responsabilité de vos actions.
Licence : MIT - voir LICENCE
1 353 payloads d'injection validées couvrant 20 classes de vulnérabilités, 31 frameworks de désérialisation et 14 moteurs de templates. Chaque payload produit un signal détectable. Zéro payload théorique.
Validation : 1 353 testés / 1 353 activés / 0 échecs / 0 ignorés sur 35 piles de test Docker. Une validation stricte prouve une exploitation réelle (calcul côté serveur, erreurs de parseur réelles, délais mesurés, rappels OOB à partir des conteneurs cibles) – pas de correspondance de chaînes.
La plupart des listes de payloads disponibles publiquement sont organisées par type de vulnérabilité : une liste pour les injections SQL, une autre pour les XSS, une autre pour les injections de commandes, etc. Un testeur choisit la liste qu'il pense correspondre à la cible, la charge dans un outil d'intrusion et l'exécute sur un paramètre. S'il se trompe sur la classe de vulnérabilité, l'ensemble du scan ne produit rien. Si le backend est une base de données peu courante, un moteur de templates non standard ou un langage que la liste n'a pas pris en compte, les payloads échouent silencieusement. Le testeur passe à autre chose en pensant que le paramètre est propre.
Cette approche présente deux problèmes fondamentaux. Premièrement, elle oblige le testeur à savoir quelle vulnérabilité existe avant de l'avoir trouvée. Deuxièmement, la plupart des payloads en circulation sont théoriques – copiés entre projets et billets de blog sans jamais avoir été testés contre un analyseur réel. Ils ont l'air corrects. Ils pourraient même être syntaxiquement valides. Mais ils ne déclenchent pas réellement de réponse détectable de la part de la cible.
Ce projet adopte une approche différente. L'unité de travail principale est le polyglotte – une chaîne de payload unique conçue pour être valide (ou significativement invalide) dans autant de contextes d'injection que possible simultanément. Un seul polyglotte s'échappe des guillemets simples, des guillemets doubles, des parenthèses, des commentaires de bloc, des attributs HTML, des délimiteurs de template et des contextes de backtick à la fois. Au lieu d'avoir besoin de savoir quelle est la vulnérabilité, le testeur envoie des polyglottes à chaque paramètre et observe les signaux.
Chaque payload de cette collection est construite autour de piliers de détection – des réponses observables qui confirment l'existence d'une vulnérabilité sans nécessiter l'accès aux logs serveur, au code source ou au système de fichiers :
7*191 qui s'évalue à 1337. Si ce nombre apparaît dans la réponse et que la payload n'a envoyé que 7*191 (pas le 1337 littéral), le backend a calculé l'expression – preuve d'exécution de code.Si une payload ne produit pas au moins un de ces signaux lorsqu'elle est testée dans son contexte cible, elle n'a pas sa place dans la liste. Chacun des 1 353 payloads ici a été validé avec des environnements de test Docker dédiés et une preuve d'exploitation stricte. Zéro théorique.
Les payloads traditionnelles OOB et de timing reposent sur des commandes shell : curl, nslookup, ping, sleep. Elles cassent constamment. Elles dépendent du système d'exploitation cible, du PATH disponible, du shell qui interprète la commande et de la permission du processus de lancer des sous-processus. Une payload OOB basée sur curl qui fonctionne sur Ubuntu échoue sur Alpine (pas de curl), échoue sur Windows (pas de curl) et échoue dans un conteneur restreint (pas d'exécution de processus sortant).
Ce projet remplace les commandes shell par des fonctions intégrées au langage autant que possible. Les payloads Python utilisent urllib.request.urlopen() et time.sleep(). Les payloads Java utilisent java.net.URL.openStream() et Thread.sleep(). Ruby utilise Net::HTTP.get() et Kernel.sleep. PHP utilise file_get_contents() et sleep(). Ces fonctions existent dans chaque installation standard de leur langage respectif – pas de recherche de PATH, pas de sous-processus, pas de dépendance au système d'exploitation.
Là où même les importations de la bibliothèque standard peuvent être bloquées (eval en bac à sable, exec restreint), les payloads se rabattent sur des alternatives sans import : boucles CPU pour le timing (sum(range(500000000)) en Python, Atomics.wait() en Node) et connexions socket brutes pour OOB (__import__('socket').create_connection(), fsockopen(), TCPSocket.new()).
Tout ne peut pas être un polyglotte. Les moteurs de templates utilisent une syntaxe fondamentalement incompatible – {{}} dans Jinja2 ne signifie rien pour <%= %> d'ERB, et aucun des deux n'est analysé comme ${} de Freemarker). Les formats de désérialisation sont binaires ou structurés, spécifiques à un framework. Pour ces catégories, le projet utilise des payloads par moteur organisées sous le même système de piliers de détection, couvrant 14 moteurs de templates et 31 frameworks de désérialisation sur 7 langages.
Le résultat est un corpus unique où les polyglottes gèrent les contextes qu'ils peuvent (SQLi, injection de commandes OS, XSS, injection de code) et les payloads spécialisées par moteur gèrent le reste, tous validés, tous produisant des signaux détectables, tous prêts pour des outils d'injection ligne par ligne.
83 payloads couvrant les 35 piles de test, les 55+ endpoints et les 4 piliers de détection par catégorie. Validé : 83 FIRE / 0 NO-FIRE / 0 SKIPPED.
Chaque catégorie d'injection bénéficie d'une couverture erreur + math + timing + OOB là où architecturalement possible. Les frameworks de désérialisation qui supportent l'exécution de code (Pickle, PyYAML, jsonpickle, node-serialize, XMLDecoder, .NET Json.NET) obtiennent une couverture multi-piliers complète. Les frameworks limités au sondage (PHP unserialize, Ruby Marshal, SnakeYAML, etc.) obtiennent une détection basée sur les erreurs. Envoyez ceci à chaque paramètre avant de passer aux listes de catégories complètes pour plus de profondeur.