Que tal.

Bueno, pues aqui me encuentro para mostrarles una tool que encontre en la Red; mas exactamente en:
http://www.securebits.org/

La tool en especifico es "Dns Multi Race Exploiter", codeada por el que mantiene dicha web, "AR".
Os la podeis bajar desde ese mismo link, en formato .tar.gz.
La tool parece estar muy bien, he estado mirando el code y no hay rastros de backdoors; asimismo
esta limpiamente codeada.
Ahora, lo que a mi me esta ocurriendo es lo siguiente:

• Hallo un Servidor DNS el cual me acepta queries ( Open Recursive ).
• Tras ello, aseguro con dig @server www.google.com ( por ejemplo )
• compilo la tool: gcc main.c dns_mre.c dns_mre
  
• Pongo los argumentos necesarios a la tool
• Ejecuto la tool

Cual mi sorpresa, cuando veo un error desde connect(): Permission denied.
Bueno, pues he modificado codigo fuente a mi antojo ( quitando el connect(), quitando la funcion
check_poison(), cambiando la definicion de los RAW Sockets.. ) pero nada. La cosa sigue saliendo
como Permission denied!
Como dije antes, puedo conectar remotamente con el NS, desde con dig hasta con ping ( o netcat tb.. ).

Cabe recalcar que, a la hora de poner el Record del hostname como argumento ( argv[1] ; o sea
<dns_entry_hostname> ); lo pongo como fqdn ( Fully Quallified Domain Name ). O sea, hago un
`wich host` a la IP, y tras ello obtengo el fqdn, e incluyo el punto final de todo fqdn; como indicado
en el RFC.
El caso es no veo la raiz de cual podria ser el problema.
Aqui animo a todo el que este interesado en el Bug encontrado por Kaminsky a probar la tool, y
a que expongan sus resultados. Si llegaran a tener mi mismo problema y consiguen entenderlo,
pediria por favor que lo exponiesen en este mismo post.
Como comentario decir que, en el argumento del source host ( -s ), a mi daria igual que introdujera
o lo que la tool introduzca, ya que ando tras un router NAT.

Bueno, Slaudos y Suerte.

P.D: No suelo postear dudas, pero aqui va una.

P.D2: Ese tipo de errores "Permission denied" en sockets, suelen ser por los permisos inherentes en
          el proceso que esta intentando acceder al socket ( AKA, RAW ), pero Por Supuesto que lo
          estoy ejecutando con permisos de r00t!


  /*********** MODIFIKO ************/

Cabe recalcar que esta tool tiene opciones de ataque variadas. Por ejemplo, te da opcion a atacar a un
Name Server que ya haya sido "parcheado", o a uno que aun no lo haya sido, tras hacer una compro-
bacion de si el server ya ha sido comprometido ( con la funcion check_poison() ).

 /************* U P D A T I N G ***************/

No se preocupen, no era tal el problema. Era mas bien un problema real: el DNS remoto no aceptaba
conexiones mias ( Wrappers?? ). El caso es que ya he logrado correr la aplicacion sin problemas.

Para aquellos los cuales quieran probar la seguridad ante un posible Envenenamiento de la Cache de
sus servidores DNS ( BIND ), pueden probar el siguiente comando desde la CLI:
# dig +short @dns.example.com porttest.dns-oarc.net TXT

Si el resultado muestra POOR, el servidor es vulnerable;
si en cambio muestra GOOD, es que el server ha sido parcheado con exito.

Cabe decir que desde Berkeley, se ha reconocido la ineficiencia de los parches proveidos para versiones
como BIND 9.3..