Android Filesystem
Quella che sege è una breve lista di path all’interno di android che è obbligatorio conoscere.
Tutti i dati delle app installate si trovano in /data/data.
I file .apk delle app si trovano in /data/app/nome.del.pacchetto. Se l’app è installata dal Play Store e si vuole risalire al file apk originale per fare reverse engineering, è possibile prelevarlo da questo percorso con adb pull.
I permessi standard assegnati alla shell possono essere trovati in /system/etc/permissions/platform.xml
I file contenenti la gesture o il pin di sblocco sono /data/system/gatekeeper.password.key e /data/system/gatekeeper.pattern.key.
Se non sono cambiate le cose, cancellandoli è possibile rimuovere lo screen lock del dispositivo.
In alternativa è possibile modificare il file /data/system/locksettings.db:
UPDATE locksettings SET value = '1' WHERE name = 'lockscreen.disabled'
Gli screenshot delle app in background si trovano in (dipende dalle versioni di Android): /data/system_ce/0/recent_images/
Il Keystore di android si trova qui: /data/misc/keystore/user_0
Cartella tmp: /data/local/tmp
Database cache keyboard: /data/data/com.android.providers.userdictionary/databases/user_dict.db
Android Keystore
Il AndroidKeystore è l’API utilizzata dalle app per eccedere alle funzionalità del Keystore di Android. Il Keystore permette di archiviare le chiavi di crittografia utilizzate dalle app in maniera sicura. Le chiavi private non possono essere estratte dal Keystore (da Android 6.0) perché non entrano mai nel processo dell’app ma sono gestite da un processo di sistema. Se l’app è compromessa potrebbe essere possibile utilizzare le chiavi ma non estrarle.
Android inoltre ha un sistema hardware di sicurezza chiamato Keymaster, se la feature è abilitata, le chiavi non vengono mai esposte al di fuori dell’hardware. Questa funzionalità deve essere supportata dal dispositivo.
Il Keystore offre dei metodi per limitare l’utilizzo delle chiavi, come ad esempio richiedere il pin per sbloccare l’accesso alla chiave, limitare l’utilizzo solo ad alcune modalità di crittografia o definire un arco temporale in cui la chiave può essere utilizzata.
Riferimenti: https://developer.android.com/training/articles/keystore
Android Keychain
Il keychain si usa quando si vogliono utilizzare delle credenziali system-wide. Quando un’app richiede l’utilizzo di credenziali attraverso il KeyChain, l’utente deve scegliere tramite la UI di sistema, a quale delle credenziali (certificati) installate l’app avrà accesso. Questo può permettere a varie applicazioni di utilizzare lo stesso set di credenziali con il consenso dell’utente. Se un’azienda ad esempio ha più app che necessitano delle stesse credenziali per comunicare con il backend, potrebbe usare il KeyChain.
Le credenziali del keychain possono essere utilizzate per firme digitali, encryption, SSL auth e VPN, Wifi etc.
Shared Preferences
La shared preferences è una cartella presente in ogni app Android. Gli sviluppatori sono soliti salvare in questa cartella le configurazioni e dati sensibili in file xml.
/data/data/nome.del.pacchetto/shared_prefs
External Storage
Gli sviluppatori potrebbero salvare dati utilizzati dall’app anche sulla scheda SD. I file salvati nella memoria esterna sono globalmente leggibili/scrivibili. Dal moment che la SD può essere rimossa e i file sono accessibili a chiunque, solitamente si sconsiglia di utilizzare lo storage esterno per archiviare le informazioni.
/sdcard
Insecure Communication
Durante le analisi occorre verificare che le app comunichino col back-end attraverso il protocollo HTTPS. Tuttavia, è necessario implementare ulteriori controlli sul certificato affinché l’app stabilisca una connessione realmente sicura evitando attacchi MiTM.
In primis l’app deve verificare l’autenticità del certificato del server e confrontandolo con i certificati root preinstallati sui sistemi Android (Impostazioni > Sicurezza > Crittografia e Credenziali > Credenziali attendibili > Sistema), quello che farebbe un browser.
Soltanto questo controllo però non è sufficiente perché con i permessi di root è possibile installare certificati self-signed, come il certificato di burp, e portare a termine l’attacco man in the middle senza troppi sforzi.
Quindi si verifica che l’app faccia uso di SSL Pinning, che consiste nel verificare che una determinata chiave pubblica o un certificato compaia all’interno di una catena di certificati considerati attendibili.
Alcune librerie che offrono funzionalità per incorporare SSL Pinning sono: OkHttp, Retrofit, Picasso, HttpUrlConnection, Volley, Apache Httpclient
Riferimenti: https://developer.android.com/training/articles/security-ssl.html
https://medium.com/@appmattus/android-security-ssl-pinning-1db8acb6621e
https://www.netguru.com/codestories/3-ways-how-to-implement-certificate-pinning-on-android
https://developer.android.com/training/articles/security-config
Se l’applicazione implementa SSLPinning non è possibile intercettare il traffico con Burp ed occorre effettuare il bypass del pinning con Frida.
La verifica può essere fatta tramite analisi statica del codice, ma dal momento che ci sono vari modi con cui uno sviluppatore può aver implementato SSL Pinnig, conviene procedere con l’analisi dinamica dell’app.