Exodus Intelligence Training
Breaking Binary Applications && Browser Exploitation
Exodus Intelligence? Training?
Exodus Intelligence is a company with many talented people. Many of them worked at TippingPoint’s ZDI (Zero Day Initiative) program and decided to run their own company. Recently, the company started a five-day 9-5 training on Breaking Binary Applications and Browser Exploitation, that I was honored to be a first to attend. While they have done these types of classes before at conferences like RECon, apparently, much has changed since those classes. The training week is split into two courses. Breaking Binary Applications, lead by Aaron Portnoy and Zef Cekaj, was taught for the first three days. This course was mostly about reverse engineering the protocol to understand how it recieves input to find design flaws and/or understanding how the client communicates and what paths those lead to to later be used for more fruitful fuzzing efforts. The Browser Exploitation class, lead by Brandon Edwards (DrRaid) and Peter Vreugdenhil (WTFuzz), was an intense two day experience. To say anything about this class would be that it’s a more than you ever wanted to know (but glad and useful that you now know) class on exploiting IE9 with a chosen Use After Free bug. Just note that these classes were not for the light-hearted, which is what I was looking for.
Breaking Binary Applications
The great thing about this class was the massive amount of material we went over in just three days and that most of the vulnerabilites weren’t public until after the class. The class was mostly geared on finding quick ways to help reverse a real application like finding your entry points, finding out what’s needed to communicate through to those entry points, ways around possible barriers, and then analyze as much as possible about what you can do with your user controlled data. We used IDA and Windbg extensively with Windows XP and server 2003 virtual machines. Easy ways around certain repetative issues we ran across were covered with the IDA Toolbag plugin. I was not able to get that plugin to work (didn’t seem to play well with IDAPython and I didn’t have enough experience with IDA plugins) so, thankfully, the class started off with the harder way first and then presented the easy/quicker way with the toolbag. I, personally, find this the best and most thorough way to learn things.
We did quite a bit of analysis using windbg. This was great because, while we didn’t focus on this architecture, windbg is the only good x64 debugger for Windows that I’m aware of. We used it so much that we eventually learned how to use and create our own filters for faster analysis of what we were looking for. With these filters, and help from other debugging tools like gflags, we were given plenty of information to perform a thorough crash analysis. Many tips from experience and custom windbg filters shown by the instructors allowed the student to cobble something up that worked for whatever situation you came across. The course especially covered the importance of using both dynamic and static analysis tools together and how to do it well.
SCADA You Say?
We started off with a SCADA product and finding how scary easy these things are to toy with. The great thing about teaching techniques on finding bugs and having known vulnerabilities is that many people in the class were able to find bugs that were previously undiscovered by the instructors. It also allowed a perfect real-life scenario training by using software that’s the equivalent of the fat kid on the dodgeball field. Everyone was able to hit it.
Java – The Still Old Faithful
The next day we went over the somewhat unwarrented fear of the Java 7u11 patch. This is the patch that sets applet security settings to high by default thus requiring a valid CA to sign the applet or it displays the big untrusted warning to the user. While most users have learned to click through anything to get what they want, any new exploit in Java is really only worth it if it bypasses this requirement. So, we analyzed the execution path a Java applet takes before the 7u11 warning is even seen. Showing different methods of attack that are still viable. The homework, after the so-simple you want to cry vulnerability was found, was to craft an exploit for the vulnerability. I really enjoyed just working on this part as I was able to come up with a better technique than the one shown by the instructors after crawling through documentation for what felt like hours.
Adobe Shockwave, We Hardly Knew Thee
My favorite part about this case study was the understanding that unleashing massive amounts of bugs is great, but it usually comes at the cost of long periods of grueling over documentation specs, api’s, and more before a valid gameplan can even be hatched. While we didn’t have to go as in-depth as the instructors, we were lead down the process on what it might take to find good bugs in large products. A lesson well needed for those who think with enough knowledge everything comes quickly and/or easily.
CA Arcserve – Interesting Developments
Finally, we were unleashed to wreck mayhem on a product. First we reverse engineered how the communication happened and where it happened (building the struct it uses). We then analyzed the attack surface, going in-depth into what many researchers don’t immediately go for when analyzing their target’s entry points. The actual vulnerability was one of my favorites as it was the most interesting to play with.
IBM Tivoli – The Pinata
This one I called the pinata for a reason. Most of the time was spent appropraitely reversing the client communication and bypassing many an annoying hurdle to get it right. But once we got everything we needed, we resorted to the quick bug hunting game of fuzzing. Each of us built our own fuzzers and hammered at the application in one of its, most likely, fruitful spots to find issues. In this game, nearly everyone in class found their own crash that they could play with.
Outlook And The Third Parties Drinking Game
As an extra bonus, we were walked through another bug hunting gem, finding old and problematic libraries used by the target. A recently patched issue was explored, analyzed, and left to the students to exploit on their own time. It was ironic that this was covered because I had to deal with this exact exploit in the wild not but a week before the class.
This was a very intense two days as it revolved around understanding many different things about IE9 internals and changes in modern Windows environments (like how the LFH works and how to abuse it). I learned a lot and there’s certain places in this course that I wanted to bash my head on the desk, but usually the instructors were just a question away from you. This class, unlike the previous, thoroughly took apart and analyzed one public UAF vulnerability and write exploits a couple of different ways.
Spray Spray Spray
After you were guided through an exploration of the Low Fragmentation Heap, IE9 internal objects, and analysis of the vulnerability, the first task was to take one of several different heap spray methods and apply it to the vulnerability. Many different styles were introduced, some that only work with IE9 or newer. The effectiveness and issues of each method was clearly presented and we were on our way. Many exercises were short leaps to better understanding of the vulnerability using excellent custom windbg filters and watching allocations. At the end of the day we were to gain EIP control with our chosen heap spray method.
Keeping it Classy – Mem Leak And Vulnerability Chains
This was the day when you had to have your head in the game. We started diving deep into exploitatoin techniques in order to get past modern protections. This included your generic ROP (in which you were given a list of instructions and were to find your own chain) and exploitiation techniques like abusing SHARED_USER_DATA module base leak. The most interesting and brain abusing part of this was understanding the memory leak, how it works, and how to trigger another vulnerability after you’ve used the memory leak to get around ASLR. This was all done internally in the browser with no spray and pray techniques. You get a chance to play with and understand how to use one vulnerability to perform the memleak and then continue to cause other issues that lead to proper and full exploitation. In the end, the exploit bypassed Windows 7 x64 (32-bit IE9 process) protections with EMET 3.5 enabled and was much more than reliable.
Even though I don’t have a lot of experience in trainings, this has been my favorite training so far. The class is more about having direct access to the instructors, in case you’re stuck/frustrated/confused, than anything else. They generally give you a concept and then 30+ minutes to play around with the concept by trying it yourself. The instructors were always willing to answer your question and give you different ways of thinking about the problem until you are on the right track. This allowed you exploration time with other options if you’re quick, or a hand-held guide on bypassing whatever mind block you’re having on understanding something. I’d reccomend anyone interested in bug hunting to definitely take the Breaking Binary Applications. If you are interested in deep diving into browser bugs and memory leaks (although IE9 is strictly covered, the understanding of the process should help in other browser frameworks), definitely take the Browser Exploitation course.