INFILTRATE 2011

Beans recently (okay, it was MONTHS ago and I had this post pending in review since then) attended the Immunity INFILTRATE Conference in South Beach Miami, as well as the MASTER CLASS HACKING TRAINING.  Unfortunately this Stephen rarely (if ever) takes photos of anything, so you won’t see pictures of Internet superstar hackers here. Instead just a boring list of things we learned.

The conference was held on Saturday and Sunday.  Almost all of Immunity was there, only a few Immuniacs were missing.  Probably the most important part of the conference was that Immunity had an open bar on Saturday night.  As a consequence, Beans actually visited the sandy part of the beach for a few minutes, and met some interesting folks, which would otherwise not have happened.

Another incredibly important part of the conference and the training was that the food was pretty good. I really hate eating bad food at conferences. Outside of the conference, I would highly recommend David’s Café on 11^th Street for awesome home-style Cuban food and La Sandwhicherie for affordable late-night sandwhiches. But otherwise be careful because South Beach can be damned expensive.

Ok now for the less interesting parts…

Halvar mentioned trying to overwrite compiled Javascript bytecode as an alternative to “getting EIP” which was a cool idea.  He also talked about the practical limits of static analysis such as regarding analysis of loops, which is what I’ve learned myself from trying to do automated static analysis.

Immunity gave a talk on how pathetically easy it is to own Android devices. Basically, your phone is always a year or two behind on the current set of WebKit and Linux kernel vulnerabilities. You are aided by the fact that TCMalloc has absolutely no security features in it whatsoever (the subject of another talk), and Android does not support ASLR or NX.  So…you can be 1337 by downloading shit off full disclosure again!

Valasek and Smith detailed how they owned the IIS FTPSVC vulnerability, which pretty much boiled down to overwriting the NextEntryOffset in a free LFH chunk with 0xffff after performing extensive heap grooming to ensure that the next allocated OVERLAPPED structure containing a function pointer would point to within the range of memory pointed to by the NextEntryOffset.  (Thus, when the “next entry” is popped off, it would overwrite the function pointer). This can happen basically because the NextEntryOffset is not validated (via a checksum) when entries are popped off the list of free LFH chunks. Of course there is a lot of voodoo that was glossed over (how to “feng sheu”, “massage”, “groom”, “whatever” the heap).  Also I don’t know how reliable it would be “IRL” or on multi-core systems, but a decent talk overall.

I was unfortunately really hung over on Sunday and missed Cesar’s and Tarjeh’s talks on Windows stuff. I assume they were good talks.  I also missed Nagy’s talk on Saturday for roughly the same reason, even though the bar hadn’t even opened yet. After being informed that the conference had not actually yet finished, I made my way back in time to see the arcade-hacking presentation by Ron.  Basically he has a USB stick he can use to upload privileged Lua code to certain DDR-like arcade machines to give free credits or “tweak” the dance program to give him an advantage in competition. The entire presentation was hilarious and I mean that in a good way.

The PAX bypass was interesting.  Basically, assume you have an arbitrary memory write privilege in the kernel, and assume you can get an uninitialized stack variable disclosure vulnerability as well. Normally with PAX installed you are S-O-L. So what you do is you fork a child, he does the stack disclosure vuln to leak his kstack address back to you. Then put him into a blocking syscall that will return data back to you via a user buffer (think “wait”) and, as a consequence, the syscall will have to write the destination address somewhere on the stack while it’s waiting. Use your arbitrary write to overwrite that saved destination address with “anywhere you’d like to read” (its just an offset from the known kstack address).  The memcpy back to user is in copy_to_user and is hence protected (mostly) from SEGV type issues. ‘NUFF SAID.

This guy from McAfee talked about a fast shellcode detection engine. Basically he played tricks with the LDT to make a heuristic shellcode scanning engine faster. My opinion on shellcode detection is that there’s always the vector you didn’t think about (such as perhaps “not shellcode”). What’s more interesting really is just the dumb/clever tricks you can do with LDT entries to safely segment memory accesses even if the face of untrusted code.

