it-swarm.dev

Gli attacchi "man in the middle" sono estremamente rari?

In "Alcune riflessioni sulla polemica dell'elenco dei contatti di iPhone e sulla sicurezza delle app" , blog cdixon

Chris Dixon rilascia una dichiarazione sulla sicurezza del web

Molti commentatori hanno suggerito che un rischio per la sicurezza principale è rappresentato dal fatto che i dati sono trasmessi in testo semplice. La crittografia tramite cavo è sempre una buona idea, ma in realtà gli attacchi "man-in-the-middle" sono estremamente rari. Mi preoccuperei principalmente del casi molto più comuni di 1) qualcuno (insider o outsider) che ruba nel database dell'azienda, 2) una citazione del governo per il database dell'azienda. La migliore protezione contro questi rischi è la crittografia dei dati in modo tale che gli hacker e la società stessa non possano decodificarli (o non inviare i dati ai server in primo luogo).

Mi chiedo se ci siano dati freddi, duri, reali a sostegno di tale affermazione - sono attacchi "man in the middle" realmente rari in il mondo reale, basato sui dati raccolti da intrusioni o incidenti di sicurezza reali?

135
Jeff Atwood

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

Azioni

Le tre principali categorie di azioni di minaccia erano Hacking, Malware e Social. I tipi più comuni di azioni di pirateria informatica utilizzate erano l'uso di credenziali di accesso rubate, lo sfruttamento di backdoor e gli attacchi man-in-the-middle.

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à di crimine high tech olandese dicono che è abbastanza credibile per preoccupazione. Delle 32 violazioni dei dati che hanno costituito le loro statistiche, 15 riguardavano azioni del MITM.

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

Per riferimenti fuzzier agli attacchi e ai metodi MiTM, vedere anche questa eccellente risposta agli attacchi MITM - con quale probabilità sono? Su Serverfault.

Vorrei andare oltre dicendo che qualsiasi istanza di una radice SSL che tossisce una cattiva certezza è un segno di un attacco, altrimenti sarebbero compromessi piuttosto inutili. Infine, dato che sono quel ragazzo, proverei sicuramente a collegarmi alla tua scatola di rete all'esterno dell'edificio se stavo facendo il tuo pentest. Si può fare cose straordinarie con una radio software anche su una connessione cablata.

103
Jeff Ferland

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

Alcuni dei controlli introdotti dalle banche (autenticazione a due fattori, ecc.) Erano in parte necessari per combattere gli attacchi MITM sempre più comuni ai clienti.

Mentre ci sono altre forme di attacco (il compromesso del client è buono) che ora può essere più facile 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 fondamentale da ricordare è che i criminali tendono a lavorare su un buon ritorno sugli investimenti. Il ROI per un attaccante è molto buono:

  • basso rischio di essere scoperti
  • basso rischio fisico
  • qualche sforzo nel codificare l'exploit può portare al guadagno monetario nel mondo reale
  • il codice può quindi essere riutilizzato o venduto ad altri criminali

Come ha detto @CanBerk, non avremo mai protocolli "completamente sicuri", ma rendere la vita più difficile ai criminali è una soluzione parziale. Il MITM non andrà via finché non sarà reso troppo difficile per essere redditizio.

29
Rory Alsop

compromesso recente dell'autorità di certificazione DigiNotar ha provocato emissione di oltre 500 certificati falsi per google.com, Microsoft.com, cia.gov e centinaia di altri siti. Questi certificati si sono in qualche modo fatti strada in 40 diversi ISP iraniani, provocando un massiccio attacco man-in-the-middle , confermato per avere ha interessato oltre 300.000 utenti iraniani nel corso di diversi mesi.

L'hacker responsabile/i responsabile - confermato di essere lo stesso responsabile responsabile del attacco precedente al CA Comodo - afferma di avere pieno accesso ad altre cinque CA, sebbene lui (loro) solo ne abbia nominato uno .

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


Nota: per evitare che questo tipo di attacchi si verifichi, considera l'utilizzo di un programma/componente aggiuntivo per tenere traccia dei certificati per modifiche sospette, come Pattuglia certificato , oppure prova uno dei nuove fantasiose sostituzioni per il modello dell'autorità di certificazione di cui tutti parlano.

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

Se affermiamo il modo diverso in cui uno potrebbe diventare MiTM e le conseguenze date, penso che possiamo trarre alcune conclusioni sull'opportunità o meno di quanto siano prevalenti gli attacchi MiTM.

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

  • 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 (in generale) e dovrebbe in molti modi essere mitigato di più e trattato il primo.

