DNS rebinding attacks

(1)

Calhoun: The NPS Institutional Archive

Theses and Dissertations Thesis Collection

2009-09

DNS rebinding attacks

Kokkinopoulos, Georgios

Monterey, California. Naval Postgraduate School

(2)

NAVAL

POSTGRADUATE

SCHOOL

MONTEREY, CALIFORNIA

THESIS

Approved for public release; distribution is unlimited DNS REBINDING ATTACKS

by

Georgios Kokkinopoulos September 2009

Thesis Advisor: Geoffrey G. Xie Co Advisor: John H. Gibson

(3)

(4)

REPORT DOCUMENTATION PAGE Form Approved OMB No. 0704-0188

Public reporting burden for this collection of information is estimated to average 1 hour per response, including the time for reviewing instruction, searching existing data sources, gathering and maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information, including suggestions for reducing this burden, to Washington headquarters Services, Directorate for Information Operations and Reports, 1215 Jefferson Davis Highway, Suite 1204, Arlington, VA 22202-4302, and to the Office of Management and Budget, Paperwork Reduction Project (0704-0188) Washington DC 20503.

1. AGENCY USE ONLY (Leave

blank)

2. REPORT DATE September 2009

3. REPORT TYPE AND DATES COVERED

Master’s Thesis

4. TITLE AND SUBTITLE: DNS Rebinding Attacks

6. AUTHOR(S) Georgios Kokkinopoulos

5. FUNDING NUMBERS

7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES)

Naval Postgraduate School Monterey, CA 93943-5000

8. PERFORMING

ORGANIZATION REPORT NUMBER

9. SPONSORING / MONITORING AGENCY NAME(S) AND ADDRESS(ES)

N/A

10. SPONSORING / MONITORING AGENCY REPORT NUMBER

11. SUPPLEMENTARY NOTES The views expressed in this thesis are those of the author and do not reflect the

official policy or position of the Department of Defense or the U.S. Government.

12a. DISTRIBUTION / AVAILABILITY STATEMENT Approved for public release; distribution is unlimited

12b. DISTRIBUTION CODE 13. ABSTRACT (maximum 200 words)

A Domain Name System (DNS) Rebinding attack compromises the integrity of name resolution in DNS with the goal of controlling the IP address of the host to which the victim ultimately connects. The same origin policy and DNS Pinning techniques were introduced to protect Web browsers from DNS rebinding attacks, but their effectiveness has been undermined by vulnerabilities introduced by plug-ins such as JavaScript and Adobe Flash Player. The new attacks fall into two broad categories: firewall circumvention and IP hijacking, depending on the consequences of each attack.

Using a realistic network testbed, this research has enacted two firewall circumvention attack scenarios, with JavaScript and Adobe Flash Player respectively. Also confirmed is the effectiveness of several published countermeasures, including configuration options for DNS and Web servers, and security updates released by plug-in vendors. Fplug-inally, the research analyzes the defense-readplug-iness of the DNS server and client configuration guidelines used by the U.S. Department of Defense (DoD), including the Defense Information Systems Agency (DISA) DNS Security Technical Implementation Guidance (STIG), the Windows Vista Client Specialized Security Limited Functionality (SSLF) Guidance, and the split-DNS architecture.

15. NUMBER OF PAGES

129

14. SUBJECT TERMS

network security, DNS rebinding, DNS pinning, same origin policy, anti DNS pinning, adobe security updates, DNS STIG, Windows Vista security, split DNS

16. PRICE CODE 17. SECURITY CLASSIFICATION OF REPORT Unclassified 18. SECURITY CLASSIFICATION OF THIS PAGE Unclassified 19. SECURITY CLASSIFICATION OF ABSTRACT Unclassified 20. LIMITATION OF ABSTRACT UU

NSN 7540-01-280-5500 Standard Form 298 (Rev. 2-89)

(5)

(6)

Approved for public release; distribution is unlimited

DNS REBINDING ATTACKS Georgios Kokkinopoulos Lieutenant, Hellenic Navy B.S., Hellenic Naval Academy, 1994

Submitted in partial fulfillment of the requirements for the degree of

MASTER OF SCIENCE IN COMPUTER SCIENCE from the

NAVAL POSTGRADUATE SCHOOL September 2009

Author: Georgios Kokkinopoulos

Approved by: Geoffrey G. Xie, PhD Thesis Advisor

John H. Gibson

Co-Advisor

Peter J. Denning, PhD

(7)

(8)

ABSTRACT

A Domain Name System (DNS) Rebinding attack compromises the integrity of name resolution in DNS with the goal of controlling the IP address of the host to which the victim ultimately connects. The same origin policy and DNS Pinning techniques were introduced to protect Web browsers from DNS rebinding attacks, but their effectiveness has been undermined by vulnerabilities introduced by plug-ins such as JavaScript and Adobe Flash Player. The new attacks fall into two broad categories: firewall circumvention and IP hijacking, depending on the consequences of each attack.

Using a realistic network testbed, this research has enacted two firewall circumvention attack scenarios, with JavaScript and Adobe Flash Player respectively. Also confirmed is the effectiveness of several published countermeasures, including configuration options for DNS and Web servers, and security updates released by plug-in vendors. Finally, the research analyzes the defense-readiness of the DNS server and client configuration guidelines used by the U.S. Department of Defense (DoD), including the Defense Information Systems Agency (DISA) DNS Security Technical Implementation Guidance (STIG), the Windows Vista Client Specialized Security Limited Functionality (SSLF) Guidance, and the split-DNS architecture.

(9)

(10)

LIST OF FIGURES

Figure 1. Same origin policy in action (From: [2]) ... 6

Figure 2. Basic DNS rebinding attack (From: [3]) ... 8

Figure 3. Data flow enabled by a policy file (From: [15])... 16

Figure 4. DNS rebinding attack using Adobe Flash Player (From: [3]) ... 18

Figure 5. Research network testbed... 26

Figure 6. Detailed network testbed architecture ... 28

Figure 7. Attacker’s DNS server records A... 30

Figure 8. Timing diagram of DNS rebinding attack scenario ... 32

Figure 9. Netmask ordering option ... 34

Figure 10. NSLOOKUP running on target server showing round-robin DNS response for “www.joker.lab”... 35

Figure 11. Victim client 2 retrieving attacker home Web page... 37

Figure 12. Victim client 2 retrieves attacker’s home Web page ... 39

Figure 13. Content from internal Web server: violation of same origin policy ... 40

Figure 14. Wireshark snapshot confirming violation of same origin policy... 41

