Ammetto di non aver mai approfondito in maniera adeguata la sicurezza delle applicazioni Mobile sul blog, sia per poco interesse da parte mio, sia per mancanza di tempo, ma ho deciso di scrivere una mini guida abbastanza approfondita in modo che chiunque possa iniziare a capirne il funzionamento, la metodologia e chissà, magari appassionarsi all’argomento. Per chi non avesse nessun’infarinatura, consiglio Come Funziona un’applicazione Android e Introduzione alla sicurezza di un’applicazione Android, anche se ne potete trovare altri nella categoria Mobile.
Home on Hacktips – Guide di Sicurezza Informatica e Hacking Etico
Ammetto di non aver mai approfondito in maniera adeguata la sicurezza delle applicazioni Mobile sul blog, sia per poco interesse da parte mio, sia per mancanza di tempo, ma ho deciso di scrivere una mini guida abbastanza approfondita in modo che chiunque possa iniziare a capirne il funzionamento, la metodologia e chissà, magari appassionarsi all’argomento.
Per chi non avesse nessun’infarinatura, consiglio Come Funziona un’applicazione Android e Introduzione alla sicurezza di un’applicazione Android, anche se ne potete trovare altri nella categoria Mobile.
Nel seguente articolo utilizzerò un telefono rootato, con al suo interno Xposed con i moduli:
- Inspeckage
- SSLUnpinning
- Rootcloack
L’applicazione in oggetto sarà InsecureBankv2.
NB: se non avete un secondo telefono per fare i test, non fatelo sul vostro principale, in quando il root, se non utilizzato con criterio, riduce di molto la sicurezza del dispositivo e rischia di essere vulnerabile a particolari attacchi. Se volete potete crearne uno virtuale, seguendo questa guida o direttamente quella di Android.
Setup dell’ambiente
Per prima cosa, dobbiamo configurare il telefono in modo tale che possa dialogare con la nostra Kali. Io, utilizzando una macchina virtuale, l’ho connessa in modalità Bridged in modo tale che esponga l’indirizzo IP direttamente sulla rete Wifi.
Dopo aver aperto Burp, imposto il proxy sull’indirizzo IP della rete
Sul telefono, basterà andare in Impostazioni -> Wifi, tener premuto sul Wifi a cui siamo connessi (dipende dalla versione che avete) e cliccare su Modifica. All’interno del menu, impostate il proxy Manuale, inserendo l’indirizzo IP di Burp
Una volta impostato, basterà importare il certificato di Burp seguendo questa guida di PortSwigger.
Per installare l’applicazione utilizzerò per comodità adb, quindi dopo aver collegato il telefono con il suo cavo alla macchina virtuale, e digitato
Avremo la nostra applicazione installata. Avviate sulla Kali AndroServer (il server dell’applicazione) con il comando
python app.py
E voilà, avremo il nostro ambiente pronto per essere testato!
Analisi statica
L’analisi statica, come si evince dal nome, è la fase in cui si analizza il file apk, sia manualmente, sia con tool automatici, al fine di poter trovare vulnerabilità o misconfigurazioni.
Per prima caso andremo ad analizzare il file con MobSF, il quale permette di farsi un’idea iniziale e iniziare a comprendere l’applicazione.
Le informazioni che possiamo ottenere sono:
- l’analisi del manifesto (AndroidManifest.xml) dove sono esplicitamente segnalate le attività che il file esegue
Che possiamo anche trovare in basso
- L’analisi del codice, che in questo caso non è disponibile
- L’analisi del file
- Le stringhe trovate, come ad esempio
Con applicazioni vere solitamente trova molte informazioni e permette di farsi un’idea generale. In questo caso, oltre alle attività, non ha trovato nulla di rilevante.
Altri tool per effettuare analisi automatiche sono:
- https://github.com/vincentcox/StaCoAn
- https://github.com/SUPERAndroidAnalyzer/super
- https://github.com/1N3/ReverseAPK
- https://github.com/linkedin/qark
Per capire cosa succede dietro le quinte nell’analisi automatica, passiamo a quella manuale.
Decompilazione APK
Tramite apktool decompilo l’app in modo da averla in una comoda cartella. Il comando utilizzato è
apktool d InsecureBankv2.apk
AndroidManifest.xml contiene la maggior parte dei dettagli di configurazione, incluso il nome del pacchetto, i componenti dell’app, le impostazioni di sicurezza e i permessi. È quello che MobSF analizza e stampa le configurazioni insicure.
Per quanto riguarda le stringhe invece le prende dal file /res/strings.xml
Questo ci fa capire quando sia utile in certi casi fare sempre un passaggio con MobSF, in quanto ci permette di evitare un’analisi manuale (in certi casi).
Ma cosa significa quelli is_admin? Proviamo a capirlo andando a modificarlo e ricompilare l’app.
Compilazione APK
Modifico la stringa inserendo yes
Ricompilo l’applicazione con il comando
apktool b InsecureBankv2
Dove InsecureBankv2 è la cartella contenente tutti i file precedentemente estratti
Con i comandi
keytool -genkey -v -keystore my-release-key.keystore -alias alias_name -keyalg RSA -keysize 2048 -validity 10000
jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore my-release-key.keystore InsecureBankv2.apk alias_name
Andiamo a firmarla nuovamente, altrimenti non potrà essere installata
La installiamo di nuovo con adb
Ed ecco che abbiamo l’applicazione con un nuovo bottone, probabilmente disponibile solo per gli admin
Cliccando dice che è ancora Work In Progress, ma è stato un ottimo esercizio per analizzare, decompilare e ricompilare un file apk.
Analisi statica del codice
Per poter leggere il codice java di un’applicazione è necessario utilizzare il tool jadx-gui, il quale decompilerà l’app in maniera automatica e ci permetterà di leggere e capire tutte le funzioni dell’app. In certi casi il codice è ofuscato e jadx fallisce, ma in questo caso è chiaramente leggibile.
Una volta aperto possiamo sia analizzare file per file il codice alla ricerca di funzioni particolari, sia cercare stringhe come “password”, “token” e similari, in modo da vedere se è rimasta qualche credenziale hardcodata all’interno del file.
In questo caso abbiamo trovato la chiave AES utilizzata per cifrare.
Andando invece a frugare tra le varie funzioni, troviamo una particolare condizione durante il Login
Il quale dice che se viene inserito il nome utente devadmin, la password viene ignorata.
Bingo! Siamo dentro l’app senza conoscerne le credenziali.
È possibile bypassare il login anche tramite il modulo app.activity.start di Drozer, come ho spiegato in questa guida.
Un altro tool per l’analisi statica molto comodo è Andromeda.
Bypass dei controlli root
Come potete vedere dallo screenshot l’app segnala che il dispositivo non è rootato, anche se in realtà lo è. Potrei spiegare come bypassare il root ma in realtà il 90% delle volte basta avere un modulo come RootCloak o MagiskHide. Nel caso in cui non funzioni, potrebbe essere necessario usare Frida, che inserirò in una prossima guida probabilmente. Se volete approfondire, questo è un ottimo articolo.
Analisi Dinamica
Nella fase di analisi dinamica andremo ad analizzare il comportamento dell’app, cosa salva all’interno del device, quali chiamate fa al server di riferimento, e via discorrendo.
Analisi all’interno del dispositivo
Una volta installata ed aver fatto qualche operazione, i file che utilizza l’app potrebbero trovarsi sia nella memoria esterna (che è una bad practice, perchè potrebbero essere letti e modificati da qualsiasi altra app) sia nella memoria interna, nel path /data/data/nomepacchetto.
Nella cartella databases solitamente si trova il database utilizzato dall’app per salvare le informazioni, mentre in shared_prefs alcune coppie chiavi:valori, utilizzate per il login o token di sessione.
Controlliamo il database per vedere se ci sono informazioni sensibili al suo interno. Per vederlo direttamente sul nostro pc facciamo una copia in una cartella accessibile dall’esterno
cp mydb /storage/emulated/0/Download/
e lo copiamo sulla nostra kali
adb pull /storage/emulated/0/Download/mydb ./mydb
Ora con un software come SQLIte viewer possiamo tranquillamente analizzarlo
Ed ecco altre credenziali hardcodate, con le quali possiamo autenticarci all’applicativo.
Per quanto riguarda la cartella shared_prefs, vediamo che ci potrebbe essere qualche informazione sensibile
Nel nostro caso abbiamo sia il server e la porta utilizzata per connettersi al server, sia delle credenziali che sembrano encodate o cifrate.
Per quanto riguarda lo username, è encodato in base64 e lo abbiamo ricavato. Ma la password sembra cifrata, magari in AES con la chiave trovata prima?
Per scoprirlo, basta tornare sul codice Java, utilizzarne le funzioni che ci servono (in questo caso per pura comodità, in quanto il codice è perfettamente leggibile e possiamo copiarlo, con qualche modifica, per averne una copia funzionante)
Beh, vuota perché siamo autenticati con devadmin che non ha password.
Per capire se funziona, mi loggo nell’app con le credenziali presenti nel database, danesh/Dinesh@123$ .
Ed ecco che abbiamo decifrato delle credenziali grazie all’analisi statica effettuata precedentemente.
Logging
È importante che non vengano loggate informazioni sensibili durante l’utilizzo dell’app. Per verificare ciò, basta aprire logcat greppando solo il nome del pacchetto in analisi, con il comando
adb logcat | grep "$ (adb shell ps | grep | awk '{print $ 2}')"
Come possiamo vedere, in questo caso vengono loggate tutte le informazioni, come password in chiaro o i trasferimenti effettuati.
Debugging con JDWP
Se nel Manifest è attivo il debugging possiamo utilizzarlo per analizzare le funzioni passo passo e potenzialmente bypassare certi controlli. Per debuggare è necessario:
- Aprire l’applicazione da analizzare (e chiudere tutte le altre per semplicità)
- Comando adb jdwp e prendere nota dell’ID stampato (nel mio caso 16432)
- Digitare a db forward tcp:7777 jdwp:16432
- Ed infine jdb -attach localhost:7777 ed ecco che possiamo iniziare a debuggare
Per un approfondimento su questo rimando ad un ottimo articolo di FSecure (descrivere questo processo richiederebbe un altro articolo).
External Storage
Come anticipato, salvare file sulla memoria esterna non è consigliato, in quanto questi file potranno essere poi utilizzati da chiunque, poiché non sono protetti come nel caso dei dati salvati nella memoria interna.
Durante il logging e il contemporaneo utilizzo dell’app vediamo come essa cerchi di aprire un file che si trova nella memoria esterna
Ma nella GUI appare che il file non esiste. Proviamo a crearne uno, inserendo un javascript
Ed ecco che il nostro Javascript è stato eseguito. Ciò significa che l’app è vulnerabile ad un attacco Cross Site Scripting da parte da altre app, in quando tutti possono accedere a quel percorso e modificarne i file.
Per un’analisi dinamica omnicomprensiva io ho sempre utilizzato Inspeckage, il quale permette di “attaccarsi” all’app ed analizzare tutte le chiamare, le funzioni e
Come potete vedere, tante delle informazioni che abbiamo ricavato in maniera manuale, Inspeckage le trova durante l’utilizzo dell’app, in modo che siano già tutte in un’unica interfaccia.
Conclusioni
Ho volutamente evitato la parte di analisi delle API, in quanto sconfinano nella parte delle vulnerabilità Web, ma non dimentichiamoci che oltre a tutto ciò che abbiamo visto nell’articolo, rimane il testing di tutte le chiamate verso il server
che potrebbero essere vulnerabili ai classici attacchi di SQLInjection, XSS, IDOR e via discorrendo.
Come abbiamo visto l’analisi di un’applicazione Android comprende diverse parti, diverse metodologie ed è decisamente più complessa di una normale applicazione web. L’apk utilizzato come esempio ha altre vulnerabilità che ho deciso di non introdurre, ma se volete potete trovare altri esempi a questo indirizzo.
Dopo aver scritto questo articolo ho scoperto l’esistenza di un’altra applicazione vulnerabile, che vi consiglio se volete fare altra pratica.
Risorse utili
- https://appsecwiki.com/#/mobilesecurity
- https://manifestsecurity.com/android-application-security/
- https://github.com/OWASP/owasp-mstg/tree/master/Document
- https://www.evilsocket.net/2017/04/27/Android-Applications-Reversing-101/
- https://conference.hitb.org/hitbsecconf2018ams/materials/D1T1%20-%20Federico%20Dotta%20and%20Piergiovanni%20Cipolloni%20-%20Brida%20When%20Burp%20Suite%20Meets%20Frida.pdf
- https://mobile-security.gitbook.io/mobile-security-testing-guide/
- https://god.owasp.de/archive/2018/slides/2018-god-holguera.pdf
Hits: 295
L’articolo Penetration Test di un’Applicazione Mobile – Android proviene da HackTips.
Durante un Penetration Test è possibile che capiti un applicativo che, invece del classico protocollo HTTP, cambi protocollo e inizi a comunicare tramite WebSocket. Questo può capitare per vari motivi, sia per questione di efficenza, poiché è una connessione full-duplex, sia per questione di velocità, in quanto in certi casi serve una conversazione real time e quest’ultime sono particolarmente adatte.
Ma questo non implica che non possano essere affette da vulnerabilità e le richieste non debbano essere sanitizzate tanto quanto delle normali richieste HTTP. Nel seguente articolo andremo ad analizzare le possibili vulnerabilità inerenti al protocollo Websocket.
Funzionamento
Citando Wikipedia, WebSocket è un protocollo di comunicazione per computer, che fornisce canali di comunicazione full-duplex su una singola connessione TCP. Sia HTTP che WebSocket si trovano al livello 7 del modello OSI e funzionano entrambi sulla porta 80 e 443.
Il protocollo WebSocket consente l’interazione tra un browser web (o altra applicazione client) e un server web con un overhead inferiore rispetto ad alternative half-duplex come il polling HTTP, facilitando il trasferimento dati in tempo reale da e verso il server.
Quando una richiesta HTTP necessità di passare al protocollo WebSocket, il server risponde con il codice 101 (Switching Protocols) ed inizia ad effettuare la conversazione con il nuovo protocollo.
Oltre all’Header Upgrade, il client invia un Header Sec-WebSocket-Key contenente byte randomici codificati in base64 e il server risponde con un hash della chiave nell’intestazione Sec-WebSocket-Accept. In questo modo viene impedito alla di inviare nuovamente una precedente conversazione WebSocket, ma non fornisce alcuna autenticazione, privacy o integrità.
La funzione di hashing aggiunge poi la stringa fissa 258EAFA5-E914-47DA-95CA-C5AB0DC85B11 (un GUID) al valore dell’intestazione Sec-WebSocket-Key (che non è decodificato da base64), applica la funzione di hashing SHA-1 e codifica il risultato usando base64 (fonte Wikipedia ).
Per chi volesse approfondire il protocollo consiglio l’RFC 7977.
Vulnerabilità
Nella pagina OWASP sono elencate diverse vulnerabilità a cui può essere soggetta una conversazione WebSocket, vediamone alcune.
Confidenzialità e integrità
Poiché il protocollo permette una conversazione sia sulla porta 80 (tramite ws://) sia sulla 443 (tramite wss://), è indubbio che se fossimo nel primo caso tutte le conversazioni potrebbero essere sniffate in chiaro, permettendo ad un attaccante esterno di visualizzare qualsiasi dato sensibile passante per esse e di effettuare un attacco MITM.
Origin
Nella richiesta di “Switching Protocol” è presente anche l’Header Origin. Se il server non validasse quest’ultimo, potrebbe di conseguenza accettare connessioni da ogni Origine e sfociare in attacchi CSRF, con conseguenze decisamente critiche.
Sanitizzazione
Sebbene sia un protocollo diverso da HTTP, WebSocket presenta alla fin fine molte vulnerabilità simili, in quanto esegue una comunicazione client-server ed interagisce con lo stesso, anche se in maniera diversa. Di seguito una lista non esaustiva, con alcuni passi specifici per poter fuzzare le richieste.
Per fare gli esempi utilizzerò DVWS, che consiglio caldamente nel caso vogliate imparare tramite un laboratorio.
Una volta inizializzato il server di DVWS (ho utilizzato lo stack XAMPP, nel caso vogliate replicare), ci troveremo davanti a diverse pagine, ciascuna contenente una vulnerabilità specifica.
Per visualizzare il traffico WebSocket, ci sono due modalità:
- tramite la console del browser (schiacciando F12) ma non si potrà intercettare il messaggio, solo visualizzarlo;
- con un Proxy, come Burp e ZAP.
Per questi esempi utilizzerò quest’ultimo poiché non ho trovato un fuzzer disponibile per Burp, mentre sembra che ZAP intercetti e fuzzi WebSocket in maniera egregia.
Il canale (#1) si riferisce ad ogni sessione WebSocket aperta, mentre le richieste sono numerate dopo il punto (.142,.143, etc.)
Bruteforce
In questo primo esempio, vediamo un interfaccia di login. Analizzando la richiesta, si può notare che le credenziali vengono encodate in base64 e successivamente inviate al server. Poiché ZAP permette di fuzzare le richieste, possiamo effettuare un attacco bruteforce al server.
Per farlo, basta inviare la richiesta al Repeater (testo destro su di essa -> “Open/Resend with Message Editor”), e nel Message Editor basterà selezionare la stringa da fuzzare, aggiungere il payload e definire il processor, in modo che ogni payload verrà poi codificato in base64.
Visto che l’applicativo è avviato direttamente sul mio computer, ho diminuito la velocità del fuzzer per fare in modo che richiesta e risposta si vedessero in maniera sequenziale nei log.
Command Injection
Visto che le modalità di intercettazione/fuzzing ora dovrebbero essere chiare, vediamo la seconda vulnerabilità. Ora l’applicazione ci permesse di effettuare un comando ping direttamente dal browser, ma come ben sappiamo, nel caso in cui l’applicativo non sanitizzi l’input dell’utente ci potrebbe essere la possibilità di eseguire comandi sul server. Provo quindi ad inserire ‘127.0.0.1;cat /etc/passwd’
Cross Site Request Forgery
Nell’applicazione possiamo vedere che manca un token anti-csrf nella risposta e che non controlla l’origin quando il server fa l’Upgrade del protocollo.
La scrittura di una PoC è molto simile ad una normale PoC nel protocollo HTTP. Per fare più veloce, prenderò il codice da una normale richiesta websocket, dal sito WebSocket.org e modificherò le parti che mi interessano
<title>WebSocket Test</title> <script language="javascript" type="text/javascript"> var wsUri = "ws://dvws.local:8080/change-password"; #URL DVWS var output; function init() { output = document.getElementById("output"); testWebSocket(); } function testWebSocket() { websocket = new WebSocket(wsUri); websocket.onopen = function(evt) { onOpen(evt) }; websocket.onclose = function(evt) { onClose(evt) }; websocket.onmessage = function(evt) { onMessage(evt) }; websocket.onerror = function(evt) { onError(evt) }; } function onOpen(evt) { writeToScreen("CONNECTED"); doSend("{\"npass\":\"nuovapassword\",\"cpass\":\"nuovapassword\"}"); #PAYLOAD per il cambio della password } function onClose(evt) { writeToScreen("DISCONNECTED"); } function onMessage(evt) { writeToScreen('<span style="color: blue;">RESPONSE: ' + evt.data+'</span>'); websocket.close(); } function onError(evt) { writeToScreen('<span style="color: red;">ERROR:</span> ' + evt.data); } function doSend(message) { writeToScreen("SENT: " + message); websocket.send(message); } function writeToScreen(message) { var pre = document.createElement("p"); pre.style.wordWrap = "break-word"; pre.innerHTML = message; output.appendChild(pre); } window.addEventListener("load", init, false); </script> <h2>WebSocket Test</h2> <div id="output"></div>Una volta modificato, lo apro con un normale browser e come si può notare dai log, la richiesta avviene senza nessun controllo server side.
SQL Injection
Anche in questo caso, se il server non sanitizza l’input dell’utente, e quest’ultimo, nel caso integisca con il Database, potrebbe esser vulnerabile ad una SQL Injection. Inserendo un solo apice nella password, osserviamo che il server risponde con un errore SQL.
Vista la semplicità della vulnerabilità RCE, suppongo che anche questa sia molto semplice. Senza testare manualmente, provo con sqlmap (che con mio grande stupore supporta il protocollo ws!). Il comando lanciato è il seguente
sqlmap --url "ws://dvws.local:8080/authenticate-user" --data='{"auth_user":"YWRtaW4=","auth_pass":"1*"}' --tamper base64encodedove in:
- data: inserisco i parametri della richiesta con l’asterisco dove voglio che fuzzino
- tamper: in modo che encodi in bas64 il payload e poi lo invii al server.
Dopo pochi secondi sqlmap identifica la vulnerabilità e stampa il tipo di database.
Conclusioni
Come avrete visto, se durante un Penetration Test vi capitano sotto mano delle web socket, i controlli da effettuare sono molto simili al protocollo HTTP. Nel caso non siate ancora sicuri sul testing, l’applicativo Damn Vulnerable Web Socket contiene altre sfide da portare a termine, che consiglio vivamente.
Alcune fonti che ho trovato utili durante lo studio del protocollo sono:
- SANS – WebSockets
- PacketStorm – WebSocket in Penetration Testing
- WebSocket Pentesting
Hits: 1298
L’articolo WebSocket Penetration Test proviene da HackTips.
Hacking: Viruses and Malware, Hacking an Email Address and Facebook page, and more! Cyber Security Playground Guide – 3rd Edition (Penetration Testing, … Computer Hacking) (English Edition)
Welcome to your Cyber-Security Playground Guide
– Now in Third Edition!
Free bonus inside! (Right After Conclusion)
Get limited time offer, Get your BONUS right NOW!
Would you like to acquire an impressive online skill such as writing a VIRUS?
Have you always wanted to understand how people get your information?
Are you interested in increasing your personal security online or your hacking toolkit?
If you can say ‘yes’ to any one of these quest
Solo per oggi su Amazon:
Il manuale dell’hacker di automobili: Guida per il penetration tester
Il manuale dell’hacker di automobili vi darà una comprensione più approfondita dei sistemi informatici e del software incorporato nei veicoli moderni. Inizia esaminando
le vulnerabilità e fornendo spiegazioni dettagliate delle comunicazioni sul bus CAN e fra dispositivi e sistemi.
Una volta visto il funzionamento della rete di comunicazione di un veicolo, imparerete a intercettare dati e a mettere in atto hack specifici per monitorare i veicoli, sbloccare le portiere, far perder
Prezzo di listino: EUR 20,99
Solo per oggi su Amazon: EUR 20,99
- 1
- 2