[ Local Web Servers Are Dangerous ]

edit:
Well, I found out that command execution and file access are not possible through the local intranet zone using default settings. Some of the machines I was testing turned out to have tweaked intranet settings. I should've checked that, but I'm correcting my mistake now. BUT! Check out John Heasman's post on how to use Java in conjunction with the weaker security policy of the local intranet zone to steal password hashes.


The title of this post may seem fairly obvious to those of you in the computer security field. Having a web server running on your machine opens up a plethora of attack vectors; command injection, SQL injection, file upload vulnerabilities, etc. But what I'm posting about today is slightly different from anything else I've seen on the subject.

What if there is a web application on the local web server that is vulnerable to XSS? And what if you are browsing from that machine? Are there any devastating attack vectors regarding this setup that you can think of? I can: Cross-Zone Scripting. The subject of cross-zone scripting has clearly been talked about before, but I'm not sure it's been talked about (at least that I've seen) in this particular context. Let me explain.


There are a few zones in Internet Explorer that we're worried about for this attack. The Internet zone is pretty well restricted. It enforces the same-origin policy, doesn't allow you to load certain ActiveX objects and so on. The Local Intranet zone on the other hand is much less restricted. The Trusted zone is not very restricted either but requires user interaction to put us in that zone. And the Restricted zone is, obviously, very restricted. For brevity's sake, I'll just tell you that the Local Intranet zone is the zone we want to try to get our malicious payload into.


Now, in the context of the scenario I just outlined above, how do we do this?

There are three different ways we can get into the Local Intranet zone.

• The site must have been connected to previously using the Universal Naming Convention (\\1.2.3.4\share)


• The site must be in the proxy exceptions list


• The site cannot contain any dots (.) in its name

Conditions 1 and 2 are going to be difficult to fulfill unless we're in possession of some 1337 ninja hacker 0dayz. Condition 3 is our ticket to mass bl00dy pwnage. At first glance it might seem like we're limited by the dot (.) predicate when we think of the local computer address. The IP 127.0.0.1 is in the internet zone because of the dots in the IP addressing format itself. But, the name "localhost" has no dots in it and just so happens to be in the Local Intranet zone.

So if our attacker injects some malicious Javascript into our local web application like this:

http://localhost/?<script>h=new%20ActiveXObject("Msxml2.XMLHTTP");....</script>

That script will be executed in the Local Intranet zone. But what does that give us as far as pwnage vectors? A lot.

• Same-origin is NOT enforced in the Local Intranet zone (IE 6 and 7)


• Can read and write files on the local system using a Scripting.FileSystemObject ActiveX object (IE 6)


• Can execute arbitrary commands on the local operating system using a WScript.Shell ActiveX object (IE 6)

Ouch.

Incidentally, this all ties in with the research I've been involved in with Nate and Billy in the past, specifically with the Picasa exploit. Always ask yourself, "why are these applications running web servers on my box?" You may not be able to think of a good answer.

edit:
I thought it might be nice to provide some Javascript code so anybody can try this.

Command Execution:

a = new ActiveXObject("WScript.Shell");
a.run("notepad");

File Access:

a = new ActiveXObject("Scripting.FileSystemObject");
b = a.OpenTextFile("C:\boot.ini");
alert(b.ReadLine);

XMLHTTP Request:

hr = new ActiveXObject("MSxml2.XMLHTTP");
hr.onreadystatechange = function() {
    alert(hr.responseText);
}
hr.open("GET", "http://www.google.com", true);
hr.send(null);