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

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

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

Binary Instrumentation for Hackers

I've been planning to write something about the "Binary Instrumentation for Hackers" presentation I gave at the Israeli Defcon user group (DC9723) on 26 April right after the presentation but I kinda got sidetracked (which I will try to avoid from now on). At first I waited for the video to be online but right now I don't know if and when it will be online and later I got too busy with some work . Anyways, my slides are available HERE and if the video will be uploaded it will be HERE (the slides are English but the presentation was given in Hebrew). I'd like to thank DC9723 organizers for having me, I hope to come back again someday.

Also, the slides from my lightning talk at Hackito Ergo Sum 2011 are up with the other conference slides HERE.

I have (today) sent submissions of workshops and talks on the subject of binary instrumentation to BlackHat USA & Defcon 19 (check out the Defcon site, it just opened), hopefully I'll get a chance to talk about some awesome stuff with the great people in attending these cons.

Oh, and if anyone happens to be in Amsterdam next week (15-21) for HITB, I'm there on business. I won't attend HITB but would love to meet anybody that actually reads my blog for a beer in the evening.

While we're at it, If you are in HITB don't miss Itzik's & Zuk's presentations - I know they have some kwel stuff planned. I also recommend going to see whatever Travis Goodspeed & Claudio Crisocone present - I haven't talked with them about the details of their presentations but they usually do great stuff. 

