HackFest: DNS Rebinding Attack http://www.defcon.org/html/links/dc-speakerscorner.html

[Lisa Kachold]

At DefCon 18, a new SOHO router exploit (while alive and well in the field
for some time) has been fully showcased: DNS rebinding Attacks:

Heffner's presentation PDF: http://thecyberjungle.com/cc/*defcon*18/*DEFCON*
-18-Heffner-*Routers*.pdf
*
This neat trick does essentially the same thing (with these two known
exloits) as any standard linux mind which has been jailbroken.*

Here's the meat from TrendMicro:

Last month at the BlackHat and DEFCON security conferences, independent
researcher Craig
Heffner<https://www.blackhat.com/html/bh-us-10/bh-us-10-briefings.html#Heffner>demonstrated
a new attack against home routers that combined DNS rebinding
and Cross-Site Request Forgery (CSRF). This attack used JavaScript to trick
the user’s browser into establishing a communication channel between the
attacker and the admin console of his/her home router. If the router
password is easy to guess (e.g., *router* or *password*) or still set to the
factory default, the attacker can quickly gain full control of the device
and by doing so expose every device on the network to attack. (For example,
the attacker might be able to change the DNS settings of the router, making
everyone connected to it vulnerable to phishing attacks.)

*The Attack: Complex but Practical and Effective*

First, the attacker has to assume a position where he/she is capable of
changing the DNS records of the domain that will be used for the attack.
Next, the attacker will need to create various pages on the malicious domain
that will host the Web side of the attack and link these with DNS. Finally,
the attacker must have sufficient control of the Web server such that he/she
can cause it to send a TCP *reset* (RST) command on demand.

The attack begins when the user visits the malicious site. Heffner used DNS
to collect the victim’s public IP address but there other ways to do this as
well. Once the attacker has the victim’s public IP address, he/she needs to
quickly create a new subdomain on the attack domain with 2 *A* records,
which map a hostname to an IP address. The first *A* record points to the
server while the second points to the public IP address of the victim’s
router. The Web server now redirects the victim’s browser to a page with
JavaScript code that will execute the CSRF portion of the attack.

Now we get to the interesting part. The browser begins to execute the
JavaScript code that tries to connect to the temporary subdomain. The
attacking server will reply with an *RST* command and end the session. This
user’s system will then try the other IP address that it knows about for the
hostname, which happens to be the external IP address of the victim’s
router. Any result is channeled to the attacking server via a portal. The
attacker can try different user name and password combination until he/she
successfully connects or the browser window/tab is closed.

*How Users Can Protect Themselves***

Normally, the admin console is not exposed to the Internet because many
consumer routers include a default setting (or provide an option) that
prevents any IP address outside of the local network from connecting to it.
However, many services on these devices listen for connections on all
interfaces. Packet filtering will prevent external users from accessing the
admin console but internal users can often access the console using an
external IP address.

Here are some suggestions that will reduce risks brought about by this
attack based on the list of suggestions provided by Craig Heffner:

   - Enable the HTTPS admin console on your device and don’t forget to
   disable the HTTP console (if possible).
   - Use a strong password for your router. Change the user name to
   something other than the factory default, if possible. If you worry about
   forgetting the new password, write it down and put it on the device itself.
   - Disable access to your router’s admin console from any external
   network. This option is often accessible from the admin console.
   - If you choose not to use the DNS servers automatically provided by your
   ISP, use another recursive resolver (with permission) or a resolver offered
   for public use such as OpenDNS <http://www.opendns.com/>. This will
   protect you from the published version of this attack code and the root
   servers will thank you.
   - If possible, add a firewall rule preventing devices on your local
   network from sending packets to the block that your public IP address is a
   member of. This will prevent any IP addresses on your LAN from contacting
   the external IP address of your router. If your ISP changes the block used
   in your neighborhood, however, you will need to edit this rule. As an added
   benefit, this rule will prevent your systems from inadvertently broadcasting
   to your neighbors.
   - Keep the firmware of your router and other network devices up-to-date.

*Updates as of August 5, 2010, 2:05 a.m. UTC*

Since this attack involves the usage of a malicious JavaScript, installing
the NoScript <http://noscript.net/> plugin should be helpful in preventing
being victimized by such attacks.

OpenDNS also discussed this same
issue<http://blog.opendns.com/2010/07/27/calling-craig-heffner/>,
and stated that using OpenDNS may be a valid solution to prevent these
attacks.  Here's their security patch for their firmware:
http://i.imgur.com/FGy89.png
Read more:
http://blog.trendmicro.com/protecting-your-router-against-possibl-dns-rebinding-attacks/#ixzz0yQ20mQ6h

Old router attack paper from 2003:
http://data.nicenamecrew.com/papers/malwareforrouters/paper.txt

List of SOHO routers currently still effected:
https://spreadsheets.google.com/pub?key=0Aupu_01ythaUdGZINXQ5Vi16X3hXb3VPYkszNXM0YXc


I was personally attacked with this one; as well as discovered new web pages
and greyed out buttons on stock pages.  Downloading the firmware and
evaluating the hexdump showed a port 564 tunnel to an IP on a known NSA
network.  I found my best skill in side stepping issues was to regularly
reset to factory firmware, rebuild, set new passwords after a completely new
most recent FW flash, in addition to all the other things that include
disabling port 80/443 access from any internal ip coming from outside
interface, or port forwarding all inbound 80/443 to a subnet not used in the
internal network, and/or turning on deep packet inspection IPS for
javascript, http proxy, active X. And disabling UPNP.  Limiting multcast
/unicast packets help also, but, the best tool to protect yourself is the
purchase of secure device that includes VLAN/VPN, IPS/IDS. different zones
for wireless ad Ethernet, split DNS, RADIUS for Enterprise WPK2, etc.

I also have a SMB version with two processors..  NOTE: All Linkssys/cisco
have open sores-code so the stack can easily be modified by loop mounting
the iso. All linksys code base can be recompiled custom on a linux
development suggests and build howto tells us.
-- 
Office: (602)239-3392
AT&T: (503)754-4452
http://it-clowns.com <http://it-clowns.com/wiki/index.php?title=Obnosis>

Come to plug GangPlank HackFest LAB September 4, 2010 Saturday Noon-3p;  We
will rollout new Drupal Project Organizational Tools for HackFesting,
Carpooling and more!

Email me to get a ride from West Phoenix early Saturday say 10:00 AM.  You
can help carry the equipment?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.PLUG.phoenix.az.us/pipermail/plug-discuss/attachments/20100902/71a24349/attachment.html>