Questo articolo è nato direttamente sul forum di HackerAlliance in risposta ad una domanda che era stata posta da HI-Teck e visto che prima o poi scomparirà ho pensato bene di trasferirlo qui tra gli articoli…
I DNS sono macchine adibite al Domain Name System, cioè alla trasformazione del nomedominio in indirizzo IP… un sistema utilizzato per assegnare nomi ai nodi della rete (in inglese: host). Indica anche il protocollo che regola il funzionamento del servizio, i programmi che lo implementano, i server su cui questi vengono elaborati, l’insieme di questi server che cooperano per fornire il servizio più intelligente.
Ideato il 23/06/1983 da Paul Mockapetris, Jon Postel e Craig Partridge; le specifiche originali sono descritte nello standard RFC 882. – Nel 1987 vennero pubblicati commenti allo standard RFC del DNS, con i nomi RFC 1034 e RFC 1035 rendendo obsolete le specifiche precedenti.
Uno dei modi per dirottare dei DNS e quindi associare a un nomedominio un IP differente da quello corretto è quello di sfruttare i bug dei datasource ODBC.
Questo accadeva con NT 3.5 e 4 accoppiato con IIS 3 e 4, con le versioni di Win2000 e rispettivi IIS 5 le cose sono un po’ cambiate, ma senza alcuni accorgimenti è possibile exploitare ancora e manipolare i DNS a piacimento…
A meno che non vi siano patch particolari, le vecchie versioni di IIS non sono sicure perchè non vi sono protezioni sull’accesso ai dati e per dirla tutta, gli strumenti “invasivi” che permettono questo tipo di attacco sono già presenti sul server: “le applicazioni stesse”.
E’ quindi possibile accedere ad un sistema DNS, sniffare user e password mettendo NetCat o simile in ascolto sulla porta SQL per poi avere il pieno controllo dei sistemi DNS o di qualsiasi altro tipo di sistema che utilizza questo tipo di tecnologia per l’archiviazione dati.
In quei paesi (ma non solo) dove regna l’assoluta ignoranza in fatto di network security, è quindi possibile trovare non dei portoni aperti, ma degli angar per aerei!
Vi domando: chi di voi installando IIS penserebbe mai di rimuovere i file contenuti nella cartella c:\inetpub\scripts\tools ?
Adesso vi spiego per bene..
Mettiamo di aver localizzato la rete da colpire, e di aver trovato NT / 2000 con IIS, strumenti di accesso ai dati (tipo SQL) accessibili ed eseguibili in remoto e ovviamente il nostro DNS ODBC per SQL…
Se dovessimo trovare una macchina multi-IP nella sottorete, saremmo nella condizione di dover cercare il nomedominio che ci interessa e quindi colpire ed isolare un solo IP per volta.
La faccenda si fa molto più pericolosa quando localizziamo una macchina mono-IP…
Su un modo IP possono starci benissimo una marea di siti web, ma tutti appoggiati di base ad un unico IP che con impostazioni particolari reindirizzano le richieste GET su una determinata cartella nella quale risiede il dominio web.
Quindi non ci è difficile immaginare cosa succederebbe se eliminassimo in solo colpo l’associazione di un solo ip (il principale) a tutti i domini della macchina mono-ip…
Allora, una volta localizzato il server contenente i tools accessibili, digitiamo un percorso tipo:
http://www.nomedominio.it/scripts/tools/mkilog.exe …a questo punto, come per incanto si creerà una pagina contenente una tabella per accedere direttamente al SQL per IIS con la scritta “Create Microsoft Internet Information Server Log Table”.
Qui abbiamo un elenco dei DNS SQL indicizzati nella macchina remota. Scegliamo il nostro DNS e passiamo a modificare il linking ODBC.
Precedentemente avremo già deciso su quale IP far puntare il dominio vittima, e per questo solitamente viene utilizzato un IP a cui abbiamo accesso.
Successivamente dovremo utilizzare un tools in grado di far accettare al nostro IP pirata i dati in arrivo dal server della vittima, utilizzando un programma in grado di mettersi in ascolto sulla porta 1433 e di continuare a rimanere in listening anche dopo la chiusura della prima sessione (chi si ricorda gli attacchi con intercettazione delle sessioni aperte? Il discorso è simile).
Per tutto questo è necessario avere anche un output a schermo di quanto sta avvenendo, non è sufficente un programma automatico in grado di eseguire funzioni solo in stealth in locale, anche perchè sarebbe completamente inutile.
Messo in ascolto il programma, non dobbiamo fare altro che navigare un po’ all’interno del sito, cercando di passare a toccare carrelli elettronici, pagine di login, pagine ASP aspettando che esse rispondano inviando al nostro server fittizio informazioni come user e password in chiaro!
Ora dovremo semplicemente indicare al server vittima di restituirci un altro tipo di output e cioè la schermata per le impostazioni dei DNS, quindi digitiamo:
http://www.nomedominio.it/scripts/tools/dsnform.exe?SQL+SERVER
Il dirottamento dei DNS è a un passo…ora basterà compilare i campi con i nuovi dati e terminare con “Create Datasource” ed aspettare un messaggio di conferma per gioire del fatto che avete appena fregato il povero admin dirottando uno dei suoi domini…
Solitamente il dirottamento non è istantaneo in quanto bisogna attendere il refresh dei DNS e quindi la loro propagazione prima che le modifiche siano effettive e visibili in tutto il mondo.
Questo tempo va solitamente dalle 8 alle 24 ore.