WOOT 2008: The Good, The Bad, and The Ugly

Day one of my trip out to San Jose to attend the WOOT, HotSec, and USENIX Security trifecta is over. The 2nd Workshop on Offensive Technologies (WOOT) took place today and I'll be breaking it down with "The Good, The Bad, and The Ugly".

I'll be discussing a few of the presentations at WOOT today: the ones that peaked my interest (The Good), the ones that didn't meet my expectations (The Bad), and the funny or miscellaneous topics that were discussed (The Ugly). WOOT started off on a good note with an impressive intro video from Tal and Paul Vixie speaking about some of the unexpected operational issues involved when enabling source port randomization for resolvers. The rest of the conference went smoothly and was on par with last year's WOOT. I had to step out during the session with Giovanni's phishing study and Elizabeth's botnet-related paper, so I unfortunately won't be able to comment on those presentations.

The Good

Insecure Context Switching: Inoculating regular expressions for survivability
Will Drewry and Tavis Ormandy, Google Inc.

While Will and Tavis' work broke a lot of regexp engines with their regfuzz tool, the more interesting aspect to take away from the paper was the notion of "insecure context switching". We see these scenarios popping up all the time (eg. the huge attack surface exposed by antivirus engines on mail servers) and now we have some sexy terminology to label them.

Modeling the trust boundaries created by securable objects
Matt Miller, Leviathan Security Group

Matt Miller (skape) gave an excellent presentation on identifying and modeling trust boundaries (specifically, the trust boundaries implied by access rights on Win32 objects) using dynamic instrumentation and tracing. I'd like to see his approach applied to other scenarios without getting too attack graph-y.

Rump Session: Software Assurance
Charle Miller, Independent Security Evaluators

Charlie Miller's rump session topic on software assurance raised some interesting question similar to David Lie's HotSec paper last year (Quantifying the Strength of Security Systems). How can we effectively provide assurance that a particular product is secure? Can open auditing challenges backed by economic incentives provide some notion of confidence in the security of a product? If $50,000 is offered for a six month period for breaking your product and no one collects, does that mean your product is secure, doesn't have a reward high enough to attract truly skilled auditors, or just that the potential financial gain by an attacker worth more than the economic incentive? Food for thought.

The Bad

Exploitable Redirects on the Web: Identification, Prevalence, and Defense
Craig Shue, Andrew Kalafut, and Minaxi Gupta, Indiana University

Craig Shue presented on the dangers of "open redirects" on the web. The premise is that a URL like http://legit.com/redirect.php?dst=http://phishing.com contained in an email may trick a user into thinking that their destination is actually legit.com even though they are immediately redirected to phishing.com.

Instead of proposing server-side modifications and client-side heuristics to address the "problem" that break many legitimate redirects, the authors should have spent more time on evaluating whether this actually is a problem worth fixing in the first place. Perhaps a user study detailing how many more subjects fell victim to a phishing attack using open redirects compared to other methods of URL obfuscation would make the results of the paper much more compelling. Without such empirical evidence, I'm simply not convinced that open redirects are a problem worth putting resources into.

The Ugly

Aaron Portnoy and Ali-Rizvi Santiago from TippingPoint DVLabs had some hilarious videos from the Pirates of the Caribbean MMORPG showing off their modifications to certain in-game attributes such as physics values. Definitely worth a look.

After Charlie Miller's rump session, I'm convinced "Dowd-weeks" needs to become an official metric of software assurance, although we'll certainly need to fire up the cloning machine to make it scale. There's only been a few times that I've slapped the "jonojono-certified" label on a code base.

My new favorite analogy is Tal's comparison of building an effective development team with student housing. Living by yourself or with a single housemate offers you a large amount of control over your lifestyle. Similarly, developing a project by yourself or with a couple people often results in a nicely designed system, pedantic code styling, and a solid end result. However, when you start adding more developers/housemates and delegate control to others, your code/lifestyle tends to degrade significantly. I can especially relate to this having lived in student housing for 6 years now ranging from no housemates to 30 housemates (literally).

UPDATE: there's been some interesting discussion on Dailydave recently regarding WOOT.