GromHacks Labs — Las listas de payloads que no quieren que tengas. 1,324 sondas de inyección enviadas desde la nave nodriza para detectar qué es inyectable a través de 20 clases de vulnerabilidades. No explotamos, solo tocamos la puerta y vemos quién responde. Cada payload probado contra analizadores reales porque los aliens exigen pruebas. No confíes en ninguna entrada. ¡Cuestiona todo!
¿Encontraste un payload que no funciona? Por favor abre un issue con el payload, el contexto objetivo y lo que esperabas que sucediera. Las solicitudes de extracción con correcciones o nuevos payloads siempre son bienvenidas.
La investigación está en curso. Este proyecto está en desarrollo activo y se actualizará regularmente con nuevos payloads, clases de vulnerabilidad y mejoras en la validación.
Aviso legal: Estos payloads se proporcionan únicamente para pruebas de seguridad autorizadas, educación e investigación. Los autores no asumen ninguna responsabilidad por el mal uso o efectos derivados. Úselo completamente bajo su propio riesgo. Al utilizar este proyecto, acepta toda la responsabilidad de sus acciones.
Licencia: MIT - consulta LICENSE
1,353 payloads de inyección validados que cubren 20 clases de vulnerabilidad, 31 frameworks de deserialización y 14 motores de plantillas. Cada payload produce una señal detectable. Cero payloads teóricos.
Validación: 1,353 probados / 1,353 disparan / 0 fallos / 0 omitidos contra 35 stacks de pruebas Docker. La validación estricta demuestra explotación real (cómputo del lado del servidor, errores reales del analizador, retrasos de tiempo medidos, callbacks OOB desde contenedores objetivo), no coincidencia de cadenas.
La mayoría de las listas de payloads disponibles públicamente están organizadas por tipo de vulnerabilidad: una lista para inyección SQL, otra para XSS, otra para inyección de comandos, etc. Un probador elige la lista que cree que coincide con el objetivo, la carga en una herramienta de intrusión y la ejecuta contra un parámetro. Si adivina mal la clase de vulnerabilidad, todo el escaneo no produce nada. Si el backend es una base de datos poco común, un motor de plantillas no estándar o un lenguaje que la lista no contempló, los payloads fallan silenciosamente. El probador continúa pensando que el parámetro está limpio.
Este enfoque tiene dos problemas fundamentales. Primero, requiere que el probador sepa qué vulnerabilidad existe antes de haberla encontrado. Segundo, la mayoría de los payloads en circulación son teóricos, copiados entre proyectos y publicaciones de blog sin haber sido probados contra un analizador real. Se ven bien. Incluso pueden ser sintácticamente válidos. Pero en realidad no desencadenan una respuesta detectable del objetivo.
Este proyecto adopta un enfoque diferente. La unidad principal de trabajo es el políglota (polyglot): una sola cadena de payload diseñada para ser válida (o significativamente inválida) en tantos contextos de inyección como sea posible simultáneamente. Un políglota escapa de comillas simples, comillas dobles, paréntesis, comentarios de bloque, atributos HTML, delimitadores de plantillas y contextos de comillas invertidas a la vez. En lugar de necesitar saber cuál es la vulnerabilidad, el probador dispara políglotas a cada parámetro y observa las señales.
Cada payload en esta colección se basa en pilares de detección: respuestas observables que confirman que existe una vulnerabilidad sin requerir acceso a registros del servidor, código fuente o sistema de archivos:
7*191 que se evalúa como 1337. Si ese número aparece en la respuesta y el payload solo envió 7*191 (no el literal 1337), el backend calculó la expresión: prueba de ejecución de código.Si un payload no produce al menos una de estas señales cuando se prueba contra su contexto objetivo, no pertenece a la lista. Cada uno de los 1,353 payloads aquí ha sido validado contra entornos de prueba Docker construidos específicamente con pruebas estrictas de explotación. Cero son teóricos.
Los payloads tradicionales de OOB y timing dependen de comandos de shell: curl, nslookup, ping, sleep. Estos fallan constantemente. Dependen del sistema operativo objetivo, el PATH disponible, qué shell interpreta el comando y si el proceso tiene permiso para crear subprocesos. Un payload OOB basado en curl que funciona en Ubuntu falla en Alpine (sin curl), falla en Windows (sin curl) y falla dentro de un contenedor restringido (sin ejecución de procesos salientes).
Este proyecto reemplaza los comandos de shell con funciones integradas nativas del lenguaje siempre que sea posible. Los payloads de Python usan urllib.request.urlopen() y time.sleep(). Los payloads de Java usan java.net.URL.openStream() y Thread.sleep(). Ruby usa Net::HTTP.get() y Kernel.sleep. PHP usa file_get_contents() y sleep(). Estas funciones existen en cada instalación estándar de su respectivo lenguaje: sin búsqueda de PATH, sin subproceso, sin dependencia del SO.
Donde incluso las importaciones de la biblioteca estándar podrían estar bloqueadas (eval en sandbox, exec restringido), los payloads recurren a alternativas sin importaciones: bucles de CPU para timing (sum(range(500000000)) en Python, Atomics.wait() en Node) y conexiones de socket sin procesar para OOB (__import__('socket').create_connection(), fsockopen(), TCPSocket.new()).
No todo puede ser un políglota. Los motores de plantillas usan sintaxis fundamentalmente incompatible: {{}} en Jinja2 no significa nada para <%= %> de ERB, y ninguno se analiza como ${} de Freemarker. Los formatos de deserialización son datos binarios o estructurados específicos de un framework. Para estas categorías, el proyecto utiliza payloads por motor organizados bajo el mismo sistema de pilares de detección, cubriendo 14 motores de plantillas y 31 frameworks de deserialización en 7 lenguajes.
El resultado es un solo corpus donde los políglotas manejan los contextos que pueden (SQLi, inyección de comandos del SO, XSS, inyección de código) y los payloads por motor diseñados específicamente manejan el resto, todos validados, todos produciendo señales detectables, todos listos para herramientas de inyección línea por línea.
83 payloads cubriendo todos los 35 stacks de pruebas, todos los 55+ endpoints y los 4 pilares de detección por categoría. Validado: 83 FIRE / 0 NO-FIRE / 0 SKIPPED.
Cada categoría de inyección obtiene cobertura de error + math + timing + OOB donde sea arquitectónicamente posible. Los frameworks de deserialización que admiten ejecución de código (Pickle, PyYAML, jsonpickle, node-serialize, XMLDecoder, .NET Json.NET) obtienen cobertura completa de múltiples pilares. Los frameworks limitados a sondeo (PHP unserialize, Ruby Marshal, SnakeYAML, etc.) obtienen detección basada en error. Dispare esto en cada parámetro antes de cambiar a listas de categoría completas para profundidad.