A small contribution to the current “hacking the intranet with JavaScript” meme:

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 polyboy.net

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.

Update (12/2006): Kanatoko Anvil from jumperz.net found out that it is not necessary to shut down the web server. It is sufficient for the malicious script to access a closed port on the intranet server (e.g. attacker.org:81) to cause the web browser to initiate a new DNS query. See here for a demo. Wow.

References

[1] DNS Attack Scenario, www.cs.princeton.edu [2] Josh Soref: DNS: Spoofing and Pinning, viper.haque.net [3] Amit Klein: Re: Detecting, Analyzing, and Exploiting Intranet Applications using JavaScript (Posting to the WebAppSec-Mailinglist), www.webappsec.org

There was more than one moment in the last month, in which I wondered about the reasons behind the same-origin restriction on the XMLHttpRequest JavaScript object’s destination URL. This restriction effectively prevents JavaScript initiated cross domain http requests. None of the other network aware elements of HTML/JavaScript are subject to such a policy (e.g. images, iframes or scripts).

Finally somebody convinced me: Lucas Carlson describes in a recent Blog entry how cross domain XMLHttpRequests could be employed to subvert firewall protection. A malicious JavaScript executed by a web browser behind a firewall would be able to communicate the content of any http intranet server, which would otherwise be protected by the firewall, to any host on the internet. Such a script is furthermore able to do a complete port scan on the intranet, thus discovering services and further attack targets.

What a pity, cross domain Ajax would be so much fun otherwise.

A backdoor that tries to phone home usually uses DNS-queries to locate the host they should report to. These DNS queries are cached by the DNS server for some time. Dan Kaminski uses this behaviour to estimate the number of PCs that are infected by Sony’s DRM rootkit(he found more than 500.000 DNS servers that received a query related to the rootkit, leading to a conservative estimate that the number of infected PCs is in the millions).

The image shows the distribution of the located DNS servers in Europe (click here for larger maps: USA, Asia, Europe). The more I learn about DNS, the more I am intrigued by this often overlooked protocol.

Oh - Sony’s uninstaller leaves the PC even more open to further attacks.

David Wheeler took the time and had a closer look on the time spans in which no unpatched exploit for a couple of popular web browsers existed. His findings where somewhat devastating, especially for IE:

It turns out that there were only 7 days in 2004 that you could have somewhat safely used Internet Explorer (it was October 12-17), even assuming that attackers only used publicly-known attacks, and that you were only worried about the worst kind of attacks.

Check out the promotional pictures posted on the F-Secure Weblog.

These pictures are so over the top. All employees are wearing laboratory gowns. They even have got signs warning about free flying wireless viruses...

This is a public service announcement: A couple of colleagues and I are starting an open study group on software insecurities. Our first meeting is on Tuesday the 26th of April at 16:00. Feel free to drop by and share the fun.

It always strikes me as funny (though not “haha”-funny) when a website devoted to computer security doesn’t display properly (check out the left hand navigation) in Mozilla based browsers .

Two-factor authentication is the combination of

1. Something you can lose and
2. Something you can forget

[via Slashdot comments]

When I was looking for more information about botnets I stumbled over a fun presentation on "Life, Love and War in the Underground". It is from late 2003 but I think the basic facts are still valid. According to the findings of the Author Rob Thomas there exists a livid marketplace in the IT underground. Botnets, 0days and rootshells are swapped or sold for hard currency (e.g. a new exploit sells for about $100 to $500). But to participate you have to know how to speak 1337...

The German Honeynet Project just released a paper on the usage of honeynets to explore botnets: Know your enemy: Tracking Botnets. Besides the description of the use of honeynets to do the tracking, the paper also does a great job in providing insights to the “why” and “how” background information of botnets.

Interestingly a lot of the more successful bots (Angobot, SDBot, DSNX) adopted the GPL as development model. I wonder if they have sourceforge.net project pages?