Figure 15. Default host header configuration for Web site www.angel.lab ... 42

Figure 16. Assigning a host name using the host header option ... 43

Figure 17. Message illustrating the failure of attack... 44

Figure 18. Wireshark snapshot confirming successful host header checking... 45

Figure 19. XmlHttpRequest script embedded in attacker’s Web page... 47

Figure 20. Flash Player installation error message... 54

Figure 21. www.joker.lab Web page with Flash application embedded... 56

Figure 22. Flash policy server in action running in Eclipse ... 57

Figure 23. Flash application normal execution ... 58

Figure 24. Client – server communication in Wireshark ... 60

Figure 25. The TCP stream for policy file request – response... 61

Figure 26. Flash 10.0.22.87 throws security error ... 62

(15)

(16)

LIST OF TABLES

Table 1. Origin comparison example... 6

Table 2. Vulnerable Adobe Flash Player policy file (From: [3])... 17

Table 3. Disable subnet prioritizationprocedure (From: [24])... 36

Table 4. Summary of results with different Web browsers ... 41

Table 5. Example code segment for sending to attacker... 47

Table 6. Satoh’s attack results using Adobe Flash Player (From: [18]) ... 49

Table 7. Vulnerability of Adobe Flash Player 9 versions to DNS rebinding attacks (From: [30]) ... 53

Table 8. Procedure for downgrading Adobe Flash Player (After: [34]) ... 55

(17)

(18)

ACKNOWLEDGMENTS

It is a pleasure to thank those who made this Thesis possible.

I would like to thank my advisor, Professor Geoffrey G. Xie, who gave me the opportunity to work with such an interesting subject in Network Security. His support, guidance, and encouragement helped me significantly to complete my research and made this Thesis process a lifetime learning experience. Thanks also to my co-advisor, John H. Gibson, who was always willing to discuss and advise me during the whole process. They both provided me with all necessary means, but most of all they taught me how to study in depth and discover solutions.

I thank the Hellenic Navy for giving me the opportunity to study at the Naval Postgraduate School.

I thank, from the bottom of my heart, my precious children, my daughter Marousa and my son Nicolas, for their understanding, support, and love, during my absence from our home for such a long period.

I save the most important thanks to my wonderful wife Tota, for her uncomplaining tremendous efforts to keep our family on track while I was, once more, far away from home. Her dedication, love, and patience never stop reminding me that I am blessed to have her by my side.

This Thesis is dedicated with endless love and respect to you my beloved wife.

(19)

(20)

I. INTRODUCTION

Modern Web browsers use the Same Origin Policy (SOP) to separate contents of trusted Web sites from other, potentially malicious ones. The origin of a Web object is uniquely identified by the combination of the protocol, host IP address, and port number parts of the object’s Uniform Resource Locator (URL). Web browsers enforce the SOP by preventing a document or script loaded from one origin from interacting with objects of a different origin. Without this protection, an attacker can easily inject a malicious Web link to violate the confidentiality or integrity of another Web page. Domain Name System (DNS) Rebinding attacks aim to violate the SOP of Web browsers, with the objective of either impersonating the hosts or using them as proxy servers to circumvent the firewall and launch various attacks against internal servers.

DNS rebinding attacks have been known, at least conceptually, since 1996. As a countermeasure, DNS Pinning for Web browsers was introduced to avoid any kind of DNS spoofing attacks facilitated by client-side code execution. DNS pinning forces a browser to use a single IP address for any given host. The Web browser “pins” the DNS response in its memory (cache) and as longs as the browser runs, it uses that cached IP address.

However, DNS pinning is not always effective because of vulnerabilities introduced by plug-ins such as JavaScript, Adobe Flash Player, and Java. These plug-ins provide additional functionalities to Web pages, but at the same time may permit an attacker to evade DNS pinning. The new DNS rebinding attacks fall into two broad categories: firewall circumvention and IP hijacking, depending on the consequences of each attack.

This research starts with an overview of the known DNS rebinding attack techniques and their consequences. Then, using a real network testbed, the research implements two firewall-circumvention attack scenarios against all major Web browsers.

(21)

The first attack scenario exploits a vulnerability of the round-robin DNS feature using JavaScript. The SOP of a victim Web browser is violated and the malicious JavaScript program is able to connect to a different host behind the firewall (e.g., an internal Web server). The same set of experiments also verifies that Host Header Checking is an effective defense method if the attack is directed toward an internal Web server. When host header checking is configured for the internal Web server, the server will reject the malicious requests because the “Host:” part of the HTTP header for these requests does not match the server’s own host name.

The second scenario uses an Adobe Flash application embedded in a HTML page, with the networking part coded using the Socket class included in

the Adobe Flash package. The results confirm the DNS rebinding vulnerabilities of earlier versions of the Adobe Flash Player plug-in and the effectiveness of a series of security updates released by the plug-in vendor.

Based on the insights gained from the experiments, the research analyzes the defenses that have been proposed in the open literature. The analysis is then applied to some of the guidelines currently used by the U.S. Department of Defense (DoD), including the Defense Information Systems Agency (DISA) DNS Security Technical Implementation Guidance (STIG), the Microsoft Windows Vista Client Specialized Security Limited Functionality (SSLF) Guidance, and the split-DNS architecture.

The rest of the thesis is organized as follows. Chapter II first presents a detailed explanation of the same origin policy and the DNS pinning technique, and then describes the DNS rebinding attack methods and their consequences. Chapter III describes the testbed network configuration and the software tools used for this research, the experiments that were carried out, and the analysis of the results. Chapter IV presents an analysis of the defenses that have been developed and applies the analysis to several U.S. DoD guidelines. Chapter V

(22)

presents the conclusions and suggestions for future work. Finally, the appendices include the source files of the HTML, Java, and Adobe Flash application programs created for this research.

(23)

(24)

II. BACKGROUND

A. CHAPTER OVERVIEW

The purpose of this chapter is to provide the background for this research. It answers the questions of what DNS rebinding attacks are and what vulnerabilities they exploit. Since these attacks have been known for twelve years, the chapter describes their first implementations as well as how they have mutated and become more difficult to mitigate. It also explains the same origin policy and the concept of DNS pinning, which are strongly related to how such attacks are mitigated today. The chapter concludes with a brief enumeration of the potential damages inflicted by DNS rebinding attacks.

B. SAME ORIGIN POLICY

Browsers enforce the same origin policy in order to prevent a document or script loaded from one origin from interacting with a document loaded from a different origin, as shown in Figure 1.

The Uniform Resource Locator (URL) for a Web object contains four basic components [1]:

