(somewhat) breaking the same-origin policy by undermining dns-pinning
Hello list,
A small contribution to the current "hacking the intranet with
JavaScript" meme (also posted to my blog at
http://shampoo.antville.org/stories/1451301/).
== Introduction =
J. Grossman, RSnake, SPI Dynamics, pdp and others have demonstrated
lately that it is possible for a malicious JavaScript
a) to obtain the (internal) IP address of the hosting web browser,
b) to portscan the lan to locate intranet http servers,
c) to fingerprint these http servers using well known URLs
d) and (sometimes) to exploiting them via CSRF.
During my research on that topic I discovered, that with some
tweaking, it is also possible for the script to obtain read access,
allowing the leakage of internal information and more precise
fingerprinting.
== Technical background =
The basis of the attack is rather old. It was described by the
Princeton University in 1996 [1] and was recently brought to my
attention by Amit Klein [3]. For the attack to succeed the attacker
needs to control the DNS entry for his web server (www.attacker.org in
the following example).
Attacking an intranet host located at 10.10.10.10 would roughly work like this:
- The victim downloads a malicious script from www.attacker.org
- After the script has been downloaded, the attacker modifies the DNS
answer for www.attacker.org to 10.10.10.10
- The malicious script requests a web page from www.attacker.org (e.g
via loading it into an iframe)
- The web browser again does a DNS lookup request for
www.attacker.org, now resolving to the intranet host at 10.10.10.10
- The web browser assumes that the domain values of the malicious
script and the intranet server match, at therefore grants the script
unlimited access to the intranet server.
To prevent this type of attack, modern web browsers implement "DNS
Pinning" - DNS lookup results are kept unchanged for the entire
browser session, even though the DNS entry's lifetime may be shorter.
Mohammad A. Haque describes in [2] how the attack method still can
work, providing that the malicious script survives in the browser
cache. The described scenario requires the victim to quit his web
browser and to access the malicious script a second time, which
renders the attack to be somewhat unlikely.
== The refined attack: Undermining DNS pinning by rejecting connections =
As it turns out, it is also possible to force the browser to renew the
DNS entry for a given domain "on the fly". The following sequence of
events worked for me (tested on IE6 xpsp2 and Firefox 1.5.0.6):
1) The victim loads the script from www.attacker.org.
2) The attacker changes the DNS entry of www.attacker.org to 10.10.10.10
3) Further more the attacker quits the web server that was running on
www.attacker.org's original IP
4) The script uses a timed event (setIntervall or setTimeout) to load
a web page from www.attacker.org
5) The web browser tries to connect to the IP which is bound to
www.attacker.org from the previous request. As the web server there is
shut down now, this connection attempt is rejected.
6) Because of this (and probably because of the DNS entry's short
lifetime), the browser drops the DNS pinning and does a new DNS lookup
request, resulting in 10.10.10.10 (sometimes it takes more than one
loading attempt to trigger the lookup request).
7) The script is now able to access the intranet server's content and
to leak it to the outside.
Some (crude) PoC code is available at http://polyboy.net/xss/dnsslurp.html
I successfully tested the described approach on two different
computers in two different networks. Still the result is purely
experimental. As I have not read the web browser's source code, I can
only guess why the attack works. For this reason it may be possible,
that the attack fails on different setups.
== Outlook =
This technique obviously can be automated. Instead of quitting the web
server on attacker.org completely, dynamic firewall rules could be
used to reject further connections from the victim's IP after the
initial script was delivered.
The attack only woks, if the attacked server does not check the http
host property, as this property would still be "www.attacker.org". For
the same reasons all virtual hosts are out of the attacker's reach.
== References =
[1] DNS Attack Scenario, http://www.cs.princeton.edu/sip/news/dns-scenario.html
[2] Mohammad A. Haque: DNS: Spoofing and Pinning,
http://viper.haque.net/~timeless/blog/11/
[3] Amit Klein: Re: Detecting, Analyzing, and Exploiting Intranet
Applications using JavaScript (Posting to the WebAppSec-Mailinglist),
http://www.webappsec.org/lists/websecurity/archive/2006-07/msg00090.html
--
Martin Johns
http://www.informatik.uni-hamburg.de/SVS/personnel/martin/index.php