libfuzzer-workshop VS onefuzz

Learning how to is half the fun!

There's a bunch of good tutorials out there on [dumb] fuzzing (presumably where you'll start). One starting point I'd recommend is taking a binary that accepts input from stdin and making some proof-of-concepts with AFL (https://lcamtuf.coredump.cx/afl/).

If you'd rather start from a code/library perspective (and not CLI), I'd recommend libfuzzer (https://github.com/Dor1s/libfuzzer-workshop/).

There's a lot of other fuzzers, techniques, and depth to the field, but I'd recommend inch worming through (speed up as you gain more comfort). The Fuzzing Book is good to help you understand the logic behind techniques and strategies (https://www.fuzzingbook.org/)

As for some management, there's a few decent "monitoring" systems out there; personally I just SSH in and check the fuzzer manually (I leave it running in a tmux pane), but if that's not your cup of tea I've heard good things about OneFuzz (https://github.com/microsoft/onefuzz) and LuckyCat (https://github.com/fkie-cad/LuckyCAT).

Happy to answer any specifics of the sort :)

That depends on the language you want to fuzz. A good general introduction and hands-on "course" for C/C++ is https://github.com/Dor1s/libfuzzer-workshop. If you prefer Java and just want to get a feeling for how concrete fuzz targets can look like, take a look at the Jazzer examples at https://github.com/CodeIntelligenceTesting/jazzer/tree/main/....

Learning how to is half the fun!

There's a bunch of good tutorials out there on [dumb] fuzzing (presumably where you'll start). One starting point I'd recommend is taking a binary that accepts input from stdin and making some proof-of-concepts with AFL (https://lcamtuf.coredump.cx/afl/).

If you'd rather start from a code/library perspective (and not CLI), I'd recommend libfuzzer (https://github.com/Dor1s/libfuzzer-workshop/).

There's a lot of other fuzzers, techniques, and depth to the field, but I'd recommend inch worming through (speed up as you gain more comfort). The Fuzzing Book is good to help you understand the logic behind techniques and strategies (https://www.fuzzingbook.org/)

As for some management, there's a few decent "monitoring" systems out there; personally I just SSH in and check the fuzzer manually (I leave it running in a tmux pane), but if that's not your cup of tea I've heard good things about OneFuzz (https://github.com/microsoft/onefuzz) and LuckyCat (https://github.com/fkie-cad/LuckyCAT).

Happy to answer any specifics of the sort :)

Microsoft’s OneFuzz is tackling some of these issues

https://github.com/microsoft/onefuzz

The biggest problem with fuzzing when it comes to “developer friendliness” isn’t just how to setup the fuzzer and the fact that you need to often write quite a bit of additional code to support fuzzing but that the results aren’t easily consumable.

Getting a fuzzer to cause a crash or some unhandled exception isn’t particularly difficult understanding the actual implication of such crash is where these tools “fail”.

SAST / DAST tools with all their issues such as false positives and relatively limited coverage at least provide actionable results.

Fuzzing not only requires a much higher understanding of the code itself and of its execution but the results are often useless for many developers.

Basically it doesn’t help you breach the gap between seeing a BSOD or a kernel panic and getting a working zero day.

To get a taste of our work, a few of the projects our group published recently: * Freta, a project to democratize full system memory forensics with trusted sensorsfor the cloud. * OneFuzz, a self hosted fuzzing as a service platform, used to scale fuzzing for multiple teams within Microsoft including Windows. * RESTler, the first stateful REST api fuzzer * RAFT, a self-hosted API testing orchestration engine, enabling developers to use RESTler and other api scanning & fuzzing tools in their CICD pipelines.