The MASTER CLASS was pretty decent, but I think Immunity was over-optimistic in what they could cover in a week.  The first two days were all in ho-hum heap stuff, but if you were unfamiliar with pwning heap vulnerabilities it would’ve been useful I guess. We went over client-side use-after-free vulnerabilities which was interesting, although that could have been a week long class in itself. Also I don’t think the (not-)Chinese IE_PEERS exploit was as much “pray-after-free” as Immunity let on. Basically in the in-the-wild IE_PEERS exploit they go in a loop going “blah.setAttribute(‘s’, window);” 10 times. But the refcount on the window object was exactly 9, so that loop does actually perfectly decrement and free the window object, and on the 10th iteration the call to VariantChangeTypeEx actually allocates a new size 0x28 object which perfectly replaces the tearoff that was freed when the refcount hit 0.  So it pretty much works “perfectly”.  The only weird part is they rely on the fact that at offset 0x1c of the new object is the value 0x0fxxxxxx instead of a legit function pointer, but that still pretty much can be relied upon to point into your standard 0x0c0c0c0c heapspray. The saddest part of the (not-)Chinese exploit really was that they were doing lazy 0x0c0c0c0c-style heapspray 7 years after it was already lazy and largely unnecessary in decent exploits.  Except what’s sadder is that kind of crap actually works 😦

The real highlight of the MASTER CLASS was Sean and Pablo’s talks on using SAT/SMT solvers. Immunity has clearly put a lot of work into making SAT/SMT usable. They provide python bindings so you can manually code constraints in a nice, easy-to-read language like Python (as opposed to this awful pseudo-LISP SMT2 language), and they can obtain and parse the results of the solver and present them back to you in an easy-to-read way.   Their sequence analyzer is also really easy to use. Basically within a day they had us (at least me) writing python scripts to automatically parse x86 machine code to ask questions like “what do I need to put into EAX to make EDX equal to 0x100” or “in this block of horrific checksumming/crypto/hashing code, what are the possible values that EDX could be on output assuming I control ECX”?  They had some dumb tricks (e.g., binary search, avoid inequalities) to make using this stuff more efficient. Instead of spending months worrying about how to do x86->IR->SMT translation, or madly scribbling notes on paper, I was just sitting around answering questions about machine code using a SMT solver after a day of instruction.

Kostya lead the kernel part of the class, but again for me it was all old hat. A lot of the mystique of “kernel stuff” is mostly because most people don’t know how to write kernel drivers. If you didn’t know about METHOD_NEITHER or that usermode code is usually mapped into kernelmode space upon vulnerability trigger, it would probably have been more interesting than I found it. However they also had us work on that SMB function pointer vulnerability from a year or two ago which was amusing to try and exploit. I lucked into it by sorting the pointed-to functions by function size and stumbling into the fact that esi gets loaded with the SMB2 packet if you redirect the ValidationRoutine to a function that executes a “retn 0x10”.  Subsequently I doodled around in IDA Free looking for interesting code paths until I found a “write zero”, “call arbitrary address”, and lastly “increment”. It seemed like the ideal place to be able to code up some constraints in a SMT solver to figure out how to explore the different potential code paths based on SMB2 packet contents but I didn’t have time to do that. I may try and revisit this vulnerability and “do it with SMT” to see how that compares to trying to figure everything out “in your head”.

Also deplib is actually pretty sweet, I’ve never used it and as a publically available tool it’s great. It really does beat manually grepping through machine code using regular expressions.  Apparently 64-bit support is forthcoming and will mostly “just work” with a few tweaks to the Immunity Debugger.

So that’s pretty much it basically. I hope I haven’t left anything out. If you go to INFILTRATE next year (assuming it is next year) make sure to visit David’s Café and get the fried pork chunks.  And talk a walk around Collins Ave to watch 20-year-old kids drive Rolls-Royces and Lamborghinis up and down the street all night long.