Wendy Knox Everette
Category: Vulnerability Development
Summary: Your webapp is probably dumping ERRORs and FATALs to your logs & you’re ignoring them unless your site is down & your pager is going off. Does anyone ever do anything with them outside of running some tail –f’s to debug?
All those error messages may be going to waste, because your website visitors are a great whitebox fuzzer. By configuring your logging to save both the errors and the URLs that generated them, then parsing those logs regularly, you can track down the most frequent crashes in your webapp.
This talk will explain (very lightly because I assume anyone at Infiltrate loves fuzzing) what whitebox fuzzing is, why your website traffic can be thought of as a huge smart fuzzer, how to capture enough information in your error and request logs to capture useful information about your bugs, and offer some suggestions about how to capture the bug information in
your logs into your bug tracker. (Here’s a hint: write some code to do all that log parsing & correlation for you.)
Why is thinking about your web traffic as a smart fuzzer interesting? What if we had smart fuzzers who understood the context, but still did all kinds of crazy things that are likely to cause crashes? What if these smart fuzzers concentrated largely on finding bugs in areas we care about? You have them. They’re called your website visitors.... users come with their own agenda, they are just trying to do use your website to do a task (Usually. Hopefully.) If context could be tied to the crashes in the web app logs, you have a source of interesting data for developers. Think of this as grabbing pcaps to reverse a vulnerability; you have the error output from your website telling you where a problem is; with some collation you can re-construct the user’s query that triggered the error.
Since Infiltrate is hung up on offensive everything, here’s your offensive slant: your website is probably running a lot of open source software used other places. Some of these crashes might be from those libraries instead of your own buggy code. If there’s a crash in that code, there you are, a free bug that’s maybe exploitable. But maybe not, it could also be a
complete waste of your time to send your software bots looking at those tasty crashes anyway.