Avvelenamento della cache DNS in LAN senza MITM

Naviga le tue risposte
4

Sono già state poste molte domande sull'avvelenamento della cache DNS (noto anche come attacco di Kaminsky), tuttavia non sono riuscito a trovare una risposta chiara alla mia domanda:

L'avvelenamento della cache DNS è possibile in una LAN, senza eseguire un attacco MITM?

Chiarimento:

È normale che l'avvelenamento della cache DNS sia possibile durante un attacco MITM.

Tuttavia, non vedo molti argomenti che ruotano intorno a una tecnica per mettere a tacere veleno su una LAN, senza eseguire un attacco MITM (come l'attacco Kaminsky). Penso che dovrebbe essere possibile, poiché tutte le richieste / risposte DNS sono semplici http, non crittografate. Dovremmo quindi essere in grado di vedere la richiesta (incluso l'ID della transazione e la porta esatta) e preparare una risposta falsa prima che un server DNS "valido" possa rispondere alla richiesta. L'utente malintenzionato si trova sulla stessa LAN del target e sarà quindi molto più veloce rispetto a un altro server DNS esterno alla LAN.

È possibile un attacco del genere? Capisco che è più facile eseguire lo spoofing del DNS durante un attacco MITM, voglio solo sapere se sarebbe praticamente possibile mettere in cache i client veleno su una LAN vincendo la gara di risposta DNS senza aver eseguito un attacco MITM.

Nota: questa non è una domanda su come è stato impedito l'attacco di Kaminsky (ID della transazione e randomizzazione della porta)

    
posta Michael 12.02.2014 - 22:17
fonte

2 risposte

2

Sì questo è possibile, sebbene siano disponibili anche attacchi migliori.

L'avvelenamento della cache DNS è possibile attraverso una serie di metodi, l'attacco di Kaminsky è solo uno di questi. La ragione per cui l'attacco Kaminsky ha suscitato tanto interesse è che non è necessario essere sulla stessa LAN. Potresti attaccare un server DNS a metà del pianeta.

È risaputo che è possibile manomettere il traffico sulla stessa LAN di se stessi, a meno che il traffico non sia protetto dalla crittografia. La maggior parte degli strumenti (ad es. Android Network Spoofer ) utilizzano l'avvelenamento ARP in combinazione con l'avvelenamento DNS, perché questo è il metodo più affidabile. In linea di principio si potrebbe fare l'avvelenamento del DNS senza MITM, proprio come si propone, ma sarebbe meno affidabile perché si sta facendo affidamento su una condizione di competizione.

Ed è per questo che non vedi molte discussioni sul tuo attacco proposto. In ogni situazione pratica hai opzioni migliori.

    
risposta data 12.02.2014 - 22:32
fonte
4

Le richieste e le risposte DNS sono non HTTP; loro sono ... DNS. Vedi lo standard . La maggior parte delle volte, le richieste e le risposte DNS utilizzano UDP : la richiesta è un pacchetto IP singolo e così è la risposta.

Con UDP, ogni pacchetto è identificato da:

  • l'indirizzo IP di origine
  • l'indirizzo IP di destinazione
  • la porta di origine
  • la porta di destinazione

Una richiesta DNS dal client C al server DNS S userà l'indirizzo IP di C come sorgente, S come destinazione, un valore di porta casuale p come porta di origine e 53 come porta di destinazione (il valore di porta standard per il server DNS). La risposta DNS userà l'indirizzo IP di C come destinazione, l'indirizzo IP S come sorgente, 53 come porta sorgente e p come porta di destinazione. Il client accetterà la risposta come "corretta" perché usa p come porta di destinazione, lo stesso p come quello utilizzato dal client come origine per la sua richiesta.

Un utente malintenzionato che desidera fornire informazioni DNS false al client C può conoscere l'indirizzo IP C e l'indirizzo IP S e può fare una buona ipotesi sul momento in cui il cliente invierà la sua richiesta. L'obiettivo dell'attaccante è inviare una falsa risposta DNS, sostenendo di provenire dal server DNS S , ma contenente. Senza un accesso completo a intercettazioni, l'attaccante non può conoscere il valore di p , perché non può vedere pacchetti. Tuttavia, i numeri di porta sono in un intervallo limitato (i numeri di porta vanno da 0 a 65535, ma l'intervallo effettivo per i numeri allocati casualmente è minore e dipende dal sistema operativo coinvolto). Pertanto, l'attaccante può semplicemente inviare alcune migliaia di pacchetti IP falsificati, ciascuno contenente le informazioni false, per tutti i possibili valori di p di porta. Il client li abbandonerà tutti tranne quello che utilizza il valore p corretto.

Lo stesso concetto può essere esteso alle comunicazioni tra server DNS, perché parlano tra loro e nascondono le risposte. Spesso è più facile tirare fuori l'attaccante, perché può innescare lo scambio DNS-to-DNS, permettendo un tempismo preciso per il suo lancio delle sue migliaia di risposte falsificate. Quando riesce a fornire informazioni false a un server DNS, si dice che il server DNS sia avvelenato .

Questo genere di cose è relativamente facile anche per gli attaccanti di bassa tecnologia che non hanno abilità di intercettazione, per non parlare del potere di intercettazione che sarebbe richiesto per un vero MitM tra il client e il suo server DNS, o tra server DNS. Il motivo per cui è semplice utilizzare l'UDP implica che l'hacker conosce tutto tranne la porta di origine casuale, che vive in un intervallo ristretto. Se i due server DNS parlano tra loro su TCP , allora l'attacco è più difficile, perché l'iniezione di dati falsi in un TCP il flusso implica di indovinare i numeri di sequenza di connessione , scelti casualmente in un intervallo di 32 bit: le "migliaia di pacchetti" sono diventati "miliardi di pacchetti".

    
risposta data 12.02.2014 - 22:39
fonte

Leggi altre domande sui tag

Qual è una buona confutazione per gli utenti che desiderano crittografare tutti i dati WITHIN Db? Tutte le suite di crittografia con rc4 sono intrinsecamente difettose?