Monday, October 14, 2013

Virtually Impossible @ ZeroNights & A PatchGuard Analysis on the company blog

Hi All,
I wanted to share two updates:
That's it for now...
G.D

Monday, June 11, 2012

Practical considerations implementing fuzzing acceleration via checkpointing

Hi all,
After giving my presentation in HITB I was fortunate to talk to some of the people that attended it and also some that contacted me via email afterwards. One of the most frequent questions I got was "how practical is it to implement a fuzzing acceleration framework?". Following up on that I decided to write a short post on the practical considerations of implementing an accelerated fuzzing framework by using DBI.
Some of the material in this post is based on one such Q&A discussion that I had with Peter Van Eeckhoutte (@corelanc0d3r) and published with his gracious permission.



Introduction to fuzzing acceleration via checkpointing

This section is aiming to provide a quick introduction to the subject. If you're familiar you can jump to the next section - practical implementation considerations.
If you're unfamiliar the concept of fuzzing acceleration via checkpointing and restoration the following slide from my HITB Amsterdam presentation provides an overview:




Friday, June 1, 2012

HITB Amsterdam 2012 Materials

Hi All!
HITB Amsterdam was an awesome conference. I hope you enjoyed it as much as I did. Thanks to all the organizers - you did an awesome job! Also thanks to everyone that attended my presentation you were a great audience, albeit sometimes quiet (shocked?!). :-)

Following HITB I wanted to make sure all of you know where to get the materials if you need those. The presentation is here, the source code for the pintool examples can be found here. If you are looking for more explanations of each of the code samples see this post.

Recently I've had a lot of discussions with people that attended the presentation in Amsterdam and with others regarding check-pointing techniques. Mostly for the sake of using check-pointing to perform high speed fuzzing but for various other usages as well. Since this seems like a topic that interests many people I've decided to write a blog post to detail some of the practical considerations implementing such systems. Look forward to this post soon.
If you'd like to request a post on a specific topic feel free to let me know what it is, though I make no promises...

Cheers!
G.D


Wednesday, May 23, 2012

Rebirth / Getting ready to HITB Amsterdam 2012

Hi all,
After a long period of not posting I'm finally back. A lot has happened in this period but most importantly I got married to my gorgeous wife Sonia. Due to the marriage preparations and some changes at work I didn't spare much time for personal research and publications. I currently have about five incomplete research projects. I am not going to make promises that I might not keep but I definitely plan to resume writing here and publishing new research in conferences.

I'll be giving a special edition of my instrumentation workshop in HITB Amsterdam on 24/May (known as a lab session in HITB speak). After learning a lot from the previous times I presented about instrumentation and improving my material I seriously believe that this will be the best edition ever. My only regret was that I had to cut down a lot of material due to the two hour presentation time. Normally people have trouble creating enough material for a two hour presentation so I guess I should count myself lucky. I've got a lot of goodness I want to put in and not enough time to talk about everything and show the demos.
Even so there is some awesome stuff included: automated vulnerability detection & prevention, fuzzing acceleration techniques, program visualization (good for anomaly detection and similarity detection), covert debugging (practically a built-in feature in PIN) and an introduction automated exploitation.

If you're interested in automated exploitation look forward to my next conference talk, possibly in hack.lu (if I'm ready by then). 

If you're attending HITB Amsterdam 2012 I hope you'll come listen. If not you're welcome to say "hi" (or share a beer) anytime - I'll be happy to meet anyone that reads what I write here.

Cheers,
Gal Diskin

Saturday, August 13, 2011

Post Vegas Post - BlackHat / DEF CON Workshop Materials, Notes and Some Mess