Quindi, per far prevalere il punto 2 sul punto 1, penso che MiTM dovrebbe davvero essere pazzo per noi per valutarlo come un ostacolo alla 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 punto di accesso wireless non autorizzato. Questo è banale, ma per un attacco mirato dovresti trovarti nella stessa posizione fisica della vittima usando la tua webapp.
  • Annusare dati wireless non crittografati o dati provenienti da un HUB (esistono anche più?)
  • Usa l'avvelenamento da ARP per attaccare gli utenti. Non banale a meno che non ti trovi sulla stessa rete degli utenti target che utilizzano la tua webapp.
  • Avvelenamento da cache DNS. Perché ciò funzioni è necessario avvelenare il DNS utilizzato dagli utenti target. Se il DNS non è impostato correttamente, questo attacco diventa in qualche modo banale da eseguire, tuttavia c'è molto su cui fare affidamento perché funzioni.
  • Attacchi di phishing. Questi ancora ingannano gli utenti ignari e ingenui, tuttavia gran parte della responsabilità ricade sull'utente.

Tutto questo solo per attaccare uno o un piccolo sottoinsieme di utenti. Anche allora, attaccare questi utenti darà loro un avvertimento nei loro browser (ci sono anche modi per attaccare questo, ma non lo sto prendendo qui). Solo compromettendo una CA principale o trovando un difetto nell'algoritmo utilizzato per generare i certificati, ti sarebbe permesso di rappresentare un emittente certificato affidabile.

Se d'altra parte guardiamo a tutte le potenziali cose brutte che possiamo vedere se non investiamo in sufficiente sicurezza della stessa webapp vediamo vettori di attacco come:

  • SQL Injection: banale e facile da sfruttare e scoprire. Impatto del danno molto elevato.
  • XSS (Cross Site Scripting) - facile da scoprire, più difficile da sfruttare. Penso che vedremo un impatto sempre maggiore da parte dell'utente in futuro. Prevedo che questo sta diventando la tendenza della "nuova iniezione SQL" che abbiamo assistito in passato.
  • CSRF (Cross Site Request Forgery) - Moderato da scoprire, moderato da sfruttare. Ciò richiederebbe agli utenti di navigare verso un sito già di proprietà, innescando una richiesta alla tua webapp che farebbe una transazione per conto dell'utente.

Quindi, citando solo questi pochi, ma metodi popolari sia per attaccare la webapp che per diventare MiTM, lo lascerei a un'analisi specifica di rischio/conseguenza della specifica organizzazione che stai cercando di proteggere, indipendentemente dal fatto che tu debba difendere o meno i tuoi utenti direttamente implementando SSL o difendendo la webapp nel suo insieme (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, concordo pienamente con l'affermazione di Chris Dixon. Assegna 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 sotto pesanti attacchi MiTM durante la scia di Firesheep. Questo potrebbe essere mitigato solo attraverso SSL e consapevolezza.

Tuttavia, se ci pensi, annusare il traffico wireless con Firesheep e dirottare le sessioni richiederebbe che la LAN wireless a cui sei connesso non abbia alcuna crittografia.

Oggi, quando vado alla guida della guerra, ha drasticamente ridotto 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 abbastanza sicurezza.

Ora, qual è il rischio che qualcuno crei uno strumento semplice e conveniente per annusare e dirottare le sessioni degli utenti? Qual è l'impatto per quegli 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 ne è un buon esempio)).

7
Chris Dale

Non ha trovato alcun libro statico o bianco che includa i dati del mondo reale che si desidera avere.

Tuttavia, vorrei aggiungere che gli attacchi MitM all'interno delle aziende avvengono quotidianamente e più di una volta. Numerosi fornitori di soluzioni 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 interna (CA) che è già considerato 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".

2
Tex Hex

Sono abbastanza sicuro che annusare le password sulle reti wireless sia estremamente comune. Guarda quanti tutorial ci sono sul Web da un semplice Ricerca Google o Ricerca Bing .

0
Dare Obasanjo

Concordo con Daramarak sul fatto che sarebbe piuttosto difficile trovare dati reali sugli attacchi MitM. Uno dei motivi è che gli attacchi MitM sono di solito rivolti agli individui, mentre gli attacchi come l'iniezione DDoS o SQL sono solitamente rivolti a società, organizzazioni, ecc.

Pertanto, mentre vediamo quasi ogni giorno un DDoS/iniezione/qualunque cosa, le informazioni relative agli attacchi MitM sono generalmente accademiche (ad es. "Twitter era 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é è abbastanza difficile escogitare un protocollo completamente sicuro contro MitM. Questo è in realtà il caso della maggior parte dei problemi di sicurezza, la maggior parte delle soluzioni sono "il miglior sforzo" anziché "completamente e assolutamente sicuri".

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

0
Can Berk Güder