The origin of a Web object is defined as the combination of the first three components of its URL [1]:

Origin = {<protocol>, <server-host>, <port-number>}

Same origin policy is implemented by Web browsers. Two objects are considered to belong to the same origin if and only if their URL contains the same protocol; hostandport-number so that the above sets are identical.

(25)

Figure 1. Same origin policy in action (From: [2])

The same origin policy is also called Single Origin or Same Site Policy. It was originally released with Netscape Navigator 2.0 and is integrated into every major Web browser [1]. As an example, consider the following URL:

http:// networks.nps.edu / lab / index.html

Table 1 compares the above URL with several URLs in terms of origins,

explaining the result:

URL RESULT REASON

http:// networks.nps.edu / lab / index.html success Same origin

https:// networks.nps.edu / lab / index.html failure Different protocol

http:// cs4550.networks.nps.edu / lab / index.html failure Different host

http:// networks.nps.edu:21 / lab failure Different port-number

(26)

However, this security policy is affected by various vulnerabilities because of design restrictions and because of trust established with other insecure services, such as the DNS. For example, Web browsers must translate the host name of the desired URL into an IP address, and then open a socket to that IP address. If the DNS responds with multiple IP addresses in one host name query, the browser will accept all of them as if they belong to the same origin, even if they are owned by different entities. DNS rebinding attacks exploit this vulnerability [3].

C. BASIC REBINDING ATTACKS

The network access security policy in Web browsers is based on host names, which are bound by the DNS to IP addresses. This policy can be undermined by a DNS rebinding attack, which binds the host name to two IP addresses. The one IP address belongs to an attacker and the other belongs to a target server. In this way, DNS rebinding attacks sabotage the same origin rule by confusing the browser into mixing content controlled by different entities into a particular security origin [3].

1. Princeton’s Attack Using Java Virtual Machine (JVM 1)

The first DNS rebinding attack was carried out by Princeton’s Computer Science Department in 1996 [4]. It exploited the DNS server’s capability of resolving multiple IP addresses for a single host name in conjunction with JVM’s security policy of that time, which was vulnerable to the following scenario:

• Suppose that a user visits an attacker’s Web page, http://

attacker.com. The attacker, who controls his Web and DNS servers, binds attacker.com to two IP addresses: his own Web server and the target’s Web server. In addition, his Web page contains a Java applet. • The victim’s browser uses the first IP address to get the content of the

page and runs the embedded applet, which requests that JVM open a socket to the second IP address, which corresponds to the target

(27)

server’s IP address. JVM permitted this connection; because the target’s IP address is contained in the DNS record for attacker.com. The key to a successful attack is that even if the user (victim) and server (target) sit behind a firewall, that firewall is powerless to stop the attack, as illustrated in Figure 2. The firewall is supposed to guard the victim by preventing machines outside the firewall from opening random network connections to the LAN it protects. However, in this attack the dangerous network connections come from one of the LAN’s trusted internal machines, so the firewall is useless. To summarize, the attacker uses the victim's Web browser to attack the victim's cooperating machines [5].

JVM is no longer vulnerable to this attack because the Java security policy has been improved so that applets are limited to connecting only to the IP address from which they were loaded [3].

(28)

2. Low TTL Version Attack

In 2001, research came up with another attack scenario that was based on the original idea of the attack described above [6], [7]. This time the attack used the Time-To-Live (TTL) value of DNS records, which can be configured from a DNS server according to an attacker’s wish. Additionally, the method used the XmlHttpRequest object, which can be used by scripts to connect to their

originating server via HTTP. It can be used inside a Web browser scripting language, such as JavaScript, to send an HTTP request directly to a Web server and load the server response data directly back into the scripting language.

The technique was characterized as Time-Varying DNS and the process contained the following steps: [3]

• A user visits the malicious Web site. An attacker’s DNS server responds with the normal IP address of the attacker’s Web page, but the TTL is set to be zero or very low.

• The user retrieves a Web page containing a malicious script that contains an XmlHttpRequest pointing back to the attacker’s page.

• Due to low the TTL, the DNS entry eventually expires and the victim’s browser issues a new query for the attacker’s site, which now resolves to the IP address of the target’s server.

• The victim’s browser is cheated now, and connects to the target server, which it thinks is the attacker’s. The victim does not recognize that the XmlHttpRequest is receiving data from the target Web

server instead of the attacker’s, and the data leads to the attacker’s server.

The connection in the last step has the same host name as the original malicious script, so the victim’s browser thinks that the connection is same origin policy authenticated, while in reality the authentication is confounded and permits the attacker to read the response from the target server. As in the previous attack

(29)

scenario, the attacker uses the victim's Web browser to attack the victim's cooperating machines. Another key point about this attack is the exploitation of

XmlHttpRequest, which, although it can be used only with the origin server,

uses DNS rebinding to cause the victim’s server to be considered as having the same origin, breaking the same origin policy [8].

The above attack scenarios have the common purpose of confusing the browser, so that by breaking the same origin policy the attacker gets access to an internal server using the victim’s browser as an insider, without the victim knows it. The DNS has not been disrupted with these attacks, as all the DSN responses are authoritative and normally provided by an attacker who owns the attacker.com domain name. Thus, DNSSEC is not useful against these types of attacks [3].

D. DNS PINNING

The first DNS rebinding attacks proved that same origin policy was not enough to defend against them. DNS pinning was discovered and applied to all modern Web browsers in order to provide protection against the exploitation of same origin policy vulnerabilities and the DNS’s lack of security.

With DNS pinning, the browser keeps in memory (cache) the mapping of the IP address to a host name that comes after a DNS response, regardless the TTL value of the record, until the browser is closed. More specifically, DNS pinning forces the browser to put in cache the first DNS response for a host name and it does not allow additional queries. In other words, browsers keep a context database in their cache, “pinning” host names to IP addresses to prevent the association of one host name to many IP addresses, which is an action that the DNS permits.

Consequently, DNS pinning protects browsers against the latter attack scenario with a low TTL, because if the browser issues a second DNS query for a host name that already has been resolved—hence stored in its pinned

(30)

database—the attacker’s response with the different IP address for the same host name will be rejected from the browser and the scenario will fail [8], [9].

Unfortunately, researchers have observed significant DNS pinning vulnerabilities. In 2006, it was documented that Web browsers do not fully apply DNS pinning [10]. Further, it was observed that DNS pinning only works in the case that the Web server in the query is actually online and available. This makes sense because if the server appears somehow to be offline, a new DNS query is necessary to find out whether it has changed or moved in some way. Thus, an attacker can shut down his server whenever he wants to circumvent the user browser's DNS pinning [9].

