Decifrare SSL su una rete mobile

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à.

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).

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 ...