Hi All,
I've finally solved some internet access problems and can upload the materials I wrote for my BH and DEF CON workshops. For those in a hurry the materials are here: [presentation] [code examples]. If you want to catch me giving this workshop (in a somewhat modified version) come hear me in hack.lu.
BH & DC this year were great - great parties (except MS that initially didn't want to let me in until after the party started and I made other plans :P), some good talks and (re)meeting great people.
Thanks again to everyone that came to listen to me.

Some notes regarding these materials:
  • Please note that the presentation was not written with offline reading in mind so it might make a hard read in some places. Questions are welcome in the comments.
  • The Defcon presentation is mostly a variant of the BlackHat one (or vice versa) which is why I did not include both.
  • The examples might be included in the official Pin distribution some day. For now I'm going to start a page on this website to preserve these materials. If you have any submissions of updates, fixes or additional examples you want included send those to me. notifications of updates will be published via  twitter.
  • Since I was lazy and intended to control the length of my presentations by deciding what to include in the demos on the fly the details of the demos / examples mostly do not appear in the presentation itself. That is why I've included notes about the demos and examples below. Please note the examples were written with educational purposes in mind and not
  • The end of the presentation contains a ton of references to all sorts of DBI usages for security or whitepapers on the subject - highly recommended read for those interested in the field.
Examples and demos:
  • Exploiter1 - An example of automated exploit development for classic stack buffer overflows and assuming no DEP and ASLR. If you had it 5-7 years ago you could write a worm that would actually "multiply" and learn new attack vectors as it goes along (muhahaha :D). I'm intentionally releasing this degenerate version so as not to provide people that couldn't write this code alone with the ability. If you're interested in full capabilities along these lines - contact me privately, I'm considering it. I might write a longer blog post on this subject (if I ever get time to write).
  • InMemFuzz - An example of in memory fuzzing and of using checkpointing to accelerate fuzzing. please note the checkpointing part only covers registers. One of the exercises in the Defcon workshop was to complete it. Again, a blog post on this will be added to the fuzzing series if / when I have time.
  • RetAddrProtect - An implementation of "shadow stack" method to defend against return address overwrites in your program. I originally invented this method for some job back in early 2004 unknowing that the term "shadow stack" existed I called it "protection stack" and only very recently discovered the proper name for it which is why, since I'm lazy, the tool still calls it "protection stack". See the work from Caro'11 by MS guys on the matter (link in the presentation).
  • Taint 1-3 - Examples of basic taint analyzers. These are simple examples that only handle the propagation of taint through the MOV class of instructions. The first outputs some of the dataflow, the second improves the log to show only taint flow and the third adds tracking of the taint source.
    • Taint_vis_2D - is a script that is meant to show how a very simple (practically dumb) visualization of taint is still very useful to us compared to reading log files. Read the source to understand how it works.
  • Program data-flow visualization - Two examples of memory visualizations are included in the kit. Those are meant for working with a recording of all memory accesses generated by the "pinatrace" (memory access trace) example from the official Pin kit. When executed on the log file generated by pinatrace these tools generate a 3D view of the program memory accesses that allows us to analyze the program visually. For example, it is fairly easy to identify loops and extrapolate potential usages of those loops. To understand the information generated: one axis represents the address, the second represents the PC location at the time of the memory access and the third axis represents the order of the operations. Blue means a read, red means a write. You can navigate through the visualizations using the mouse (zoom in/out and rotate). Again, if you're interested in advanced taint / data-flow visualization capabilities I'm open to discussion privately. See example images below.
  • Anti Debug - the first anti debug example is meant to show that Pin will not trip this anti-debug protection while using a debugger would. The second is meant to show that the transparent debug feature in Pin allows you to debug ignoring Anti-Debug techniques. Please note that the first example will trip the debugger under the transparent debugger - if you want transparent debugging to work on it you need to write a pintool (which was meant as education / exercise).
  • Double Free - An example of how to detect potential double free cases. Some might say that it is less relevant due to the fact that is a fairly easy task using static analysis and modern libc protections however, sometimes you don't have the luxury of having access to the source code or you work on legacy systems where it becomes relevant. In addition, vulns like the OpenSSH double-free race condition vulnerability would not normally be caught by a static analyzer looking for double free.
  • Malloc Fault injection - this simple PinTool does exactly what the name suggests. It injects malloc failures into the program at a random interval. For our case I set the frequency to be very high (every ~100 calls to malloc) it is interesting to note that the Linux loader and libc initializations usually fail intelligbly with a reasonable message. 
  • VulnEx# - these are vulnerable code examples to run the tools on - each example purpose is documented.
Pretty Pictures:
Here are some pictures of visualizations with a small explanation on how to read those. these are based on the very early work of the OS loader in Linux while starting to execute "ls". If you're looking for why I choose this specifically the answer is "because" or in detail - because it fit me at that specific moment (yeah, I'm lazy).