Moreover, researchers from the Web Security Team of Stanford University identified specific DNS pinning weaknesses for several Web browsers [3]. According to that research:

• Internet Explorer 7 pins DNS bindings for 30 minutes.

Unfortunately, if the attacker’s domain has multiple “A” records and the current server becomes unavailable, the browser will try a different IP address within one second.

• Internet Explorer 6 also pins DNS bindings for 30 minutes, but

an attacker can cause the browser to release its pin after one second by forcing a connection to the current IP address to fail, for example by including the element <img src= "http: //attacker.com:81/">.

• Firefox 1.5 and 2 cache DNS entries for between 60 and 120

seconds. DNS entries expire when the value of the current minute increments twice. Using JavaScript, the attacker can read the user’s clock and compute when the pin will expire. Using multiple “A” records, an attacker can further reduce this time to one second.

(31)

• Opera 9 behaves similarly to Internet Explorer 6. In [the

Stanford security team’s] experiments, [it was] found that it pins for approximately 12 minutes but can be tricked into releasing its pin after 4 seconds by connecting to a closed port.

• Safari 2 pins DNS bindings for one second. Because the pinning

time is so low, the attacker may need to send a Connection: close HTTP header to ensure that the browser does not re-use

the existing TCP connection to the attacker [3].

For these reasons, although DNS pinning is a security measure that can defend against basic DNS rebinding attacks, it appears that it was not fully implemented by Web browsers. This eventually led to the implementation of second-generation DNS rebinding attacks, which are known as Anti-DNS pinning attacks.

E. ANTI-DNS PINNING REBINDING ATTACKS

The combination of DNS rebinding and anti-DNS pinning was first employed in 2006. These attacks are known as anti-DNS pinning attacks, and the distinction from the basic attacks is important because, as was discovered during this research, there is a lot of confusion about terminology related to DNS rebinding attacks. So, the first attacks, as described above, should be considered basic DNS rebinding attacks, whereas the attacks that were carried out after the implementation of DNS pinning and which act against it, should be considered anti-DNS pinning rebinding attacks. This author believes that this is a necessary distinction to make, in order to make the concept clearer.

1. Anti-DNS Pinning Rebinding Attack Using JavaScript

In 2006, an anti-DNS pinning rebinding attack using JavaScript was presented by researchers [10], which was a variant of the basic attack. However, this time the challenge was DNS pinning, which had been applied in Web

(32)

browsers as an extra security measure against DNS rebinding. Despite this, the attack succeeded in defeating DNS pinning by taking advantage of its vulnerabilities.

The scenario published by M. Johns was as follows:

• The victim visits the malicious Web site attacker.com and loads the script it contains.

• The attacker then changes the DNS entry of attacker.com in order to resolve to the internal server’s IP address, which is the target. Moreover, the attacker disconnects the Web server that was running on the original IP address.

• The script uses a timed event (setIntervall or setTimeout) to

load a Web page from attacker.com.

• The victim’s Web browser executes the script and tries to connect back to attacker.com using the IP address, which is bound to it due to DNS pinning. But, as the Web server is no longer available, the connection is rejected and DNS pinning is dropped, due to the weakness described in the previous section.

• The browser then drops the DNS pinning and does a new DNS lookup request for attacker.com. This time, the response results in a different IP address; the browser has removed from its cache the previous mapping of the server hostname (attacker.com) to an IP address, so cannot be protected from the misdirection.

• As the new IP address points to the internal server, the attacker’s script is now able to access the internal server's content and reveal it [10].

The key point to this attack is that the attacker undermines the browser’s DNS pinning by rejecting the connection back to him and then using DNS rebinding to succeed in getting access to an internal server that otherwise would not be permitted. It is interesting to note that there are several ways to accomplish that rejection. Some of these can be summarized as follows:

(33)

• Web server can simply be disconnected or stopped [10]

• Web server can apply a firewall rule to its own IP address. So, when the victim tries to connect using its IP address, the connection will be rejected [9].

• The attacker can terminate the TCP connection using the RST (reset) control bit. This idea comes from the TCP Reset Denial of Service attacks [11] but it can also be used for defeating DNS pinning [3].

• The attacker may include in the HTML code the element:

<img src= “http://attacker.com:81”>,

This is an instruction to find a Web page’s image in a closed port, so the connection will fail and cause the victim’s browser to initiate a new DNS query [12].

2. Anti-DNS Pinning DNS Rebinding Attack Using Adobe Flash Player 9.0.48.0

DNS rebinding attacks affected Adobe Flash Player, which is a very popular software platform. A brief but comprehensive description of Adobe Flash Player is provided as follows from Wikipedia:

The Adobe Flash Player is software for viewing animations and

movies using computer programs such as a Web browser; in common usage, Flash lets you put animation and movies on a Web

site. Flash player is a widely distributed proprietary multimedia and

application player created by Macromedia and now developed and

distributed by Adobe after its acquisition. Flash Player runs SWF

files that can be created by the Adobe Flash authoring tool, by Adobe Flex or by a number of other Macromedia and third party

tools.

Adobe Flash, or simply Flash, refers to both a multimedia authoring

program and the Adobe Flash Player, written and distributed by Adobe, that uses vector and raster graphics, a native scripting

language called ActionScript and bidirectional streaming of video

and audio. Strictly speaking, Adobe Flash is the authoring

environment and Flash Player is the virtual machine used to run the Flash files, but in colloquial language these have become mixed:

"Flash" can mean the authoring environment, the player, or the application files. [13]

(34)

Researchers from Stanford security team in 2006 published an attack scenario against Adobe Flash Player 9.0.48.0 [3], which also affected the previous Flash versions. The attack used DNS rebinding, exploiting vulnerabilities in the interaction between Flash files and Web browsers. These vulnerabilities were characterized as critical, according to Adobe official site as was stated in a security bulletin of 2007:

Critical vulnerabilities have been identified in Adobe Flash Player that could allow an attacker who successfully exploits these potential vulnerabilities to take control of the affected system. A malicious SWF must be loaded in Flash Player by the user for an attacker to exploit these potential vulnerabilities [14].

First, the Stanford security team discovered that Adobe Flash Player 9 does not perform any DNS pinning, nor does it use the browser’s pinning, which means that Flash is vulnerable to DNS rebinding attacks. The vulnerability is registered and described in Common Vulnerabilities and Exposures database (CVE-2007-5275):

