Anti-DNS pinning is a technique for kinda-sorta circumventing the same domain policy enforced in Web browsers. While it does have some limitations, it is great for using a client’s browser to access restricted internal resources (such as a router’s Web interface). The problem is that whenever I see people talk about anti-DNS pinning, they make it more complex than it really should be. They focus on DNS cache time outs and forcing browsers to re-request DNS lookups and so forth. This is really all unnessesary; all an attacker really needs to do in order to thwart DNS pinning is to use DNS load balancing.

What’s so great about using DNS for load balancing? Any decently sized Web site does it; it’s pretty much standard procedure. Take a look at the DNS lookup for www.google.com and think about how it works for a second:

; <<>> DiG 9.4.3-P2 <<>> www.google.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57946
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 7, ADDITIONAL: 0

;; QUESTION SECTION:
;www.google.com.			IN	A

;; ANSWER SECTION:
www.google.com.		262385	IN	CNAME	www.l.google.com.
www.l.google.com.	82	IN	A	64.233.161.147
www.l.google.com.	82	IN	A	64.233.161.99
www.l.google.com.	82	IN	A	64.233.161.104

;; AUTHORITY SECTION:
l.google.com.		3802	IN	NS	f.l.google.com.
l.google.com.		3802	IN	NS	d.l.google.com.
l.google.com.		3802	IN	NS	c.l.google.com.
l.google.com.		3802	IN	NS	e.l.google.com.
l.google.com.		3802	IN	NS	b.l.google.com.
l.google.com.		3802	IN	NS	a.l.google.com.
l.google.com.		3802	IN	NS	g.l.google.com.

;; Query time: 0 msec
;; SERVER: 71.252.219.43#53(71.252.219.43)
;; WHEN: Mon May 11 15:23:53 2009

;; MSG SIZE  rcvd: 212
,

When your browser navigates to www.google.com, it will first try the 64.233.161.147 IP address; if that doesn’t work, it will try 64.233.161.99 and finally 64.233.161.104. Now, let’s say that we own a domain name, myevilsite.org, and we want to attack your internal router, located at 192.168.1.1. When your browser tries to navigate to myevilsite.org, it will perform a DNS lookup, and our DNS server will respond with the following:

;; ANSWER SECTION:
www.myevilsite.org	82	IN	A	12.34.56.78
www.myevilsite.org	82	IN	A	192.168.1.1

The browser will cache these IP addresses and first attempt to connect to 12.34.56.78, which is the IP address for the myevilsite.org Web server. The browser will load up our Web page that contains some JavaScript that we have crafted to assist us in this attack, and as soon as our Web server has supplied the browser with this page, it will shut down (note that the server itself is still up, just that there is no longer a service listening on port 80).

Our JavaScript then attempts to make a connection back to www.myevilsite.org via an XMLHttpRequest. Since this is within the same domain policy of the browser, the browser allows the request and attempts to connect back to 12.34.56.78; except that now the browser will recieve a TCP RST packet because there is no longer a service running on port 80 at that IP address. Upon seeing this, the browser will then try the next IP address in the list – which is 192.168.1.1. The browser thinks that it is still connecting to www.myevilsite.org, but it is actually connecting to your internal router. Since the browser sees this as still within the scope of its same-domain policy, our JavaScript that is running in your browser has full access to your router’s Web page.

Using this method, we can circumvent the DNS caching mechanism employed by the browser almost instantaneously (we don’t have to wait for anything to time out or reset or whatever). Granted, we still need to log in to the router, or otherwise bypass the login, in order to view or change settings, but we have now completely broken your firewall’s security, your browser’s security, and any anti-CSRF security that may have been implemented in your router’s Web application.

Now, think about the number of people that you know who leave their router’s login set to the default. Now think about the number of routers with security vulnerabilities that allow us to view / change settings without a valid login. Now think about people who change only the administrative login, but leave user accounts set to their defaults (this is basically anyone who uses a D-Link, since even the D-Link set-up CD ignores the unprivileged User account). That’s a lot of people who’s WPA keys we can steal, DNS settings we can configure, VOIP settings we can spy on, etc.

