La mia risorsa attuale preferita per dati freddi, concreti, reali è il rapporto Verizon 2011 sulle indagini sulla violazione dei dati. Un estratto dalla pagina 69 del rapporto:

Azioni

Le prime tre categorie di azioni contro le minacce erano Hacking, Malware e Social. I tipi più comuni di azioni di hacking utilizzati sono stati l'uso di credenziali di accesso rubate, lo sfruttamento di backdoor e gli attacchi man-in-the-middle.

Dalla lettura, deduco che si tratta di un'azione secondaria utilizzata una volta che qualcuno ha un punto d'appoggio nel sistema, ma i dati della Dutch High Tech Crime Unit dicono che è abbastanza credibile per la preoccupazione. Delle 32 violazioni dei dati che componevano le loro statistiche, 15 riguardavano azioni MITM.

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

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

Vorrei andare oltre dicendo che qualsiasi istanza di una radice SSL che sputa un certificato cattivo è un segno di un attacco, altrimenti sarebbero compromessi piuttosto inutili. Infine, poiché sono quel tipo , proverei sicuramente a collegarmi alla tua scatola di rete fuori dall'edificio se stessi facendo il tuo pentest. Si possono fare cose incredibili con una radio software anche su una connessione cablata.

La semplice risposta è no: esiste un'ampia varietà di prove che questo tipo di attacco è comune.

Alcuni dei controlli introdotti dalle banche (autenticazione a due fattori ecc.) erano in parte richiesti per combattere i sempre più comuni attacchi MITM ai clienti.

Sebbene esistano altre forme di attacco (la compromissione del client è buona) che ora possono essere più facili da eseguire attraverso l'uso di malware per posizionare un trojan sul PC client, MITM è ancora relativamente facile nella maggior parte dei casi.

Il fatto principale da ricordare è che i criminali tendono a lavorare su un buon ritorno sull'investimento. Il ROI per un utente malintenzionato è molto buono:

• basso rischio di essere scoperti
• basso rischio fisico
• un certo sforzo nella codifica dell'exploit può portare a guadagno monetario nel mondo reale
• il codice può quindi essere riutilizzato o venduto ad altri criminali

Come ha detto @CanBerk, non riusciremo mai a ottenere alcun "completamente sicuro 'protocolli, ma rendere la vita più difficile ai criminali è una soluzione parziale. Il MITM non andrà via finché non sarà diventato troppo difficile per essere redditizio.

La recente compromissione dell'autorità di certificazione DigiNotar ha portato al rilascio di oltre 500 certificati falsi per google.com, microsoft.com, cia.gov e centinaia di altri siti. Questi certificati in qualche modo si sono fatti strada in 40 diversi ISP iraniani, provocando un massiccio attacco man-in-the-middle , ha confermato di aver colpito oltre 300.000 utenti iraniani nel corso di diversi mesi .

Gli hacker responsabili: ha confermato di essere gli stessi responsabili del precedente attacco a la CA Comodo - afferma di avere pieno accesso ad altre cinque CA, sebbene lui (loro) solo ne abbia nominata una.

Quindi sì, Man -in-the-middle gli attacchi sono una minaccia molto reale , anche oggi.

Nota: per evitare che questo tipo di attacchi si verifichino, considera l'utilizzo di un programma / addon per tenere traccia dei certificati per modifiche sospette, come Certificate Patrol, oppure prova una delle nuove fantasiose sostituzioni per il modello di autorità di certificazione di cui tutti parlano.

Questa risposta riguarda principalmente l'affermazione di Chris Dixon più che rispondere "Quanti attacchi provengono da MiTM".

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

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

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

Direi che il primo ha un impatto molto maggiore (generalmente) e dovrebbe essere mitigato in molti modi al massimo e trattato il primo.