The Adobe Macromedia Flash 9 plug-in allows remote attackers to cause a victim machine to establish TCP sessions with arbitrary hosts via a Flash (SWF) movie, related to lack of pinning of a hostname to a single IP address after receiving an allow-access-from element in a cross-domain-policy XML document, and the availability of a Flash Socket class that does not use the browser's DNS pins, aka DNS rebinding attacks, a different issue than CVE-2002-1467 and CVE-2007-4324 [16].

Second, the reference to the cross-domain-policy XML document is about the policy file request that Adobe Flash Player sends back to the server as well as the response it receives. The attack exploits the effects of an unauthorized policy file. In order to make this better understood, author provides a description of how policy files work in Flash, using the material provided from the official Adobe site. As shown in Figure 3, when a user visits a Web pagethat embeds a Small Web Format (SWF) file, the policy file request and reply is as follows (the steps map to numbers shown in Figure 3):

(35)

• User visits a.com and browses the SWF file, which is embedded.

• The SWF file from a.com takes permission to load data from b.com using the policy file on b.com. The b.com site hosts a policy file that gives permission for a.com domain, which means that a SWF file from a.com can load data directly from b.com site.

• Now the SWF file can load data from b.com, manipulating the privileges the user has for connecting with b.com.

• Since the SWF file has the permission it can send any data it finds on b.comback to its own server at a.com [15].

Figure 3. Data flow enabled by a policy file (From: [15])

As a result of these vulnerabilities, the attack scenario using Adobe Flash Player 9.0.48.0 was documented by Stanford security researchers, providing a feasible DNS rebinding attack as shown in Figure 4, described in the following steps:

• The client’s Web browser visits a malicious Web site attacker.com that embeds a SWF movie.

(36)

• The SWF movie opens a socket to the attacker’s IP address according to the attacker’s DNS server response, which also is configured with a short TTL.

• Flash Player in the victim’s machine sends back a policy request file using the current socket connection.

• The attacker’s server responds with a policy file as shown in Table 2, which permits all domains to make socket connections to all ports. • The SWF file tries to make a new connection to attacker.com, but due

to the low TTL, the DNS entry has expired and Adobe Flash Player queries again for an IP address. At this point, DNS rebinding appears because the attacker responds with the IP address of the target server [3].

<?xml version="1.0"?>

<cross-domain-policy>

<allow-access-from domain="*" to-ports="*" /> </cross-domain-policy>

Table 2. Vulnerable Adobe Flash Player policy file (From: [3])

As stated previously, Adobe Flash Player 9 does not perform DNS pinning, hence it permits the connection to the new IP address.

(37)

Figure 4. DNS rebinding attack using Adobe Flash Player (From: [3]) F. PLUG-INS AND MULTI-PIN VULNERABILITIES

Modern browsers use several plug-ins for interacting with Web pages. In fact, the user has no other option than to install and use these platforms in order to be capable of browsing his favorite sites. For example, Java, Adobe Flash Player, and Adobe Acrobat are tools that every Web browser must have installed. On the other hand, all these useful tools have introduced new vulnerabilities that can be exploited by DNS rebinding among many other types of attacks that are out of the scope of this research.

Many plug-ins permit direct socket access back to their origins and the fact that they maintain separate DNS pin databases introduces the basis for the third generation of DNS rebinding attacks. The paradox is that the lack of separate DNS pinning in Adobe Flash Player 9.0.48.0 led to the attack scenario described previously, whereas the presence of separate DNS pinning leads to new vulnerabilities and exposures. Indeed, if a plug-in platform pins to the

(38)

attacker’s IP address and the Web browser pins to the target’s IP address, the attacker can take advantage of the communication capabilities between them to get around same origin policy restrictions.

For example, Java Virtual Machine (JVM) maintains DNS pins separately from the browser, opening up the possibility of DNS rebinding vulnerabilities. According to Stanford security team researchers, Java is exposed to the following weaknesses [3]:

LiveConnect bridges JavaScript and the JVM in Firefox and Opera,

permitting script access to the Java standard library, including the Socket class, without loading an applet. The browser pins to the attacker’s IP address, but the JVM spawned by LiveConnect does a

second DNS resolve and pins to the target’s IP address. The attacker’s JavaScript can exploit this pin mismatch to open and communicate on a socket from the client machine to an arbitrary IP address on an arbitrary destination port, including UDP sockets with a source port number ≥ 1024.

Applets with Proxies are also vulnerable to a multi-pin attack, regardless of which browser the client uses. If the client uses an HTTP proxy to access the Web, there is yet another DNS resolver involved—the proxy. When the JVM retrieves an applet via a proxy, it requests the applet by host name, not by IP address. If the applet opens a socket, the JVM does a second DNS resolve and pins to the target’s IP address.

Relative Paths can cause multi-pin vulnerabilities. If a server hosts

an HTML page that embeds an applet using a relative path with the parameter mayscript set to true, that machine can be the target of a

multi-pin attack. The browser pins to the target, retrieves the HTML page, and instructs the JVM to load the applet. The JVM does a second DNS resolve, pins to the attacker, and retrieves a malicious applet. The applet instructs the browser, via JavaScript, to issue

XMLHttpRequests to the target’s IP address [3].

Another example is Adobe Flash Player, whose version 9 exposure due to lack of DNS pinning has already been described. However, Flash could additionally be vulnerable to multi-pin attacks even if it uses DNS pinning. The reason is due to the operation of the Flash platform.

(39)

When the user visits a Web page that contains Flash content, the browser downloads the content (a movie, for example) and initiates Flash Player, transferring the movie’s origin by host name. When the attacker’s movie attempts to open a socket, Flash Player does a second DNS query back to the movie’s origin and the attacker could respond with the target’s IP address, which is the IP address the Flash Player would use for pinning [3].

Although the methods described so far require the attacker to send the IP address of the target machine, there is also an alternate method. The attacker can simply guess the internal host name of the target server, for example cs.nps.edu, and rebind attacker.com to a CNAME record which maps to that host name. When the attacker guesses an existing host name, the client’s own recursive DNS resolver will complete the resolution and return the IP address of the target. Otherwise, the attacker has to search for IP addresses to find an interesting target using a scanning tool such as Nmap or Superscan [3].

It is important to note that the essential initial condition for mounting a DNS rebinding attack is to attract the victim to visit the attacker’s Web page. This is subject to techniques based on Social Engineering, which is out of the scope of this research. For the purpose of this study, the author assumes that the potential victim has already been attracted to visit the malicious Web page. G. IMPACT OF DNS REBINDING ATTACKS

