que tal.
Por supuesto que se pueden hacer. Dependiendo de unos casos u otros, diferen-
tes contextos son necesarios/recomendables. EN el caso de DNS Cache
Poisoning, el atakante debera saber el Transaction ID ( el del DNS Autoritativo
con el "DNS Caching" ) mas el puerto usado ( udp para la mayoria ) por el
DNS Caching. Para esto, se requeriria que el atakante poseyera un DNS Auto-
ritativo para un dominio suyo, asi podria sniffar el puerto que Bind este usando
en esa transaccion.. Komo es muy probable que Bind use el mismo puerto para
el mismo cliente ( podemos comprobarlo kon mas de una peticion ), ya tendria-
mos el puerto usado. El ID es otra historia, ya que ( normalmente ) es un numero
de 16 bytes ( 65535 posibilidades ). En versiones ( que son las 8 y 4 ?? ?? )
esta la vulnerabilidad de Bind conocida como " Birthday attack". La filosofia
de este atake se basa en que, en un grupo de 20 personas, hay una alta proba-
bilidad de que dos o mas personas kompartan la misma fecha de cumplanos...
El kaso es que esto transportado a la vulnerabilidad en Bind en esas versiones,
viene a decir que Bind manda mas de una requesta de tipo recursive por cada
una de las peticiones de los clientes ( o sea, que si le llega una peticion de un
cliente preguntando por la direccion IP de
www.google.es, varias peticiones
recursivas en favor de ese cliente, y no solo una ). Eh aki el "bug" del que este
atake se aprovecha, ya que el atakante ( .... ) mandaria un monton de
requestas preguntando por la direccion a envenenar en su cache ( por ejemplo
www.bank.com ) a este DNS Caching con version de BIND vulnerable,
al mismo tiempo que manda un monton de repuestas por cada requesta
que hace.. Ahora, komo esas versiones de Bind tiene el "bug" del birthday attack,
pues es mucho mas probable que demos kon un ID correcto. ( Ademas de
vulnerable, el DNS Server debe ser open recursive.. osea, que acepte requestas
desde tipo recursive desde cualkier lado de internet, y no solo desde su Red
interna que seria lo mas seguro para ellos ). Pero komo dije al principio, para que
el atake fuese totalmente efectivo deberiamos de saber el puerto usado por Bind
en esta transaccion ( para saber al puerto que devolvemos nuestro pokoton de
respuestas falsas no?? ) y para ello, lo mas adecuado es poseer un DNS autori-
tativo para un dominio nuestro y, antes de realizar el atake, preguntar al DNS
server a envenenar por nuestro dominio y esniffar la respuesta.
Ya se que pudo reslutar un poko lioso, pero no lo esta tanto. Tengo un poko de
prisa y de nuevo me hallo en un ciber cafe que apesta, asi que si puedo responder
a alguna pregunta que tengais, hacedla y me imagino que en un par de dias bajare
por el cyber y entrare en la pagina del foro.
De todas maneras, decir que eso anterior es para un DNS Cache Poisoning basado
en el fallo del Birthday attack que tienen esas versiones. Esto se podria hacer con-
tra versiones de 9.x de Bind, solo que el fallo del Birthday attack ya esta corregido.
Pero, pongamos ahora que podemos DoSear de alguna manera el servidor DNS
de la pagina que tiene que responder a la recuesta recursiva ( en el caso anterior
www.bank.com ). Pues, desde que tenemos DoSeado el server, tenemos muchas
mas posibilidades de que el DNS Caching Server ( al que mandamos las peticiones
y las respuestas ) se trague una de nuestras respuestas ( las cuales llevaran
la direccion IP de uno de nuestros dominios --> es la web que hara el defacement
o el phishing ) que si no estuviera DOseado. Ademas, desde que nosotros manda-
mos las respuestas automaticamente, y asi no hay resolucion de nombres ( yendo
desde los root nameservers hasta el DNS Autoritativo para
www.bank.com )
tenemos mas posibilidades de que se trague una respuesta nuestra tambien.
Cabe decir que la implementacion de DNSSEC nos dejaria sin poder realizar
este bonito atake ( hata donde yo se ), pues se usarian IDs encryptados
y demas menesteres.
En el tema del DNS Amplification Attack, deseariamos tener una Botnet con
muchos zombies a nuestra disposicion. En este preciso atake, entra en juego
el kerido Spoofing. Ahora, tendriamos que spoofear nuestra direccion por la del
Host a DoSear/attackar. Al mismo tiempo, dirijiriamos nuestros zombies a que
realizaran una recuesta de un DNS Record ( podemos usar un DNS nuestro y
hacer la peticion de un Recor tipo TXT kon unos pokos de bytes --> recordar que
no hace falta exagerar!! ya que se trata de un atake de amplificacion, y komo tal
las requestas seran mucho mas "grandes" que las requestas; ya que utilizamos
muuuchos hosts ( amplificacion ) y ya que las DNS replies son en medida mas
"pesadas" que las repuestas! ). Pues todas esas respuestas iran a parar a noso-
tros pues nosotros somos los que iniciamos esa requestas a todos ESOS OPEN
RECURSIVES DNS Servers ( hakr (Ip - spoofed) --> Zombies --> Open
recursives --> DNS Server (large record) --> ( IP - Spoofed ).. pero.. ah!!
tenemos nuestra direccion IP Spoofeada
kon la del objetivo a DoSear!! Mmm... y es MUY probale que se este usando udp
para este tipo de transaccion.. por lo kual, no necesitamos un conexion bidirec-
cional y activa como en TCP!!! El spoof, es entonces mas que dichoso!!!
O sea: Las respuestas TODAS iran a parar al DNS Spoofeado, y sera el el
DoSeado y no nosotros! Pobre DNS, y su uso de udp..
Cabe recalcar que DNS utiliza tcp para transacciones tipo Zone Transfers..
( en *NIX:
# host -l host.com DNS1.host.com
O a veces, puedes probar los secundarios:
# host -l host.com DNS2.host.com
)
Si no keremos utilizar para este atake un DNS nuestro, pues podriamos ponernos
a buscar algun Record en un DNS Server que tenga un peso adecuado para
nuestro proposito. Creo que se han visto atakes Utilizando el Record Root ( O sea,
el punto: . ) para este tipo de atakes.. De otra manera, podriamos ownear
un DNS con un fallo de buffer overflow y asi, colocar nosotros mismo en el
un Record tipo TXT bien larguito.. ( Record TXT: es un Record que describe el
DNS en cuestion... texto vaya. )
Este tipo de atakes no lo resuelve DNSSEC!!! asi que... Lo que si podria kortartnos
las alas ( y de hecho ocurre a las pocas horas/minutos de que realicemos este
atake ) es un filtro tipo syngress ( egress ?? ).
Como dije antes, aki aprovechamos varias kosas:
1) deberiamos de poseer un botnet con un numero de zombies considerado.
2) deberiamos de tener una amplia lista de OPEN DNS recursives.
3) Utilizamos UDP ( optimo para el Spoofing, y el utilizado por DNS a menudo )
4) Debemos apuntar nuestros zombies a un DNS el cual tenga de una manera
u otra un Record de unos 1000 bytes ???
5) debemos hacer Spoof con la direccion a atakar
Me dejare kosas en el tintero, pero ya me preguntareis si kereis, claro.
Tambien cabe decir que hay otro atake a la Cache de DNS llamado
"DNS Snooping attack". Este ( basicamente ) consiste en que Un
Caching/Recursive DNS ( en nuestro caso comun seria el de nuestra ISP ) ante
un recursive query deberia iniciar un proceso de preguntas ( llamado recursion )
empezando preguntando a los DNS Root, seguido de los DNS Autoritativos
correspondientes hasta dar con la respuesta, respuesta que mandara al cliente
( nosotros, en el caso de que hayamos iniciado el query ). Cabe decir, que en
nuestra makina tenemos un cliente DNS, que es el que se konecta kon nuestro
DNS Resolver en nuestra ISP, por ejemplo. Este cliente nuestro se llama resolver.
Bueno, pues en cuando nosotros hacemos un query al DNS Recursive ( y
probable mente Caching de nuestra IP ( son los DNS que konfiguramos en nuestro
windoze )por ejemplo: el primario y el secundario -- o en Linux los que recibimos
por ejemplo via DHCP y que kedanb grabados en /etc/resolv.conf ) ese caching
DNSServer Cacheara la respuesta por un tiempo definido en el valor TTL ( Time
To Live ) en la cabezara DNS. Ya se que a muchos le sonara este TTL ( un pake-
te IP.. Traceroute... ). Cualkier peticion de resolucion de ese mismo dominio
( anteriormente requestado por nosotros ) por otro cliente sera manejado por
dicho DNS Caching Server ( ISP ) desde la Cache. O sea, si el DNS Caching
( ISP ) recibe una peticion de un cliente, y tiene en su cache dicha respuesta,
optara por no hacer recursion ( o sea, "apagara" el bit de recursion ) y devolver-
le la respuesta kon la info que tiene en la Cache ( Para eso estan las Caches
no???
) A este punto, ya tenemos komo funciona a grandes rasgos un DNS
Caching/recursive Server. Ahora, imaginemos que keremos saber si los clientes
de una ISP en concreto han accedido a una pagina tal:
www.sexcity.com.
Aki entra el atake "Cache Snooping".. y seria komo sigue:
Debemos cerciorarnos de que dicho DNS Server acpeta requestas tipo
no-recursive.. Esto kiere decir que el bit +recursion estaria off... y, kon lo
explikado anteriormente ( recursion = que el DNS recursive/Caching haga todas
las preguntas necesarios para atender a la nuestra ), podemos deducir que AHORA
EL DNS CACHING/RECURSIVE dara las respuesta que tenga en Cache solamente.
Este atake se puede elaborar con dif en Linux: ( creo que era asi )
# dig @dns1.dnsserver.com
www.host-a-snoopear A +norecursive
Donde
www.host-a-snoopear es el dominio que keremos saber si la gente que usa
el dns1.dnsserver esta accediendo.. A ( es el DNS Record de Address )Con el bit
+norecursive estamos haciendo eso:
deshabilitando la recursion y haciendo que el DNS Server responda solo desde
Cache.
O sea, si haciendo ( en linux ) un comando tal:
# host -t ns ISP.com
obtenemos los DNS Servers de la ISP en cuestion, y keremos ver si esa los
clientes de esa ISP han accedido recientemente a la pagina:
www.sexxx.com,
podriamos intentar lo siguiente:
# dig @dns1.ISP.com
www.sexxx.com A +norecursive
Si en la respuesta obtenemos un campo tal:
ANSWER: 1 --> si no es 1 y es 0, es que no hubo respuesta y no la tiene en
Cache..
pues sabremos que esa direccion ha sido accedida por algun cliente en cuestion.
Aki DNSSEC tampoko kreo que nos impidiera nuestro objetivo, solo una mejor
configuracion por parte del Admin de los DNS lo podria.
Esto puede ser util en otras ocasiones:
Imaginad que tenemos medio hackeada un Base de Datos ( digamos Microsoft SQL
Server
) y keremos ver si el user comprometido de la database ( digamos
SA ?? ) tiene acceso a la internet.. pero.. como lo probamos ??? Mmm...
podria ser tentador el hacernos un ping a nuestra makina y capturar nosotros
los pings en ese mismo instates y asi tendriamos la solucion; pero esto es un
poko arriesgado desde mi punto de vista... que tal si hacemos que dicho user ( el
comprometido sea cual sea en la database ) haga una requesta por un host
"extranio" a un open recursive, y tras ello iniciamos nosotros un query tipo
+norecursive al mismo servidor DNS para probar que el user de la database
tierne konexion a inet?? uf.. que lio madre. Osea: hacemos desde la database
una requesta por:
www.estxilmarzoa.com un DNS Server que permita
open recursive queries ( asi komo +norecursive ). Pues tras ello, seriamos
nosotros desde nuestra makina los que nos dirijiriamos al mismo DNS server
pero con una peticion tal:
# dig @dns1.dnsserver.com
www.estxilmarzoa.com A +norecursive
y si obtenemos un 1 en el campo de ANSWER, es que muy probablemente el
user comprometido en la database pueda acceder a inet, y si es asi...
BE CREATIVE!
Bueno, kon esto me despido hasta otra: averno
Saludos a todos, Suerte.
/* Modifico */
De todas maneras, para este ultimo atake os dejo el siguiente link:
http://www.rootsecure.net/content/downloads/pdf/dns_cache_snooping.pdf
NOTA: Snooping = fisgonear
/ ************ Modifiko2 **************/
Nota importante: se me olvido aniadir que, en el atake de DNS CACHE POISONING,
TAMBIEN NECESIAMOS HACER USO DEL SPOOFING. O sea, que si keremos
envenenar la cache de 20.20.20.20 para que en lugar de la direccion de
www.microsoft.com ( pongamos 10.10.10.10 ) tenga la de un dominio nuestro
( pongamos 30.30.30.30 ), debemos realizar el atake tal komo he mencionado
antes, pero spoofeando nuestra IP kon la de ns1.microsoft.com ( por ejemplo ).
A fin de cuentas, tenemos que realizar Spoofing al modo usual ( kon nuestra
cabecera IP forjada kon la IP del DNS primario autoritativo para el dominio
al cual keremos suplantar ).
Cabe aniadir que kreo que en los kasos de BIND ( Berkeley Internet Name
Domain ) versiones 4 y 8 /* komentadas anteriormente */ tienen ademas una
vulnerabilidad de prediction IDs.. O sea, que los transactions IDs no son de
ningun modo randoms. Esto es, que si obtenemos un transaction ID ( sniffing )
es altamente probable que el siguienter ID sea ese mismo ID + 1.
####### ((id++)) ##############################
Bueno, ahora me gustaria lanzar una llamada al interesado en kooperar konmigo.
Si hay alguien que disponga de un DNS Server ( que no sea un mono klaro ),
pues podria kontactar konmigo para un negocio. Podriamos formar un "Team"
temporal, y yo le podria proveer de toda info que dispongo y tools para realizar
este atake a cambio de compatir conmigo ese DNS Autoritativo para uno de
sus dominios ( o para el uniko ).
No tengo internet en kasa ( por ahora ) asi que prefiero saltarme el paso de inten-
tar ownear un servidor DNS!! :s
/****************** Modifico3 **************************/
Cabe decir que, reiterando en el aatake de DNS Cache Poisoning.. en la etapa
en la que le mandamos todas las requestas al DNS Server para despues mandar-
le todas las respuestas para ver si se traga una ( respuesta ), las requestas
es mejor hacerlas Spoofeando diferentes direcciones; ya que de este modo cada
requesta sera tratada independientemente y kon ID diferente. Las respuestas
las mandaremos despues kon nuestra IP spoofeada kon la de ns1.microsoft.com
( en el ejemplo anterior ) y solo kon esa direccion.
Tambien esta el DNS Hijacking ( pero en Red Local ) que konsiste en "ponerse en
medio" ( por ello en LAN ) y kon una herramienta komo DNS Hijacker o DSniff,
procederiamos a un atake ( que miraria por peticiones de resolucion DNS basadas
por ejemplo en Records de tipo A ) el kual llevariamos ahi si kasi todas las de
ganar; ya que dichas respuestas la mandamos nosotros ( incluyendo un dominio
nuestro para el envenenamiento de la Cache ) sin tener que hacer ningun tipo
de resolucion. Desde que el DNS Server Autoritativo para el dominio debe ser
alcanzado ( si no esta en Cache! ) via algun tipo de resolucion ( recursion o
iteration ), nuestra respuesta ( automatica ) tiene muuuuchas mas ventajas de
ser cacheada kon antelacion que la "verdadera".
/************* Modifico4 ****************************************/
Mmmh... si en el Bind 4.x y 8.x, los IDs son predecibles de tal modo que el
siguiente ID sea el ID+1, por que mandar todo ese Bunch the requestas..??
/* EOF */
Gracias, Saludos y Suerte.
Autor
En línea
