Archiviazione e comunicazioni non sicure

Due delle vulnerabilità mobile più comuni sono la memorizzazione non sicura dei dati e le comunicazioni non sicure. Sono incluse nell'OWASP Mobile Top 10.

Entrambe derivano dal fatto che gli sviluppatori si fidano eccessivamente del dispositivo e proteggono i dati in modo insufficiente.

Le app conservano i dati in /data/data/<package>/:

• SharedPreferences: file XML di coppie chiave-valore.
• Database SQLite.
• File interni ed esterni.

I pentester esaminano ciascuna di queste aree alla ricerca di segreti memorizzati in chiaro.

Un problema frequente consiste nel memorizzare password, token o PII in chiaro in SharedPreferences o in un database.

Su un dispositivo con root, tramite un backup o con Objection, un aggressore può leggerli direttamente. I dati sensibili devono essere cifrati o conservati in hardware sicuro.

I dati scritti nello storage esterno (l'area della scheda SD) sono leggibili da chiunque nelle versioni meno recenti di Android e accessibili a qualsiasi app dotata dell'autorizzazione di archiviazione.

Salvare lì file sensibili li espone alle altre app. I log scritti su disco costituiscono una fuga di dati correlata.

Tra le opzioni sicure figurano Android Keystore (le chiavi sono memorizzate nell'hardware e non vengono mai esposte all'app) e EncryptedSharedPreferences.

Keystore può eseguire operazioni crittografiche senza rivelare la chiave, una soluzione molto più sicura rispetto a una chiave hardcoded nel codice.

Per comunicazioni non sicure si intende la trasmissione di dati senza una protezione adeguata. Il caso peggiore è l'HTTP in chiaro, in cui chiunque si trovi sulla rete può leggere o modificare il traffico.

Tutto il traffico sensibile deve usare HTTPS/TLS.

Per ispezionare il traffico, instradi il dispositivo attraverso un proxy d'intercettazione come Burp Suite. Installi il certificato CA di Burp sul dispositivo per poter leggere il traffico HTTPS.

Questo mostra gli endpoint API, i parametri e gli eventuali dati sensibili in transito.

Le app ben realizzate usano il certificate pinning per rifiutare qualsiasi certificato diverso dal proprio, impedendo il funzionamento di un proxy di base.

Come ha imparato, un bypass del certificate pinning SSL con Frida lo disabilita, consentendo di intercettare e valutare comunque la sicurezza effettiva delle API.

Anche con HTTPS, tra i problemi figurano l'accettazione di tutti i certificati, di quelli scaduti o la disattivazione della verifica del nome host, spesso introdotte per semplificare lo sviluppo.

Queste impostazioni consentono a un aggressore di eseguire un attacco man-in-the-middle nonostante la presenza di TLS.

Altre due fughe di dati:

• android:allowBackup="true" consente a chiunque abbia accesso al dispositivo di estrarre i dati dell'app tramite adb backup.
• Un output logcat dettagliato potrebbe stampare token o PII.

In produzione, entrambi devono essere disabilitati oppure sottoposti a sanitizzazione.

Due fughe di dati spesso trascurate: copiare dati sensibili negli appunti (leggibili dalle altre app nelle versioni meno recenti di Android) e lo screenshot di sistema acquisito quando un'app passa in background.

Le app bancarie mitigano il problema con il flag della finestra FLAG_SECURE, che blocca gli screenshot e l'anteprima nel selettore delle attività.

Ricordi il luogo più sicuro in cui conservare le chiavi crittografiche su Android.

Ora comprende lo storage e le comunicazioni non sicuri:

• Le app espongono segreti in chiaro in SharedPreferences, nei database, nello storage esterno e nei log.
• Conservi i segreti in Android Keystore o in EncryptedSharedPreferences.
• Le comunicazioni non sicure vanno dall'HTTP in chiaro alla convalida TLS debole; le intercetti con Burp.
• Eluda il certificate pinning con Frida; disabiliti allowBackup e sanifichi i log.

Ha completato il corso di Mobile App Pentesting.