The exploitation of the various DNS rebinding vulnerabilities involves several components: the DNS service itself, the security policies applied (or not) in browsers (same origin policy and DNS pinning), and the operation of plug-ins that interact with all modern Web browsers. An attacker can take advantage of these vulnerabilities. Depending on the result achieved, the impact of these attacks has been separated into two categories: firewall circumvention and IP hijacking [3].

(40)

1. Firewall Circumvention

A firewall bounds network traffic between computer networks in different zones of trust. For example, a firewall can be configured to block connections from the public Internet to a LAN’s internal machines and negotiate connections even from internal machines to servers with sensitive data according to the administrator’s wish. Firewall circumvention attacks bypass this prevention on inbound connections, allowing the attacker to connect to internal servers while the user is visiting the attacker’s Web page.

a. Stealing Data

Web servers inside corporate firewalls often contain confidential documents, relying on the firewall to prevent non-legitimate users from retrieving these documents. However, using a DNS rebinding attack, an attacker can control the victim client’s browser to read and get these documents.

b. Exploiting Unpatched Machines

Note that the presence of a firewall often leads network administrators to the erroneous impression that this defense is enough to keep away attackers. Considering also that the patching process is time-consuming and expensive, administrators may not patch internal machines as quickly as Internet-facing machines. Using DNS rebinding, an attacker can attempt to exploit known vulnerabilities in unpatched machines on the internal network. If an exploit succeeds, the attacker can form a presence within the firewall that persists even after the victim closes the Web browser.

c. Exploiting Internal Open Services

Similarly, relying on the firewall, internal networks support many open services intended only for the organization’s use. Moreover, users inside firewalls often feel comfortable creating file shares or FTP servers accessible to anonymous users under the assumption that the servers will be available only to

(41)

clients within the network. Finally, routers are often installed without changing the default password or encrypting route information packets.

Consequently, if an unsuspicious internal user visits the attacker’s external Web page, the implementation of DNS rebinding may succeed in exposing these services to unfortunate results. For example, internal network printers may print until they exhaust their supplies in paper and ink, or shared documents can be stolen. Finally, routers with default passwords can be accessed so that attacker can change the configuration files [3].

2. IP Hijacking

DNS rebinding attacks can also target machines on the public Internet. In this case, an attacker uses a victim’s browser, taking advantage of the trust that public services have in the victim’s IP address. Once the attacker has taken control of the victim’s IP address using the DNS rebinding techniques, there are several attacks that can be mounted.

a. Click Fraud

Click Fraud can be defined as any click done in bad faith, which means any click where there is no intention by the user to buy, browse or get information from the Web page visited. Click fraud happens in the case where the purpose of a click is to either drain funds or generate profits [17].

b. Spam Messages

Many mail servers blacklist IP addresses known to send spam e-mail. By hijacking a client’s IP address, an attacker can send spam from trusted IP addresses. In order to send spam e-mail, the attacker has to send packets to SMTP servers on port 25. Although most browsers do not permit this action, it is permitted by Adobe Flash Player and Java [3].

(42)

c. Breaking IP-Based Authentication

Many Internet services still employ IP-based authentication. After hijacking an authorized IP address, the attacker can access the service, defeating the authentication mechanism. Because the communication originates from an IP address actually authorized to use the service, the service provider fails to recognize the security breach.

d. Framing Clients

An attacker who hijacks an IP address can perform illegal actions and set up the victim. For example, if an attacker gains unauthorized access to a computer system using the victim’s hijacked IP address, the logs will associate the client to that illegal action instead of the attacker because the attack seems to originate from the victim’s machine. [3]

(43)

(44)

III. EXPERIMENTS – SETUP AND RESULTS

A. CHAPTER OVERVIEW

The purpose of this chapter is to describe the experiments conducted for this thesis and present the main results obtained from them. Section B describes the network testbed in detail; the testbed was built using the available hardware components in the Networks Laboratory of the Computer Science department. Section C, provides the description and experimentation with a DNS rebinding attack scenario and the results are provided. In Section D, the research focused on vulnerabilities to DNS rebinding for different Adobe Flash Player versions and experiments using socket programming between a client and a server in an effort to address security issues with the same origin policy and DNS-pinning with respect to DNS rebinding attacks.

B. CONFIGURATION OF TESTBED

The testbed represented a network topology for experiments. As shown in Figure 5, it consisted of the attacker’s LAN with domain name joker.lab, the target LAN with domain name angel.lab, which hosted some important enterprise services, and a third LAN in the angel.lab domain, which simulated a group of authorized clients for the services (e.g., Web) hosted on the target LAN. The testbed was designed to operate locally, isolated from the Internet for testing purposes. The following sections describe in detail the hardware, software, and configuration of the testbed components.

1. Hardware

The architecture of the testbed consisted of the following components: • Three (3) Cisco 2600 series routers.

• Three (3) Catalyst 1900 series switches.

• Six (6) DELL Optiplex personal computers with a 1.86 GHz Intel Core2 CPU.

(45)

Thursday, July 09, 2009

Page 1

DNS rebinding research testbed simplified

MS XP Client VICTIM Client 1 MS Router MS Server attacker DHCP DNS WEB DNS WEB Router 2 Router 1 angel.lab MS Server TARGET Server joker.lab www.angel.lab www.joker.lab www.helper.lab MS Server helper WEB Router 3 MS XP Client VICTIM Client 2

Figure 5. Research network testbed 2. Software

The following operating systems and applications were installed:

• All servers run Microsoft Windows Server 2003 R2 Enterprise Edition SP2, which was provided by MSDNAA Software Center, of which NPS CS students can be members. Servers provide DNS and DHCP services to their LANs, as well as Web server capabilities for hosting and managing their Web pages using IIS 6.0, which is embedded in MS Server 2003 software.

• Clients run Microsoft Windows XP Service Pack 2.

• Clients had installed the most popular Web browsers and an

application that permits the execution of previous versions of Internet Explorer. Web browsers included:

(46)

o Mozilla Firefox 3.0.8

o Google Chrome 1.0.154.65

o Safari 4 Public Beta (528.16) release for Windows o Internet Explorer 7

o An application which is an installer that contains multiple

versions of IE, specifically IE 4.01, IE 5, IE 5.5, IE 6.0, which is very useful in order to test a Web site in various versions of Internet Explorer [20]. The application was successfully tested in Windows XP SP2 client machines.

• All PCs had Java(TM) SE Runtime Environment (build 1.6.0.13) installed. Additionally, Eclipse Platform 3.4.2 was installed on both attacker host and target server.

• Adobe Flex Builder 3 built on Eclipse was installed in attacker server for Flash application development and execution [21].

