Metodologia OWASP

L’analisi delle applicazioni Android può essere fatta seguendo la metodologia OWASP MSTG (Mobile Security Testing Guide) che si occupa di tracciare le linee guida per realizzare un’analisi completa dell’applicazione.

https://mobile-security.gitbook.io/mobile-security-testing-guide/

Le aree chiave della sicurezza di un’applicazione mobile sono le seguenti:

• Local Data Storage
• Communication with Trusted Endpoints
• Authentication and Authorization
• Interaction with the mobile platform
• Code Quality and Exploit Mitigation
• Anti-Tampering and Anti-Reversing

OWASP Mobile TOP 10 – 2016

• M1. Improper Platform Usage​
• M2. Insecure Data Storage​
• M3. Insecure Communication​
• M4. Insecure Authentication​
• M5. Insufficient Cryptography​
• M6. Insecure Authorization​
• M7. Client Code Quality​
• M8. Code Tampering​
• M9. Reverse Engineering​
• M10. Extraneous Functionality​

M1. Improper Platform Usage

Riguarda l’uso improprio di una funzionalità della piattaforma o il mancato utilizzo dei controlli di sicurezza della piattaforma. Include gli Android intents, le autorizzazioni della piattaforma, l’ uso improprio di TouchID, del KeyStore o altri controlli di sicurezza che fanno parte di Android.

M2. Insecure Data Storage​

Riguarda il salvataggio di informazioni sensibili come username e passwords in chiaro, all’interno del dispositivo, in file xml, database sqlite non protetti, log di Android, binary data stores, cookies e sessioni.

M3. Insecure Communication​

Trasmissione in chiaro di informazioni via TCP/IP, WiFi, Bluetooth/Bluetooth-LE, NFC, audio, infrared, GSM, 3G, SMS. Utilizzo di certificati self-signed, mancanza di SSL pinning.

M4. Insecure Authentication​

Interazione anonima con l’API del back-end, assenza di token di autenticazione, utilizzo improprio dei token di autenticazione, password salvate sul dispositivo, password policy debole.

M5. Insufficient Cryptography​

Riguarda la capacità di riportare allo stato originale le informazioni cifrate all’interno del dispositivo. Si segnalano algoritmi di cifratura deboli (SHA1, MD4, MD5 RC2), funzioni random insicure, IV generato in maniera non casuale, cifratura a blocchi EBC, CBC, chiavi hardcoded.

M6. Insecure Authorization​

Avviene quando non è implementata o è implementata in modo scorretto la verifica dei permessi di un utente che sta tentando di eseguire un’azione. Nel momento in cui l’applicazione o il back-end non verifica che l’utente abbia i permessi necessari per portare a termine tale azione si ha un’insicure auth (IDOR, endpoints nascosti, trasmissione del ruolo dell’utente attraverso token o parametri al back-end).

M7. Client Code Quality​

Riguarda la non sanificazione degli input che interagiscono con il codice dell’app. Si parla di errori di programmazione che portano a buffer overflows, format string vulnerability (SQLi), XSS attraverso le WebView, utilizzo scorretto di librerie esterne, utilizzo insicuro di librerie esterne. Riguarda esclusivamente il codice in esecuzione sul dispositivo.

M8. Code Tampering

Riguarda l’alterazione delle funzionalità dell’app attraverso tools di instrumentations (Frida. objection, etc). Tutte le app sono “vulnerabili” al code tampering, gli sviluppatori dovrebbero implementare sistemi di prevenzione di manomissione del codice. Solitamente si segnala la mancanza di questi sistemi di protezione e prevenzione.

M9. Reverse Engineering

Riguarda la presenza di simboli di debug, codice non offuscato e tutto ciò che agevola il reverse engineering.

M10. Extraneous Functionality

Presenza di backdoors, funzionalità di test/collaudo che non dovrebbero essere presenti in produzione, commenti che rivelano informazioni sensibili etc.

Riferimenti: https://owasp.org/www-project-mobile-top-10/

Tipologia di APP

App Native

Android dispone di una SDK e le app native di android sono quelle sviluppate in Java o Kotlin. È disponibile anche la NDK che, attraverso JNI (Java Native Interface) permette di integrare porzioni di app scritte in C/C++.

