Professional Documents
Culture Documents
• Firewall Circumvention. The attacker can use DNS re- Abusing Internal Open Services. Internal networks
binding to access machines behind firewalls that he or contain many open services intended for internal use only.
she cannot access directly. With direct socket access, For example, network printers often accept print jobs from
the attacker can interact with a number of internal internal machines without additional authentication. The
services besides HTTP. attacker can use direct socket access to command network
printers to exhaust their toner and paper supplies.
• IP Hijacking. The attacker can also use DNS rebinding Similarly, users inside firewalls often feel comfortable cre-
to access publicly available servers from the client’s IP ating file shares or FTP servers accessible to anonymous
address. This allows the attacker to take advantage of users under the assumption that the servers will be avail-
the target’s implicit or explicit trust in the client’s IP able only to clients within the network. With the ability to
address. read and write arbitrary sockets, the attacker can exfiltrate
the shared documents and use these servers to store illicit
To mount these attacks, the attacker must first induce the information for later retrieval.
client to load some active content. This can be done by a Consumer routers are often installed without changing the
variety of techniques discussed in Section 4.4. Once loaded default password, making them an attractive target for re-
onto the client’s machine, the attacker’s code can communi- configuration attacks by web pages [40]. Firmware patches
cate with any machine reachable by the client. have attempted to secure routers against cross-site scripting
and cross-site request forgery, in an effort to prevent recon-
4.1 Firewall Circumvention figuration attacks. DNS rebinding attacks allow the attacker
A firewall restricts traffic between computer networks in direct socket access to the router, bypassing these defenses.
different zones of trust. Some examples include blocking
connections from the public Internet to internal machines 4.2 IP Hijacking
and mediating connections from internal machines to Inter- Attackers can also use DNS rebinding attacks to target
net servers with application-level proxies. Firewall circum- machines on the public Internet. For these attacks, the at-
vention attacks bypass the prohibition on inbound connec- tacker is not leveraging the client’s machine to connect to
tions, allowing the attacker to connect to internal servers otherwise inaccessible services but instead abusing the im-
while the user is visiting the attacker’s Internet web page plicit or explicit trust public services have in the client’s IP
(see Figure 1). address. Once the attacker has hijacked a client’s IP ad-
Spidering the Intranet. The attacker need not specify dress, there are several attacks he or she can perpetrate.
the target machine by IP address. Instead, the attacker Committing Click Fraud. Web publishers are often paid
can guess the internal host name of the target, for example by web advertisers on a per-click basis. Fraudulent publish-
hr.corp.company.com, and rebind attacker.com to a CNAME ers can increase their advertising revenue by generating fake
record pointing to that host name. The client’s own recur- clicks, and advertisers can drain competitors’ budgets by
sive DNS resolver will complete the resolution and return clicking on their advertisements. The exact algorithms used
the IP address of the target. Intranet host names are often by advertising networks to detect these “invalid” clicks are
guessable and occasionally disclosed publicly [30, 9]. This proprietary, but the IP address initiating the click is widely
technique obviates the need for the attacker to scan IP ad- believed to be an essential input. In fact, one common use
dresses to find an interesting target but does not work with of bot networks is to generate clicks [7].
the multiple A record technique described in Section 3.1. Click fraud would appear to require only the ability to
Having found a machine on the intranet, the attacker can send HTTP requests to the advertising network, but adver-
connect to the machine over HTTP and request the root tisers defend against the send-only attacks, permitted by the
document. If the server responds with an HTML page, the same-origin policy, by including a unique nonce with every
attacker can follow links and search forms on that page, advertising impression. Clicks lacking the correct nonce are
eventually spidering the entire intranet. Web servers inside rejected as invalid, requiring the attacker to read the nonce
corporate firewalls often host confidential documents, rely- from an HTTP response in order to generate a click.
ing on the firewall to prevent untrusted users from accessing This attack is highly cost-effective, as the attacker can
the documents. Using a DNS rebinding attack, the attacker buy advertising impressions, which cost tens of cents per
can leverage the client’s browser to read these documents thousand, and convert them into clicks, worth tens of cents
and exfiltrate them to the attacker, for example by submit- each. The attack is sufficiently cost-effective that the at-
ting an HTML form to the attacker’s web server. tacker need not convert every purchased impression into a
Compromising Unpatched Machines. Network admin- click. Instead, the fraudster can use most of the purchased
istrators often do not patch internal machines as quickly impressions to generate fake impressions on the site, main-
as Internet-facing machines because the patching process is taining a believable click-through rate.
time-consuming and expensive. The attacker can attempt
Sending Spam. Many e-mail servers blacklist IP addresses Vulnerability Impressions
known to send spam e-mail [39]. By hijacking a client’s IP Flash Player 9 86.9%
address, an attacker can send spam from IP addresses with LiveConnect 24.4%
clean reputations. To send spam e-mail, the attacker need Java+Proxy 2.2%
only write content to SMTP servers on port 25, an action Total Multi-Pin 90.6%
blocked by most browsers but permitted by Flash Player
and Java. Additionally, an attacker will often be able to use Table 2: Percentage of Impressions by Vulnerability
the client’s actual mail relay. Even service providers that
require successful authentication via POP3 before sending Cumulative Duration of Successful Attacks
e-mail are not protected, because users typically leave their for 75% Shortest Duration Attacks
desktop mail clients open and polling their POP3 servers.
100
Framing Clients. An attacker who hijacks an IP address Cumulative Duration of Successful Attacks
can perform misdeeds and frame the client. For example, 100,000
an attacker can attempt to gain unauthorized access to a
computer system using a hijacked IP address as a proxy. Successful Attacks (logscale) 10,000
As the attack originates from the hijacked IP address, the
logs will implicate the client, not the attacker, in the crime. 1,000
Moreover, if the attacker hosts the malicious web site over
HTTPS, the browser will not cache the page and no traces 100
will be left on the client’s machine.
10
4.3 Proof-of-Concept Demonstration
1
We developed proof-of-concept exploits for DNS rebinding
1 10 100 1000 10000 100000 1000000
vulnerabilities in Flash Player 9, LiveConnect, Java applets Duration of Attack Success (secs, logscale)
with proxy servers, and the browser itself. Our system con-
sists of a custom DNS server authoritative for dnsrebinding.net,
a custom Flash Player policy server, and a standard Apache Figure 2: Duration of Successful Attacks
web server. The various technologies issue DNS queries
that encode the attacker and target host names, together
with a nonce, in the subdomain. For each nonce, the DNS The experiment lasted until the user navigated away from
server first responds with the attacker’s IP address (with a the advertisement, at which time we lost the ability to use
zero TTL) and thereafter with the target’s IP address. Our the viewer’s network connection. For privacy, we collected
proof-of-concept demo, http://crypto.stanford.edu/dns, only properties typically disclosed by browsers when viewing
implements wget and telnet by mounting a rebinding at- web pages (e.g., plug-in support, user agent, and external IP
tack against the browser. address). The experiment conformed to the terms of service
of the advertising network and to the guidelines of the in-
4.4 Experiment: Recruiting Browsers dependent review board at our institution. Every network
operation produced by the advertisement could have been
Methodology. We tested DNS rebinding experimentally produced by a legitimate SWF advertisement, but we pro-
by running a Flash Player 9 advertisement on a minor ad- duced the operations through the Socket interface, demon-
vertising network targeting the keywords “Firefox,” “game,” strating the ability to make arbitrary TCP connections.
“Internet Explorer,” “video,” and “YouTube.” The experi-
ment used two machines in our laboratory, an attacker and a Results. We ran the ad beginning at midnight EDT on
target. The attacker ran a custom authoritative DNS server three successive nights in late April 2007. We bid $0.50
for dnsrebinding.net, a custom Flash Player policy server, per 1000 impressions for a variety of keywords. We spent
and an Apache web server hosting the advertisement. The $10 per day, garnering approximately 20,000 impressions per
target ran an Apache web server to log successful attacks. day. Due to a server misconfiguration, we disregarded ap-
The Flash Player advertisement exploited the vulnerability proximately 10,000 impressions. We also disregarded 19 im-
described in Section 3.1 to load an XML document from the pressions from our university. We received 50,951 impres-
target server in our lab. The attack required only that the sions from 44,924 unique IP addresses (40.2% IE7, 32.3%
client view the ad, not that the user click on the ad. IE6, 23.5% Firefox, 4% Other).
We ran the rebinding experiment on the 44,301 (86.9%) can be blocked either by filtering packets at the firewall [5]
impressions that reported Flash Player 9. We did not at- or by modifying the DNS resolvers used by clients on the
tempt to exploit other rebinding vulnerabilities (see Ta- network.
ble 2). The experiment was successful on 30,636 (60.1%)
impressions and 27,480 unique IP addresses. The attack • Enterprise. By blocking outbound traffic on port 53, a
was less successful on the 1,672 impressions served to Mac firewall administrator for an organization can force all
OS, succeeding 36.4% of the time, compared to a success internal machines, including HTTP proxies and VPN
rate of 70.0% on the 49,535 (97.2%) Windows impressions.4 clients, to use a DNS server that is configured not to
Mac OS is more resistant to this rebinding attack due to resolve external names to internal IP addresses. To
some caching of DNS entries despite their zero TTL. implement this approach, we developed a 300 line C
For each successful experiment, we measured how long an program, dnswall [15], that runs alongside BIND and
attacker could have used the client’s network access by load- enforces this policy.
ing the target document at exponentially longer intervals, as
• Consumer. Many consumer firewalls, such as those
shown in Figure 2. The median impression duration was 32
produced by Linksys, already expose a caching DNS
seconds, with 25% of the impressions lasting longer than 256
resolver and can be augmented with dnswall to block
seconds. We observed 9 impressions with a duration of at
DNS responses that contain private IP addresses. The
least 36.4 hours, 25 at least 18.2 hours, and 81 at least 9.1
vendors of these devices have an incentive to patch
hours. In aggregate, we obtained 100.3 machine-days of net-
their firewalls because these rebinding attacks can be
work access. These observations are consistent with those
used to reconfigure these routers to mount further at-
of [24]. The large number of attacks ending between 4.2 and
tacks on their owners.
8.5 minutes suggests that this is a common duration of time
for users to spend on a web page. • Software. Software firewalls, such as the Windows
Firewall, can also prevent their own circumvention by
Discussion. Our experimental results show that DNS re-
blocking DNS resolutions to 127.*.*.*. This tech-
binding vulnerabilities are widespread and cost-effective to
nique does not defend services bound to the external
exploit on a large scale. Each impression costs $0.0005 and
network interface but does protects a large number of
54% of the impressions convert to successful attacks from
services that bind only to the loopback interface.
unique IP addresses. To hijack 100,000 IP addresses for a
temporary bot network, and attacker would need to spend Blocking external names from resolving to internal addresses
less than $100. This technique compares favorably to rent- prevents firewall circumvention but does not defend against
ing a traditional bot network for sending spam e-mail and IP hijacking. An attacker can still use internal machines to
committing click fraud for two reasons. First, these applica- attack services running on the public Internet.
tions require large numbers of “fresh” IP address for short
durations as compromised machines are quickly blacklisted. 5.2 Fixing Plug-ins
Second, while estimates of the rental cost of bot networks Plug-ins are a particular source of complexity in defend-
vary [44, 14, 7], this technique appears to be at least one or ing against DNS rebinding attacks because they enable sub-
two orders of magnitude less expensive. second attacks, provide socket-level network access, and op-
erate independently from browsers. In order to prevent re-
5. DEFENSES AGAINST REBINDING binding attacks, these plug-ins must be patched.
Defenses for DNS rebinding attacks can be implemented Flash Player. When a SWF movie opens a socket to a
in browsers, plug-ins, DNS resolvers, firewalls, and servers. new host name, it requests a policy over the socket to de-
These defenses range in complexity of development, diffi- termine whether the host accepts socket connections from
culty of deployment, and effectiveness against firewall cir- the origin of the movie. Flash Player could fix most of
cumvention and IP hijacking. In addition to necessary mit- its rebinding vulnerabilities by considering a policy valid
igations for Flash Player, Java LiveConnect, and browsers, for a socket connection only if it obtained the policy from
we propose three long-term defenses. To protect against fire- the same IP address in addition to its current requirement
wall circumvention, we propose a solution that can be de- that it obtained the policy from the same host name. Us-
ployed unilaterally by organizations at their network bound- ing this design, when attacker.com is rebound to the tar-
ary. To fully defend against rebinding attacks, we propose get IP address, Flash Player will refuse to open a socket to
two defenses: one that requires socket-level network access that address unless the target provides a policy authorizing
be authorized explicitly by the destination server and an- attacker.com. This simple refinement uses existing Flash
other works even if sockets are allowed by default. Player policy deployments and is backwards compatible, as
host names expecting Flash Player connections already serve
5.1 Fixing Firewall Circumvention policy documents from all of their IP addresses.
Networks can be protected against firewall circumvention SWF movies can also access ports numbers ≥ 1024 on
by forbidding external host names from resolving to internal their origin host name without requesting a policy. Al-
IP addresses, effectively preventing the attacker from nam- though the majority of services an attacker can profitably
ing the target server. Without the ability to name the tar- target (e.g., SMTP, HTTP, HTTPS, SSH, FTP, NNTP)
get, the attacker is unable to aggregate the target server into are hosted on low-numbered ports, other services such as
an origin under his or her control. These malicious bindings MySQL, BitTorrent, IRC, and HTTP proxies are vulnera-
4
We succeeded in opening a socket with 2 of 11 PlayStation 3 ble. To fully protect against rebinding attacks, Flash Player
impressions (those with Flash Player 9), but none of the 12 could request a policy before opening sockets to any port,
Nintendo Wii impressions were vulnerable. even back to its origin. However, this modification breaks
backwards compatibility because those servers might not be • IP Addresses. Refining origins with IP address [28]
already serving policy files. is more robust than pinning in that a single browsing
session can fail-over from one IP address to another.
Java. Many deployed Java applets expect sockets to be al- When such a fail-over occurs, however, it will likely
lowed by default. If clients are permitted to use these applets break long-lived AJAX applications, such as Gmail,
from behind HTTP proxies, they will remain vulnerable to because they will be prevented from making XML-
multi-pin attacks because proxy requests are made by host HttpRequests to the new IP address. Users can recover
name instead of by IP address. A safer approach is to use the from this by clicking the browser’s reload button. Un-
CONNECT method to obtain a proxied socket connection to an fortunately, browsers that use a proxy server do not
external machine. Typically proxies only allow CONNECT on know the actual IP address of the remote server and
port 443 (HTTPS), making this the only port available for thus cannot properly refine origins. Also, this defense
these applets. Alternatively, proxies can use HTTP head- is vulnerable to an attack using relative paths to script
ers to communicate IP addresses of hosts between the client files, similar to the applet relative-path vulnerability
and the proxy [28, 29], but this approach requires both the described in Section 3.2.
client and the proxy to implement the protocol.
• Public Keys. Augmenting origins with public keys [27,
Java LiveConnect. LiveConnect introduces additional 23] prevents two HTTPS pages served from the same
vulnerabilities, but browsers can fix the LiveConnect multi- domain with different public keys from reading each
pin vulnerability without altering the JVM by installing other’s state. This defense is useful when users dis-
their own DNS resolver into the JVM using a standard miss HTTPS invalid certificate warnings and chiefly
interface. Firefox, in particular, implements LiveConnect protects HTTPS-only “secure” cookies from network
through the Java Native Interface (JNI). When Firefox ini- attackers. Many web pages, however, are not served
tializes the JVM, it can install a custom InetAddress class over HTTPS, rendering this defense more appropriate
that will handle DNS resolution for the JVM. This custom for pharming attacks that compromise victim domains
class should contain a native method that implements DNS than for rebinding attacks.
resolution using Firefox’s DNS resolver instead of the system
resolver. If the browser implements pinning, LiveConnect
and the browser will use a common pin database, removing Smarter Pinning. To mitigate rebinding attacks, browsers
multi-pin vulnerabilities. can implement smarter pinning policies. Pinning is a de-
fense for DNS rebinding that trades off robustness for secu-
5.3 Fixing Browsers (Default-Deny Sockets) rity. RFC 1035 [32] provides for small (and even zero) TTLs
to enable dynamic DNS and robust behavior in the case of
Allowing direct socket access by default precludes many
server failure but respecting these TTLs allows rebinding
defenses for DNS rebinding attacks. If browser plug-ins de-
attacks. Over the last decade, browsers have experimented
faulted to denying socket access, as a patched Flash Player
with different pin durations and release heuristics, leading
and the proposed TCPConnection (specified in HTML5 [19])
some vendors to shorten their pin duration to improve ro-
would, these defenses would become viable. Java and Live-
bustness [13]. However, duration is not the only parameter
Connect, along with any number of lesser-known plug-ins,
that can be varied in a pinning policy.
expect socket access to be allowed, and fixing these is a chal-
Browsers can vary the width of their pins by permitting
lenge.
host names to be rebound within a set of IP addresses that
Checking Host Header. HTTP 1.1 requires that user meet some similarity heuristic. Selecting an optimal width
agents include a Host header in HTTP requests that spec- as well as duration enables a better trade-off between se-
ifies the host name of the server [11]. This feature is used curity and robustness than optimizing duration alone. One
extensively by HTTP proxies and by web servers to host promising policy is to allow rebinding within a class C net-
many virtual hosts on one IP address. If sockets are de- work. For example, if a host name resolved to 171.64.78.10,
nied by default, the Host header reliably indicates the host then the client would also accept any IP address beginning
name being used by the browser to contact the server be- with 171.64.78 for that host name. The developers of the
cause XMLHttpRequest [43] and related technologies are re- NoScript Firefox extension [26] have announced plans [25]
stricted from spoofing the Host header.5 One server-side de- to adopt this pinning heuristic.
fense for these attacks is therefore to reject incoming HTTP
• Security. When browsers use class C network pinning,
requests with unexpected Host headers [28, 37].
the attacker must locate the attack server on the same
Finer-grained Origins. Another defense against DNS class C network as the target, making the rebinding
rebinding attacks is to refine origins to include additional attack much more difficult to mount. The attack is
information, such as the server’s IP address [28] or public possible only if the attacker co-locates a server at the
key [27, 23], so that when the attacker rebinds attacker.com same hosting facility or leverages a cross-site scripting
to the target, the browser will consider the rebound host vulnerability on a co-located server. This significantly
name to be a new origin. One challenge to deploying finer- raises the bar for the attacker and provides better re-
grained origins is that every plug-in would need to revise its courses for the target.
security policies and interacting technologies would need to
• Robustness. To study the robustness of class C net-
hand-off refined origins correctly.
work pinning, we investigated the IP addresses re-
5
Lack of integrity of the Host header has been a recur- ported by the 100 most visited English-language sites
ring source of security vulnerabilities, most notably in Flash (according to Alexa [3]). We visited the home page of
Player 7. these sites and compiled a list of the 336 host names
used for embedded content (e.g., www.yahoo.com em- either changes the semantics of DNS for other applica-
beds images from us.i1.yimg.com). We then issued tions or requires that the OS treats browsers and their
DNS queries for these hosts every 10 minutes for 24 plug-ins differently from other applications.
hours, recording the IP addresses reported.
• Cache. The browser’s cache and all plug-in caches
In this experiment, 58% reported a single IP address
must be modified to prevent rebinding attacks. Cur-
consistently across all queries. Note that geographic
rently, objects stored in the cache are retrieved by
load balancing is not captured in our data because we
URL, irrespective of the originating IP address, creat-
issued our queries from a single machine, mimicking
ing a rebinding vulnerability: a cached script from the
the behavior of a real client. Averaged over the 42%
attacker might run later when attacker.com is bound
of hosts reporting multiple IP addresses, if a browser
to the target. To prevent this attack, objects in the
pinned to an IP address at random, the expected frac-
cache must be retrieved by both URL and originat-
tion of IP addresses available for rebinding under class
ing IP address. This degrades performance when the
C network pinning is 81.3% compared with 16.4% un-
browser pins to a new IP address, which might occur
der strict IP address pinning, suggesting that class C
when the host at the first IP address fails, the user
pinning is significantly more robust to server failure.
starts a new browsing session, or the user’s network
Other heuristics for pin width are possible. For example, connectivity changes. These events are uncommon and
the browser could prevent rebinding between public IP ad- are unlikely to impact performance significantly.
dresses and the RFC 1918 [35] private IP addresses. This
provides greater robustness for fail-overs across data centers • document.domain. Even with the strictest pinning, a
and for dynamic DNS. LocalRodeo [22, 45] is a Firefox ex- server is vulnerable to rebinding attacks if it hosts a
tension that implements RFC 1918 pinning for JavaScript. web page that executes the following, seemingly in-
As for security, RFC 1918 pinning largely prevents firewall nocuous, JavaScript:
circumvention but does not protect against IP hijacking nor document.domain = document.domain;
does it prevent firewall circumvention in the case where a
firewall protects non-private IP addresses, which is the case After a page sets its domain property, the browser al-
for many real-life protected networks and personal software lows cross-origin interactions with other pages that
firewalls. have set their domain property to the same value [42,
Even the widest possible pinning heuristic prevents some 17]. This idiom, used by a number of JavaScript li-
legitimate rebinding of DNS names. For example, public braries6 , sets the domain property to a value under
host names controlled by an organization often have two IP the control of the attacker: the current host name.
addresses, a private IP address used by clients within the
firewall and a public IP address used by clients on the Inter- 5.4 Fixing Browsers (Default-Allow Sockets)
net. Pinning prevents employees from properly connecting Instead of trying to prevent a host name from rebinding
to these severs after joining the organization’s Virtual Pri- from one IP address to another—a fairly common event—a
vate Network (VPN) as those host names appear to rebind different approach to defending against rebinding is to pre-
from public to private IP addresses. vent the attacker from naming the target server, essentially
generalizing dnswall to the Internet. Without the ability to
Policy-based Pinning. Instead of using unpinning heuris- name the target server, the attacker cannot mount a DNS
tics, we propose browsers consult server-supplied policies to rebinding attack against the target. This approach defends
determine when it is safe to re-pin a host name from one IP against rebinding, can allow socket access by default, and
address to another, providing robustness without degrading preserves the robustness of dynamic DNS.
security. To re-pin safely, the browser must obtain a policy
from both the old and new IP address (because some at- Host Name Authorization. On the Internet, clients re-
tacks first bind to the attacker whereas others first bind to quire additional information to determine the set of valid
the target). Servers can supply this policy at a well-known host names for an given IP address. We propose that servers
location, such as /crossdomain.xml, or in reverse DNS (see advertise the set of host names they consider valid for them-
Section 5.4). selves and clients check these advertisements before binding
a host name to an IP address, making explicit which host
Pinning Pitfalls. Correctly implementing pinning has sev-
names can map to which IP addresses. Host name autho-
eral subtleties that are critical to its ability to defend against
rization prevents rebinding attacks because honest machines
DNS rebinding attacks.
will not advertise host names controlled by attackers.
• Common Pin Database. To eliminate multi-pin at- Reverse DNS already provides a mapping from IP ad-
tacks, pinning-based defense require that all browser dresses to host names. The owner of an IP address ip is
technologies that access the network share a common delegated naming authority for ip.in-addr.arpa and typi-
pin database. Many plug-ins, including Flash Player cally stores a PTR record containing the host name associ-
and Silverlight, already use the browser’s pins when ated with that IP address. These records are insufficient
issuing HTTP requests because they issue these re- for host name authorization because a single IP address can
quests through the browser. To share DNS pins for have many valid host names, and existing PTR records do
other kinds of network access, either the browser could not indicate that other host names are invalid.
expose an interface to its pin database or the operating 6
For example, “Dojo” AJAX library, Struts servlet/JSP
system could pin in its DNS resolver. Unfortunately, based web application framework, jsMath AJAX Mathemat-
browser vendors appear reluctant to expose such an ics library, and Sun’s “Ultimate client-side JavaScript client
interface [12, 33] and pinning in the operating system sniff” library are vulnerable in this way.
The reverse DNS system can be extended to authorize Trusted Policy Providers. Clients and DNS resolvers
host names without sacrificing backwards compatibility. To can also check policy by querying a trusted policy provider.
authorize the host www.example.com for 171.64.78.146, the Much like spam black lists [39] and phishing filters [6, 31,
owner of the IP address inserts the following DNS records: 16], different policy providers can use different heuristics to
determine whether a host name is valid for an IP address,
auth.146.78.64.171.in-addr.arpa. but every provider should respect host names authorized
IN A 171.64.78.146 in reverse DNS. When correctly configured, host name au-
www.example.com.auth.146.78.64.171.in-addr.arpa. thorization in reverse DNS has no false negatives (no valid
IN A 171.64.78.146 host name is rejected) but many false positives (lack of pol-
To make a policy-enabled resolution for www.example.com, icy is implicit authorization). Trusted policy providers can
first resolve the host name a set of IP addresses normally greatly reduce the false positive rate, possibly at the cost of
and then validate each IP address as follows: increasing the false negative rate. Clients are free to select
as aggressive a policy provider as they desire.
1. Resolve the host name auth.ip.in-addr.arpa.
2. If the host name exists, ip is policy-enabled and ac- 6. RELATED WORK
cepts only authorized host names. Otherwise, ip is
not policy-enabled and accepts any host name. Using Browsers as Bots. The technique of luring web
users to an attacker’s site and then distracting them while
3. Finally, if ip is policy-enabled, resolve the host name their browsers participate in a coordinated attack is de-
www.example.com.auth.ip.in-addr.arpa scribed in [24]. These “puppetnets” can be used for dis-
tributed denial of service but cannot be used to mount the
to determine if the host name is authorized. attacks described in Section 4 because puppetnets cannot
read back responses from different origins or connect to for-
An IP address ip implicitly authorizes every host name of bidden ports such as 25.
the form *.auth.ip.in-addr.arpa, preventing incorrect re- JavaScript can also be misused to scan behind firewalls [18]
cursive policy checks. For host names with multiple IP ad- and reconfigure home routers [40]. These techniques of-
dresses, only authorized IP addresses should be included in ten rely on exploiting default passwords and on underlying
the result. If no IP addresses are authorized, the result cross-site scripting or cross-site request forgery vulnerabil-
should be “not found.” If an IP address is not policy en- ities. DNS rebinding attacks can be used to exploit de-
abled, DNS rebinding attacks can be mitigated using the fault passwords without the need for a cross-site scripting
techniques in Section 5.3. or cross-site request forgery hole.
The policy check can be implemented in DNS resolvers7 ,
such as ones run by organizations and ISPs, transparently Sender Policy Framework. To fight spam e-mail, the
protecting large groups of machines from having their IP Sender Policy Framework (SPF) [46] stores policy informa-
addresses hijacked. User agents, such as browser and plug- tion in DNS. SPF policies are stored as TXT records in for-
ins, can easily query the policy records because they are ward DNS, where host names can advertise the set of IP
stored in A records and can issue policy checks in paral- addresses authorized to send e-mail on their behalf.
lel with HTTP requests (provided they do not process the
HTTP response before the host name is authorized). Stan-
dard DNS caching reduces much of the overhead of redun- 7. CONCLUSIONS
dant policy checks issued by DNS resolvers, browsers, and An attacker can exploit DNS rebinding vulnerabilities to
plug-ins. As a further optimization, policy-enabled resolvers circumvent firewalls and hijack IP addresses. Basic DNS re-
can include policy records in the “additional” section of the binding attacks have been known for over a decade, but the
DNS response, allowing downstream resolvers to cache com- classic defense, pinning, reduces robustness and fails to pro-
plete policies and user-agents to get policy records without tect current browsers that use plug-ins. Modern multi-pin
a separate request. We have implemented host name autho- attacks defeat pinning in hundreds of milliseconds, granting
rization as a 72-line patch to Firefox 2. the attacker direct socket access from the client’s machine.
One disadvantage of this mechanism is that the owner of These attacks are a highly cost-effective technique for hi-
an IP address, the ISP, might not be the owner of the ma- jacking hundreds of thousands of IP addresses for sending
chine at that IP address. The machine can advertise the spam e-mail and committing click fraud.
correct set of authorized host names only if the ISP is will- For network administrators, we provide a tool to prevent
ing to delegate the auth subdomain to the owner or insert DNS rebinding from being used for firewall circumvention
appropriate DNS records. Instead, machines could advertise by blocking external DNS names from resolving to internal
authorized host names over HTTP in a well-known location, IP addresses. For the vendors of Flash Player, Java, and
similar to crossdomain.xml, but this has several disadvan- LiveConnect, we suggest simple patches that mitigate large-
tages: it requires policy-enabled DNS resolvers to implement scale exploitation by vastly reducing the cost-effectiveness
HTTP clients, it requires all machines, such as SMTP gate- of the attacks for sending spam e-mail and committing click
ways, to run an HTTP server, and policy queries are not fraud. Finally, we propose two defense options that prevent
cached, resulting in extra traffic comparable to favicon.ico. both firewall circumvention and IP hijacking: policy-based
7
To prevent a subtle attack that involves poisoning DNS pinning and host name authorization. We hope that ven-
caches, a policy-enabled DNS resolver must follow the same dors and network administrators will deploy these defenses
procedure for CNAME queries as for A queries, even though quickly before attackers exploit DNS rebinding on a large
responses to the former do not directly include IP addresses. scale.
Acknowledgments [22] M. Johns and J. Winter. Protecting the Intranet
We thank Drew Dean, Darin Fisher, Jeremiah Grossman, against “JavaScript Malware” and related attacks. In
Martin Johns, Dan Kaminsky, Chris Karlof, Jim Roskind, Proc. DIMVA, July 2007.
and Dan Wallach for their helpful suggestions and feedback. [23] C. K. Karlof, U. Shankar, D. Tygar, and D. Wagner.
This work is supported by grants from the National Science Dynamic pharming attacks and the locked same-origin
Foundation and the US Department of Homeland Security. policies for web browsers. In Proc. CCS, October 2007.
[24] V. T. Lam, S. Antonatos, P. Akritidis, and K. G.
Anagnostakis. Puppetnets: Misusing web browsers as
8. REFERENCES a distributed attack infrastructure. In Proc. CCS,
[1] Adobe. Flash Player Penetration. http://www.adobe. 2006.
com/products/player census/flashplayer/. [25] G. Maone. DNS Spoofing/Pinning. http:
[2] Adobe. Adobe Flash Player 9 Security. //sla.ckers.org/forum/read.php?6,4511,14500.
http://www.adobe.com/devnet/flashplayer/ [26] G. Maone. NoScript. http://noscript.net/.
articles/flash player 9 security.pdf, July 2006. [27] C. Masone, K. Baek, and S. Smith. WSKE: web server
[3] Alexa. Top sites. http://www.alexa.com/site/ds/ key enabled cookies. In Proc. USEC, 2007.
top sites?ts mode=global. [28] A. Megacz. XWT Foundation Security Advisory.
[4] K. Anvil. Anti-DNS pinning + socket in flash. http://xwt.org/research/papers/sop.txt.
http://www.jumperz.net/, 2007. [29] A. Megacz and D. Meketa. X-RequestOrigin.
[5] W. Cheswick and S. Bellovin. A DNS filter and switch http://www.xwt.org/x-requestorigin.txt.
for packet-filtering gateways. In Proc. Usenix, 1996. [30] Microsoft. Microsoft Web Enterprise Portal, January
[6] N. Chou, R. Ledesma, Y. Teraguchi, and J. Mitchell. 2004. http://www.microsoft.com/technet/
Client-side defense against web-based identity theft. itshowcase/content/MSWebTWP.mspx.
In Proc. NDSS, 2004. [31] Microsoft. Microsoft phishing filter: A new approach
[7] N. Daswani, M. Stoppelman, et al. The anatomy of to building trust in e-commerce content, 2005.
Clickbot.A. In Proc. HotBots, 2007. [32] P. Mockapetris. Domain Names—Implementation and
[8] D. Dean, E. W. Felten, and D. S. Wallach. Java Specification. IETF RFC 1035, November 1987.
security: from HotJava to Netscape and beyond. In [33] C. Nuuja (Adobe), 2007. Personal communication.
IEEE Symposium on Security and Privacy: Oakland, [34] G. Ollmann. The pharming guide. http://www.
California, May 1996. ngssoftware.com/papers/ThePharmingGuide.pdf,
[9] D. Edwards. Your MOMA knows best, December August 2005.
2005. http://xooglers.blogspot.com/2005/12/ [35] Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J.
your-moma-knows-best.html. de Groot, and E. Lear. Address Allocation for Private
[10] K. Fenzi and D. Wreski. Linux security HOWTO, Internets. IETF RFC 1918, February 1996.
January 2004. [36] J. Roskind. Attacks against the Netscape browser. In
[11] R. Fielding et al. Hypertext Transfer RSA Conference, April 2001. Invited talk.
Protocol—HTTP/1.1. RFC 2616, June 1999. [37] D. Ross. Notes on DNS pinning.
[12] D. Fisher, 2007. Personal communication. http://blogs.msdn.com/dross/archive/2007/07/
[13] D. Fisher et al. Problems with new DNS cache 09/notes-on-dns-pinning.aspx, 2007.
(“pinning” forever). https: [38] J. Ruderman. JavaScript Security: Same Origin.
//bugzilla.mozilla.org/show bug.cgi?id=162871. http://www.mozilla.org/projects/security/
[14] D. Goodin. Calif. man pleads guilty to felony hacking. components/same-origin.html.
Associated Press, Janurary 2005. [39] Spamhaus. The spamhaus block list, 2007.
[15] Google. dnswall. http://www.spamhaus.org/sbl/.
http://code.google.com/p/google-dnswall/. [40] S. Stamm, Z. Ramzan, and M. Jakobsson. Drive-by
[16] Google. Google Safe Browsing for Firefox, 2005. http: pharming. Technical Report 641, Computer Science,
//www.google.com/tools/firefox/safebrowsing/. Indiana University, December 2006.
[17] S. Grimm et al. Setting document.domain doesn’t [41] J. Topf. HTML Form Protocol Attack, August 2001.
match an implicit parent domain. https: http://www.remote.org/jochen/sec/hfpa/hfpa.pdf.
//bugzilla.mozilla.org/show bug.cgi?id=183143. [42] D. Veditz et al. document.domain abused to access
[18] J. Grossman and T. Niedzialkowski. Hacking intranet hosts behind firewall. https:
websites from the outside: JavaScript malware just //bugzilla.mozilla.org/show bug.cgi?id=154930.
got a lot more dangerous. In Blackhat USA, August [43] W3C. The XMLHttpRequest Object, February 2007.
2006. Invited talk. http://www.w3.org/TR/XMLHttpRequest/.
[19] I. Hickson et al. HTML 5 Working Draft. http: [44] B. Warner. Home PCs rented out in sabotage-for-hire
//www.whatwg.org/specs/web-apps/current-work/. racket. Reuters, July 2004.
[20] C. Jackson, A. Bortz, D. Boneh, and J. Mitchell. [45] J. Winter and M. Johns. LocalRodeo: Client-side
Protecting browser state from web privacy attacks. In protection against JavaScript Malware.
Proc. WWW, 2006. http://databasement.net/labs/localrodeo/, 2007.
[21] M. Johns. (somewhat) breaking the same-origin policy [46] M. Wong and W. Schlitt. Sender Policy Framework
by undermining DNS pinning, August 2006. (SPF) for Authorizing Use of Domains in E-Mail.
http://shampoo.antville.org/stories/1451301/. IETF RFC 4408, April 2006.