A cura di: Curzi Fernando (leader team hackerhood)
Prima di iniziare ci terrei spiegare cos’è Android Debug Bridge. ADB è un utility android da riga di comando utilizzata particolarmente dagli sviluppatori per comunicare con un dispositivo smartphone android. I comandi adb facilitano una varietà di azioni sul dispositivo, come per esempio: l’installazione e il debug delle app, fornisce l’accesso a una shell Unix e permette di svolgere una moltitudine di attività tecniche. ADB è sostanzialmente un programma client-server che include tre componenti principali:
- Un client , che invia comandi e viene eseguito sul computer dello sviluppatore.
- Un daemons (adbd), che esegue i comandi su un dispositivo, Il daemons viene eseguito come processo attivo in background su ciascun dispositivo.
- Un server, che gestisce la comunicazione tra il client e il daemons. Il server viene eseguito come processo sul computer dello sviluppatore in ambito locale o in remoto.
Come funziona ADB
Quando si avvia un adb client, controlla innanzitutto se sul sistema vi è in esecuzione un processo server, in caso contrario lo avvia per la prima volta. Una volta eseguito il server si collega alla porta TCP locale 5037 e ascolta i comandi inviati dai adb client, tutti gli adb client utilizzano la porta 5037 per comunicare con l’adb server.
Il server imposta quindi le connessioni a tutti i dispositivi in esecuzione e individua gli emulatori eseguendo la scansione delle porte dispari nell’intervallo da: 5555 a 5585 utilizzato dai primi 16 emulatori, quando il server trova un adb daemons (adbd), imposta una connessione a quella porta.
La vulnerabilità
Compreso il funzionamento ADB c’è da dire che spesso queste configurazioni tecniche vengono attivate di fabbrica su alcuni device aziendali e governativi, basti fare un test sul proprio smartphone, aprire dal menu settings/about_phone/build_number e pigiare 7 volte sulla voce Build_number per attivare le configurazioni da sviluppatore in cui si trovano anche quelle per ADB. La configurazione ADB attiva a volte è semplicemente il risultato di dimenticanze da parte di alcuni utenti che dopo aver utilizzato l’utility si dimenticano di disattivarla; la situazione si aggrava se sul dispositivo vi sono anche i privilegi di root. Tutto questo non sarebbe un grandissimo problema se sul dispositivo fosse attiva una delle tante misure di sicurezza che mitiga l’accesso ADB, come per esempio: l’autenticazione: “Authentication is required“. Malgrado quest’ultima venga attivata spesso dai soli sviluppatori proprio perché conoscono la problematica, c’è da dire però che l’autenticazione non risulta essere una soluzione definitiva, esiste infatti un comando che induce il server ADB a riavviarsi e bypassare l’autenticazione: “$kill adb-server”.
In questo articolo vedremo alcune tecniche utilizzate dai black hat per le attività di exfiltration di dati come: fotografie personali, video e documenti sensibili dal mondo ioT (internet of Things), per metterli in vetrina su uno dei tanti marketplace nel darkweb. Lo scopo dell’articolo è quello di sensibilizzare gli utenti ad evitare configurazioni errate per ADB, pertanto di seguito Hackerhood tratterà solo tecniche orientate all’ hacking.
Nel contesto negli scenari che verranno rappresentati Red Hot Cyber non si assumerà alcuna responsabità della replica di tali tecniche sui dispositivi altrui, per tali motivi verrà oscurato il nome del framework utilizzato, gli indirizzi IP utilizzati, eventuali volti di persone estratti da foto o video, cercando di rendere il meno possibile esaustiva la replica della procedura.
Preparazione dell’attacco e ricerca IP
Per una prima analisi degli indirizzi IP utilizziamo Android Termux, successivamente proseguiremo con Kali Linux, salteremo direttamente all’utilizzo del framework senza procedere alla sua installazione con le relative dipendenze.
Utilizziamo https://shodan.io per recuperare alcuni indirizzi IP esposti senza le dovute misure di sicurezza. Sebbene Shodan permetta di verificare l’apertura della porta 5555 utilizzata da ADB server attraverso un sistema di ping (Banner Grabbing), allo stesso tempo limita le ricerche effettuate per account. La nostra analisi su Shodan sarà orientata ai soli indirizzi IP di smartphone, ma come già sappiamo il sistema operativo Android viene utilizzato in molti dispositivi IoT come: smartwach, smartTV, VMBox, Radio, Lavatrici, condizionatori ecc. In particolare ci concentreremo su indirizzi IP geolocalizzati nel territorio della Federazione Russa, USA e CINA. Cercheremo di violare qualche device recuperando le risorse salvate sul dispositivo, registrare un video dalla fotocamera o installarci una backdoor, quest’ultima potrebbe essere utile ad un criminale per accedere in maniera persistente in momenti diversi senza l’utilizzo del tool.
Su shodan scegliamo uno dei seguenti indirizzi ip, un buon candidato per la dimostrazione potrebbe essere il 89.178.215.**
Connettiamoci al device e apriamo una shell:
Fatto! siamo già dentro il device, ci è voluto veramente poco! enumeriamo qualche cartella come: sdcard, Pictures e downloads ma notiamo subito che non c’è nulla di interessante all’interno.
Facendo qualche ricerca su Google, il device “Beeline” come indicato dal Banner Grabbing di Shodan corrisponde ad un dispositivo Android di tipologia “Smart bike”, quindi in sostanza abbiamo bucato per caso un nav per biciclette in Russia… al massimo ci permetterà di trovare all’interno le statistiche di pedalata e i battiti cardiaci del ciclista.
saltiamo quindi ad un altro dispositivo più interessante.
Andiamo nuovamente su Shodan e cerchiamo qualche altro indirizzo IP, troviamo il 186.90.66.** geolocalizzato in Venezuela corrispondente ad un device SmartTV, potrebbe essere interessante da analizzare.
Cerchiamo prima di tutto su Google di cosa si tratta realmente, Il device corrisponde ad un SmartBox TV.
Avviamo la Shell dal framework:
Enumeriamo qualche cartella
Con il comando $ifconfig confermiamo di trovarci fisicamente nella rete locale della SmartTV.
Enumerando ancora nelle cartelle troviamo la lista delle applicazioni installate sul dispositivo:
In effetti corrispondono a quelle tipiche che vengono installate su una comune SmartTV.
Anche in questo device non abbiamo trovato nulla che ci possa interessare ma abbiamo dato una prima idea e di vedere come facilmente si potrebbe sfruttare Android Debug Bridge per accedere a qualsiasi dispositivo esposto su Shodan con la configurazione ADB aperta. Se si tratta del più piccolo device che si trova in casa vostra o di uno smartphone non importa il problema è la configurazione ADB errata sul dispositivo. Vedremo oltre ad aprire una reverse Shell quali altre cose si possono fare con questo tool, inoltre potremmo installare utilizzando Kali Linux un’ applicazione .apk per esempio.
Passiamo ora su una Kali Linux cercando su Shodan qualche altro indirizzo IP e sperando di beccare un comune smartphone con la porta ADB aperta.
Exploiting
Quello che abbiamo fatto fino adesso non sono altro che tentativi per cercare il target giusto. Shodan ti permette di ricercare una miriade di dispositivi connessi da tutto il mondo non solo con la porta 5555 aperta ma anche con altre porte, offrendo oltremodo una varietà di filtri di ricerca che permettono di fare delle attività di OSINT e cercare target prestabiliti in zone prefissate o appartenenti ad un determinato ISP o ad una determinata compagnia. Una volta individuato il target un criminale potrebbe sfruttare il framework per avere la possibilità di installare nei dispositivi una backdoor e utilizzare Metasploit per aprirsi una sessione persistente con Meterpreter.
Gli attaccanti in questo tipo di scenari preferiscono utilizzare degli script automatizzati scritti in gran parte in linguaggio Ruby e Python che attraverso un’API che il motore di ricerca mette a disposizione ricercano automaticamente gli indirizzi IP vulnerabili su Shodan. Inoltre sfruttano il framework che stiamo utilizzando (o anche altre Vulnerabilita’ come le 0day) per installare massivamente malware nelle memorie dei device che andranno poi ad alimentare una delle tante Botnet gestite da un’organizzazione per le attività di criptojacking, DDOS, phishing ecc.
In questo articolo per una questione etica non potremmo svolgere tutte queste attività ma vedremo sostanzialmente come sfruttare il framework per installare una backdoor.
Recuperiamo da Shodan un probabile indirizzo IP di smartphone e apriamo la shell con il comando.
Con il tool Ngrok avviamo un server fittizio che fungerà da proxy per effettuare il port forwarding sul nostro multi/handler in ascolto:
Con Msfvenom generiamo un file.apk che andremo ad installare nel device che fungerà da backdoor.
Avviamo l’Handler su metasploit intanto..
Installiamo sul device la backdoor che abbiamo generato con msfvenom
Verifichiamo con un comando del tool se l’installazione è avvenuta correttamente: com.metasploit.stage ci conferma l’installazione.
Avviamo l’applicazione da remoto che ci permetterà di ricevere la sessione su meterpreter
Fatto.. Abbiamo una sessione su Meterpreter
Da questo momento in poi si potrà utilizzare la backdoor per accedere al dispositivo e ci si potrà anche installare un modulo di persistenza, inoltre si potrà:
- Avviare la fotocamera,
- Avviare una registrazione video,
- Estrarre uno screenshot dallo schermo,
- Avviare la registrazione audio del microfono,
- Dump dei contatti,
- Inviare un sms,
- Dump degli sms,
- Geolocalizzazione,
- Verificare se il dispositivo è abilitato ad essere utilizzato con i privilegi di root
…
Qui le Informazioni di sistema:
Qui l’ Audio estratto dal microfono:
Qui abbiamo avviato uno streaming video della fotocamera
“device is rootet” ci indica che il dispositivo è stato anche “rootato”
In merito alla violazione di questo smartphone abbiamo preferito non mostrare fotografie o video privati che ritraggono persone reali.
Mostreremo solo lo streaming a video recuperato da una smartTV nella circostanza di un utente alle prese con la scelta di un canale.
Qui di seguito uno screenshoot estratto dallo schermo dello smartphone
Conclusioni
La sicurezza delle configurazioni ADB è migliorata rispetto a quella di 10 anni fà ma come avete ben capito non si tratta di una vulnerabilità/bug ma di una missconfiguration molto grave che potrebbe esporre la tua privacy e i tuoi dati a rischio.
La soluzione più semplice è quella di disabilitare il Debug. L’impostazione è disabilitata in maniera predefinita su tutti i device ma la maggior parte delle Rom personalizzate ha questa configurazione abilitata. Per disabilitarla abilita prima la modalità sviluppatore (come spiegato alli’inizio dell’articolo) e vai su:
Settings 🡪 Developers Options 🡪 Android Debbuging
Assicurarsi che il Debug di Android sia disattivato
Una configurazione più avanzata potrebbe essere quella di disabilitare adbd deamon.
ADB in realtà si basa sul binario ADBD. Nella Maggior parte delle ROM AOSP il binario è memorizzato in sbin/adbd, se si modificano i permessi in 000 non può più essere eseguito e non può essere utilizzato. Un modo per raggiungere questo obiettivo è utilizzare questo script:
# disabilitare adbd deamon
mount –o rw,remount –t rootfs rootfs /
chmod 000 /sbin/adbd
mount –o ro,remount –t rootfs rootfs /
mount –o ro, remount /system
Salva il codice in un file chiamato 99secure e inseriscilo in /etc/init.d/ se la tua ROM supporta init.d lo script verrà eseguito all’avvio e rimuoverà i permessi adbd in modo che non possa essere mai eseguito.
Aver effettuato modifiche ai privilegi del vostro dispositivo che in gergo direste “rootare” oltre a farvi essere “fighi” vi espone ad innumerevoli rischi di sicurezza. L’utente root ha pieno accesso al sistema e può eseguire quasi tutte le attività nel dispositivo. La maggior parte delle ROM personalizzate viene fornita con l’impostazione di root abilitata, l’esecuzione del dispositivo con root abilitato è intrinsicamente insicuro, se un’app dannosa (come candycrush.apk) venisse eseguita con i privilegi di root, avrebbe pieno accesso al sistema e potrebbe fare qualsiasi cosa (come abbiamo visto nella dimostrazione).
La soluzione
Settings 🡪 Developers Options 🡪 Root Access 🡪 Disabled
In alternativa puoi cambiare I permessi del binario:
mount –o rw,remount /system
chmod 000 /system/xbin/su
mount –o ro,remount /system
Comments are closed