[Speeding up the eXploit development process]
Jerome Athias gives a talk on how to more effectively use the eXploit framework.
You can watch the presentation via Google Video Link
Download .doc format – HERE
[Advanced Hacking Flash/Hard Drive Recoveries]
Scott Moulton talks about advanced data recovery from flash and solid state hard drives.
View the presentation via Google Video Link
[Crypto Boot Camp]
Rodney Thayer gave a 2 hour seminar on cryptographic technology. It was designed to give the audience a working knowledge for dealing with vendors. He gave some rules of thumb for choosing encryption. In order of preference, when doing symmetric key crypto: use AES with a minimum 128bit key, if not that 3-key Triple-DES, or last RC4 with 128bit key. For hashing: SHA 256 preferred, SHA 1 if you can’t do any better, and MD5 if you can’t SHA. For public key: RSA using at least a 2048bit key. The top choices in these lists were picked because they’ve stood up to years of scrutiny. One major theme of talk was to never roll your own crypto algorithm or buy someone elses. Proprietary algorithms get broken all the time, like the GSM A5 crypto we talked about earlier this year.
[Release notes not yet available]
[Real world Fuzzing]
Just when you though fuzzing was dead, Eliot Phillips from Hackaday comes back with his notes on Charlie Miller’s fuzzing seminar.
We dropped in on Charlie Miller’s fuzzing seminar at the end of the day yesterday. Fuzzing become a fairly popular topic in the last year and essentially involves giving a program garbage input, hoping that it will break. If it can’t handle the fake data and fails in a non-graceful fashion, you could have found a potentially exploitable bug. Fuzzing is a fairly simple idea, but as Charlie points out, without some thinking while you’re doing it it’s unlikely to be very productive.Say you wanted to fuzz a PDF reader. You take a random good PDF file and use a fuzzing program iterate through multiple mutations of that file. This brings up the question of how long do you fuzz something? Do you let it run 24hrs, is that enough time? Charlie applies the principles of code coverage to determine exactly how much of the code his fuzzing is actually testing. He used the PNG library as an example. He picked a random PNG to mutate from and it tested a small percentage of the code. Studying the PNG spec he found that there are 21 different chunk types possible in a PNG file so he grabbed 1600 random PNGs and mutated off of those. These many different seed files gave him a lot more code coverage because the files feature almost all the different chunk types. The principle idea being if you don’t execute a line of code you’ll never find the bug in that line of code.
Charlie was part of the team that’s credited for finding the first iPhone exploit. They used code coverage to determine where to start working. Apple’s WebKit is open source and there is a note that says to use Mozilla’s test suite to test modifications the JavaScript core. Using gcov, which is part of gcc, they ran the test against the code. The tool showed what code was executed by the test suite. They ignored that code and started poking at the large block of untested code they found since that was more likely to contain a bug. That’s where they found the Perl RegEx parser which was eventually exploited.
This isn’t just for programs with the source; you can also use code coverage tools like Pei Mei with IDA Pro to determine what part of a binary file the specific code you’re looking for lives. Then you can write smarter generators that will hit more of that particular code.” – via: hackaday
[Video of the presentation – Google Video Link]
[uri use and abuse]
Nathan McFeters and Rob Carter gave a presentation on the problems with URI handling. URIs are used to send commands to external applications from a web browser. itms:// for iTunes for example. Any application that registers a URI has the potential to be abused through this route. For their first example they showed a stack overflow in Trillian’s AIM handling. The next demo created a “Critical Update Available” button on Picasa’s interface. When the user clicked it, their photos would be uploaded to the attacker’s server. They even display a “download progress” bar to encourage the user to keep the connection open.” – via: hackaday
You can read about the attack on cocontributor Billy Rios’s blog.
Although I didn’t attend, I tried to keep track of all the keynotes, and blog submissions of last weekends Toorcon 9 (October 19-21). Here you will find a brief synopsis of what took place, or at least what I came to find of interest. As more information becomes available I will continue to post.
Vivek Ramachandran’s Cafe Latte attack was one of the last talks. It’s fairly simple and deals with cracking WEP keys from unassociated laptops. First your WEP honeypot tells the client that it has successfully associated. The next thing the client does is broadcast a WEP encrypted ARP packet. By flipping the bits in the ARP packet you can replay the WEP packet and it will appear to the client to be coming from an IP MAC combo of another host on the network. All of the replies will have unique IVs and once you get ~60K you can crack it using PTW. The bit flipping is the same technique used in the fragmentation attack, but Cafe Latte requires generation of far fewer packets. – Hackaday
Download of the Presentation – PowerPoint Presentation Link
View the presentaion via Google Video Link
OK, this one is just theoretical... 