I wish I could say that this was all my idea, but it’s been around since at least 2002. I can say that it works very well however, and on our internal lab it takes less than a second to carry out the attack and glean all of the router’s WiFi security settings in either Firefox 3.0 or IE7. We are working on a tool to help streamline this attack, which we will hopefully have out in the coming weeks, so keep a look out for it.

We’ve already talked about our hardware-based attacks against WiFi-Protected Setup, but even without physical access to the router, WPS can still be leveraged by an attacker to gain access to a secured wireless network. Why try to crack a 60-character WPA2 key when you can run a phishing attack and force the router to give you the key instead? It’s as simple as creating an HTML image tag.

As we’ve covered before, WPS is a protocol designed to help with the distribution of WPA keys: all you have to do is push a button. From an attacker’s perspective however, it would be great if he could push that button remotely. Luckily for him, routers provide not only physical WPS push buttons, but also virtual push buttons in the administrative Web interface. When you click on the button, it just sends a standard HTTP request to the router, which causes the router to activate WPS and begin looking for a client to give the WPA key to. This is a key point, as now an attacker can use a CSRF attack to activate WPS. All the attacker has to do at that point is use a WPS-capable WiFi card to perform the WPS handshake(s) and retrieve the WPA key.

If you take a quick look at Milw0rm, there are a couple of Belkin G routers that are vulnerable to authentication bypass vulnerabilities, that is, you can change router settings without having to log in. Interestingly, our Belkin N router has these exact same vulnerabilities, suggesting that quite probably the entire line of Belkin routers also share this vulnerability (hooray for code re-use!).

To use this attack against our router, we simply crafted the following HTML page:

HTML page used to "crack" WPA2 via CSRF

This page has a hidden img tag that points to the WPS activation URL on the Belkin router. Since the Belkin is vulnerable to authentication bypass, anyone who views this page inside of our network will unknowingly activate WPS on the router. The page look innocuous when viewed in a browser:

What the page looks like in the browser window

However, by monitoring the WPS state of the router with WPSpy, we can clearly see that the router went from simply a configured state, to configured and looking for push-button WPS clients:

The Belkin router's WPS state changes when the HTML page is viewed by a client on the LAN

The attacker can now easily claim to be a WPS push button client, at which point the router will happily provide the attacker with the WPA key:

Using a WPS-capable WiFi card to retrieve the WPA key via WPS

It should be noted that Belkin routers aren’t the only ones affected by this type of attack. Various other routers have authentication-bypass vulnerabilities, and even those that don’t are still not immune. If no authentication bypass vulnerability exists, an attacker can simply create two images; the first one attempts to log in to the router with the default username / password, while the second one activates WPS.

This attack is difficult to mitigate. Even if you disable WPS, the attacker can add a second image tag that enables WPS first. Disabling JavaScript won’t even help, because you don’t need to use JavaScript to perform CSRF attacks. The best recourse is to do your homework and buy a router that (hopefully) doesn’t have an authentication bypass vulnerability, and change the default login.

This new feature is called WiFi-Protected Setup. WPS is a standard designed to ease the distribution of strong WPA/WPA2 encryption keys. Anyone who has tried to enter a 60-character WPA key into a Wii will immediately appreciate WPS; when you want to add a new client to your wireless network, you simply push a button on the router, push a button on the client (clients typically have “soft” buttons), and the two will negotiate an 802.11 EAP session which the router uses to securely send the network encryption key to the client.

Unfortunately, along with this ease-of-use, WPS brings a whole new threat into SOHO router networks: physical attacks. Physical tampering with a router used to mean some malicious person bringing in a laptop, plugging it into the router, and trying to brute force the router login. But now, an attacker can install a simple hardware back door which activates WPS at a specified interval. In fact, in some cases this can be done with nothing more than a stick of gum.

The attack is very simple; you just have to create a circuit that “pushes” the WPS button on the router. With some routers, such as Linksys, you can simply short out the pins on the WPS button, causing WPS to remain permanently on. This can be done very easily using the foil wrapper from a stick of gum:

