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 searchsecurity.com:

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.

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.

Finding the Found

ARGH.

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

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 uninformed.org or any skape papers. skape=smart.

-Nate