Brian Holyfield claims to have been doing it for a bit (http://www.gdssecurity.com/l/b/2010/09/14/automated-padding-...), although his approach seems to have relied upon default error emissions and is defeated by the common customErrors=on configuration. It doesn't sound like today's attacks have such limitations. And it isn't clear what actual effective workarounds exist, if any.
Even in cases where app logic will trip this approach up early (making hard assumptions about session vals having been initialized post-login and consequently failing fast, etc), the secrets are still captured.
Brian does not claim to have been doing it before Juliano or Thai. He wrote the blog post to explain in layman's terms what the attack was and released his own version of the original POET tool written in Perl.
Comments
Plus, the researchers didn't destroy the security. It was never there in the first place. And I doubt they were the first to exploit it, either.
Exactly what evidence have you observed to make you believe that other researchers have used CBC padding oracles to break the security of ASP.NET?
Brian Holyfield claims to have been doing it for a bit (http://www.gdssecurity.com/l/b/2010/09/14/automated-padding-...), although his approach seems to have relied upon default error emissions and is defeated by the common customErrors=on configuration. It doesn't sound like today's attacks have such limitations. And it isn't clear what actual effective workarounds exist, if any.
Even in cases where app logic will trip this approach up early (making hard assumptions about session vals having been initialized post-login and consequently failing fast, etc), the secrets are still captured.
Brian does not claim to have been doing it before Juliano or Thai. He wrote the blog post to explain in layman's terms what the attack was and released his own version of the original POET tool written in Perl.