Prima di iniziare questo lungo tutorial ci terrei spiegare cos’è Android Debug Bridge.
ADB è un utility per 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 in uso governativo, 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 dai dispositivi iOT ( internet of Things) come: fotografie, video,documenti sensibili, numeri di carte di credito ecc, per metterli successivamente in vetrina su uno dei tanti marketplace nel darkweb o oer ricattare qualcuno richiedendo il riscatto in bitcoin.
Lo scopo dell’articolo è quello di sensibilizzare gli utenti ad evitare configurazioni errate per ADB, pertanto di seguito Hackerpunk tratterà solo tecniche orientate all’ hacking, inoltre per facilitare la comprensione l’articolo verrà diviso in due parti: scanning ed exploiting.
Importante:
Nel contesto negli scenari che verranno rappresentati lo staff di Hackerpunk non si assumerà alcuna responsabilità della replica di tali tecniche sui dispositivi altrui, per tali motivi per maggiore sicurezza 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 per altri fini al di fuori di quelli incentrati alla messa in sicurezza dei dispositivi iOT.
Preparazione dell’attacco e ricerca IP
Per una prima analisi degli indirizzi IP utilizziamo Android Termux su android, successivamente proseguiremo con Kali Linux, salteremo in questo caso direttamente all’utilizzo del tool senza procedere alla sua installazione con le relative dipendenze.
Utilizziamo la piattaforma https://shodan.io per recuperare alcuni indirizzi IP esposti sprovvisti delle 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 nel mondo, 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 agganciare qualche device recuperando delle risorse salvate sul dispositivo, registrare un video dalla fotocamera o installarci una backdoor, quest’ultima potrebbe essere utile ad un criminale informatico per accedere in maniera persistente sul device 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 corrisponderebbe 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 la missconfiguration di 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 installarci dentro una backdoor in formato .apk utilizzando Kali Linux per esempio.
Nella seconda parte del tutorial passeremo da Android su Kali Linux cercando su Shodan qualche altro indirizzo IP sperando di beccare un comune smartphone con la porta ADB aperta.
2 parte ( exploiting)
Seguici anche su:
@INSTAGRAM https://www.instagram.com/hackerpunk2019/
@LINKEDIN https://www.linkedin.com/company/hackerpunk
@FACEBOOK https://www.facebook.com/hackerpunk2019
@EBOOK
@EBOOK (English version)
@YOUTUBE https://www.youtube.com/channel/UCiAAq1h_ehRaw3gi09zlRoQ
