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