Newsgroup: it.comp.sicurezza.varie
Titolo: Infettare un dns non autoritativo

Salve, vorrei domandarvi se e' possibile, per un hacker, interrompere
l'erogazione di un servizio web in questa maniera:
Un hacker domanda al suo dns locale, di risolvere 
www.esempio.com
A questo punto il dns locale interroga il dns autoritativo del dominio
esempio.com
.
L'hacker altera i dati che il dns autoritativo invia al dns locale,
rendendo cosi' 
www.esempio.com
 non piu' accessibile da tutti gli utenti che
utilizzeranno quel dns locale contenente dati corrotti.
<sfilzadidomande>
E' possibile questo tipo di attacco?
Come potrebbe l'hacker corrompere i dati provenienti dal dns autoritativo
di 
esempio.com
?
Per proteggere il sistema *basta* impiegare i Secure DNS?
</sfilzadidomande>
Domanda finale:
Se io gestisco il servizio 
www.esempio.com
, e uso come mio DNS autoritativo
un S-DNS, possono collegarsi al mio sito solo gli utenti che dispongono di
un DNS locale di tipo S-DNS?
Grazie 10000000 !

"Fuz" <nos...@nospam.nospam> wrote in message
news:9ad33q$see$1...@nreadB.inwind.it...

Secondo il mio modesto parere, l'attacco da te descitto non puo' essere
lanciato. L'hacker dovrebbe avere accesso fisico al dns autoritativo per
corrompere i dati.
Di solito gli attacchi eseguiti su il DNS server non sono veri e propri
attacchi. L' hacker usa il DNS principalmente per il 'footprinting', ovvero,
per ottenere informazioni della potenziale vittima. La tecnica
principalmente usata e' quella della 'zone transfer' (creare un falso
secondary master server e forzare il primary a rispondere ad una richiesta
di aggiornamento cosi' da ottenere un quadro completo della vittima). Questo
accade se il DNS server non e' stato propriamente configurato (90% dei
casi).
Tuttavia il settore hacking/sicurezza e' molto dinamico. Cio' che e' vero
oggi non lo e' domani (e viceversa). Quindi se qualcuno e' al corrente che
un exploit di questo genere e' possibile...allora si faccia avanti, magari
con qualche dettaglio tecnico.
A presto
Tony H

 Per proteggere il sistema *basta* impiegare i Secure DNS?
Fattori di securedns sono, imho, l'uso di:validi fw a mattoncino, Av,
proxy serv, gateway e shares con pws.
Alcune faq le trovi nel sito in firma di Hack, sul ng. Altro su ISS.
¯massimo_

 corrompere i dati.
Permettetemi di spiegare meglio la dinamica dell' hacking che mi preoccupa:
- l' hacker chiede al dns A di risolvere 
www.esempio.com
;
- il dns A rivolge la richiesta al dns B che e'  l' autoritativo di
esempio.com
;
- l' hacher contatta il dns A, fingendo di essere il dns B; in questo modo
scrive sulla cache del dns A tutto cio' che vuole. Tutti gli utenti che
utilizzeranno il dns A per risolvere degli indirizzi di 
esempio.com
,
riceveranno le risposte alterate dall' hacker.
Ho detto delle stupidate ?
Ciao a tutti.


No: teoricamente e' possibile.
Due problemini:
1) l'hacker dovrebbe mettere a tacere B;
2) l'hacker dovrebbe convincere A di essere B.

 2) l'hacker dovrebbe convincere A di essere B.
Non basta, forse, che l'hacker si presenti ad A con l'IP di B ???
Ciao!


No, anche se chiederei piu' lumi a chi sa piu' di me di DNS*.
Per "comunicare" in TCP, due host hanno bisogno di instaurare
prima una connessione.
Se C (hacker), vuol fare le veci di B, deve riuscire a fare
le seguenti cose:
- mandare un pacchetto con flag SYN (richiesta di inizio connessione)
  ad A con l'ip di B
A quel punto, A rispondera' a B (quello vero) con un pacchetto SYN/ACK
in cui dichiara di aver ricevuto il SYN.
Se il vero B fosse in grado di rispondere, direbbe ad A: "Io non
ti ho chiesto un bel niente...resetta la connessione!", mandandogli
indietro un pacchetto con flag RST.
E' per questo che e' necessario mettere a tacere B.
Non finisce qui, pero', perche', ammesso che B non sia in grado di 
rispondere, C deve ancora convincere per bene A di essere B.
A tal fine, siccome C non riceve il SYN/ACK di A, deve poter
prevedere un numero contenuto in quel pacchetto, detto ISN
(Initial Sequence Number) che dovra' includere nel
pacchetto di risposta al SYN/ACK spedito da A a B.
Solo se a C riesce questa operazione la connessione sara' instaurata
e C potra' iniziare a spedire dati ad A.
L'operazione descritta, molto male e sommariamente, nel suo complesso,
prende il
nome di blind spoofing (falsificazione alla cieca, perche' C non ha modo
di
vedere le risposte che A manda a B).
[*]
Per quanto ne so, pero', il servizio nameserver funziona anche su
UDP...ma
ignoro i dettagli.
Spoofare in UDP e', generalmente, molto piu' semplice, visto
che UDP e' un protocollo connectionless e non richiede, cioe', 
l'instaurazione di una connessione con il triple handshake.

 Ho detto delle stupidate ?