Quindi, affinché il punto 2 prevalga sul punto 1, penso che MiTM dovrebbe davvero essere pazzo per noi per valutarlo come un ostacolo di sicurezza come il punto 1 (come Chris indica 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 non autorizzato. Questo è banale, ma per un attacco mirato dovresti trovarti nella stessa posizione fisica della vittima utilizzando la tua webapp.
• Annusa dati wireless non crittografati o dati provenienti da un HUB (esistono anche 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 della cache DNS. Affinché questo funzioni è necessario avvelenare il DNS utilizzato dagli utenti mirati. Se il DNS non è configurato correttamente, questo attacco diventa in qualche modo banale da eseguire, tuttavia c'è molto su cui fare affidamento affinché funzioni.
• Attacchi di phishing. Questi ingannano ancora gli utenti ignari e ingenui, tuttavia gran parte della 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 avviso nei loro browser (ci sono modi per attaccare anche questo, ma non lo prendo qui). Solo compromettendo una CA radice o trovando un difetto nell'algoritmo utilizzato per generare i certificati ti sarà permesso di presentarti come un emittente di certificati affidabile.

Se invece esaminiamo tutti i potenziali cattivi cose che possiamo vedere se non investiamo in una sicurezza sufficiente della webapp stessa vediamo vettori di attacco come:

• SQL Injection - banale e facile sia da sfruttare che da scoprire. Impatto del danno molto elevato.
• XSS (Cross Site Scripting): facile da scoprire, più difficile da sfruttare. Penso che in futuro ne vedremo un impatto sempre maggiore sugli utenti. Prevedo che questo stia diventando il trend della "nuova SQL Injection" a cui abbiamo assistito in questi giorni.
• CSRF (Cross Site Request Forgery) - Moderato da scoprire, moderato da sfruttare. Ciò richiederebbe agli utenti la navigazione su un sito già di proprietà, attivando una richiesta alla tua webapp che farebbe una transazione per conto dell'utente.

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

Quindi, a mio modesto parere, sono molto d'accordo con l'affermazione di Chris Dixon. Dai la priorità alla protezione della webapp il più possibile prima di iniziare a pensare di proteggere il livello di trasporto.

Modifica : Nota a margine: pagine come Facebook, Gmail e altre erano sottoposte a pesanti attacchi MiTM durante la scia di Firesheep. Questo può essere mitigato solo tramite SSL e consapevolezza.

Tuttavia, se ci pensi, lo sniffing del traffico wireless con Firesheep e il dirottamento delle sessioni richiederebbe che la LAN wireless a cui sei connesso non abbia alcuna crittografia.

Oggi, quando vado alla guida della guerra, è diminuito drasticamente il numero di AP wireless aperti e anche il numero di AP abilitati WEP. Continuiamo a vedere sempre più AP crittografati WPA2 che nella maggior parte dei casi ci forniscono una sicurezza sufficiente.

Qual è il rischio che qualcuno crei uno strumento facile e conveniente per annusare e dirottare le sessioni degli utenti? Qual è l'impatto per questi utenti? Potrebbe anche essere mitigato in diversi modi (ri-autenticare l'utente quando proviene da impronte diverse allo stesso tempo, avvisando l'utente quando qualcosa sembra sbagliato (Gmail è un buon esempio di questo)).

Non ha trovato alcun white paper o statico che includa i dati del mondo reale che volevi avere.

Tuttavia, vorrei aggiungere che gli attacchi MitM all'interno delle aziende avvengono quotidianamente e più di una volta. Diversi fornitori di sicurezza hanno soluzioni per scansionare il traffico crittografato (ad esempio, Palo Alto Networks) e almeno la società per cui lavoro attualmente ha attivato questa funzione.

Per fare ciò, al dispositivo firewall / proxy viene semplicemente concesso un certificato dall'autorità di certificazione (CA) interna che è già considerata attendibile da tutti i client. Quando un'applicazione richiede una connessione sicura, il dispositivo firewall / proxy genera al volo un nuovo certificato per il server di destinazione e lo invia al client. Poiché il client si fida della CA interna, si fida anche del certificato del dispositivo e avvierà felicemente una connessione "sicura".

Sono abbastanza sicuro che lo sniffing delle password su reti wireless sia estremamente comune. Guarda quanti tutorial ci sono sul Web da una semplice Ricerca Google o ricerca Bing.

Sono d'accordo con daramarak sul fatto che sarebbe abbastanza difficile trovare dati del mondo reale sugli attacchi MitM. Uno dei motivi è che gli attacchi MitM sono per natura solitamente mirati a individui, mentre attacchi come DDoS o SQL injection sono solitamente mirati ad aziende, organizzazioni, ecc.

Pertanto, mentre vediamo un DDoS / injection / qualunque sia il rapporto quasi ogni giorno, le informazioni sugli attacchi MitM sono generalmente accademiche (ad esempio "Twitter è stato DDoS'd!" vs. "SSL è vulnerabile a MitM")

Tuttavia, va notato che "raro" non significa necessariamente "difficile". La maggior parte degli attacchi MitM è probabilmente molto più facile da eseguire rispetto alla maggior parte degli altri tipi di attacchi e molti protocolli che utilizziamo ogni giorno sono vulnerabili a tali attacchi in un modo o nell'altro, semplicemente perché è piuttosto difficile ideare un protocollo completamente sicuro contro MitM. Questo è in effetti il ​​caso della maggior parte dei problemi di sicurezza, la maggior parte delle soluzioni è "il massimo sforzo" anziché "completamente e assolutamente sicuro".

Pertanto, penso che il motivo principale per cui gli attacchi MitM sono meno comuni è che di solito non c'è bisogno / incentivo per eseguirne uno.

Beh, immagino che se fossero rari, nessuno comprometterebbe una CA, tuttavia abbiamo visto una serie di tentativi e alcuni successi in questo (sospetti incluso l'Iran).

Quindi presumo che abbia e sarà fatto. Altrimenti, perché dovrebbero preoccuparsi di compromettere una CA? Non è il compito più semplice del mondo. Perché non attaccare direttamente il tuo obiettivo?

Detto questo, potrebbero essere rari. Chiunque comprometta una CA è probabilmente abbastanza bravo da coprire abbastanza delle sue tracce in modo che non conosciamo l'entità del loro lavoro. Sinceramente non metterei oltre il governo degli Stati Uniti per aver fatto la stessa cosa a livello nazionale così come all'estero. Sarei davvero sorpreso se non lo facessero. A sostegno di ciò, non ricordo di aver mai letto che HTTPS sia entrato nel modo dei governi degli Stati Uniti. Lo sento periodicamente in merito alla crittografia Skype, TrueCrypt o crittografia del disco PGP.