Attacco man-in-the-middle per app Android

La mia risposta presuppone che il tuo aggressore sia "abile nell'arte" di fare questo tipo di lavoro.

getting the apk

Ci vorrebbe meno tempo di quanto ti ci sia voluto per scrivere la domanda.

decompiling

Dipende un po 'dalla velocità del computer, ma dovrebbe essere dell'ordine di alcuni minuti.

finding the function to hook

Se esci dal tuo modo di provare a rendere questo non ovvio ... forse un giorno? È un po 'difficile da dire in astratto, poiché dipende molto dalle dimensioni e dalla complessità dell'app, che si tratti di una singola "funzione" o se il lavoro è sostanzialmente più coinvolto, ecc.

Basti dire che chiunque voglia prendersi il tempo sarà in grado di trovare ciò che deve essere cambiato.

compiling

Dipende un po 'dalla velocità del computer e dalla dimensione del codice di base, ma di nuovo dovrebbe essere misurato in pochi minuti.

installing

Ci vorrebbe meno tempo di quanto ti ci sia voluto per scrivere la domanda.

In this scenario how much more security could code obfuscation give?

Qualche anno fa, un ricercatore della sicurezza mi disse che usare la semplice offuscazione di ProGuard rendeva più facile fare questo tipo di attacco.

Ci sono più potenti offuscatori là fuori, incluso il "fratello maggiore" di ProGuard DexGuard. Allo stesso modo, ci sono persone che creano de-obfuscators, strumenti che portano l'offuscamento a livello di DexGuard a qualcosa di più simile a ProGuard. Ad esempio, DexGuard tenta di crittografare il maggior numero possibile della tua app; i de-obfuscator genererebbero un'edizione decifrata del codice.

Quindi, il beneficio degli offuscatori di alto livello varia, in base allo stato attuale della corsa agli armamenti tra gli sviluppatori di obfuscator e gli sviluppatori di de-obfuscator. Non posso dire con certezza dove si trova ora la corsa agli armamenti, figuriamoci quando qualcun altro legge questa risposta da anni a questa parte.

Io paragono gli offuscatori alla vecchia storia di due cacciatori nei boschi inseguiti da un orso. Se tu fossi uno dei cacciatori, non devi correre più veloce dell'orso per fuggire. Devi solo correre più veloce dell'altro cacciatore. Nel caso degli obfuscator, l'obiettivo è rendere poco attraente la tua app, facendo sì che gli attaccanti si spostino su altri bersagli potenzialmente più facili. Il problema con questo approccio è che presuppone che l'attaccante non si preoccupi della tua app in particolare, che la tua app sia solo un bersaglio tra molti. Gli attaccanti che si preoccupano di attaccare la tua app per motivi specifici non si comportano in questo modo e passeranno il tempo a craccarlo. In altre parole, correre più veloce dell'altro cacciatore presuppone che l'orso non sia incazzato con te in particolare.

La possibilità del MITM con un'applicazione Android è nell'ordine indicato.

1. Nessun SSL / TLS

In questo caso è abbastanza semplice eseguire MITM. L'uso di SSL / TLS invece di solo "crittografia" era intenzionale. SSL / TLS non fornisce solo "Riservatezza", ma fornisce anche "Autenticazione". Pertanto, se la comunicazione dell'app non è su HTTPS o su un altro canale SSL, è abbastanza semplice eseguire un MITM a livello di rete e manipolare tutte le richieste e le risposte.

2. Utilizzo dell'archivio credenziali attendibile del dispositivo.

Come i browser, anche i dispositivi Android dispongono di una serie di CA affidabili. Se l'applicazione fa affidamento sull'archivio delle credenziali attendibili del dispositivo per l'autenticazione tramite SSL, [non sto parlando dell'autenticazione della password qui], è ancora vulnerabile al MITM nelle seguenti situazioni: a) una delle CA attendibili nell'elenco delle credenziali del dispositivo il negozio è stato compromesso, b) un avversario è stato in grado di aggiungere un'autorità di certificazione personalizzata all'archivio credenziali del dispositivo, entrambi con una probabilità almeno maggiore di 0.

3. Blocco SSL

Il blocco SSL è un metodo in cui l'applicazione utilizza le credenziali nei dispositivi attendibili memorizza se stesso, ma limita le CA a un sottoinsieme di ciò che è disponibile. Ci sono metodi con i quali questo può anche essere aggirato, probabilmente da un malware. Un esempio è l'uso di moduli Cydia Substrate / Xposed come JustTrustMe per l'esecuzione di test di penetrazione su applicazioni Android che utilizzano il pinning SSL.

4. Utilizzo di un archivio certificati personalizzato

Questo è quando un'applicazione utilizza il proprio archivio certificati in cui tutte le informazioni sono raggruppate nell'APK stesso. In questo caso, l'attaccante, per eseguire un attacco MITM, dovrebbe decompilare o disassemblare l'applicazione, modificare il codice smali per aggiungere il proprio certificato, ricompilare e firmare l'apk e t = far installare la vittima. Sì, è abbastanza difficile.

Se la tua app per Android è scritta in Java (o Kotlin) e non usi un offuscatore, l'attacco è abbastanza semplice. Gli strumenti di offuscamento professionali potrebbero scoraggiare l'hacker, ma se l'obiettivo è sostituire l'output con una stringa predefinita, l'offuscamento del codice non offrirà una protezione effettiva.

Le persone possono persino apportare queste modifiche a livello di piattaforma, perché la tua app utilizzerà l'API di rete di sistema, che è open source su Android.

Dovresti cercare una risposta a livello di protocollo. Se entrambi i server firmano i loro pacchetti e includono una firma del pacchetto in arrivo nella loro risposta, renderanno la sfida di MitM molto più difficile.