Notice the series of memory read-writes a little up and to the right from the center - this is a loop, almost certainly with a counter. since no other memory writes are visible most probably this is a search loop or a loop related to register calculation

Same loop as before, now a little to the left from the center and depicted using separate lines for reads and writes. Note that it is now almost certain that the top red line represents some sort of counter.

On the center and a little below and to the right notice another loop - note the symmetry in the reads and writes relative positions. figuring out what it probably is is left as an exercise to the reader :P (you can also see this same loop from the top in the first picture to the left of the center)
~1000 memory accesses, note that blocks with relations are easily identifiable. Easy to see that a filtering capability is very valuable. finding more interesting patterns will require some more staring.

BTW, the ZIP files on google docs are downloadable - through "file" -> save original

-- The End (for today)
Please leave a comment and share if you liked it.

Posts or possibly talks or whitepapers in planning / phases of writing, though I don't know when I'll get to each particular item: "how I would go about blowing up batteries if I was 0xcharlie" (pending legal review - meaning it is too close to my work research and besides if batteries start blowing up there could be trouble...), "Fuzzing series part 2 - monitoring OR why I'm tired of hearing about !exploitable", "fuzzing series part 3 - fuzzing protocols from the RFCs using semi-context aware grammars", "how to attack HW using SW" (pending legal review - again close to work stuff), "Enough with the code coverage! - feedback driven fuzzing based on data coverage and taint analysis", "old/new heap attacks", "increasing exploit reliability". Every post or potential talk depends popular demand, free time and me not getting sued.

-- Gal

    Tuesday, June 7, 2011

    The 3 phases of fuzzing

    This post is going to be the first of a few discussing the art and science of fuzzing.

    Sooner or later we all fuzz something. When we do it is important to us (or at least to me) to spend time wisely to maximize results with a minimal effort. Some people think that only fuzzing dumbly and quickly is the way to go, while others think that only smart fuzzing will bring results against targets that had any prior fuzzing done on. I think both are wrong. For those that support dumb fuzzing I will point out MS SAGE work that found a ton of stuff after they ran dumb fuzzing on their applications. For those supporting only smart fuzzing I'd point the Adobe 1-byte bug found by a dumb fuzzer not too long ago.

    So, here is my take on the question of dumb, smart or in-between fuzzing:
    1. In every project we should start with dumb fuzzing - making sure we don't miss the obvious by making our fuzzer too smart. This should happen in day one, as soon as we have a minimal understanding of the project we should write some dumb fuzzer and start running it - this is CPU cycles well spent. Usually we'll find something this way. We must also keep adjusting our
    2. As we go on we start gaining a more in-depth understanding of the project we're working on. This is the time to start developing a smarter fuzzer. It is important to start from a slightly "dumb" smart fuzzer. Meaning one that has a minimal knowledge of the protocol or implementation details. We should have some hints on how to focus this fuzzer from our initial dumb fuzzer and what we found (or didn't find) there.
    3. Finally it's time to bring out the big guns - we must build our "ultra smart" fuzzer. This one should be an evolution of the initial slightly "dumb" smart fuzzer we wrote. It should be based on our findings during the project - from fuzzing an other stuff we did. 

      Well, that was my general view on fuzzing. Next post or posts will discuss why I'm tired of !exploitable or the question of monitoring while fuzzing and share a small tool / python code I'm working on whose purpose to make a "somewhat context aware" fuzzer for context free grammars. The final aim of this tool is to be able to fuzz stuff immediately from the BNF description found in many RFCs.

      -- Gal

      BlackHat USA & Defcon 19

      It's been a while since I last wrote something here. I've been busy with work and working on conference stuff. I've been accepted to give a workshop on DBI in BlackHat and Defcon (my workshop is not listed yet on Defcon website) in August.

      This means a lot of work making the workshop and preparing to talk. Couple it with being busy at work and having to go on reserve duty in the IDF for two weeks starting next week and you will understand why I barely have time to write something. Anyways I've decided to post some thoughts and incomplete works here soon so it doesn't get boring so stay tuned.

      Since I'm giving a workshop on DBI I'm now looking for all works published to review the existing art known in the market and probably reference. If you have anything you did, read or know of that uses DBI for security - using PIN or any other DBI engine - please share those with me here or on Twitter  you are also welcome to send me an email (if you can't figure out an address, you probably shouldn't reach me by email).

      -- Gal