• Archived Flash Player 9 package, which contains all the Flash Player 9 versions, as well as the necessary uninstaller for testing purposes, was downloaded [22].

• Network protocol analyzer Wireshark 1.0.6 installed on all the testbed machines.

3. Network Topology Description

The research testbed represents the network topology shown in detail in Figure 6. It consists of two sides, the attacker LAN and the target LAN.

The target LAN (left side of the diagram) is the angel.lab domain (192.168.23.8/29), which contains a server that plays the role of the target server and a client which plays the role of a victim client (victim 1). There is also an additional LAN under Router 3, which includes another victim client (victim 2). This LAN (192.168.23.0/29) has access to angel.lab, which means that victim 2 is a legitimate user who is permitted access to the angel.lab server, so this client is not firewalled.

(47)

The angel.lab target server provides DHCP, DNS and WEB services to the LAN. It hosts and maintains the Web page www.angel.lab, which is meant to

be accessible only to legitimate clients of this LAN. Thus, in this network topology, legitimate clients of that target server are victim client 1 and victim client 2 only. MS Router is the default gateway of this LAN, which is a server configured as a router and which additionally has the responsibility of applying the firewall rules that protects the LAN from outsiders.

Figure 6. Detailed network testbed architecture

The right side shows the joker.lab domain (192.168.23.16/29), which is the attacker’s side under Router 2. It consists of the attacker server, which provides DNS and WEB services, hosting and maintaining the www.joker.lab page. Additionally, the attacker controls a second Web server in the same domain, which hosts the www.helper.lab page. That server is required to cooperate with

(48)

the primary attacker server in several ways, such as receiving the results of an attack. Router 2 is the default gateway of the attacker’s LAN.

All LANs are provided with switches with factory default configuration. Router 1 is directly connected to all LANs, providing the necessary connectivity between the components of the network topology. Appendix A contains the configuration files of the Cisco routers (1, 2, and 3). The testbed’s routers utilize dynamic routing configured to use the RIP version 2 routing protocol.

The correct operation of the network topology is fundamental for the implementation of experiments and the export of scientifically argued conclusions. For that reason, a script was written to test the connectivity between the testbed’s LANs. The script is a .bat file running in Windows, which pings all the interfaces of the testbed’s hosts in order to check that all hosts are connected and communicate properly with each other. The code of mspinger.bat is contained in Appendix A, as well as an output of its execution.

C. DNS REBINDING ATTACK SCENARIO VIA JAVASCRIPT

The DNS rebinding attack scenario used during this research was provided by Collin Jackson of Stanford Web security team. It is an attack method that uses round-robin DNS and the XmlHttpRequest object as described in

detail in the following sections. 1. Attack Scenario

The scenario is about getting around a firewall (firewall circumvention). The attacker is firewalled outside the target LAN, and tries to intrude in order to perform malicious actions, specifically stealing data from the target Web server. According to the scenario, the unsuspecting victim visits the attacker’s malicious Web site and the attacker then channels HTTP traffic through the victim in order to get to the target server inside the firewall. The attacker’s purpose is to read the content of http://www.angel.lab, which he cannot do normally with HTML, but

(49)

The attacker’s Web server hosts the www.joker.lab HTML page; it contains a function whose purpose is to make an XmlHttpRequest to the root

directory and alerts the result, showing the HTML content of the page on the screen. The attacker’s DNS server needs two IP addresses on the round-robin DNS. The first IP address maps to the attacker’s Web server (192.168.16.226) and the second IP address maps to the victim’s Web server (192.168.23.10). This configuration is shown in Figure 7.

The attacker uses DNS rebinding to trick the victim’s Web browser into thinking that 192.168.16.226 and 192.168.23.10 are in the same origin, so that the Web page loaded from first IP (www.joker.lab) will be able to perform an

XmlHttpRequest to the second IP (192.168.23.10), which corresponds to the

internal server’s Web page (www.angel.lab).

Figure 7. Attacker’s DNS server records A

In this way, when the victim client visits the attacker’s domain name, he retrieves the attacker’s page (www.joker.lab), as he was supposed to do. The attacker’s server is then physically disconnected from the network, so that the original IP address for that page is no longer available. The browser will make a new DNS lookup by itself after a time interval, which depends on the browser, in order to attempt to reconnect. However, this time, due to round-robin DNS, it will use the second IP address, which belongs to the internal target Web server. As

(50)

long as the attacker server is disconnected, there must be a second Web server under the attacker’s control, to which the result of the attack will be redirected.

Thus, the key components for this DNS rebinding attack scenario are:

• The attacker’s Web HTML page www.joker.lab containing the

malicious code.

• The round-robin DNS configuration in the attacker’s DNS server with two IP addresses, where the second is the target server’s IP address. • The unavailability of the attacker’s Web server, which takes place after

the victim’s initial visit to the attacker’s Web page. 2. Attack Process

The procedure is carried out by following the steps shown pictorially in the timing diagram in Figure 8 and described as follows:

• Initially, the client’s browser queries for www.joker.lab IP address asking its own local DNS server (time t1).

• The DNS server sends back to client the response received from the authoritative DNS server, which is under the attacker’s control. Thus, the client receives 192.168.16.226 and 192.168.23.10, in that order (time t2).

• The client’s browser uses the first IP address, sends a GET message and receives the HTML content of www.joker.lab(time t3).

• At this point, the attacker physically disconnects the Web server he controls from the network in order to make it unavailable. The server can also be made unavailable using other techniques, such as those described in previous sections. For example, the Web page may contain an instruction to find an image in a closed port, so the connection will fail and cause the victim browser to initiate a new DNS query.

• The client’s browser should make a new query after an amount of time (dt) depending on the Web browser, according to Stanford security

(51)

team tests, as discussed in previous sections. As a result of round-robin DNS, this time the client uses the second IP address 192.168.23.10 in order to visit the same Web page as before, the attacker’s www.joker.lab.

• The same origin policy breaks because the client sends a GET message to 192.168.23.10, which corresponds to www.angel.lab although the client intends to visit www.joker.lab (time t4).

• In the case where the client’s browser successfully receives the HTML content from www.angel.lab, the intrusion is successful, because now data can be sent back to the attacker’s domain (time t5).

2 t1 dt t2 t3 t4 t3 t5

Client victim Server target Attacker server coAttacker server

Time t

t4

192.168.23.10 192.168.16.226

(52)

3. Testing – Results