Place the foil in the Linksys' case

When the board is placed back in the case, the foil shorts the pins on the WPS button

Use the remaining foil to cover up the WPS LED

Note that since WPS will always be activated, the WPS LED will be constantly blinking, so it’s probably a good idea to cover up the LED as shown in the above picture.

Although a simple hack, using gum to back door a router is not the best solution. In the routers tested, the gum hack only worked on our Linksys router; the rest require us to push, hold, and release the WPS button before they would activate WPS. Even in the Linksys device, this is a non-stealthy hack, as the administrative interface will (rather obnoxiously) indicate that WPS is activated whenever an administrator logs in to view the wireless settings.

A far better solution can be found by using a simple NE555 timer circuit. The push buttons are typically configured with one contact connected to ground, and the other contact connected to something else that reads the button’s state. Using an NE555, we can connect the non-ground pin on the button to ground for a second or two, and then return the pin to it’s open state. The following circuit will push the WPS button for 1.5 seconds every 2.5 minutes:

NE555 Schematic Diagram

Vcc and ground are connected to the router’s DC power supply. Since the 555 can be powered from a wide range of voltage sources (4.5v – 16v), no voltage regulator should be required (routers typically run off of 5 – 12 volt DC power adapters). Conn1 is connected to the non-grounded pin on the WPS button.

The output (pin 3) stays high for 2.5 minutes and goes low (i.e., is grounded) for 1.5 seconds. D1 ensures that there is no charge flowing into pin 3 (probably not likely, but we don’t know exactly what the WPS button is connected to). When pin 3 goes low, it effectively grounds the button connected to Conn1; resistor R3 limits any current flowing through D1 during this period. The circuit can be modified to stay high for much longer periods of time by increasing the value of the R1 resistor.

Although the NE555 is not very precise when used to time long periods, precision is not really a concern in this application, so activating WPS once every 10-12 hours is possible. This has the added benefit of making such a back door more difficult to detect; WPS has a two minute time out period (if no client is found within two minutes, the router stops looking for a client until the button is pushed again), so the light will only be blinking for two two-minute intervals throughout a 24 hour period.

Below are pictures of the above circuit connected to several routers from various vendors. Since the WPS button works the same way on basically all routers, this circuit is a universal hardware back door for practically any router that has WPS support:

The circuit connected to a Linksys WRT160N

The circuit connected to a D-Link DIR-628

The circuit soldered up and placed inside a Belkin F5D8233-4v3

Now, you just wait for WPS to be activated (WPS state can be passively monitored real-time using our WPSpy tool) and use a WPS-capable WiFi card (or software) to retrieve the key:

Using a Belkin WiFi card to retrieve the WPA key via WPS

Our presentation focuses on SOHO router security, specifically, exploiting router vulnerabilities to gain direct access to the internal WiFi network without having to crack encryption keys.

We discuss various methods of router reconnaissance, including some new tools that we’ve written specifically for this purpose, how to obtain WPA keys using simple HTML img tags, and how to own the WiFi network remotely using anti-DNS pinning attacks.

We even throw in some hardware hacks, describing how to implant a hardware backdoor into a router’s WPA encryption using nothing more than a stick of gum or a simple $8 circuit.

Download the slides here!

As always, there are going to be a lot of other great talks there too; tickets are still available and are only $100 for the conference, so if you’re going to be in the Chicago area May 8th and 9th, we hope you’ll stop by!

While there are several methods which can be used to achieve our goal, this tutorial will examine only DLL redirection. This approach was chosen for several reasons:

• It is relatively simple to implement.
• It allows us to view and modify parameters passed to an API function, change return values of that function, and run any other code we desire.
• While most other methods require code to be injected into the target process or run from an external application, DLL redirection requires only write access to the target application’s working directory.
• We can intercept any API call without modifying the target (either on disk or in memory) or any system files.

The full article has been posted on EthicalHacker.net and milw0rm.com.