Gli attacchi di "uomo nel mezzo" sono estremamente rari?

La mia risorsa attuale preferita per dati freddi, duri, reali è Rapporto Verizon 2011 Breach Investigations Report . Un estratto dalla pagina 69 del rapporto:

Actions

The top three threat action categories were Hacking, Malware, and Social. The most common types of hacking actions used were the use of stolen login credentials, exploiting backdoors, and man-in-the-middle attacks.

Dalla lettura di ciò, deduco che si tratta di un'azione secondaria utilizzata una volta che qualcuno ha un punto d'appoggio nel sistema, ma i dati dell'Unità criminale olandese High Tech dicono che è abbastanza credibile da preoccuparsi. Delle 32 violazioni dei dati che hanno costituito le loro statistiche, 15 hanno coinvolto azioni MITM.

Sicuramente non fermarti qui, però. L'intero rapporto è una miniera d'oro di lettura e il miglior lavoro che ho trovato per dimostrare le reali minacce.

Per riferimenti più confusi agli attacchi e ai metodi MiTM, vedi anche questa eccellente risposta agli attacchi MITM - quanto sono probabili? su Serverfault.

Vorrei andare oltre nel dire che ogni istanza di una radice SSL che tossisce un cert cattivo è un segno di un attacco, altrimenti sarebbero dei compromessi piuttosto inutili. Infine, dato che sono quel ragazzo , sicuramente proverei a unire la tua casella di rete all'esterno dell'edificio se stessi facendo il tuo pentimento. Si può fare cose incredibili con una radio software anche su una connessione cablata.

Questa risposta riguarda principalmente la dichiarazione di Chris Dixon più che la risposta a "Quanti attacchi provengono dal MiTM".

Se affermiamo il diverso modo in cui si potrebbe diventare MiTM e le conseguenze date, penso che possiamo trarre alcune conclusioni sul fatto se ci interessino o meno gli attacchi MiTM prevalenti.

Se consideriamo alcuni rischi per le diverse situazioni, potremmo avere qualcosa come:

• Qualcuno ruba il database sfruttando l'applicazione web stessa?
• Qualcuno che attacca utente / amministratore tramite attacco MiTM

Direi che il primo ha un impatto molto più grande (generalmente) e dovrebbe in molti modi essere mitigato di più e trattato il primo.

Quindi, per il punto 2 prevalere sul punto 1, penso che il MiTM debba essere davvero pazzo per noi per attribuirlo a un ostacolo di sicurezza come il punto 1 (come dice Chris nella citazione)!

Ora se vediamo i diversi vettori di attacco. Primo per MiTM. Per diventare MiTM si potrebbe ad esempio:

• Possedere un access point wireless canaglia. Questo è banale, ma per un attacco mirato dovresti trovarti nella stessa posizione fisica della vittima usando la tua webapp.
• Annota dati o dati wireless non crittografati provenienti da un HUB (esistono persino più?)
• Usa l'avvelenamento ARP per attaccare gli utenti. Non banale, a meno che tu non sia sulla stessa rete degli utenti target che utilizzano la tua webapp.
• Avvelenamento da cache DNS. Per far funzionare questo è necessario avvelenare il DNS utilizzato dagli utenti target. Se il DNS non è configurato correttamente, questo attacco diventa in qualche modo banale da eseguire, tuttavia c'è molto da fare perché questo funzioni.
• Attacchi di phishing. Questi ancora ingannano gli utenti ignari e ingenui, tuttavia molta responsabilità ricade sull'utente.

Tutto questo per attaccare solo uno o un piccolo sottoinsieme di utenti. Anche in questo caso, attaccare questi utenti darà loro un avvertimento nei loro browser (ci sono modi per attaccare anche questo, ma non lo sopporto qui). Solo compromettendo una CA radice o individuando un difetto nell'algoritmo utilizzato per generare i certificati, ti sarà permesso di porsi come emittente di certificati attendibili.

Se d'altra parte guardiamo tutte le cose potenzialmente brutte che possiamo vedere se non investiamo abbastanza sicurezza nella webapp stessa vediamo i vettori di attacco come:

• SQL Injection - banale e facile da sfruttare e scoprire. Impatto sui danni molto elevato.
• XSS (Cross Site Scripting) - facile da scoprire, più difficile da sfruttare. Penso che vedremo un impatto sempre maggiore degli utenti da questo in futuro. Prevedo che stia diventando la tendenza "new SQL Injection" che abbiamo visto in quei giorni.
• CSRF (Cross Site Request Forgery) - Moderato da scoprire, moderato da sfruttare. Ciò richiederebbe agli utenti di navigare verso un sito già di proprietà, attivando una richiesta per la tua webapp che effettuerebbe una transazione per conto dell'utente.

Quindi, menzionando solo questi pochi, ma popolari metodi per attaccare webapp e diventare MiTM, lascerei il caso a un'analisi di rischio / conseguenza specifica dell'organizzazione specifica che stai cercando di proteggere, indipendentemente dal fatto che dovresti o meno difendere il tuo gli utenti direttamente implementando SSL o difendendo la webapp nel suo complesso (che include anche proprietà intellettuale, dati dell'utente, dati sensibili, dati potenziali che potrebbero violare altre applicazioni e così via).

Quindi, a mio modesto parere, sono assolutamente d'accordo con la dichiarazione di Chris Dixon. Stabilisci la priorità di proteggere la webapp il più possibile prima di iniziare a pensare di proteggere il livello di trasporto.

Modifica : Una nota a margine: Pagine come Facebook, Gmail e altri erano sotto pesanti attacchi MiTM durante la scia di Firesheep. Questo potrebbe essere mitigato solo tramite SSL e consapevolezza.

Tuttavia, se ci pensate, sniffare il traffico wireless con Firesheep e dirottare le sessioni richiederebbe la LAN wireless a cui siete connessi per non avere alcuna crittografia.

Quando guido oggi la guida di guerra ha ridotto drasticamente il numero di AP wireless aperti e anche il numero di AP AP abilitati al WEP. Continuiamo a vedere sempre più AP AP crittografati, che nella maggior parte dei casi ci forniscono abbastanza sicurezza.

Ora, qual è il rischio che qualcuno crei uno strumento facile e conveniente per sniffare e dirottare le sessioni degli utenti? Qual è l'impatto per quegli utenti? Potrebbe anche essere mitigato in diversi modi (re-autenticare l'utente quando proviene da impronte diverse allo stesso tempo, notificando l'utente quando qualcosa sembra sbagliato (gmail ne è un buon esempio)).