The testbed uses Wireshark to follow the steps of the attack procedure and to watch the conversations between clients and servers. Initially, at time t1 the victim client makes a DNS query for the attacker’s page, which goes to its DNS server in the LAN to which it belongs. The DNS server queries for the Web page, and the query gets a response from the DNS server, which the attacker controls. The response finally reaches the client at time t2. As shown in Figure 8, the response contains the two IP addresses, first the attacker’s Web server, and second the target server’s IP address.

a. Round-Robin DNS Configuration

At this first step of the attack process, the DNS server configuration of both target and attacker plays an important role. Although the DNS server in Windows 2003 works in round-robin by default, there is a subnet mask ordering option, which is chosen by default. This option ensures that clients are directed to the nearest server that matches their request. This utility prevents the implementation of the attack, because during the experiments, victim client 1 is directed to the nearest server; this is the target server due to its IP address belonging to the same subnet as the client and being the nearest. Figure 9 shows the target server’s DNS configuration, where the enable netmask ordering option is unchecked in order to make the attack scenario feasible.

After deactivating that option, the round-robin DNS works on both attacker and target servers, in the way the attacker desires. Thus, the DNS server gives back to the client the attacker’s IP address as its first option rather than the nearest, which is the second. Round-robin can be seen in action after that interference using NSLOOKUP, as shown in the Figure 10, which details NSLOOKUP running on the target server machine. However, the client machine’s behavior may prevent round-robin from working, as described in the following section.

(53)

(54)

Figure 10. NSLOOKUP running on target server showing round-robin DNS response for “www.joker.lab”

b. Subnet Prioritization

The second observation comes from victim client 1’s behavior. Victim client 1 is a host that belongs to the same LAN as the target server. When a browser tries to visit the attacker’s Web page, it uses the IP address of its subnet, which is the second IP address and not the first one that it received from its DNS server. This is another constraint for the scenario, which happens because the Windows XP DNS resolver uses Subnet Prioritization by default. According to Microsoft support documentation about this issue [23]:

If the resolver receives multiple IP address mappings (A resource records) from a DNS server, and some of the records have IP addresses from networks to which the computer is directly connected, the resolver places those resource records first. This

(55)

behavior reduces network traffic across subnets by forcing computers to connect to network resources that are closer to them [23].

Thus, subnet prioritization on the client’s machine prevents round-robin DNS from working victim 1. There is a way to disable this feature by adding the PrioritizeRecordData registry entry with a value of 0 in the registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services \Dnscache\Parameters[23].

The procedure that has to be followed [24] is shown in Table 3, which was tested successfully on victim client 1.

1. Start a registry editor (e.g., regedit.exe) on each client machine.

2. Navigate to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services \Dnscache \Parameters registry subkey.

3. From the Edit menu, select New, DWORD Value. 4. Enter the name PrioritizeRecordData, then press Enter. 5. Double-click the new value, set it to 0, then click OK. 6. Close the registry editor.

7. Reboot the machine for the change to take effect.

To re enable subnet prioritization, either delete the PrioritizeRecordData registry value or set this value to 1.

Table 3. Disable subnet prioritizationprocedure (From: [24])

Consequently, the round-robin DNS works on victim client 1 if and only if a change in its registry occurs as described above. This condition makes it impossible to mount the attack scenario using this client, because the attacker would have to be able to change the victim’s registry remotely even before the victim visits his malicious Web page (www.joker.lab).

However, the attack scenario is still feasible as regards victim client 2. This client does not belong to the same LAN as the target server and he has access to angel.lab, as detailed in the setup configuration description. Therefore,

the default subnet prioritization feature does not prevent the round-robin from working. In Figure 11, the Wireshark snapshot from victim client 2 shows that

(56)

phase of the attack scenario, where the client visits the attacker’s Web page using the first IP address of his DNS query response.

Figure 11. Victim client 2 retrieving attacker home Web page

Until this point, the tests on this testbed have shown that the attack scenario with round-robin DNS is possible if and only if the following conditions are fulfilled:

• The enable netmask ordering option has to be unchecked in the target DNS server

• The victim client cannot be a member of the same subnet as the target server because the Windows XP DNS resolver uses subnet prioritization by default.

c. Server’s Unavailability

At time t3, victim client 2 has retrieved the attacker’s Web page, www.joker.lab. The attacker then disconnects its Web server physically from the network, so that the IP address that the client used initially is no longer available.

(57)

According to Stanford’s security team tests [3], the victim’s Web browser should try a different IP address within several seconds, contrary to DNS pinning, which is implemented in current Web browsers and which prevents host names from referring to multiple IP addresses.

However, despite extensive testing with all current major Web browsers, as well as with previous versions of Internet Explorer, no such behavior was noticed on this testbed. The victim client’s Web browser does not react to the attacker’s server unavailability. In an effort to explain this difference in the results, the author forwarded these observations to Collin Jackson from the Stanford security team, who noted that it was probably due to the differences in the configurations between their research’s testbed and the this research’s testbed. The browser’s reaction was simulated using the Web browser’s refresh option, which enabled the process to continue. This means that instead of waiting for the Web browser to try a different IP address, the user refreshes the Web page, which leads to the same results because the browser will not be able to connect to the unavailable IP address and will eventually try a different one.

d. Breaking Same Origin Policy

Therefore, when the scenario reaches time t3, the victim client has retrieved the attacker’s Web page and the attacker Web server becomes unavailable by physically disconnecting it. For instance, in Figure 12 is shown the attacker’s Web page www.joker.lab as it is retrieved from victim using Firefox 3.0.8 browser.

(58)

Figure 12. Victim client 2 retrieves attacker’s home Web page

The user then refreshes the Web page but the initial IP address in no longer available. After some period of time dt, the browser uses the second IP address (192.168.23.10), which corresponds to the target server’s Web page, www.angel.lab. Figure 13 shows that although the browser thinks that it has retrieved www.joker.lab, in reality it has retrieved the HTML content of the target server’s Web page. This is a violation of the same origin policy of the Web browser, which is accomplished using DNS rebinding. The communication between victim client 2 and servers was recorded using Wireshark. For example, Figure 14 shows how the same origin policy in Firefox browser is violated after dt = 1:55 min.

DNS rebinding attacks

DNS rebinding attacks

Kokkinopoulos, Georgios

NAVAL

POSTGRADUATE

SCHOOL

MONTEREY, CALIFORNIA

THESIS

ABSTRACT

TABLE OF CONTENTS

LIST OF FIGURES

LIST OF TABLES

ACKNOWLEDGMENTS

I. INTRODUCTION

II. BACKGROUND

III. EXPERIMENTS – SETUP AND RESULTS