CTFs or Bug Bounties?

Written in


In the recent times, I’ve been very active in both categories, playing with Social Engineering Experts team, as well as doing Bug Bounties on HackerOne.

In both areas, I’ve found moderate success. In CTF’s, we’re the top team in Singapore, and top 10 globally through united effort. Although I must say it’s mostly carried by very strong web and crypto players, but I’ve had my contributions!

In Bug Bounties, I started off pretty slow, only choosing to do VDPs (Vulnerability Disclosure Programs) instead of BBPs (Bug Bounties Programs). The former does not pay any money for vulnerabilities discovered while the latter does. I took this approach because I felt that lesser people would be working on VDPs, and it would give me good exposure and confidence and I rack up findings, and boy was I really proud and happy when I found my first bug! Subsequently I pivoted into doing BBPs, which were a lot harder given the amount of people doing it, and the “quality” of the programs, but then again I’ve managed to find bugs there as well which really boosted my confidence, albeit much lesser than VDPs.

So which is more realistic? Obviously Bug Bounties, as they are literally real world applications and bugs that affect very real users. But which is more fun? I’ll have to give it to CTFs, and here’s why.

When it comes to CTFs, there’s been a very slow power creep as more and more vulnerabilities become well known to everyone, and the only way to make a good challenging CTF is to find obscure vulnerabilities in obscure packages. Create a challenge that’s a Blind SQL and no one is really going to find it fun. Most interesting challenges I’ve seen are the ones who scour through GitHub repositories, finding Security issues or peculiar behaviors, and implementing them in the challenge. One example is a specific header made for Gin which allowed users to redirect their request unintentionally (https://github.com/gin-gonic/gin/issues/2916). Or crazy things with iframes and parent child relationships, or CSRF/CSP hacking, or XS-Leaks and many more.

In Bug Bounties, you rarely get to see these things. The main difference being Black Box and White Box analysis. CTFs are mostly White Box problems where you’re given the source code, and you have to figure out where the vulnerability is based on the code, or packages installed. In fact, if you made a Black Box CTF challenge, people are just going to complain that it’s guessy, but ironically, that’s how Bug Bounties are!

Most Bug Bounties are not really creative problems, but rather simple misconfiguration of security, ACLs or input sanitization. Reading the “Hacktivity” (https://hackerone.com/hacktivity) page on the HackerOne site which contains disclosed findings of Bugs, you’d think “Well that was really stupid of the developers” more often than thinking “What a creative way to exploit the system!” (Disclaimer, some bugs are really cool).

My “specialty” in Bug Bounties are in abusing ACLs, Cross-Account Tampering, and Subverting Business Logic. What “specialty” means is that I’m proficient in targeting these types of weaknesses, and chose to focus on finding these sort of bugs. I would not try to find SQL injections past that bare minimum of putting a single quote as most modern systems, frameworks and the dreaded CloudFlare proxy would guard against this. And given that it’s a Black Box, I would have no idea how to manipulate the control flow of the middleware or backend system. That leaves me with poking at developer logic, one of the few things that are filled with assumptions that can be exploited.

But that also means really boring. For every request, you send try other HTTP verbs like PUT PATCH POST. For every JSON, you add fields and values to see if it gets updated. For every parameter, you add and remove values to manipulate the output. It becomes almost clockwork, which is a good system, but a really boring one.

The best and most creative bug I found was an SSRF, but the rest of it was HTTP verb tampering or JSON tampering to bypass system logic.

That being said it’s still fun and thrilling when you finally manage to find something and report it to the developers, because it’s not meant to be that way. CTFs problems on the other hand are meant to be vulnerable, and not finding the solution can be frustrating and at times demoralizing.

Though I must say that being good at CTFs does not make you a better security person as being good at Bug Bounties, because the problems you solve in CTFs are at times very contrived with no real world impact, whereas Bugs found in Bug Bounties, though boring, are representative of a large majority of systems everywhere. A cliche saying: “The Mundanity of Excellence”.

Therefore, to sum up this long ramble, I’ve decided to dial back on CTFs, and to be more active in Bug Bounties. Perhaps a 80/20 split. Bug Bounties actually make me feel like I’ve helped someone and made a security impact to a company (the reputation points for bragging rights don’t hurt either), while CTFs feels more like an unrealistic game, with very unrealistic solutions, with no impact on anyone. I’ll still stick around with my CTF team and play some challenges here and there, but the most of my time would be focused on Bug Bounties!


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: