Bug Bounty Program Primer – Finding Vulnerabilities for Fun and Profit

After some requests and questions asked, I decided to answer the emails in the form of a post about bug bounty programs.

For those that do not know me personally, let me get the ‘street cred’ out of the way.  I have been bug hunting (bounty hunting) for a couple years now, and came in 10th during the “Hack the Pentagon” bug bounty program.  I have amassed a large number of unknown bugs (0days).  Some have been disclosed, others have not.  I have discovered many different types of web application vulnerabilities in the wild (SQLi, LFD, XXE, XSS, Arbitrary File Upload, Command Injection, etc.).  And on and on and on.  Hopefully that’s enough for me to dispense with some lessons learned and help some of you get a start in securing the Internet 🙂  I’ve structured this like an FAQ of questions I had and have been getting asked, so let’s get this started….

 

What is a bug bounty program?

In essence, this is a way for companies to open the doors to security researchers (white or black hat) to find security problems without fear of legal repercussions.  Note that this doesn’t mean you won’t go to jail.  Generally there is a scope to the bug bounty program, and if you go outside that scope, you cross the legal protection and could easily get in trouble with the law.  For example, if the scope says you can attack ‘www.foo.com’ and you find a flaw in ‘bar.foo.com’…you are attacking something they did not say you could.  Expect legal fees, and potentially a really large ‘friend’ when you get locked up.

Bug bounty programs are appealing because they don’t just offer a way to ethically disclose security flaws, but they often also offer incentive.  These incentives range from a ‘Hall of Fame’ listing those who have discovered legitimate problems, to swag (T-shirts, stickers, etc.), to a hand shake with the Almighty (yes I’m deifying cash).

 

Will I get arrested for participating in bug bounty programs?

Short answer, maybe.  That depends on your ability to read and follow directions.  If you stay in scope, you are covered.  If you don’t…..

 

Where can I find a list of bug bounty programs?

There are more lists than these, but here are the ones that I have bookmarked.  Though to be honest, at this point I just refresh hackerone and bugcrowd.

  • https://hackerone.com/directory
  • https://bugcrowd.com/programs
  • http://www.vulnerability-lab.com/list-of-bug-bounty-programs.php
  • http://www.w4rri0r.com/bug-bounty-programs/where-are-you-bug-hunters.html

 

How competitive are bug bounty programs?

This depends.  If you get in at the ground level, it’s more of a race than anything.  Hack the Pentagon I had the majority of my findings closed as duplicates.  I simply got beat to the punch.  But I had several findings that were accepted too.  Generally speaking, the longer the program has been running, the harder it will be to find stuff.  Logically that makes sense as there are hundreds of eyes looking for low hanging fruit, and the ripest fruit (big bounties).  Look at hackerone and bugcrowd, pick some programs and check how many bugs have been found, fixed, and how many hackers have been thanked.  The larger the number, generally the harder it will be to find something profitable.  Not impossible, but harder.

Take Google and Facebook as a prime example.  They were inundated with findings when their programs opened.  Now, it’s a headline when someone finds something of merit.  It took them over a year before there was a noticeable slowing in headlines about bugs.  And now it’s almost a pride thing to get a bounty in either program.  There are still bugs to be found….but they are not anywhere near as prevalent, or easy to find.

So the short answer is, if you get in quick, it’s pretty easy to find stuff.  The longer you wait, the more bugs will be consumed by pros.  Plan accordingly.

 

What is the general process for finding a bug or vulnerability?

This is in no way an easy question to answer.  I have derived my own strategy with the base I learned from a web application security course I took.  I have since modified (mutated) it to fit my own personal style.  Unfortunately the depth of the question does not lend itself well to this post, and I will have to revisit this in length, at another time in another post.  For now I’ll give a brief overview of the strategy I use.

  • OSINT – identify all information I can about the target to flesh out the scope as much as possible (ie. subdomains, user accounts, etc.)
  • Examine each URL, in the scope, and categorize functionality (file uploads, probable DB queries, user input that is reflected, etc.)
  • Categorize possible attack locations
  • Use a generic test at each attack location
  • If there is a possible attack vector, dig deep, otherwise move on

 

How long should I spend on a particular bug bounty program?

