Intercettazione del traffico di app Android con Burp

5

Sto cercando di capire cosa fanno le app Burp e Android quando il traffico è https. Ho non installato la Burp CA sul telefono.

  1. Alcune app si rifiutano completamente di funzionare. Visualizzano un messaggio di errore o pensano che il telefono non sia online. È a causa di Pinning SSL?

  2. Alcune app funzionano normalmente ma Burp non acquisisce alcun pacchetto. Come sta succedendo? Senza rutti CA come possono comunicare telefono e server? Burp sta solo inoltrando il traffico?

  3. Alcune app funzionano normalmente ma Burp intercetta solo i pacchetti per alcune operazioni. Le operazioni intercettate utilizzano probabilmente gestori di trust vuoti o qualcosa del genere, ma come è il resto del codice che comunica con il server?

posta mk_ 10.03.2017 - 09:31
fonte

2 risposte

4

La prima cosa da ricordare è che Burp è un proxy HTTP (S). Non fa nulla su qualsiasi dato che non sia HTTP (S) (OK, eccetto i websocket). Le app Android, d'altra parte, possono utilizzare qualsiasi protocollo che desiderano. Molti usano HTTP (S), solo perché si addice al tipo di dati che stanno inviando, ma in realtà non è necessario.

Se un'app non utilizza HTTP (S), tale traffico non verrà visualizzato in Burp. L'esempio più ovvio di questo è il traffico DNS: non vedrai alcuna richiesta di ricerca DNS visualizzata anche se utilizzi un browser tramite Burp.

  1. App che si rifiutano completamente di funzionare. Potrebbero usare il pinning del certificato - due opzioni qui, però. Primo tipo, stanno cercando un certificato valido per il sito di destinazione da installare sul dispositivo. In questo caso, l'installazione del certificato CA Burp potrebbe farli funzionare nuovamente. Secondo tipo, utilizzano un blocco personalizzato, che richiede un certificato specifico fornito dal server o un certificato firmato da una voce specifica nella catena di affidabilità. Questi non saranno ingannati dal certificato CA Burp.
  2. App che funzionano senza pacchetti catturati. Probabilmente non stanno usando HTTP (S). Potrebbe trattarsi di client SSH, servizi di messaggistica come Whatsapp o giochi, in cui la perdita di un pacchetto è meno importante della maggior parte dei pacchetti che arrivano rapidamente, il che sarebbe più adatto a una connessione di rete basata su UDP rispetto a uno basato su TCP come HTTP. Potrebbero inoltre ignorare qualsiasi impostazione proxy presente, specialmente se stai solo intercettando utilizzando un'app proxy HTTP. Per visualizzare questi dati, avrai bisogno di uno strumento come Wireshark, che può gestire altri tipi di dati, e una scheda wifi che supporta la modalità monitor.
  3. App che mostrano solo traffico. Se il traffico che vedi sono pacchetti di statistiche o pubblicità, probabilmente rientrano nella classe 2 sopra - la maggior parte dei sistemi di statistiche sembra utilizzare HTTP (S) perché è relativamente facile da implementare in qualsiasi cosa e generalmente devi avere una specie di HTTP connessione aperta per scaricare comunque gli annunci.
  4. App che non si connettono effettivamente. Ci sono alcune applicazioni che sembrano dovrebbero essere connesse a Internet, ma in realtà non lo fanno, o lo fanno solo su base irregolare. Questi possono includere app per l'orario, alcuni giochi (dove i punteggi più alti vengono aggiornati quotidianamente, per esempio) o qualsiasi cosa in cui è possibile archiviare i dati localmente per la maggior parte (le applicazioni di mappatura possono memorizzare localmente l'area "normale" e fare chiamate per recensioni di attrazioni o luoghi più lontani). In questo caso, potresti non averli visti provare a connettersi mentre stavi guardando.

Suggerirei di guardare il traffico con Wireshark, se possibile, e vedere quali protocolli vengono utilizzati, quindi scovarne di interessanti usando un software appropriato, tenendo presente che alcuni sono intenzionalmente difficili da ispezionare - pacchetti crittografati da Whatsapp dovrebbe essere illeggibile, altrimenti hanno qualcosa di gravemente sbagliato!

    
risposta data 10.04.2017 - 15:54
fonte
2

Ho riscontrato un problema simile durante il pentesting di un'applicazione per iPhone. L'applicazione non utilizzava le librerie native e non supportava il proxy http. Per "risolvere" questo problema, ho inoltrato tutto il traffico in modo trasparente al proxy Burp. Vedi Come acquisisci TUTTO il traffico da un'app Android? per la descrizione di questa configurazione.

Alcune applicazioni utilizzano il blocco dei certificati. Alcune applicazioni imposteranno il primo certificato che vede, altre applicazioni lo hanno codificato nell'applicazione. Nel primo caso, devi solo assicurarti che il traffico attraversi il tuo proxy quando lo esegui per la prima volta.

Credo che vedrete un avviso nella scheda di avviso Burps se il client si disconnette prematuramente (rifiuta il certificato).

Nel secondo caso, è un po 'più difficile in quanto dovrai modificare il file binario stesso.

Non ho provato a sovvertire il blocco dei certificati da un'applicazione Android, ma questo link sembra un buon approccio.

    
risposta data 10.03.2017 - 17:30
fonte

Leggi altre domande sui tag