(yeah, in case it was unclear I'm disappointed to be in  Amsterdam at the same time HITB happens and not attend HITB).

-- Gal

Hackito Ergo Sum 2011 - Day 3 (and last)

Day 3 was another great day: we had a couple of cybercrime talks, Ruby on rails, DNIe , USB autorun for Linux and the solution to the conference crackme. I want to take a chance to thank the organizers, I really enjoyed this conference, the people were great and the talks interesting and I hope to be back next year, maybe even to present a talk.

As usual I welcome comments, either here or directly to me - feel free to let me know anything constructive.

Raoul Chiesa / Keynote

Raoul's keynote focused on cybercrime and UNICRI and their hacker profiling project (HPP). Cool quote - "you got information, you got power". The talk was cool and included parts focusing on who's behind cybercrime that I won't recount here out of respect to the fact he asked not to record anything during these parts of the talk. He shared his views on why cybercrime works:

• New user every day = new fools every day
• Making money  (fits to the economical crisis)
• Technical know how is easy to get
• Back in the day we worked hard to get something
• Easy to recruit idiots ("mules")
• Psychological - "they will never find me/bust me"
• Psychological - Lack of violent actions

And how HPP classifies hackers:

• Amateur
• Wanna be lamer (9-16)
• Script kiddie (10-18)
• Hobbyist
• Cracker (17-30)
• Ethical hacker (15-50)
• Quiet, paranoid, skilled hacker (16-40)
• Pros
• Cyber warrior (18-50)
• Industrial spy (22-45)
• Gov agent (25-45)
• Military hacker (25-45)

He had a lot of interesting stuff to say and the talk actually went overtime. I can't possibly begin to recount even the public parts of the talk in a short summary but I highly advise you to listen to him if you get a chance.

Joernchen of Phenolit / Ruby on Rails form a code auditor's perspective

This talk focused on how to audit Ruby on Rails (RoR) code. Key points:

• 3 layers called MVC - Models, Views, Controllers - review them
• Start from the controllers
• Look at the database
• Look at the filters
• RoR has some fancy magic that can go wrong - for example: mass assignments (CCC.de had a vuln because of using this)

Nice talk and definitely someone you should talk to if you audit RoR, personally this isn't in my focus areas.

Gabriel Gonzalez Garcia / Man in the Remote: PKCS 11 for fun and profit

This talk focused on ways to defeat the DNIe which is the Spanish government system of digital IDs used for authentication and non-repudiation certificates. Basically he implemented an attack against the untrusted terminal problem that the PC is posing between the DNIe device and what it authenticates to. There are two ways to use DNIe for web auth: Java applet or SSL + client certificate. The device itself has an EAL 4+ certification and defends against most hardware tampering attacks. What he found were two practical attacks on the terminal:

1. Write a fake interface library that acts as an RPC server connecting his machine with a remote DNIe
2. Write a fake java applet that acts as the proxy and runs on the client machine (easier)

He proposed a solution that I personally disagree with to use "distance bounding" == measure response time and disallow slow responses.

Jon Larimer / USB autorun attacks against Linux

This talk focused on how to implement autorun attacks against Linux and showed one successful attack. To be exact it is successful against GNOME. So first of all the specs of freedesktop.org forbid systems from running code without asking the user. That being said a lot of processing is done when a new storage device is connected: file system drivers execute, file browsers read the contents and thumbnailers create thumbnails. These attacks are basically physical access which usually means "game over" because you can use DMA attacks using 1394 vulns and other attacks like cold boot attacks. However, assuming the latter is complicated for you and you are on a system where protections for against 1394 DMA attacks were implemented you need another way. From here on Jon described his processes of research which I will skip directly to the end - he decided to focus on Thumbnailers used by Nautilus (GNOME file manager). He found a vulnerability in the Evince thumbnailer for DVI files (among others). Luckily (or unfortunately, depending on you view) Evince uses AppArmor and compiles as PIE, in addition the kernel has ASLR enabled (but 32bit system). He worked on overcoming this:

• ASLR and PIE can be defeated by brute forcing -
• On a 32bit system there are only about 3000 addresses that the Linux kernel can load libc to.
• Using this we can just generate 3000 files - 1 for each address
• Loading will be slow (about 10 min), but success is almost sure
• Interesting result he found were that in his statistics around 10% of the addresses were used significantly more than others
• So you can create only about 300 files and have high chance of success
• He says he didn't research why is this. This is something that someone should really pay attention to.
• AppArmor can be worked around
• Doesn't protect against X11 library calls

He showed a demo of killing the lockscreen using a USB stick. Jon Oberhide added an interesting comment that there is a rather new layer for partition parsing in Linux that had a lot of bugs recently.

Yuval Vadim Polevoy / Money is in the eye of the beholder: new and exciting ways to steal you money

This talk again focused on Cybercrime, Yuval is from RSA research lab and really interesting to talk to. He focused on how cyber-criminals make money and the underground economy. I will recount some of the most interesting points, I'm not sure I can do justice to the details but that is the cost of summarizing...

• A cybercrime operation requires:
• Bots
• Campaign
• Drop point
• Bot plugins
• Hiring & managing mules
• Establishing covert channels
• Maintain fast-flux (optional)
• The skill set required for that is:
• Low level programmer
• Oday researcher
• Spammer
• Hosting owner
• JS programmer
• HR recruiter
• E-commerce export
• IT specialist

These are too many skills for most people, so the common solution nowadays is outsourcing parts of this effort to others.

For the end, he focused a bit on the future techniques that malware authors will use, in particular screen grabbing. Yuval showed a demo of two techniques that can be used for screen grabbing in Windows, thus defeating on screen keyboard and allowing other stuff like cheating in online poker…

Eloi Vanderbéken / Hackito Ergo Sum crackme

For the end Eloi talked about the crackme. I won't go into all the details but here are the highlights:

• Verification alg - based on modified RC4
• Obfuscation
• Inst. Mutation
• Control flow graph obfuscation
• Encryption layers
• Direct native API call
• Using sysenter (also uses a lot of random invalid syscalls) which is why the crackme only worked on 32bit systems
• Anti-X
• Anti debugger
• Anti-instrumentation
• This was especially interesting to me, in particular because Eloi used Pin as the example for instrumentation engine
• Detect hook on KiUserExceptionDispatcher nad KiUserCallbackDispatcher
• Detect stack reuse by instrumentation code: place a constant in esp-4, execute syscall, check constant
• Anti data-tainting

This is definitely a respectable set of protections. Only 3 solutions were submitted. I might try to write a PinTool that will be able to handle all these protections and post it here if I can.

Well, that's it for Hackito this year - I hope you will read my future posts.

Hackito Ergo Sum 2011 - Day 2

Day two of HES 2011 brought even more awesomeness. I will summarize the talks here:

Keynote - Rodrigo Branco (BSDaemon) / Behind the scenes: security research
First up was Rodrigo giving a keynote ( which shows he is old :P ) he focused on the state of the industry and mentioned several key points that might be debatable:

• there are a lot of snake-oil security experts, its really hard to find real experts
• 0days are nowadays spreading in minutes to all vulnerable hosts
• lots of "vulnerabilities" released are not exploitable or at best have an exploit that works only on the VM of the guy that developed it and nowhere else
• The new generation of hackers is not coming - most of us grew in a time where using a computer was a challange, now its just plug&play, GUI, etc...
• he went into security myths common in the industry

I'll settle for repeating two interesting points he made since this is a short summary:

1. What is the difference between rouge AV and a real AV?
1. both do not guarantee anything
2. both have "premium options" you can buy
3. both have a nice GUI (although rouge AVs usually havea nicer one)
4. both will slow your system
5. both will have false alarms
2. All companies benefit from having a security research team but you need to know how to build and work with one:
1. Researcher brings real understanding of threats and security awareness
2. when choosing a researcher, select carefully
3. researcher are lazy so define expectation not a specific target
1. if you know what you want you hire a developer, not researcher
4. your team has to travel
5. expect to buy tools

James Oakley and Sergey Bratus / Exploiting the Hard-Working DWARF
Due to circumstances I couldn't avoid I had to miss this talk which is really worthwhile. I have done some work on DWARF for instrumentation but was interested to see it from an exploitation point of view, especially since they say it is Turing complete.
Slides (from shmoocon actually): http://www.cs.dartmouth.edu/~electron/dwarf/



Jon Oberheide & Dan Rosenberg / Stackjacking Your Way to grsecurity or PaX Bypass
In this talk the authors showed how to exploit the Linux Kernel in spite of hardening mechanisms like GRSecurity or PaX. They took an interesting approach - not focusing on a specific vulnerability but making a minimal set of assumptions on the situation and showing any vulnerability and situation satisfying these assumptions can be exploited.

• Kernel protection Assumptions:
• Zero knowledge of kernel address space
• Fully randomized kernel text & data
• Cannot introduce new code into Kernel address space
• Cannot modify kernel control flow (e.g. data only - no ROP)
• Attacker assumptions:
• #1: can do arbitrary kmem write
• Requires some knowledge of some kernel layout information leak to exploit
• #2: Kernel stack memory leak
• AKA "the Dan Rosenberg" :P

taking this into account they developed a 3-stage exploitation technique: KSTACK leak --> stack groping --> overwrite a specific part of thread_info struct. Going into details will require a whole post at least so I will mention the highlights only, for more details try Oberhide's homepage (nothing up yet) or Dan's blog (seems abandoned). For now I will focus on two points:

• In order to get all the information needed from a Kernel stack leak they developed a library called "libkstack" - it works with a leak of 3-bytes and up.
• Stack grouping is a name to techniques they invented in order to actually exploit
• kernel_ds - invented by Dan R. focuses on using set_fs() to change addr_limit in the kernel
• Obergroupe - invented by Oberhide - uses a child process to clobber a process stack frame while it is inside a syscall (race condition)

Exploitation is pretty safe and takes about 1-2 minutes according to their demo.




Richard Johnson – A Castle Made of Sand: Adobe Reader X Sandbox
This talk went into detail regarding Adobe reader sandboxing and security, here are my takeaways:

• Adobe started using ASLR and DEP which is great, but only on new Windows systems. also seems implementaiton is partially lacking since some DLLs (e.g encryption) are loaded to a pre-defined address.
• Adobe works on sandboxing using Win process privileges and IPC limitations, a lot more work is required
• need to implement security features for non-Windows platforms as well
• need to compile to 64 bit - will reduce chances of spraying

Aaron Portnoy & Logan Brown / Concentrated Fire: Black Box Auditing Adobe Shockwave
The guys from TippingPoint gave a similar talk to the one from CanSecWest so no need to go deep here. Some cool stuff:

• They use a lot of Dynamic Binary Instrumentation to analyze SW
• Shockwave uses a private memory manager called SmartHeap
• they crowd-sourced the exploitation of the crashes they discovered during Recon
• If shockwave lacks a vulnerable component on your target don't worry - it will DL it for you :)
• ZDI will not buy any more shockwave bugs or touch shockwave from now on!

Kevin Redon & Ravishankar Borgaonkar / femtocells : inexpensive devices to test UMTS security
For those of you that don't know a femtocell is a small cellular base-station that works in a really limited range. Basically your phone connects to the femtocell that connects to your provider network over the internet. First part of the talk focused on taking control of the femtocell firmware, I will skip this except they used the recovery mode, which shows how careful you need to be with such features. you can buy a Femtocell in 12 countries, see femto-forum for details. Once you are in control you can do some cool stuff:

• MITM on UMTS 
• Calls are only encrypted between the phone and the femtocell, then sent in clear text
• showed a demo (that failed first time) of recording a call and capturing SMS messages
• Provider networks assume full trust in players so no firewalls, protections, etc... 
• seems like easy targets from their description, no actual details provided
• 3G / 4G phones can be attacked by the femtocell acting as the network provider
• again, no details were provided

This is still a research in progress, seems very promising. I recommend to follow.




Lightning Talks
There were 3 lightning talks today:

• First one was mine, I got manipulated into doing it while drinking beer over lunch but it was really fun.
• I talked about "Binary Instrumentation for Hackers" 
• I presented a few select slides form the talk I'm working on (see earlier posts) explaining what can you do with binary instrumentation and and example Pin based binary instrumentation tool.
• After me Alex talked about his Passive DNS work
• See the website
• He showed a cool demo how it worked on the recent Lizamoon attack
• Last talk for the day was joernchenon Distributed Ruby (dRuby) vulns
• to sum it up dRuby uses $SAFE which prevents you from calling arbitrary code (eval etc) by activating taint protection
• unfortunately this doesn't work so well becasue you can still use syscall()
• nice method to identify if you are one a 64bit or 32bit by using syscall(20)

Well that's it for today, I hope I can keep the pace and publish a summary tomorrow as well.