Friday, March 13, 2009

Heap Egg Hunter

It's a bit ghetto, if you compared it to skape or others egg hunters, but it worked for us in a pinch and was fun to put together. See it at Rob Carter's blog. All credit should go to him, I was lazy and complained a lot. I like to think I helped with quality control.

Of course, just use skape's egg hunter for any real work.

For the Love of God, You're Doing it Wrong!!!

Maybe it's just an angry Friday morning for me, but I feel the need to attack PCI. Anoton Chuvakin tweeted a blog post that he saw today, and I couldn't help myself. It's not a new article, but it matters not, since I still found points hilarious.

From Robert Westervelt, News Editor of

Speaking to a group of merchants at a recent PCI DSS conference, Mellinger, who developed the precursor to the current PCI DSS rules, is calling for an overhaul to eliminate subjectivity and ease restrictions to get more merchants to meet the standard.

"I would rather they set the bar lower and then raise it once more merchants have complied," Mellinger said. "The more people we can get compliant, the better off we are."

HOLY CRAP!!!! How can you set the bar lower than PCI? Don't you love how it ties in so nicely with that last sentence about being better off with more people compliant? TRANSLATION (From Google's douche->English translator): The more people that have to pay me to say they are compliant, the better off we are. It continues...

"PCI is the best safeguard to protect a company if there is a problem and there will be incidents," Mellinger said. "But when banks come in and do their audits and don't look at the PCI findings, that's a problem."

How do you type a groaning noise? Uuuughhhh... Sorry, I tried, that doesn't really capture my disgust, but you get the idea. Guys, gals, if you believe that PCI is the best safeguard to protect a company then you are doing it WRONG. For the love of God, you're doing it wrong.

Wednesday, March 11, 2009

LOL Wednesday

This came into me from the twitterverse, and I felt I must pay respect to Max Cornelisse for perhaps the coolest hack I've ever seen. In fact, if you have a look at his YouTube page, you'll see it's not a singular event, the guy has several videos.

I suppose this could also be fake... I'm not claiming it is, I've actually seen crazy things similar to this happen live, so maybe it's possible, but even if it is fake, I tip my hat to a ridiculous social engineering hack, due to the raw amount of followers this guy has.

In any case, Max, if you see this and see me, I owe you a beer for giving me a good laugh today.

Tuesday, March 10, 2009

Finding the Found


I wonder how often this happens to researchers. It's not that it has happened often to me, twice now, and once turned out to be slightly unique. I'm talking about finding a vulnerability that's not only been found before, but has also been fixed.

Yesterday I fulfilled a promise to myself, which I made long ago, to start looking at protocol handlers in *Nix. It took awhile... I was bored of them. Anyways, within minutes of starting on the newest install of Ubuntu, I discovered a format string flaw within the Vinagre VNC client's vnc:// protocol handler. It was basically your classic vnc://%n causes crash. I was thrilled, obviously, and set out to begin working on exploit code.

Then I came to the realization that I could make tracing this a lot easier if I looked at the source code first (tend to forget that exists when you do most your research on Windows). I searched Google for Vinagre's page, but one of the first hits that came up was to a Core Advisory on the very same format string flaw I had "found". DAMN! Forgot to update my fresh installed Ubuntu VMWare! DAMN! Found a flaw someone else already found and it's already fixed!

I guess it could've been worse, I could've spent forever working on exploit code and THEN found out. Kudos to the Core team for the find. Their advisory shows the p0c performed in a couple ways and they do mention that there's many ways to kick this off, but they don't mention the protocol handler (I wonder if the protocol handler was there by default when this was discovered). I do like the protocol handler attack vector... call me a web app guy if you must, but there's a perverse pleasure one takes in actually owning someone from a cross-site scripting attack (not just stealing some cookies).

I wonder how often this happens to other researchers... I mean, it could've been worse, I could've found the flaw, wrote the sploit, turned it in, only to have been undercut in the process by someone who didn't take the time to fully explore the flaw.

Oh well, one down, several to go when it comes to the *Nix protocol handler front... although, I did like the idea of finding an exploit in one that was there by default.

