Exploit for the DNS cache poisoning vulnerability...

[one.miguel at gmail.com (Juan Miguel Paredes)]

Thanks for the feedback.  It seems that sending the DNS request that reveals
the information required to send spoofed packets is not really that
difficult after all.  The only other issue I can forsee is if there are
multiple internet facing resolvers, an attacker would need to know all of
them and send spoofed packets to all of them.  Of course if the internet
facing DNS server is patched, attacking the unpatched internal caching DNS
servers would be next to impossible, unless the attacker is lucky enough to
be inside the network and can sniff packets between the caching servers and
the internet facing servers in order to get the source port and the
destination IP.

Thanks again for the feedback.

On Thu, Jul 24, 2008 at 5:33 PM, Jose Carlos Luna <Jose.Carlos.Luna at cern.ch>
wrote:

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.metasploit.com/pipermail/framework/attachments/20080725/df78e0d4/attachment.htm>