Paddington Oracle Bear

Immunity does a lot of commercial consulting, and one thing I make sure to do is follow up on essentially every gig. I think it's important to know what we're getting into customers with, and why. This is the major benefit of any services arm - you get a ground truth for how all this stuff applies in the wild.

For example: Does training effect phishing? What do people build web applications with? What vulnerabilities are in .Net applications these days? Is Java on the Server still vulnerable to the same things it used to be, or have new frameworks made it better?

This is different than the sorts of data you get from web application scanners. You can only reach so deeply with a scanner, which means that applications can, over time, appear to be getting MORE secure. But what they MIGHT be doing is getting more secure from the kinds of things scanners can find!

The Paddington Oracle: "I see something over there! IT IS BAD CRYPTOGRAPHY IN YOUR SESSION ID!"

For example: in the past year, we've found more Padding Oracle cryptographic attacks than SQL Injections. This introduces another problem: Development teams are well prepared to understand certain classes of vulnerabilities.  I find SQL Injection and File Include are something you can easily explain, but CSRF and XSS are a lot harder. Imagine the fun we have on a consulting readout when we hand over ten pages of explanation of the cryptographic differences between what they did, and what they should do to defeat a complex attack that while hard to explain, still "got a shell".

Good consulting is more TRAINING than services. If you don't teach them how to do padding oracle attacks, then they'll just re-code the bug into something else. And failing that, you have to at least teach them it is important to get right, and to test it before they ship it. Sometimes that alone is the win of the engagement.