no hai descritto il cosiddetto cache-poisoning.
un mayhem che andiamo per post.
--
what i choose to do is no concerne to you and your friends.
(remove ME to reply)

 prima una connessione.
snippo alla grande per farti notare che poiche' non stai facendo uno zone
tranfer lavori in udp, che come dici piu' sotto, e' un po' meno sicuro.
un mayhem che vorrebbe rimappare su di se bancasella .... ;P


 2) l'hacker dovrebbe convincere A di essere B.
chiamasi forse spoofing?
un mayhem che ...


 Ho detto delle stupidate ?
No, ma come ho detto nel mio post precedente, la causa principale che
consente di effettuare attacchi al DNS sever sono di solito conseguenza di
una superficiale configurazione del server stesso.
Se si predono le dovute precauzioni come:
1.Restrict or Authenticate Zone Transfers.
2.Restrict Dynamic Updates.
3.Turn off Recursion and Glue Fetching or Restrict Queries.
4.Installare uno Split DNS Configuration
5.Usare l'opzione piu' sicura per aggiornare il  domain records.
...dovrebbe essere un deterrente sufficiente per tenere a bada la maggior
parte degli attacchi.
Tony H

 un mayhem che vorrebbe rimappare su di se bancasella .... ;P
rotfl...un whip che si sta documentando sui dns...:-)

 un mayhem che ...
Eh?
;-)))


Vero. Lurkando il ng  ho trovato info su ISS, di X-Force e pgp,
che ne pensi di 
http://xforce.iss.net/index.php
 puo' bastare?
AvresTi ¦ more info, sui 5 del list? BYE?
Saluti
¯massimo_

 5.Usare l'opzione piu' sicura per aggiornare il  domain records.
Allora... con calma... qui mi sembra che stiamo andando proprio al nocciolo
della questione.
Che cosa significano queste cinque cose ?
Non ne ho capita nemmeno una, e desidererei veramente molto, qualche
ulteriore commento.
Un'altra cosa: in questi 5 punti non compaioni i S-DNS (Secure DNS). Come
mai?
Grazie e ciao
- fuz

 AvresTi ¦ more info, sui 5 del list? BYE?
Se ti riferisci all' Internet Scanner 6.1, lo uso e mi trovo molto bene. Il
suo lato piu' positivo e' che fa tutto il lavoro per te; stabilisci l'IP
range e il tipo di scan e lo fai partire. Ti fornisce anche le soluzioni
agli eventuali 'buchi'. Il suo lato piu' negativo e' che costa una cifra....
Riguardo al | more info, sui 5 del list...il discorso si fa un tantino
'serio' visto che si tratta solo della punta di un iceberg. In linea (molto)
generale, gli elementi da considerare sono:
1. Sistema Operativo dove il DNS server e' installato:
    in Win2k, che dovrebbe essere piu' sicuro di WinNT, il 'Authenticate
Zone Transfers' e' settato su "Allow zone transfers To any server".
http://support.microsoft.com/support/kb/articles/q193/8/37.asp
In Unix devi fare i conti con BIND (Berkeley Internet Name Domain) visto che
e'responsabile di molti security holes in UNIX. Fa in modo che sia sempre
aggiornato. Devi configurare named.boot per forzare le restrizioni sul Zone
transfer.
Dai una occhiata a questi links per ulteriori info:
http://www.cert.org/advisories/CA-98.05.bind_problems.html
 e
http://www.cert.org/advisories/CA-1999-14.html
Linux, per esempio fa partire 'named' per default durante il boot.
2. Firewalls:
Potresti configurare il tuo FW o packet-filtering router per bloccare tutti
i (non autorizzati) inbound connections su TCP port 53; considerando che le
richieste di name lookup sono UDP, mentre le richieste di zone transfers
sono TCP.
Per esempio in Checkpoint FW1 alcune porte sono aperte per default. (DNS
lookup (UDP53), DSN zone tranfers (TCP53) e RIP(UDP520) permettono il
traffico from any host to any host e in piu' il trafiico non e' 'logged'.
Come vedi il discorso diventa 'serio' se si dovessero considerare tutti gli
aspetti e le implicazioni. I link che ho fornito sono un buon punto di
partenza. Non so se ci sono equivalenti links in Italiano.
HTH
Tony H

 partenza. Non so se ci sono equivalenti links in Italiano.
Infatti avevo già visitato il sito del quale avevo considerato
un utilizzo su reti Garr-B, con un occhio di riguardo a Noc.
Mi domandavo che ci azzecca con pgp security, anche se,
probabilmente, hanno compiti tipicamente differenti.
Ti confesso, inoltre, che sono un piccolo utente da poco tempo
affacciato su Net, e purtroppo giro con uno sprovveduto Win98Se,
e nella mia utenza casalinga raccolgo le info + interessanti in vista
di un prossimo aquisto worksystem implementato su Mac per Unix,
anche se oltre alla sicurezza avrei ancora molto da imparare, sia
per l'uso di svariate applicazioni sw, che del pc stesso. :-)
Tutto ciò in vista di un futuro viaggio nelle isole del south-Africa,
tra il pinguino(reale)del polo sud, e quello store(virtuale)Monzabique.
E in questi 5 mesi che rimangono alla partenza, resto in ascolto
su INFN, e qui su Usenet, lurkante, come il mio nick ;-)
Grazie della compagnia e buon lavoro.
Saluti
¯massimo_