Interesting side note... I mentioned this happened to me one other time as well, but that it turned out to be a unique case. This was actually in the format string flaw that I found in Apple's iPhoto, which was originally reported and "fixed" with the Month of Apple Bugs project. I remember very well contacting Erik Cabetas for some assistance in putting out some proof of concept exploit code and him telling me that it had already been found during MOAB and fixed by Apple.

I was blown away since I had literally just bought and patched my Mac Book. At the time, I was brute force trying to hit up protocol handlers on the Mac for fodder for my "URI Use and Abuse" research and was attempting to use a string designed to cause either a format string flaw or some kind of buffer overflow. The string I had used was a long string of %n characters... or so I thought. Apparently in the process of creating that long string, I accidentally had typed a %dd into the mix. This pushed iPhoto down a different path, leading to the same vulnerability in a different code path.

Let no one speak ill of my poor typing skillz again :).

Friday, March 6, 2009

Reinventing the Wheel

Sometimes you out smart yourself, or maybe just give yourself too much credit.

I discovered a pretty vanilla stack-based buffer overflow in a product used by a client during a recent A&P assessment, and Rob Carter and I were working out proof of concept exploit code. The details of the flaw I can't post yet, but they're somewhat unimportant anyways. As I said, it's pretty vanilla, no /GS, no /SafeSEH, no DEP, no ASLR. The overflow does not allow us to clobber SEH, but does allow us to overwrite local variables that eventually gain us control of a return address and EIP (after supplying some writeable addys and getting around the payload restrictions).

Due to the way the vulnerability works, our payload on the stack gets truncated, so we can't just return to call esi or some such thing and run our shellcode. What we can do, is return to the stack and run some small stub that will allow us to hunt for our shellcode in other locations. Our payload in this case is all over the process's heaps.

So here is where out smarting myself, or giving myself too much credit comes into play... Rob and I thought, oh, great, let's just write something that queries the PEB for the heap list, and then walks the heaps looking for our payload.

Sounds simple, right? Well, there's a couple hoops to jump through (which Rob will likely discuss at some point on his blog), but really, it should be. We were pretty stoked when we got it working, but there's still some tweaks to make it reliable that we were working through that made it unreliable on my test systems (but not on Rob's). In any case, I wanted a PoC now, so I pulled up Skape's (Matt Miller's) paper on egg hunting and was pretty blown away about the level of detail that went into it. Also, skape's smallest egg hunter really kicked the crap out of me and Rob's in terms of size.

I guess the take away is, reinvent the wheel for the learning exercise, and for the off chance that you find something really good, but also realize, there's some pretty damn smart people out there, and in a crunch, go read or any skape papers. skape=smart.


Wednesday, February 25, 2009

PDF Abuse Gets Worse

Anyone following the current abuse of PDF docs likely saw that it now also affects you even if you have JavaScript turned off:

BUT, I'm afraid it might get much worse than that. The Secunia article that points to the iDefense advisory suggests that this might be vulnerable on Mac platforms as well. I decided I'd test this out and found that on a fully patched Mac OS X build, Safari 4,,, and potentially others all crash using the proof of concept exploit provide on milw0rm:

The crash is actually in PDFKit/libJBIG2 from CoreFoundation, which supports all of those applications and likely much more.

I should mention I've done nothing to determine if this is exploitable. It just crashes where you would expect in libJBIG2 from CoreFoundation. I'm bout to go snowboarding in Utah, so I didn't have time to spend with it, but I felt it was necessary for people to know since this is in the wild at this point.

Monday, February 23, 2009


Hello all,

Well, it's been a good day and it's just now noon! It's always good to see your research enjoyed by others. Having it recognized as the top web application hacking technique of the year for 2008, is even cooler! Rob Carter, John Heasman, Billy Rios, and I were honored with the 2008 top web hacking technique of the year, as recognized on Jeremiah Grossman's blog and voted on by a constituent of peers including Jeff Forristal, Chris Hoff, Rich Mogul, and of course, HDM.

Getting recognized for something interesting you've done is even better when it's from people you respect and follow within industry. For anyone who didn't see the GIFAR work, you can get our most recent presentation on it from Black Hat Japan's page, linked here, which we also presented at BH USA which has video and audio available if you haven't seen it... full vid here, standard vid here, audio here.

Here's to 2009 and finding even more interesting stuff!


nsearch - A New ImmunityDbg Searching Script

Hola, hope all in the world finds you well!

Well, some of my new research has not really been new at all, in fact, it's been catching up with all the different protections for memory corruption issues and how to get around them. This was really a necessity for me, as I was sitting on some stack-based buffer overflows that were not, what I would call, straightforward to exploit. Several protections were in play at the same time, including /GS, /SafeSEH n all modules, and DEP. To help me out with this, I wrote up an Immunity Debugger plugin that would help me search memory for potential pop/pop/ret r32 and call/jmp dword ptr[ebp/esp +/- X] and equivalent commands. I needed to find these either in some module that did not have /SafeSEH, or in a mapped, executable memory segment.

Due to the great support for Python in ImmDbg and the API it exposes to work with the debugger, this was pretty straightforward and easy to write. The examples provided by Immunity really helped out, as well. Thanks to Nico for all the help!

You can download it from the Immunity Forums, here. Which is also where I will maintain any revisions.

It has a couple of modes, which I'll describe below:

1.) Search instructions: !nsearch /a pop r32\\npop r32\\nret
This can be used to search all memory regions for a given set of commands.

This is intended to perform similar to the !search script included with Immunity Debugger, but it works a little different. It has an advantage, in that it can and will search all of memory; however, it uses imm.Assemble(), which does not currently support assembly of instructions with offsets (and possibly with numeric values). For example, call dword ptr[ebp+30] will not assemble correctly, and therefore will not be found using this mode. For this, you will need to use the /x mode and supply the opcodes for the command, or use the /f mode and code into the script the opcodes you want to look for.

2.) Search opcodes: !nsearch /x ff 55 30
This can be used to search all memory regions for a given set of opcodes.

