GromHacks Labs -- Le liste di payload che non vogliono farti avere. 1.324 sonde di iniezione trasmesse dalla nave madre per rilevare cosa è iniettabile in 20 classi di vulnerabilità. Non sfruttiamo, bussiamo solo alla porta e vediamo chi risponde. Ogni payload testato su parser reali perché gli alieni esigono prove. Non fidarti di nessun input. Metti tutto in discussione!
Trovato un payload che non funziona? Per favore apri una segnalazione con il payload, il contesto di destinazione e cosa ti aspettavi accadesse. Le richieste pull con correzioni o nuovi payload sono sempre benvenute.
La ricerca è in corso. Questo progetto è in fase di sviluppo attivo e verrà aggiornato regolarmente con nuovi payload, classi di vulnerabilità e miglioramenti nella validazione.
Disclaimer: Questi payload sono forniti esclusivamente per test di sicurezza autorizzati, formazione e scopi di ricerca. Gli autori non si assumono alcuna responsabilità per eventuali usi impropri o effetti indiretti. Utilizzare interamente a proprio rischio. Utilizzando questo progetto accetti la piena responsabilità per le tue azioni.
Licenza: MIT - vedi LICENSE
1.353 payload di injection validati che coprono 20 classi di vulnerabilità, 31 framework di deserializzazione e 14 motori di template. Ogni payload produce un segnale rilevabile. Zero payload teorici.
Validazione: 1.353 testati / 1.353 attivi / 0 fallimenti / 0 saltati contro 35 stack di test Docker. La validazione rigorosa dimostra lo sfruttamento effettivo (calcolo lato server, errori reali del parser, ritardi di temporizzazione misurati, callback OOB dai container target) — non semplice corrispondenza di stringhe.
La maggior parte delle liste di payload disponibili pubblicamente sono organizzate per tipo di vulnerabilità: una lista per SQL injection, un'altra per XSS, un'altra per command injection, e così via. Un tester sceglie la lista che pensa corrisponda al target, la carica in uno strumento di intrusione e la esegue contro un parametro. Se sbaglia a indovinare la classe di vulnerabilità, l'intera scansione non produce nulla. Se il backend è un database insolito, un motore di template non standard o un linguaggio che la lista non ha considerato, i payload falliscono silenziosamente. Il tester passa oltre pensando che il parametro sia pulito.
Questo approccio ha due problemi fondamentali. In primo luogo, richiede che il tester sappia quale vulnerabilità esiste prima di averla trovata. In secondo luogo, la maggior parte dei payload in circolazione sono teorici — copiati tra progetti e articoli di blog senza mai essere testati contro un parser reale. Sembrano corretti. Potrebbero anche essere sintatticamente validi. Ma in realtà non innescano una risposta rilevabile dal target.
Questo progetto adotta un approccio diverso. L'unità di lavoro principale è il poliglotto — una singola stringa di payload progettata per essere valida (o significativamente invalida) in quanti più contesti di injection possibile simultaneamente. Un poliglotto esce da virgolette singole, virgolette doppie, parentesi, commenti a blocchi, attributi HTML, delimitatori di template e contesti di backtick tutti insieme. Invece di dover sapere qual è la vulnerabilità, il tester lancia poliglotti a ogni parametro e osserva i segnali.
Ogni payload in questa raccolta è costruito attorno a pilastri di rilevamento — risposte osservabili che confermano l'esistenza di una vulnerabilità senza richiedere accesso ai log del server, al codice sorgente o al filesystem:
7*191 che viene valutata come 1337. Se quel numero appare nella risposta e il payload ha inviato solo 7*191 (non il letterale 1337), il backend ha calcolato l'espressione — prova di esecuzione di codice.Se un payload non produce almeno uno di questi segnali quando testato contro il suo contesto target, non appartiene all'elenco. Ognuno dei 1.353 payload qui è stato validato contro banchi di prova Docker appositamente costruiti con prova rigorosa di sfruttamento. Zero sono teorici.
I payload OOB e di temporizzazione tradizionali si basano su comandi shell: curl, nslookup, ping, sleep. Questi si rompono continuamente. Dipendono dal sistema operativo target, dal PATH disponibile, da quale shell interpreta il comando e se il processo ha il permesso di generare sottoprocessi. Un payload OOB basato su curl che funziona su Ubuntu fallisce su Alpine (nessun curl), fallisce su Windows (nessun curl) e fallisce all'interno di un contenitore ristretto (nessuna esecuzione di processo in uscita).
Questo progetto sostituisce i comandi shell con funzioni native del linguaggio, ove possibile. I payload Python usano urllib.request.urlopen() e time.sleep(). I payload Java usano java.net.URL.openStream() e Thread.sleep(). Ruby usa Net::HTTP.get() e Kernel.sleep. PHP usa file_get_contents() e sleep(). Queste funzioni esistono in ogni installazione standard del rispettivo linguaggio — nessuna ricerca nel PATH, nessun sottoprocesso, nessuna dipendenza dal sistema operativo.
Laddove anche gli import della libreria standard potrebbero essere bloccati (eval in sandbox, exec ristretto), i payload ricorrono ad alternative senza import: cicli CPU per la temporizzazione (sum(range(500000000)) in Python, Atomics.wait() in Node) e connessioni socket grezze per OOB (__import__('socket').create_connection(), fsockopen(), TCPSocket.new()).
Non tutto può essere un poliglotto. I motori di template usano sintassi fondamentalmente incompatibili — {{}} in Jinja2 non significa nulla per <%= %> di ERB, e nessuno dei due viene analizzato come ${} di Freemarker). I formati di deserializzazione sono dati binari o strutturati specifici di un singolo framework. Per queste categorie, il progetto utilizza payload per motore specifico organizzati sotto lo stesso sistema di pilastri di rilevamento, coprendo 14 motori di template e 31 framework di deserializzazione in 7 linguaggi.
Il risultato è un unico corpus dove i poliglotti gestiscono i contesti che possono (SQLi, OS command injection, XSS, code injection) e payload specifici per motore creati appositamente gestiscono il resto, tutti validati, tutti che producono segnali rilevabili, tutti pronti per strumenti di injection riga per riga.
83 payload che coprono tutti i 35 stack di test, tutti i 55+ endpoint e tutti i 4 pilastri di rilevamento per categoria. Validati: 83 ATTIVI / 0 NON ATTIVI / 0 SALTATI.
Ogni categoria di injection riceve copertura di errore + matematica + temporizzazione + OOB dove architetturalmente possibile. I framework di deserializzazione che supportano l'esecuzione di codice (Pickle, PyYAML, jsonpickle, node-serialize, XMLDecoder, .NET Json.NET) ottengono copertura multi-pilastro completa. I framework limitati al probing (PHP unserialize, Ruby Marshal, SnakeYAML, ecc.) ricevono rilevamento basato su errore. Lancia questo contro ogni parametro prima di passare agli elenchi completi per categoria per approfondimento.