Nella nostra ultima ricerca, abbiamo trovato 3 diverse vulnerabilità in TinyCheck, uno strumento open source sviluppato e pubblicato da Félix Aimé, uno degli esperti GReAT di Kaspersky. Ognuna delle vulnerabilità ha una gravità elevata di per sé. Una volta combinato in una catena, un utente malintenzionato remoto potrebbe sfruttarlo per ottenere un RCE (esecuzione di codice remoto) sulla macchina TinyCheck remota.
In poche parole, abbiamo usato il credenziali predefinite di TinyCheck per modificare due sezioni in un file di configurazione:
- Nel primo, abbiamo aggiunto un payload dannoso, che verrà eseguito successivamente tramite iniezione di comando vulnerabilità.
- Nel secondo, abbiamo aggiunto un URL a un elenco che causerà SSRF, che in seguito attiverà il payload dannoso dalla prima sezione.
Cos'è TinyCheck
TinyCheck consente all'utente di analizzare la rete di un dispositivo. L'utente può connettere il proprio dispositivo al proxy WiFi di TinyCheck, che catturerà l'attività di rete. Questa attività può essere analizzata per il traffico dannoso che passa attraverso la rete.
Dal momento che abbiamo esperienza con proxy su Android, sapevamo che un semplice proxy non avrebbe dovuto avere troppi problemi a gestire il traffico potenzialmente dannoso. Ma TinyCheck è più ricco di funzionalità, offrendo una migliore capacità di sniffing rispetto a un semplice script proxy. Il codice sorgente è disponibile su GitHub che ha permesso di esaminarlo.
TinyCheck ha 3 servizi rilevanti:
- “Backend” – un server Flask aperto al mondo e protetto da nome utente/password (autenticazione di base). Il server si concentra principalmente sulla modifica della configurazione.
- "Frontend": un server Flask che gira su localhost, non ha password e il suo compito principale è avviare/arrestare/gestire l'acquisizione di rete.
- "Watchers": un servizio watchdog che itererà su un elenco di URL e farà una richiesta HTTP GET a questi.
Vulnerabilità n. 1 – Credenziali predefinite
Questa è la più semplice delle 3 vulnerabilità, ma essenziale per l'intero attacco. Per impostazione predefinita, TinyCheck viene fornito con le credenziali predefinite di "tinycheck” come nome utente e password.
Avere tali credenziali predefinite senza richiedere all'utente di modificarle al primo utilizzo presenta un rischio inutile.
Utilizzando le credenziali predefinite, abbiamo avuto accesso a una varietà di endpoint nel server "back-end", che ci ha fornito una superficie di attacco più ampia.
L'endpoint importante che useremo in seguito è quello che modifica il file di configurazione YAML.
https://tinycheck.local/config/edit/CATEGORY/KEY/VALUE
Maggiori informazioni su come l'abbiamo usato di seguito.
Vulnerabilità n. 2 – SSRF
La dimenticanza della richiesta lato server (SSRF) è sempre entusiasmante e molte volte trascurata dagli sviluppatori o dai ricercatori di sicurezza. Sfruttando questa vulnerabilità, siamo riusciti a forzare il server a effettuare una richiesta HTTP. È utile per bypassare il firewall o per accedere alla rete interna, che prima non era accessibile.
Abbiamo scoperto che il server ha un elenco di URL memorizzati nel file di configurazione YAML sotto watchers/iocs:
Utilizzando la prima vulnerabilità, siamo stati in grado di riscrivere l'elenco e modificarlo con i nostri URL:
È interessante notare che ora siamo stati in grado di fare in modo che il servizio "osservatori" esegua una richiesta HTTP GET a qualsiasi URL che scegliamo. Ancora più importante, potremmo raggiungere il server "frontend" mentre viene eseguito localhost una volta ricaricato il servizio “osservatori”.
Ancora una volta, questo ci ha dato una superficie di attacco più ampia per raggiungere più endpoint e più logica che potevamo sfruttare.
Vulnerabilità n. 3 – Iniezione di comandi
Abbiamo iniziato a indagare sul server "frontend". Non lasciarti confondere dal nome, questo è un server Flask, non solo un frontend JS.
Avendo un intero nuovo mondo di endpoint dalla vulnerabilità SSRF, abbiamo esaminato le classi di servizio, le funzioni e le utilità che potrebbero essere sfruttabili.
Dopo aver letto il codice sorgente e approfondito lo stack delle chiamate di funzione, ci siamo imbattuti in questo codice:
Popen("tshark -i {}".format(self.iface), shell=True)Popen è il modo di chiamare un sottoprocesso in Python. Il shell=True e la format sono le parti sfruttabili, nel senso che il comando che verrà eseguito verrà interpretato come una stringa. Mentre l'intenzione originale qui funziona se self.iface è solo una stringa come "eth0", ci siamo resi conto che se fossimo stati in grado di iniettare una stringa pericolosa, saremmo stati in grado di eseguire codice arbitrario.
Fortunatamente per noi, il self.iface è stato effettivamente letto dal file di configurazione sotto il file network/in sezione, il suo valore originale suppone che punti a un'interfaccia di rete.
self.iface = read_config("network/in")Come per la vulnerabilità SSRF, abbiamo inserito il nostro payload utilizzando lo stesso endpoint di modifica della configurazione.
L'iniezione stessa era semplice:
; whoami>/tmp/exploit.outCiò significa che con il nostro payload, il comando originale verrà formattato come:
Popen("tshark -i ; whoami>/tmp/exploit.out", shell=True)In effetti, il file conteneva la parola root, il che significa che potremmo assumere il controllo del sistema, poiché il server è in esecuzione come root e non come utente dedicato con privilegi limitati.
Ma abbiamo dovuto attivare questo codice. In questo momento, il nostro payload è stato eseguito proprio quando l'utente inizia a catturare l'attività di rete tramite l'interfaccia utente.
La catena di exploit completa
Per legare tutto insieme, avevamo bisogno di un modo per attivare il nostro carico utile.
Lo abbiamo fatto sfruttando l'SSRF per chiamare uno degli endpoint "frontend" locali, che avvia la funzione di acquisizione della rete in modo da non dover attendere che l'utente lo faccia.
Questo ha richiamato il codice vulnerabile dal servizio "osservatori" e per l'iniezione di comando da eseguire con il nostro payload dannoso.
Divulgazione al team di sicurezza di Kaspersky
La divulgazione della vulnerabilità al team di sicurezza di Kaspersky è stata per noi un'esperienza straordinariamente positiva. Shutout per loro per averci contattato molto rapidamente e aver ottenuto il vantaggio del prodotto, Félix Aimé, coinvolto che ha risolto tutte le vulnerabilità nel giro di un giorno o due.
Cronologia delle informazioni
- 2020-12-14: Rapporto dettagliato inviato a [email protected]
- 2020-12-15: prima risposta dal Product Security Team di Kaspersky
- 2020-12-18: tutte le vulnerabilità sono state corrette + consulenza per eseguire l'aggiornamento alla versione con patch
- 2021-01-22: CVE rilasciati
- 2021-02-11: Pubblicazione del post sul blog
Vuoi saperne di più?
Un incontro di consulenza gratuito incluso.