The search is done using the imm.Search() method, but in this case, it will not first use imm.Assemble() method to assemble supplied instructions into opcodes.

This is going to be the most reliable, but also least flexible, method of using this script to search memory, as it will find exact opcodes you want, not try to get the assembly of an instruction right.

3.) Feelin Lucky: !nsearch /f
This can be used to search many opcodes at the same time.

The reasoning for using this search method is to search many opcodes at the same time that might bring you back to your shell code. There's only a couple examples right now, but this section could be easily added to. Essentially what I've done so far is use the pop pop ret combos, jmp/call dword ptr[ebp/esp+x] instructions from Litchfield's paper on exploiting win2k3, and a couple of examples from Pablo Sole's paper on DEPLib. If someone has a good list of obvious ones, I'll throw that in, otherwise, feel free to add your own favorites or required per your exploit into the code. This mode was really what the script was designed for, but I figured I'd put in the other modes to make it useful there as well. The code for this is all located within the doSearch method on approx line 96 in the first conditional, feelinlucky. It has a number of examples to show how you could add your own commands to search for.

4.) Less Mode: !nsearch /f /less
The /less mode allows for less verbose output, in this case only those modules marked "No" for /SafeSEH, those modules marked "Yes [No Handler]" for /SafeSEH (think ATL.dll), and memory pages that are not loaded modules will be displayed. This cleans it up a bit for those sploiting something with tons of modules. While I'm on the subject, ATL.dll shows up as Yes [No Handler], and it's quite often used in SEH overwrite exploits.

I've heard mention that it's usable because it was built with an "old version" of /SafeSEH checks, and I'm trying to confirm what causes that. So, I make no claims as to if every module that shows up as "Yes [No Handler]" will be usable for an SEH overwrite, but it's worth a look. I will also be trying to figure out exactly what's going on with this behavior, I just haven't gotten to it yet.

5.) Single Module Mode: !nsearch /f /singlemod modname
The /singlemod modname mode allows you to search only for usable opcodes from a single module. This is nice for cases where you know exactly which module you want to use (say a module that always starts at the same base addy in vista).


Hello World!

Ok, it's been a long, long time since I blogged. Sorry, but sometimes the fun times in life just get in the way of things like blogging. In any case, I'm getting back to it! For those who followed me on ZDNet, you won't see nearly as many posts, for those that followed me on xs-sniper, expect something more like that.

Today you'll get two posts, cause I'm catching up with things!