Exploit for the DNS cache poisoning vulnerability...

[Jose.Carlos.Luna at cern.ch (Jose Carlos Luna)]

Just an idea that popped to my mind.

In this case I would send as you suggest a link or webpage (there is no 
really need for it to be XSS) that makes the internal client to
resolve sequentially:
randomAAAAA.atacker.com
randomAAAAB.atacker.com

All the spoofing part of the attack is launched from ns.atacker.com.
The atacker will answer the above replies as:
randomAAAAA.atacker.com. CNAME randomAAAAA.victim.com.
randomAAAAB.atacker.com. CNAME randomAAAAB.victim.com.

This way I have all the information I need (the address and port of the 
caching DNS) and good synchronization with the client part
of the attack as the caching dns will immediately go resolve 
randomXXXX.victim.com when I answer with the CNAME data.

In the client started page we could also implement an stopping mechanism 
like make it to resolve stop.atacker.com every X tries.

Cheers,

natron escribi?:
> Juan, your scenario would be a difficult one to exploit with the 
> current code.  An external attacker would be able to send spoofed 
> responses to your DNS server, but would not be able to send requests 
> to the server for randomAAAAA.domain.com 
> <http://randomAAAAA.domain.com>.  An external attacker could, in 
> theory, modify the request generating side of the msf exploit to use 
> one of the ideas Jarrod mentioned in the earlier email (e.g. XSS 
> forcing an internal browser to fire off DNS requests for you), then 
> send the spoofed responses to wherever the DNS server pops them out.
>
> Something like:
>
> 1) XSS kicks off DNS request to attacker-controlled DNS server, 
> telling attacker the location of the victim's DNS server doing the 
> internet-facing resolving as well as what port(s) it's using
> 2) XSS kicks off AAAA.domain.com <http://AAAA.domain.com> 
> AAAB.domain.com <http://AAAB.domain.com> etc
> 3) MSF spoofs responses and poisons the cache.
>
> Nathan
>
> 2008/7/24 Juan Miguel Paredes <one.miguel at gmail.com 
> <mailto:one.miguel at gmail.com>>:
>
>     Thanks HD.
>
>     I'm trying to understand this and get this to work in our lab.
>
>     In our environment, we have internet-facing DNS servers.  The only
>     systems allowed to query the internet-facing DNS servers are
>     internal DNS caching servers.  All internal users can only query
>     the caching servers.  (sorry, I'm not a DNS guy so my terminology
>     is wrong, I'm sure).  Attacker can't hit either the
>     internet-facing DNS server or the caching servers from outside. 
>     An attacker would need to be inside the network to begin with.  No
>     problem there.  However, the attacker would also be forced to
>     target the caching servers. Additionally:
>
>     1.  The attacker would need to know which internet-facing DNS
>     server the caching server is working with at the time of the
>     attack (or spoof them all).
>     2.  Instead of spoofing the authority as in the msf module, the
>     attacker would have to spoof the internet-facing DNS servers.
>
>     After that, unpached DNS servers are game.  I'm in the process of
>     modifying the .rb modules for our environment, but I thought I
>     should ask: am I on the right track here or am I missing something?
>
>     Thanks.
>
>
>     On Wed, Jul 23, 2008 at 11:20 PM, H D Moore <hdm at metasploit.com
>     <mailto:hdm at metasploit.com>> wrote:
>
>         Woops:
>         http://www.caughq.org/exploits/CAU-EX-2008-0002.txt
>         _______________________________________________
>         http://spool.metasploit.com/mailman/listinfo/framework
>
>
>
>     _______________________________________________
>     http://spool.metasploit.com/mailman/listinfo/framework
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> http://spool.metasploit.com/mailman/listinfo/framework
>   


-- 
Jose Carlos Luna Duran @ CERN / luna at aditel.org / dreyer at pandas.es
Dep: IT/CS/NS
Geneve 23 CH-1211