Una recente ricerca dei ricercatori di ZecOps ha costruito un PoC che dimostra la possibilità per gli agenti di minaccia di costruire una formidabile tattica per la persistenza. 

È risaputo che il problema fondamentale di qualsiasi software è la sopravvivenza allo spegnimento (o riavvio) del dispositivo fisico su cui viene eseguito: questa sopravvivenza è detta appunto “persistenza”, in quanto consente al software di rimanere, ovvero di riprendere la sua esecuzione anche a dispetto della volontà dell’utente. 

È quello a cui aspirano gli agenti di minaccia quando progettano uno scenario di attacco basato di malware (il termine è a dire il vero utilizzato anche per altre forme di persistenza che riguardano la presenza della minaccia con forme di accesso). 

È quindi corretto poter pensare che la corretta profilassi contro i malware che non possano disporre di un ancoraggio di persistenza possa essere quella di riavviare il proprio dispositivo: ma tutto questo è stato spazzato via dalla ricerca di ZecOps, almeno per i possessori di iPhone. 

La ricerca ha dimostrato infatti che è possibile interagire a livello software con il meccanismo con cui il sistema operativo iOS esegue la sequenza di spegnimento (o riavvio), a tal punto da impedirla. Certo, questo allarmerebbe l’utente; ma il passo successivo degli aggressori sarebbe quello di falsificare le schermate per simulare una fase di riavvio o di spegnimento in modo da non allarmarlo, e continuare così impunemente a compiere quanto nella disponibilità del software che hanno impiantato. Questo è dovuto ad un bug al momento “irrimediabile” denominato “NoReboot”. 

Con schermata nera, l’utente può dedurre che il proprio dispositivo è spento tipicamente dall’osservazione di alcuni comportamenti naturali del proprio dispositivo: le notifiche, le chiamate in ingresso, la vibrazione, il feedback sul tocco dello schermo, la comparsa di indicatori accessori (come attivazione videocamera, ecc). Ma tutti questi sono meccanismi software, pertanto possono essere inibiti da “NoRebot”. 

La PoC non si occupa di come eseguire la delivery, ma dimostra cosa potrebbe succedere se qualcuno sia in grado di iniettare il codice capace di questo artificio: tutto nasce da una classe di sistema (FBSSystemService che esiste da iOS 8.0) in Objective-C, in cui è definito un metodo shutdownWithOptions. Mediante il run-time dell’Objective-C è possibile recuperare una definizione di classe e modificarne legittimamente un metodo mediante funzione “method_exchangeImplementations”. L’implementazione malevola dovrà semplicemente avvisare i servizi coinvolti nelle procedure di spegnimento (o riavvio) di eseguire altro codice, quello che simuli tali procedure, quando attivato (per intervento dell’utente sul dispositivo). 

I servizi coinvolti sono InCallService, SpringBoard (volgarmente noto come schermata home) e backboardd. Non è necessario che l’utente sia sulla schermata home perché il tutto abbia inizio: quando SpringBoard non è attivo il servizio backboardd è responsabile dello schermo, pertanto registrerà l’evento della pressione dei tasti responsabili dell’attività di reboot o shutdown. Sempre con il metodo di sostituzione dinamica dei metodi (method_exchangeImplementations), anche l’implementazione di backboardd viene manipolata al fine di intervenire nella catena degli eventi (segnali) che innescherebbe la procedura di spegnimento 

Se la procedura forzasse anche lo spegnimento di SpingBoard, impedendone la ripartenza, potrebbe simulare uno shutdown irreversibile (l’utente non ritroverebbe il controllo del dispositivo), pur essendo il dispositivo attivo, come pure il malware, tenendo così completamente in ostaggio il dispositivo per le finalità volute (con accesso ad internet e quanto altro). 

NoReboot non è un bug di persistenza (come abbiamo visto, il dispositivo non viene né riavviato né spento), e iOS non può essere corretto in tal senso: vedremo come Apple risolverà la questione. 

Abbiamo una possibile soluzione temporanea? Se proprio avessimo la certezza di essere stati contaminati da una minaccia, potremmo applicare il riavvio forzato (che è a livello hardware, e che agisce anche in modalità differenti da quella operativa). Questo toglie semplicemente e brutalmente alimentazione al dispositivo (fornendola nuovamente in un secondo momento), quindi non c’è modo che possa essere interrotto: non è una cosa da fare con regolarità, in quanto potrebbe danneggiare il dispositivo (in particolare il filesystem dove risiedono software e configurazioni). Unica possibilità per i malintenzionati in questo caso è quello di poter intercettare la sequenza di eventi che innesca il riavvio forzato (la pressione prolungata di differenti tasti) e provi a mimare il riavvio/spegnimento con una immagine per “illudere” l’utente: questo rilascerebbe prima del tempo l’ultimo pulsante necessario all’avvio della sequenza, impedendola così di fatto. La corretta procedura ce la fornisce Apple, https://support.apple.com/it-it/guide/iphone/iph8903c3ee6/ios, ma attenzione al tempo e a false immagini, altrimenti non serve a nulla!  

Tweet