Here’s another ‘it depends’ answer.  I find that some programs are VERY ripe.  And warrant more time.  Others, are like rubbing my face on asphalt to get dolled up for prom.  This is where experience really comes into play.  Generally I spend a day or two getting a feel for the target.

Let’s look at some real world examples.  I spent a week looking at the united airlines bug bounty program.  This was a headline making program and I saw it as a challenge to hit the boards.  My goal (was still relatively new to bounty hunting) was just a single bug.  I found that first bug on day one.  This lent to the logical conclusion that the scope would be pretty ripe.  Unfortunately by the end of the week I was only getting duplicates and decided it wasn’t worth the time spent.  I was glad to be on the boards and called it a day.  They are still making pay outs, so I think I missed out.  Big lesson learned.

sighOn the flipside, pornhub recently launched their program with hackerone.  As it turns out, they had already been running a private program (BOOOOOO….I’d tell them to go F themselves for that, but…uh….I’m pretty sure that’s what that site is all about), which clipped most of the low hanging fruit.  After a day, I realized they had gotten all the easy stuff and I was looking for obscure stuff.  This was an easy one to walk away from.  Recently there was a headline how pornhub paid out a bounty…..for a couple guys who used zero days in php to attack them.  Read that again, they attacked the language, not the site.  The bug(s) used would have gone for MUCH more than what pornhub paid out, but that neither here nor there.  The point is, a zero day was required to get a decent pay day.  I walked away perfectly.  Lesson learned.

 

How long does it take to find a bug or vulnerability?

And again, it depends.  I’ve had bugs pop up within minutes.  I’ve gone weeks on a program and found nothing.  It really depends.  Part luck, part skill, part experience.  And when I’m working on a COTS product, I’ve had a few apps that panned out to nothing (only a few).  Some apps I spend a couple days on, some months.  In the case of the latter, I recently concluded a 6 week gruelling campaign against a major vendor, on one of their products.  Found RCE, over a dozen SQLi….and no one gives a shit.  Totally wasted time.

On the other hand, in another product I discovered a stacked SQLi in the very first parameter I tested.  That landed me several grand.  It’s almost like playing the lottery.  If you want in this game, you really have to want to be in this game.  There are many pits of nothing.  Be ready for them.

 

What if I find a bug in a product that does not have a bug bounty program?

First off, if you are hacking sites without permission, stop.  Stop now.  You will go to jail.  Any bounty/bug I have found has either been within an authorized bug bounty program, or with a COTS (commercial off the shelf) product within the confines of my own personal lab.  If you attack something, you better be damn sure you have the permission to attack it.

That being said, there are 3rd party organizations that will buy bugs in products with no bug bounty program.  They are legal.  Here is a quick list of the top 3 and how they legally disclose/use your vulnerabilities/exploits:

Zero Day Initiative – a direct quote: “TippingPoint provides a “virtual patch” functionality that protects vulnerable systems from compromise when host-by-host patches have not been applied or do not yet exist from the vendor. Our security research team develops new Digital Vaccine® protection filters that address the latest vulnerabilities and are constantly distributed to our customers. By writing vulnerability filters for security issues that come in through the Zero Day Initiative, TippingPoint maintains a competitive edge while protecting customers and encouraging security researchers to bring findings into the public domain.”

Beyond Security – Sells the vulnerability/exploit to pen test companies for use in their engagements, while simultaneously working with a vendor to correct the vulnerability.

Zerodium – Sends vulnerability information to a feed that their clients subscribe to, allowing for protection before a fix is implemented.

 

What tools should I use for finding bugs or vulnerabilities?

Here is another big post in the making.  I’ll be as brief as I can here, while plotting on another post to go in depth.

Burp Suite is the go to here.  Period.  I have a pro license (though the scanner is largely unused).  If you are serious about bug hunting, get the free version and decide if the pro version makes sense later.  In 90% of the cases, the free version will be plenty.

I do occasionally use SQLMap.  Though only when I can’t figure out the PoC (Proof of Concept) on my own.  It’s great for automating possible injection strings, but noisy as all hell (definitely recommend not using during red team engagements).

DirBuster is sometimes used for finding folders, pages, and docs that are not intended to be referenced, though that is rarely something I check during bug hunting.

Finding subdomains is a necessity (typically with *.foo.com scopes).  For this I generally use sites like https://pentest-tools.com/information-gathering/find-subdomains-of-domain