Pro: Velocità/Reattività, accesso all’hardware, notifiche push, funzionamento offline.

Contro: Non è multipiattaforma

Web App

Sono progettate per sembrare native ma di fatto si appoggiano al browser web. Sono sviluppate in HTML5 e hanno un’icona che non è altro che un bookmark che apre il browser.

Pro: Multipiattaforma, tempi di sviluppo più brevi, non passano dal playstore.

Contro: Non hanno accesso all’hardware, no notifiche push.

App Ibride

Si eseguono alla stessa maniera delle app native ma la maggior parte dei processi fa affidamento al browser. Le app Ibride sono quelle realizzate con Cordova, Ionic, React Native etc.

Pro: Multipiattaforma, hanno accesso all’hardware del device, notifiche push, costi e tempi di sviluppo.

Contro: Performance inferiori, stabilità.

Android Security Architecture

L’architettura di Android si basa su kernel Linux e può essere idealmente suddivisa in 5 diversi layer:

Alla base dell’architettura c’è il kernel Linux che contiene tutti i drivers e fornisce accesso all’hardware. Sopra al kernel c’è l’HAL, un’interfaccia standard che permette agli sviluppatori di far comunicare il software con l’hardware. Poi c’è il layer che contiene tutte le librerie native di C/C++ (es. libc di linux, che però su android si chiama bionic). Le librerie degne di nota sono le seguenti:

• Surface manager: Gestisce le finestre e le schermate.
• Media Framework: Permette l’utilizzo dei codecs per la riproduzione e la registrazione audio/video.
• SQLite: Database.
• WebKit: Browser engine.
• OpenGL: Scritte in C e C++ servono per renderizzare a schermo contenuti 2D e 3D.

Sullo stesso layer delle librerie native si trovano i componenti della runtime di Android. Fino alla versione 4.4 di Android era presente esclusivamente la Dalvik Virtual Machine (DVM) che nelle versioni attuali di Android (dalla 5.0 “Lollipop”) è stata sostituita da Android RunTime (ART).

La differenza sostanziale tra le 2 runtime è che la prima utilizza un tipo di compilazione Just-In-Time (JIT), al momento dell’esecuzione dell’app e la seconda Ahead-of-time (AOT), durante l’installazione.

Il Layer Java Api Framework espone delle classi per gestire dei servizi ad alto livello come le activities, content providers etc.

• Activity Manager: Gestisce il ciclo di vita dell’app.
• Activities: schermate dell’app.
• Content Provider: Permette lo scambio di dati tra le applicazioni. I dati possono essere salvati nel filesystem, in database SQLite, sul web etc e tramite il content provider, altre app possono accedere o modificare tali dati.
• Resource Manager: Fornisce accesso a tutto ciò che non è codice come stringhe, impostazioni colori, layout interfacce etc.
• Notification Manager: Permette all’app di mostrare le notifiche.
• View System: Insieme di viste utilizzate per creare la UI.
• Package Manager: Il servizio con cui le app sono in grado di ottenere info sulle altre app installate sul dispositivo.
• Telephony Manager: Fornisce info in merito ai servizi di chiamata, sms e simili.
• Location Manager: Fornisce accesso ai servizi di localizzazione.

In cima a tutti i layer si trovano le applicazioni installate sul device.

APP Sandbox

L’esecuzione di ogni applicazione Android avviene nella propria sandbox, ciascun’ applicazione è isolata dalle altre e da tutti gli altri processi facendo leva sul sistema ormai collaudato dei permessi multiutente di Linux (DAC). Praticamente Android assegna un UID unico ad ogni applicazione che poi verrà eseguita nel contesto di quell user ID / group ID.

Dal momento che la sandbox è gestita dal kernel attraverso i permessi di linux, è importante notare come tutto ciò che sta sopra, tutte le librerie incluse dall’applicazione, api e framework, ereditano i permessi concessi all’app.

Ad ogni modo Android nel corso del tempo ha implementato ulteriori protezioni oltre a DAC, ha introdotto SELinux, ha limitato l’accesso alle app ad alcune chiamate di sistema, ha limitato l’accesso al filesystem etc.