| I diritti sono riservati, come da legge sul Diritto d'Autore n. 518 del 1992 e successive modifiche. Nessuna parte di questo topic potrà essere riprodotta e archiviata in sistemi server diversi da quelli voluti dall'autore. E' invece, consentita la citazione del topic e/o di alcune parti interne, senza preventiva autorizzazione, purchè sia chiaramente identificabile il nome del dominio ufficiale e dell'autore (sciax2.it,exterminetor) Per le autorizzazioni o qualsiasi comunicazione in merito potete scrivere a: Dio (unknow@live.it) Il DNS Cache poisoning è un attacco informatico gia noto da più di dieci anni che mira a cambiare la cache dei name server in modo da modificare l'associazione indirizzo IP / nome del server. Il pericolo viene dal fatto che i server DNS per comunicare tra loro usano riferimenti (QUERY ID) abbastanza facili da prevedere. Questo attacco richiede meno conoscenze di quello che si potrebbe pensare e viene facilitato dal fatto che il programma bind (un server dns creato da Paul Vixie nel 1988) è facilmente reperibile su internet. Bastano un pò di pratica e studio del programma per rendersi conto che quello che dovrebbe essere il cuore della comunicazione dei server DNS ha qualche problema. COME FUNZIONA? Prima di tutto, cosa fanno i server DNS tutto il giorno? Semplice, trasformano link come Perfavore,
Entra
oppure
Registrati
per vedere i Link!
o Perfavore,
Entra
oppure
Registrati
per vedere i Link!
in un indirizzo ip (es. 123.12.134.123) che contiene tutte le informazioni per raggiungere il server desiderato. Ma se l'abbinamento tra un sito e il suo vero IP viene modificato, la comunicazione viene di conseguenza dirottata a un diverso indirizzo ip. Potrebbe sembrare solo uno stupido errore, ma se pensiamo per esempio ai servizi bancari online, è evidente che la cosa potrebbe essere assolutamente manifestata: Ci colleghiamo, immettiamo utente e password al sito fasullo che impersona quello della nostra banca e intanto qualcuno ne gode a discapito nostro.IL DNS CANONICO Durante una comunicazione sul web, prima che le informazioni appaiano nel nostro web browser vengono compiuti diversi passaggi, di cui normalmente non ne abbiamo notifica. Se per esempio cerchiamo ( Perfavore,
Entra
oppure
Registrati
per vedere i Link!
), il browser inoltra la nostra richiesta che viene trasmessa fino al primo DNS. L'informazione su quanto tempo considerare valido il sito della nostra ultima richiesta DNS viene espressamente fornita dal Server B (ammesso che B abbia trovato nel suo elenco tale informazione). Alla scadenza, la richiesta deve essere verificata di nuovo. L'ANELLO DEBOLE La query ID o QID, serve per tenere ordinate e separate le varie interrogazioni fatte al server. E' come il numerino che prendiamo al supermercato per fare la fila, ogni cliente ha il proprio e il negoziante serve i clienti uno alla volta seguendo l'ordine prestabilito. Per convenzione i primi 16 bit dei pacchetti TCP sono utilizzati per inserire questo identificatore univoco. Questo sistema però presenta una marcata vulnerabilità. Poniamo il caso che EXTERMINETOR sia il resolver e MADONNA un server DNS. Nascosto alle ombre, cè DIO. EXTERMINETOR si collega a MADONNA e le chiede l'indirizzo Perfavore,
Entra
oppure
Registrati
per vedere i Link!
. MADONNA trova nel suo elenco che 1.2.3.4 corrisponde a Perfavore,
Entra
oppure
Registrati
per vedere i Link!
. Ma DIO vuole che la risposta sia 6.6.6.0. Siccome DIO non può vedere la QID dei pacchetti di EXTERMINETOR, la sua QID non coinciderà con quella di EXTERMINETOR. Questa è la difesa che ha EXTERMINETOR per la sua navigazione, ma di solito l'attacco QID è iniziato molto tempo prima e il server continua a ricevere le risposte di DIO. Nel frattempo, BIND, incrementa la QID per ogni risposta, come il cartellino del negozio. Quindi il DNS server crea le sue QID ad esempio 4001 e poi 4002. Quindi, indovinare la prossima, è scontatamente facile. Sarà 4003. DIO quindi cerca di inviare una risposta con il QID 4003, se ci riesce, DIO ha vinto.La fonte è esclusivamente mia. |
Ultima modifica:
