mcorybillington/suitecrm-rceWriteup su CVE-2020-28328: Remote Code Execution nel file di log di SuiteCRM più un bonus Cross-Site Scripting
Recentemente ho scoperto due vulnerabilità in SuiteCRM che forniscono una catena di attacco per un utente con privilegi limitati per ottenere l'esecuzione di codice sul sistema operativo sottostante. La catena di attacco è Cross-Site Scripting, che può essere utilizzata per eseguire Cross-Site Request Forgery, che porta all'esecuzione di codice remoto manomettendo la configurazione dell'applicazione e avvelenando un file di log. Tutto ciò viene ottenuto tramite un caricamento di file che contiene JavaScript dannoso che un utente con privilegi limitati può indurre un utente con privilegi amministrativi a eseguire. I file Proof-Of-Concept e il video che ho allegato dimostrano un utente con privilegi limitati che esegue questo attacco e ottiene una reverse shell sul sistema che ospita SuiteCRM.
Questo è stato corretto nella versione 7.11.17 di SuiteCRM.
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Non sono pienamente d'accordo con questa valutazione poiché l'exploit richiede accesso amministrativo, il che cambierebbe PR:L in PR:H, portando il punteggio finale da 8.8 a 7.2.
Io lo valuterei come: CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H
Rif.: https://nvd.nist.gov/vuln/detail/CVE-2020-28328
SuiteCRM Version 7.11.15
Il Cross-Site Scripting persistente risiede nel caricamento file di 'Crea documenti'. Un utente con privilegi limitati può caricare un file con qualsiasi contenuto. L'utente può quindi esaminare il link fornito per scaricare questo documento e determinare la posizione del file nel filesystem individuando il parametro id. Questo lungo valore casuale è il nome del file all'interno della directory /uploads/. L'utente può inserire JavaScript arbitrario in questo file e poi inviare il link a un altro utente. Questo può essere utilizzato per dirottare la sessione di un altro utente e/o eseguire azioni per conto di quell'utente, come mostrato nel video PoC.
Dopo aver scoperto di poter diventare admin attraverso il dirottamento della sessione tramite il Cross-Site Scripting, ho poi scoperto di poter controllare le proprietà di sistema in 'Admin → System Settings', in particolare la proprietà del file di log. Le estensioni del file di log erano abbastanza bloccate, ma sono riuscito a usare BurpSuite per aggiornare il valore 'Log File Name' a un valore arbitrario, incluse le estensioni .php. Ho fatto ciò inviando una richiesta senza modificare nulla e catturando la richiesta POST che aggiorna effettivamente i valori. Ho cambiato il nome del file tramite il parametro logger_file_name in shell.php e ho semplicemente lasciato vuoto il campo 'Extension'. Questo ha fornito un file php che potevo aprire nel browser nella webroot, ma avevo bisogno di codice php all'interno del file da eseguire.
Successivamente, ho esaminato l'output nel file e ho notato che potevo controllare l'input nel file tramite le proprietà utente se aggiornavo un utente (come il nome o il cognome dell'utente), se la registrazione (logging) era impostata su info (che credo fosse il valore predefinito...). Quindi, ho catturato una richiesta in Burp e ho inserito del codice php <?php $id =`id`; echo $id; ?> nel campo del modulo last_name. Questo ha prodotto l'output del comando id su Linux nel contesto dell'utente del server web, www-data. Gli unici caratteri che ho potuto notare essere sottoposti a escaping nel file di log sono gli apici singoli, gli apici doppi e le barre rovesciate. Puoi verificarlo eseguendo tail sul file di log sql sul backend.
Sono riuscito a eseguire tutto questo come utente admin perché sono riuscito a ottenere i cookie di sessione; tuttavia, per avere una catena funzionante, dovevo far eseguire tutto via JavaScript nel contesto dell'utente admin. Ho potuto creare uno script usando alcune richieste fetch per eseguire ciascuna di queste richieste POST. La prima aggiornava le proprietà di sistema, la seconda aggiornava il campo 'Last Name' dell'utente admin e l'ultima eseguiva una richiesta GET sul nuovo file di log creato con codice php dannoso. Il codice php dannoso avrebbe eseguito una richiesta curl verso la mia macchina, scaricato una bash reverse shell e poi convogliato l'output di quella richiesta curl direttamente a bash, eseguendo il codice. Ho quindi caricato questo usando lo stesso metodo discusso nella sezione XSS e ho riaperto il nuovo link come utente admin. Con un server web che ospitava il mio file bash e un listener netcat in esecuzione, sono riuscito a ottenere una reverse shell.
Assicurati di avere AllowOveride All impostato in Apache. nginx non ha questa impostazione e non l'ho testato su nginx.
Aggiorna all'ultima release di SuiteCRM, o almeno alla versione 7.11.17.
Questo è il fix specifico. Commit 1618af16eaa494c4551bac961e5ac8fc3d87ab8c
SuiteCRM è stata molto reattiva durante tutto il processo di segnalazione. Hanno riconosciuto la RCE, che è stata corretta. L'XSS era il risultato di una configurazione del server web, quindi non l'hanno riconosciuta come vulnerabilità. Hanno però notato che avrebbero aggiornato la documentazione alla luce di questo.
AllowOveride All mitiga l'XSSOra abbiamo rilasciato una patch per questo problema ed è nel dominio pubblico, non c'è problema che tu faccia un post sul blog sulle vulnerabilità dal nostro punto di vista.
https://www.exploit-db.com/exploits/49001
Sono stati molto facili con cui lavorare e ho sicuramente intenzione di continuare a cercare e segnalare vulnerabilità in questo software!