PHP - Deserialization + Autoload Classes
PreviousBasic Java Deserialization (ObjectInputStream, readObject)NextCommonsCollection1 Payload - Java Transformers to Rutime exec() and Thread Sleep
Last updated
Last updated
Impara e pratica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Impara e pratica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Prima di tutto, dovresti controllare cosa sono le Classi Autoloading.
Siamo in una situazione in cui abbiamo trovato una deserializzazione PHP in un'app web senza nessuna libreria vulnerabile a gadget all'interno di phpggc. Tuttavia, nello stesso contenitore c'era una diversa app web composer con librerie vulnerabili. Pertanto, l'obiettivo era caricare il loader composer dell'altra app web e abusarne per caricare un gadget che sfrutterà quella libreria con un gadget dall'app web vulnerabile alla deserializzazione.
Passi:
Hai trovato una deserializzazione e non ci sono gadget nel codice dell'app attuale
Puoi abusare di una funzione spl_autoload_register come la seguente per caricare qualsiasi file locale con estensione .php
Per questo usi una deserializzazione in cui il nome della classe sarà all'interno di $name. Non puoi usare "/" o "." in un nome di classe in un oggetto serializzato, ma il codice sta sostituendo gli underscore ("_") con barre ("/"). Quindi un nome di classe come tmp_passwd sarà trasformato in /tmp/passwd.php e il codice cercherà di caricarlo.
Un esempio di gadget sarà: O:10:"tmp_passwd":0:{}
Se hai un upload di file e puoi caricare un file con estensione .php potresti sfruttare questa funzionalità direttamente e ottenere già RCE.
Nel mio caso, non avevo nulla di simile, ma c'era all'interno dello stesso container un'altra pagina web di composer con una libreria vulnerabile a un gadget phpggc.
Per caricare questa altra libreria, prima devi caricare il loader di composer di quell'altra web app (perché quello dell'applicazione attuale non accederà alle librerie dell'altra). Conoscendo il percorso dell'applicazione, puoi ottenere questo molto facilmente con: O:28:"www_frontend_vendor_autoload":0:{} (Nel mio caso, il loader di composer si trovava in /www/frontend/vendor/autoload.php)
Ora puoi caricare il loader di composer dell'altra app, quindi è tempo di generare il payload phpgcc da utilizzare. Nel mio caso, ho usato Guzzle/FW1, che mi ha permesso di scrivere qualsiasi file all'interno del filesystem.
NOTA: Il gadget generato non funzionava, affinché funzionasse ho modificato quel payload chain.php di phpggc e impostato tutti gli attributi delle classi da privati a pubblici. Altrimenti, dopo aver deserializzato la stringa, gli attributi degli oggetti creati non avevano valori.
Ora abbiamo il modo di caricare il loader di composer dell'altra app e avere un payload phpgcc che funziona, ma dobbiamo fare questo nella STESSA RICHIESTA affinché il loader venga caricato quando il gadget viene utilizzato. Per questo, ho inviato un array serializzato con entrambi gli oggetti come:
Puoi vedere prima il loader che viene caricato e poi il payload
Ora possiamo creare e scrivere un file, tuttavia, l'utente non poteva scrivere in nessuna cartella all'interno del server web. Quindi, come puoi vedere nel payload, PHP chiama system con un po' di base64 creato in /tmp/a.php. Poi, possiamo riutilizzare il primo tipo di payload che abbiamo usato come LFI per caricare il caricatore di composer dell'altra webapp per caricare il file generato /tmp/a.php. Basta aggiungerlo al gadget di deserializzazione:
Riepilogo del payload
Carica l'autoload di composer di un'altra webapp nello stesso container
Carica un gadget phpggc per abusare di una libreria dell'altra webapp (la webapp iniziale vulnerabile alla deserializzazione non aveva alcun gadget nelle sue librerie)
Il gadget creerà un file con un payload PHP in /tmp/a.php con comandi malevoli (l'utente della webapp non può scrivere in nessuna cartella di nessuna webapp)
L'ultima parte del nostro payload utilizzerà caricare il file php generato che eseguirà comandi
Ho dovuto chiamare questa deserializzazione due volte. Nei miei test, la prima volta il file /tmp/a.php è stato creato ma non caricato, e la seconda volta è stato caricato correttamente.
Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
