Decifrare SSL su una rete mobile

1

Lavoro per una grande azienda e stiamo cercando di valutare la sicurezza di alcune informazioni proprietarie che vengono inviate e ricevute in una nuova applicazione che stiamo sviluppando.

Dopo i nostri test iniziali ci siamo resi conto che avremmo potuto facilmente fare un attacco MitM con Fiddler tramite WiFi in pochissimo tempo, lasciando un mucchio di informazioni allo scoperto. Da allora l'abbiamo modificato in modo che le informazioni proprietarie della nostra azienda non possano essere inviate tramite WiFi ma solo tramite la rete.

Quindi la domanda è, è possibile per qualcuno decodificare i nostri pacchetti HTTPS sulla rete mobile (probabilmente QXDM)?

Comprensibilmente se ottengono le nostre chiavi private potrebbero farlo con wireshark ma assumeremo che non sarà così.

Se conosci qualche metodologia, vorremmo testarli contro la nostra app.

Modifica: aggiunta di ulteriori informazioni

È un'applicazione Android che invia importanti informazioni aziendali ai e dai nostri server. Non siamo preoccupati per le persone che perdono informazioni personali (qualcun altro che ascolta, ad esempio), semplicemente non vogliamo che le nostre informazioni aziendali vengano decodificate (una situazione in cui un utente finale decrittografa i pacchetti https della nostra applicazione). Siamo stati in grado di decrittografarlo facilmente usando wifi e fiddler (dal momento che sono stati modificati), abbiamo bisogno di sapere che cosa può fare un utente per decifrare i pacchetti che vengono inviati semplicemente attraverso la rete tra la nostra app e il nostro server.

    
posta Nefariis 27.01.2015 - 19:48
fonte

3 risposte

1

Se sei stato in grado di utilizzare MiTM una sessione SSL, significa che l'applicazione non sta verificando che il certificato sia stato rilasciato da un'autorità fidata. Strumenti come Fiddler utilizzano certificati autofirmati, che dovrebbero essere rifiutati da un layer SSL correttamente configurato. Sfortunatamente gli scrittori di applicazioni spesso ignorano la necessità di controllare i certificati e credono ciecamente che SSL li protegga senza capire come funziona SSL.

Ma c'è un altro, più profondo problema. Se stai cercando di proteggere i tuoi dati dall'utente e l'utente ha accesso fisico al dispositivo su cui sono visualizzati i dati, è game over. Non puoi proteggerlo. L'opzione nucleare sarebbe quella di accendere un debugger, scaricare la memoria del dispositivo e setacciarla per qualsiasi informazione proprietaria. Sono sicuro che ci saranno attacchi più sofisticati di quelli che sarebbero più facili, ma è quello più ovvio che mi viene in mente che so che il 100% funzionerebbe.

Ma il punto è che non puoi concedere simultaneamente a un utente l'accesso ai dati e impedirne l'accesso. Se i dati sono di qualsiasi valore per lanciare un attacco anche semi-sofisticato, qualcuno lo farà.

    
risposta data 28.01.2015 - 03:22
fonte
1

Per prima cosa:

Se l'app è soggetta a un mitm tramite Wi-Fi, la modifica del supporto di comunicazione non risolverà il problema. Se il canale di comunicazione è stato l'unica modifica apportata , posso prontamente affermare che sì, la tua app è ancora vulnerabile agli attacchi mitm, l'unica cosa che l'utente malintenzionato ha bisogno è di avere accesso alla rete del corriere (ea giudicare da nel modo in cui scelgono le loro password, non direi che sarebbe difficile da realizzare per un individuo sufficientemente motivato ...).

Uno dei modi in cui è possibile proteggere l'app per smartphone è implementare Blocco dei certificati . OWASP ha una pagina molto estesa sull'argomento e un altro cheat orientato al mobile sull'argomento.

Quindi, non dovresti concentrare i tuoi sforzi su dove i tuoi dati fluiscono attraverso, perché la vulnerabilità non dipende da quello.

Ricorda inoltre che il blocco dei certificati non è una panacea, in quanto non ti proteggerà dagli attacchi mitm che colpiscono il telefono cellulare, ma è efficace contro gli attacchi mitm basati sulla rete.

Modifica

Se dimentichiamo l'intercettazione del proxy per un minuto, parleremo della pura decifrazione SSL e dipende dai possibili attacchi SSL che si applicano al tunnel stabilito. Dovresti controllare la versione TLS (SSL dovrebbe essere vietato) e le crittografie supportate. Ci sono molti attacchi che mirano ai pacchetti SSL per la decodifica del tunnel. Uno di questi è stato scoperto tra qualche mese, il mercato della sicurezza è venuto a conoscenza di POODLE non solo in SSL, ma anche in TLS. I ricercatori hanno persino scoperto che è in grado di sfruttare TLS v1.2 , a seconda dei cifrari utilizzati per stabilire il tunnel crittografato.

Se sei preoccupato per le minacce interne, una preoccupazione cruciale è la chiara archiviazione di testo di informazioni sensibili. Dai file delle preferenze condivisi ai database SQL aperti, questa è una delle principali vulnerabilità mobili al giorno d'oggi. Inoltre, tieni presente che il codice sorgente può essere banalmente invertito, a seconda della piattaforma (ad esempio Android).

    
risposta data 27.01.2015 - 21:33
fonte
0

Devi selezionare con attenzione:

  • Le suite Cipher consentite dal tuo software, alcune sono molto potenti e dovrebbero essere privilegiate, alcune sono meno potenti e dovrebbero essere abilitate solo se c'è qualche problema di compatibilità con il tuo servizio, alcune sono deboli e dovrebbero essere disabilitate a tutti i costi.
  • La versione di SSL / TLS che autorizzi, in realtà dovrei dire la versione di TLS da quando, dopo l'attacco di Poodle, SSL v2 e v3 sono progressivamente disabilitati su base generale.

Il principale tipo di attacco che qualcuno può intraprendere contro una connessione protetta SSL quando si trova in posizione MiTM sarebbe provare a eseguire il downgrade della negoziazione di handshake per forzare gli host a utilizzare una versione di protocollo o suite di crittografia debole, ecco perché è importante disabilitarli esplicitamente.

Inoltre, non so se il tuo caso specifico potrebbe essere aperto a tale minaccia, ma non controllare la minaccia causata dagli utenti finali che cliccano ciecamente sul pulsante "OK" quando viene richiesto un avviso di certificato del server sconosciuto, in In tal caso, "qualcuno" deve solo generare il proprio certificato e decifrare la comunicazione localmente ...

    
risposta data 27.01.2015 - 22:33
fonte

Leggi altre domande sui tag