DEFCON-18-Heffner-Routers-WP.pdf

Remote Attacks Against SOHO Routers

08 February, 2010

Craig Heffner

Abstract

This paper will describe how many consumer (SOHO) routers can be exploited via DNS re-binding to

gain interactive access to the router's internal-facing Web based administrative interface. Unlike other

DNS re-binding techniques, this attack does not require prior knowledge of the target router or the

router's configuration settings such as make, model, IP address, host name, etc, and does not use any

anti-DNS pinning techniques.

Confirmed affected routers include those manufactured by Linksys, Belkin, ActionTec, Thompson,

Asus and Dell, as well as those running third-party firmware such as OpenWRT, DD-WRT and

PFSense.

Existing Attacks and Their Limitations

Many SOHO routers contain vulnerabilities that can allow an attacker to disrupt or intercept network

traffic. These vulnerabilities include authentication bypass, cross-site scripting, information disclosure,

denial of service, and perhaps the most pervasive vulnerability of them all, default logins [1, 2, 3].

However, these vulnerabilities all share one common trait: with very few exceptions they exist solely

on the internal LAN, thus requiring an attacker to gain access to the LAN prior to exploiting a router's

vulnerabilities.

There are various existing attacks which may be employed by an external attacker to target a router's

internal Web interface. These attacks are best delivered via an internal client's Web browser when that

client browses to a Web page controlled by the attacker.

Cross-Site Request Forgery (CSRF) is perhaps the easiest of these attacks and is well suited for

exploiting authentication bypass vulnerabilities. However, it is restricted in several ways:

1. While it can be used to generate requests, it cannot be used to view the response. This is due to

the browser's same-domain policy, and eliminates the possibility of using CSRF to exploit

certain vulnerabilities, such as information disclosure vulnerabilities [4].

2. It cannot be used to exploit default logins on routers that employ Basic HTTP authentication.

While this used to be possible by specifying a specially crafted URL (such as

http://user:password@192.168.1.1 ), modern versions of Firefox will display a pop-up warning

to the end user, and Internet Explorer no longer recognizes such URLs as valid (see Appendix

A).

3. It requires the attacker to pre-craft his attack to target specific routers. The attacker's exploit

Web page must know or guess the router's internal IP or host name, as well as the router's make

and/or model. Although there have been some efforts to produce JavaScript-based router

identification code, it is experimental and generally does not work against routers that employ

Basic HTTP authentication for reasons described in #2 above [5].

Due to the limitations of CSRF, DNS re-binding attacks are very attractive to a remote attacker, as they

provide a means to circumvent the browser's same-domain policy and allow the attacker's code

(typically JavaScript) to interact with the router's internal Web interface [6].

The object of a DNS re-binding attack is to get a user to load JavaScript from an attacker’s Web page

and then re-bind the attacker’s domain name to the IP address of the user’s router. The attacker's

JavaScript code can then make interactive XMLHttpRequests to the router by opening a connection to

the attacker's domain name since that domain now resolves to the IP address of the victim's router. This

connection is allowed by the browser's same-domain policy since the JavaScript is running in a Web

page that originated from the attacker's domain.

However, DNS re-binding attacks are well known and Web browsers have implemented various

protections to help mitigate the threat of a DNS re-binding attack. Most notably, DNS pinning is

implemented in all modern browsers. DNS pinning attempts to prevent DNS re-binding attacks by

caching the first DNS lookup that the browser performs; without a second DNS lookup, the same IP

address will always be used for a given domain name until the browser’s cache expires or the user exits

the browser.

For this reason anti-DNS pinning attacks have become increasingly popular. These attacks attempt to

circumvent browser DNS caching and force the browser to perform a second DNS lookup, at which

time the attacker's domain name gets re-bound to an IP address of the attacker's choosing.

While DNS-rebinding attacks are possible, they have the noted disadvantage of time: such attacks take

15 seconds in Internet Explorer, and 120 seconds in Firefox [7]. Further, IE8 and Firefox 3.x browsers

no longer appear to be vulnerable to these types of DNS re-binding attacks (see Appendix B).

The Multiple A Record Attack

An older method of DNS re-binding is the “multiple A record” attack as discussed in Stanford's

Protecting Browsers From DNS Rebinding Attacks paper [8]. This attack is better known to DNS

administrators as DNS load balancing.

In this scenario, an attacker's DNS response contains two IP addresses: the IP address of the attacker's

server followed by the IP address that the attacker wishes to re-bind his domain name to. The client's

Web browser will attempt to connect to the IP addresses in the order in which they appear in the DNS

response:

1. The client's browser connects to the first IP address in the DNS response, which is the IP

address of the attacker's Web server, and retrieves the HTML file containing the attacker's

JavaScript.

2. After the client request is completed, the attacker's Web server then creates a new firewall rule

to block further connections from that client's IP address.

3. When the attacker's JavaScript initiates a request back to the attacker's domain via an

XMLHttpRequest, the browser will again try to connect to the attacker's Web server. However,

since the client's IP is now blocked, the browser will receive a TCP reset packet from the

attacker's Web server.

4. The browser will automatically attempt to use the second IP address listed in the DNS response,

which is the IP address of the client’s router. The attacker's JavaScript can now send requests to

the router as well as view the responses.

One notable restriction to the multiple A-record attack is that it can not be used to target internal IP

addresses, such as the internal IP address of a router. If a DNS response contains any non-routable IP

addresses, the browser will attempt to connect to those addresses first, regardless of their order in the

DNS response. This obviously breaks the exploit, as the attacker needs the client's browser to connect

to his public Web server first and retrieve his malicious JavaScript.

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: