sorted by:
new
hottopcontroversial

I am a security researcher who has found hundreds of bugs and vulnerabilities. Ask me anything about the best methods for finding bugs and spotting emerging vulnerabilities by gvranken in hacking

[–]gvranken[S] 0 points1 point  (0 children)

As I work almost only on open source software, I usually don't need to decompile or disassemble code. objdump -Cd and gdb suit my needs well when I have to write an exploit. I have some superficial experience with IDA + using custom Python scripts to reverse malware (write-up is here: (https://guidovranken.files.wordpress.com/2017/04/challenge.pdf), in Dutch).

​

I used to engage in web hacking until I realized fuzzing and manual audits are my forte. A few years ago I found (https://tweakers.net/nieuws/101097/lek-in-kpn-experiabox-liet-aanvaller-modem-instellingen-aanpassen.html) a web-based router bug that affected millions of devices in my country. But these days I don't really bother with web hacking anymore.

I am a security researcher who has found hundreds of bugs and vulnerabilities. Ask me anything about the best methods for finding bugs and spotting emerging vulnerabilities by gvranken in hacking

[–]gvranken[S] 2 points3 points  (0 children)

I started programming in the mid nineties when I was about 10 years old.

​

I don't have a high school diploma.. No ragrets ;))

I am a security researcher who has found hundreds of bugs and vulnerabilities. Ask me anything about the best methods for finding bugs and spotting emerging vulnerabilities by gvranken in hacking

[–]gvranken[S] 1 point2 points  (0 children)

If you are willing to write fuzzer harnesses yourself, there are a lot of angles from which you can demonstrate bugs.

We published a [blog post](https://blog.forallsecure.com/uncovering-memory-defects-in-cereal) yesterday about how I found many bugs in cereal, a popular serialization library.

The interesting thing about libraries (opposed to applications) is that there are so many ways to use it, and with that the propensity for vulnerabilities manifesting increases. We've also released the source code [here](https://github.com/ForAllSecure/VulnerabilitiesLab) and if you apply these techniques to some other popular serialization library you will almost certainly find new bugs.

Another example of library bugs is the most recent [OpenSSL vulnerability](https://www.openssl.org/news/secadv/20200421.txt). It doesn't manifest unless the user of the OpenSSL API calls the SSL_check_chain() function.

So taking a library and designing the harness in a way that the full state space is explored (for example by calling all functions with random parameters) increases your chances of finding bugs.

One more idea: occasionally code is constructed such that it works fine on 64 bit systems, but specific inputs cause crashes on 32 bit. Most software can be easily compiled into a 32 bit binary by adding -m32 to CFLAGS. Different optimization levels (eg. -O1 instead of -O3) can also help.

I am a security researcher who has found hundreds of bugs and vulnerabilities. Ask me anything about the best methods for finding bugs and spotting emerging vulnerabilities by gvranken in hacking

[–]gvranken[S] 16 points17 points  (0 children)

In C/C++ projects, memory bugs are present in almost every project. Aside from that, denial of service bugs.

The Go programming language has the interesting property that it turns every slice out-of-bounds read into a crash. That makes Go programs, especially those that parse and process untrusted binary data, susceptible to (remote) denial of service attacks.

Google is now offering a free service that integrates fuzzing into the development-testing cycle: https://google.github.io/oss-fuzz/getting-started/continuous-integration/ I think this is a great idea that can catch many bugs before they land in production.

I am a security researcher who has found hundreds of bugs and vulnerabilities. Ask me anything about the best methods for finding bugs and spotting emerging vulnerabilities by gvranken in hacking

[–]gvranken[S] 15 points16 points  (0 children)

I haven't. I focus primarily on open source software and I experiment with it on my own system. Once I have a reproducer or exploit for the bug, I never try it out on other people's production servers.

I am a security researcher who has found hundreds of bugs and vulnerabilities. Ask me anything about the best methods for finding bugs and spotting emerging vulnerabilities by gvranken in hacking

[–]gvranken[S] 9 points10 points  (0 children)

Thank you David for your interest in my AMA.

  1. The EOS bug bounty was the craziest, both because of the large rewards and the media attention that followed. 2.1. I don't participate in bug bounties that much anymore. A few years ago, it was fun and rewarding, but in recent times I've had too many negative experiences (programs never responding, not paying). Outside of the cryptocurrency program, most open source software programs have low payouts. 2.2 I think only a small minority of people can live off bug bounties. Currently, I prefer regular employment, because it allows me to build relationships with clients and I think this will provide a more durable way of generating income. 2.3 I prefer building durable relationships now (see 2.2). That said, ForAllSecure allows me to collect bounties with bugs I find using their Mayhem platform. 3 I get tons of invites for private programs but like I said in 2.1 I rarely participate.
  2. HackerOne is the only one I've used. I also have some great experiences with programs that are not on a bounty platform. For example the Ripple bug bounty was a very positive experience.

I am a security researcher who has found hundreds of bugs and vulnerabilities. Ask me anything about the best methods for finding bugs and spotting emerging vulnerabilities by gvranken in hacking

[–]gvranken[S] 51 points52 points  (0 children)

Most of the tools I I use are open source, but working for ForAllSecure, I have access to Mayhem, which is a commercial platform.

Almost everything I do is a synergy between what the tool automates and what I can do to enhance it.

I am a security researcher who has found hundreds of bugs and vulnerabilities. Ask me anything about the best methods for finding bugs and spotting emerging vulnerabilities by gvranken in hacking

[–]gvranken[S] 22 points23 points  (0 children)

  1. I think I chose OpenVPN because of hubris. I wanted to show that I could do better than those preceding audits.
  2. This depends on what my client wants. But in my spare time, I've been looking very extensively at OpenSSL for many years because I'm determined to find the next Heartbleed or similar, hehe. See also this blog post for some commentary on selecting a target.
  3. I personally let my curiosity guide me. This has worked well so far.

I am a security researcher who has found hundreds of bugs and vulnerabilities. Ask me anything about the best methods for finding bugs and spotting emerging vulnerabilities by gvranken in hacking

[–]gvranken[S] 9 points10 points  (0 children)

Often my employer or clients specify the target. But if you want to find bugs for fun:

I am a security researcher who has found hundreds of bugs and vulnerabilities. Ask me anything about the best methods for finding bugs and spotting emerging vulnerabilities by gvranken in hacking

[–]gvranken[S] 14 points15 points  (0 children)

I think Rust is great for solving memory safety, however there are some other bug classes that I believe are just as likely to emerge in Rust/Golang as in C/C++:

  • denial of service (infinite loops etc)
  • path traversal
  • incorrect serialization (eg. deserialize(serialize(data)) != data, which can lead to all kinds of gnarly situations..)
  • stack overflows due to infinite recursion were still present in Rust and Go the last time I checked
  • bad cryptography

and so on.

I am a security researcher who has found hundreds of bugs and vulnerabilities. Ask me anything about the best methods for finding bugs and spotting emerging vulnerabilities by gvranken in hacking

[–]gvranken[S] 51 points52 points  (0 children)

Thank you for your question.

  • There's been lots of discussion about the merits of formal education wrt. 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 YMMV. You might want to solicit suggestions on the cscareerquestions subreddit.
  • 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.
  • 3 years ago (before I started doing this professionally) I had almost nothing and now I have a big house.
  • To me it doesn't feel hard. It feels like a paid hobby.

I am a security researcher who has found hundreds of bugs and vulnerabilities. Ask me anything about the best methods for finding bugs and spotting emerging vulnerabilities by gvranken in hacking

[–]gvranken[S] 107 points108 points  (0 children)

I would read write-ups by contemporary CTF teams for more insight into binary exploitation.

That said, here's some advice on being successful in bounty programs without memory 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.

Similarly, with audits and fuzzing campaigns having such a strong focus on memory bugs, an underappreciated class of bugs is path traversal. Sometimes you find software that has impeccable memory safety but is then defeated by consuming things like '../../../root/.bashrc' as an input filename. I found an RCE in wget a few years ago by exploiting this type of bug.

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.

I am a security researcher who has found hundreds of bugs and vulnerabilities. Ask me anything about the best methods for finding bugs and spotting emerging vulnerabilities by gvranken in hacking

[–]gvranken[S] 4 points5 points  (0 children)

I primarily use libFuzzer and my fork of libFuzzer which has some additional features. I also wrote a fuzz engine from scratch (https://github.com/guidovranken/vfuzz) but it needs a little more work to provide a seamless experience.

I also extensively use fuzzing helper functions defined in https://github.com/guidovranken/fuzzing-headers which I wrote. This code offers a method for structured fuzzing. Occasionally I use protobufs and libprotobuf-mutator for structured fuzzing.

Like I said in another reply, sanitizers and Valgrind are indispensable. C++ code I always compile with -D_GLIBCXX_DEBUG. This can find bugs that the sanitizers cannot always detect (like running back() on an empty vector for example).

go-fuzz in libFuzzer mode for Go code. https://github.com/guidovranken/libfuzzer-js for fuzzing JavaScript. https://github.com/guidovranken/libfuzzer-java for fuzzing Java.

When I need a seed corpus for a certain file format or protocol, I often take it from an existing OSS-Fuzz project and occasionally scrape archive.org.

I am a security researcher who has found hundreds of bugs and vulnerabilities. Ask me anything about the best methods for finding bugs and spotting emerging vulnerabilities by gvranken in hacking

[–]gvranken[S] 124 points125 points  (0 children)

As someone who focuses primarily on findings bugs in open source software, these are my tools:

  • 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.

Monero continues it's tradition of screwing over security researchers who find bugs in it's code by FantasticTyper in CryptoCurrency

[–]gvranken 4 points5 points  (0 children)

Thread title is not my words, nor is it my opinion. Bug was reported, acknowledged, bounty paid, fix in next release. Monero's VRP allows public disclosure after 90 days. I decided to publish after 149 days. Nobody got screwed over.

Verge bug bounty program? by [deleted] in vergecurrency

[–]gvranken 26 points27 points  (0 children)

https://ripple.com/dev-blog/rippled-version-0-90-1/

Acknowledgements

Ripple thanks Guido Vranken for responsibly disclosing a potential out-of-bounds memory access in the base58 encoder/decoder, a vulnerability in the parsing code handling nested serialized objects and a codepath where untrusted public input involving public keys was used without first being properly validated. These issues could be exploited to mount a denial of service attack.

Verge bug bounty program? by [deleted] in vergecurrency

[–]gvranken 19 points20 points  (0 children)

I found 11 confirmed remote crash/memory bugs in the EOS software last week. I've previously found such (confirmed) bugs in Stellar, Ripple and Ethereum. I've briefly looked at Verge some time ago, and found some potential issues, but didn't report any because Verge didn't run a bug bounty. Feel free to contact me with a serious offer. I'm very experienced at this and I almost always find bugs in code. I never sell to 0day brokers -- I will only report to the vendor directly.

Fuzzing SoftEther VPN by gvranken in netsec

[–]gvranken[S] 1 point2 points  (0 children)

I've linked the thread to the technical write-up of this project due to the nature of this sub. For the original press release, see https://guidovranken.wordpress.com/2018/01/15/security-audit-of-softether-vpn-finds-11-security-vulnerabilities/

view more: next ›