Last month Guido Vranken hosted a successful Reddit AMA, sharing insight on his experience as a professional vulnerability researcher. Top questions from Reddit included what advice he had for someone looking to make money from vulnerability research, his process for hacking, and what advice he had specifically for someone heading off to college.
Vranken describes himself as a self-taught programmer and security researcher. “I’m especially well-known for my ability to find vulnerabilities and identity bugs within software. Some of my notable work includes finding more than 50 bugs in major cryptographic libraries, making $120K in two weeks from Block.one’s bug bounty program and finding vulnerabilities in OpenVPN that two professional audits missed.”
For those starting out, Vranken recommends one way to get up to speed on finding and exploiting modern software for vulnerabilities is to read write-ups by contemporary CTF teams for more insight into binary exploitation.
“Working for ForAllSecure, I recently found a remote code execution bug in OpenWRT that has presumably affected millions of devices. It didn't involve defeating memory protections but it consisted simply of sending a compromised binary, because the OpenWRT package manager didn't check its hash, so an adversary could run any code, as root.” He said his research on OpenWRT was a combination of writing custom harnesses, running binaries of the box without recompilation, and manual inspection of code.
“Similarly, with audits and fuzzing campaigns having such a strong focus on memory bugs, an under appreciated class of bugs is path traversal.” A path traversal vulnerability is when someone successfully manipulates the file path so that it is possible for them to access arbitrary files and directories stored on file system including application source code or configuration and critical system files “Sometimes you find software that has impeccable memory safety but is then defeated by consuming things like '../../../root/.bashrc' as an input filename,” he said. “I found an RCE in wget a few years ago by exploiting this type of bug.”
Vranken used the AMA to share “his experience with deep fuzzing to find hard-to-spot bugs, and special techniques like differential fuzzing -- testing the behavior of two or more implementations to ensure they are functionally equivalent. I've previously worked with Ethereum and used this technique to find bugs that could have disturbed the network, and more recently to find many bugs in cryptographic libraries.”
As for bug bounties, “Cryptocurrency programs will also reward bugs that could cause chain splits. Ethereum has had a few of those bugs, where the two most popular clients would interpret a crafted smart contract differently. Denial-of-service bugs are also eligible as those could weaken the network.”
For tools and processes, Vranken mentioned:
- The sanitizer suite (https://github.com/google/sanitizers) is indispensable.
- Valgrind. It's relatively slow compared to sanitizers, but useful for finding use of uninitialized memory bugs without having to recompile everything with MemorySanitizer (which often is a non-trivial task).
- libFuzzer. This is my main fuzzing tool. I spend a lot of time using and abusing it. I also frequently use my fork of libFuzzer which has a few additional features (https://github.com/guidovranken/libfuzzer-gv).
- grep will never cease to be useful for performing certain aspects of manual code auditing.
- I keep a list of notes with things to pay attention to when auditing. This also includes a list of regular expressions that I use with grep.
- GCC and Clang's -Wall option (and other warning options) are useful and will sometimes point out vulnerabilities directly to you.
- Occasionally I use the Godbolt Compiler Explorer: https://gcc.godbolt.org/
- A simple Python script I once wrote is useful for finding function recursions (that can potentially lead to stack overflows): https://github.com/guidovranken/binloop/blob/master/binloop.py
- vim with ctags for traversing and editing code.
- https://grep.app/ and https://codesearch.debian.net/ are my to go websites for searching code.
- I often launch a Python terminal to perform various calculations.
- gdb for analyzing crashes.
- ForAllSecure's Mayhem which makes it very easy to find bugs in binaries without recompilation.
For advice to college students, or those heading off for the first time, Vranken said there’s been a lot of discussion about the merits of formal education in software engineering and similar professions. “I personally did not complete any education and no employer has ever asked me about it; an active Github/blog presence has worked very well for me, but your mileage may vary." He directed participants to the careerquestions subreddit channel for more discussion about that.
As for a life as a professional hacker, “To me it's very exciting, addicting even. There's nothing like the dopamine rush of your terminal lighting up like a pinball machine indicating your fuzzer has found a new bug. There is also a lot of room for creativity. Three years ago (before I started doing this professionally) I had almost nothing and now I have a big house.”
Vranken concluded, “To me it doesn't feel hard. It feels like a paid hobby.”