Android è il sistema operativo mobile più diffuso al mondo e, in quanto tale, il bersaglio principale del malware mobile. Il suo modello di sicurezza è costruito su più livelli — isolamento del kernel Linux, sandbox applicativa, sistema dei permessi, verifica delle app — ma la sua apertura strutturale (sideloading, frammentazione degli aggiornamenti, ecosistema di vendor eterogeneo) lo espone a vettori di attacco che iOS non condivide per design.
Architettura di sicurezza
Linux kernel e SELinux: Android è basato sul kernel Linux con SELinux (Security-Enhanced Linux) in modalità enforcing. SELinux applica policy mandatory access control (MAC) che limitano le azioni di ogni processo anche se compromesso — un’app non può accedere ai file di un’altra app anche con exploit di privilege escalation, perché la policy SELinux lo nega a livello kernel.
Application sandbox: ogni applicazione è eseguita come utente Linux distinto (UID unico assegnato all’installazione). I file dell’app sono di proprietà del suo UID e inaccessibili alle altre app per i normali meccanismi Unix. La comunicazione tra app avviene attraverso meccanismi espliciti e controllati (Intent, Content Provider, Binder IPC).
Android Runtime (ART): la JVM-like runtime su cui gira il codice delle app. Compila il bytecode Dalvik in codice nativo. Il bytecode è facilmente reversibile — i file APK possono essere decompilati con strumenti come jadx, apktool — il che facilita l’analisi forense e il reverse engineering, ma anche la clonazione e il repackaging di app maliciose.
Sistema dei permessi
Le app dichiarano nel manifest i permessi richiesti. L’utente concede (o nega) i permessi sensibili (dangerous permissions) a runtime, singolarmente:
- Normali: concessi automaticamente senza prompt (accesso a Internet, Bluetooth).
- Pericolosi: richiedono consenso esplicito dell’utente (fotocamera, microfono, posizione, contatti, SMS, storage).
- Signature: concessi solo ad app firmate con la stessa chiave del sistema o del dichiarante del permesso.
Abuso dei permessi: app maliciose richiedono permessi eccessivi e li usano per sorveglianza (stalkerware, accesso ai contatti per spam), esfiltrazione di dati o premium SMS fraud.
Vettori di attacco principali
Sideloading di APK: Android permette di installare app da sorgenti esterne al Play Store (file APK scaricati da browser, link condivisi, store alternativi). È il vettore principale di distribuzione del malware mobile — l’app non è analizzata da Google Play Protect.
Repackaging: un’app legittima viene decompilata, modificata con payload malevolo (tipicamente un dropper o adware), ricompilata e ridistribuita su store non ufficiali. Visivamente identica all’originale.
Malicious apps su Play Store: nonostante Google Play Protect, app maliciose riescono periodicamente a bypassare le analisi. Tipicamente usando tecniche di delayed payload delivery (il comportamento malevolo si attiva solo dopo alcuni giorni dall’installazione) o scaricando il payload da remoto dopo l’approvazione.
Exploit del kernel/driver: vulnerabilità nel kernel Linux o nei driver del vendor (GPU, modem, chip Wi-Fi) permettono privilege escalation da app a root, sfuggendo alla sandbox. La frammentazione Android — molti vendor distribuiscono aggiornamenti di sicurezza in ritardo o mai — lascia milioni di dispositivi esposti a exploit noti.
Stagefright e simili: vulnerabilità nei componenti di parsing multimediale (Stagefright, 2015: RCE tramite MMS) dimostrano che il vettore di attacco può non richiedere alcuna interazione utente.
Protezioni avanzate
Verified Boot (dm-verity): garantisce che il sistema operativo non sia stato manomesso confrontando ogni blocco del filesystem di sistema con un hash firmato. Un dispositivo con bootloader sbloccato o sistema modificato viene identificato come non verificato.
Keystore hardware: le chiavi crittografiche possono essere generate e usate nel Trusted Execution Environment (TEE) o nello StrongBox (chip di sicurezza dedicato) senza mai uscire dall’hardware in chiaro. Un’app può usare una chiave per firmare senza mai avervi accesso diretto.
Play Protect: scansione continua delle app installate, anche post-installazione, tramite analisi cloud. Non efficace contro malware custom o zero-day, ma rileva la maggior parte delle famiglie di malware note.
Attestation e Play Integrity API
Android attestation è il meccanismo con cui un dispositivo dimostra a un server remoto che il software in esecuzione è autentico e non manomesso. Il server invia una sfida, il dispositivo la firma con una chiave generata nell’hardware TEE legata all’identità del dispositivo, e il server verifica la firma con i certificati Google.
Play Integrity API (successore di SafetyNet) fornisce tre verdetti:
- MEETS_DEVICE_INTEGRITY: il dispositivo non è rootato e il bootloader è bloccato.
- MEETS_BASIC_INTEGRITY: il dispositivo non mostra segni evidenti di manomissione.
- MEETS_STRONG_INTEGRITY: il dispositivo ha attestation hardware (chip dedicato).
Le app bancarie, di pagamento e di DRM usano questi verdetti per rifiutare l’esecuzione su dispositivi rootati o con bootloader sbloccato. Questa protezione può essere aggirata con tecniche di attestation bypass (hook su Frida, Magisk Hide, Shamiko) che nascondono lo stato di root dalla API, ma richiede competenze avanzate e viene periodicamente rotta dai nuovi aggiornamenti di Play Integrity.
Vedi anche: App Sandboxing.