
High frequency security bug hunting: 120 days, 120 bugs - ctz
https://shubs.io/high-frequency-security-bug-hunting-120-days-120-bugs/
======
modeless
$40k in bug bounties in 120 days seems pretty good! I always wondered if
someone could make a living off of bug bounties.

~~~
infosecau
Hi, OP here,

The total amount was just under $80,000 in 120 days. The table reflects
payouts for bugs I was able to disclose, there are a fair few bugs worth >7k
that I wasn't able to include in that table. Some platforms/programs
explicitly asked not to be listed there.

~~~
a1a
I just wrote a comment in another thread about bug bounties being cheap.
Assuming you work 8 hours a day, your hourly salary would be $83,3. Wow!

Do you think your frequency is somewhat maintainable? I myself dream about
working full time with bug hunting but have only gotten to a point where I
report a few bugs on a hobby basis. To me it feels weird skipping my
consultant salary for small payments and sometimes even a "good job dude,
here's a t-shirt".

~~~
infosecau
I wasn't able to maintain the frequency after 120 days. I had started the
project and was hoping to do 365 bugs in 365 days, however I stopped at 120
days after I had realized that continuing at such a rate would lead to
significant mental health issues.

In addition to that, I work full time and participating in bug bounties was/is
purely a part time endeavor of mine. Perhaps if I worked full time on bounties
I could keep up. Not entirely sure how it would work out, but it would be a
risky journey at first nonetheless.

~~~
jevinskie
Would you be willing to further explain your mental health concerns? Was it a
worry of burnout, undesirable hyper-focus on bug finding, or something else?

------
jacquesm
He, that's the most literal implementation of 'move fast and break stuff' that
I've seen to date. Kudos to the OP for having the stamina to both work a full
work week _and_ do this on the side for almost 4 months, for most people
either one would be enough to reach reasonable limits.

On another note, and still on-topic, the fact that you actually could do this
full time is a nice testimony to the quality of the software that we put out
collectively, it really should not be this easy. It _also_ gives you an idea
of how many applications out there are simply waiting to be hacked, or
alternatively, how many of them have already been hacked. Chances are that
not-so-nice people have been doing the exact same thing as the author.

------
dsacco
Great work, though I wish this blog were published after the redactions were
updated so the findings could be really public.

In particular, I really like this:

 _" When you submit bugs, remember that you aren't actually entitled to
anything. Unfortunately, that's how bug bounties work. It's a sellers market.
If a program doesn't pay as much as you'd expect for a bug, just don't
participate in that program again. What's the point of causing drama over a
bug or two? Who is the magic internet man who's going to buy your exploit for
$1,000,000 using magic internet money (bitcoin) that those Hacker News users
keep on referencing? If anyone knows who this person is, do tell me! There's
no such thing as a "union" for bug bounty hunters nor an easily accessible
secondary blackmarket that pays for your bugs in a company."_

Fascinating. It's almost as though a successful security researcher and bug
bounty participant is saying the same things Tom and I keep saying here,
despite a constant hoard of people outside the industry who believe web
application bugs are worth anything on the black market.

For anyone who would like to replicate this success, know the following:

1\. _The Web Application Hacker 's Handbook_ is your friend. It's outdated but
it's still the best foundation. Follow it up with _The Browser Hacker 's
Handbook_ or _The Mobile Application Hacker 's Handbook._

2\. You can optimize for exotic vulnerabilities in Google, Facebook et al
which pay the highest bounties or you can optimize for low hanging fruit in
companies which are just opening up a bounty program. The longer a company has
a bounty program, the less of a chance you'll successfully XSS them in a day
of assessing their web applications. Optimizing for finding security
vulnerabilities serially in the highest paying bounty programs requires a much
greater level of skill, vulnerability intuition ("what did the developers not
think about or consider here?") and patience.

3\. To do this seriously, learn to recognize vulnerabilities as contextual
faults in the the way a particular software's implementation matches the
developer's design expectations. Try not to think of vulnerabilities as
classifications, like XSS, CSRF, IDOR, etc. For a first pass to find low
hanging fruit it's helpful to proceed this way, but for more advanced work you
want to look holistically.

4\. If you want to specialize in application security at the binary level
(sandbox escapes, memory corruption - vulnerabilities in operating systems and
major OS applications), you'll want to learn reverse engineering. Start with
_Hacking: The Art of Exploitation_ and then proceed to _Reversing: Secrets of
Reverse Engineering_ or _Practical Reverse Engineering._ You'll also want to
read _The Art of Software Security Assessment_ and _Security Engineering_
alongside those, to develop excellent source code auditing and binary
penetration testing skills. Frankly you should read those no matter what you
do in security.

5\. It's very possible to earn a competitive tech salary just by finding
vulnerabilities and reporting them (or selling them, if that's your bag, but,
_critically_ , you won't be selling website bugs). However, it's difficult and
time consuming. It requires an orthogonal skill set to straight development,
and while it might not be more time consuming it will certainly _appear_ that
way while you're doing it. Like much of security work, bug bounty hunting
consists of long periods of research and analysis, during which you might feel
like you haven't made any progress. This is interposed with brief moments of
inspiration and a final moment of euphoria when you finally break something
after poking at it for days or weeks or months.

You can earn a lot by finding lots of bug bounties, or you can do it by
finding a few serious flaws in widely used "foundational" software in a year
(think browsers, Flash, Rails, Windows, etc.). The latter method requires less
context-switching, so if you can swing for that it's the way I'd recommend.
All you need is three or four bugs in an OS or browser to match a Bay Area
median salary.

As always, I'm very happy to help anyone who would like to get into security
professionally.

~~~
147
Dylan,

I'm a software engineer. Let's say I wanted to transition into security with
the eventual goal of consulting for web / mobile application security.

1\. Would going through the books you've recommended here and practicing a
good path to get me to there?

2\. Could you elaborate more on your second to last paragraph? Say I found a
Rails vulnerability. How would I monetize that? I interpreted your statement
as saying do lots of bug bounties or fewer not bug bounties.

~~~
dsacco
Hey Christopher,

1\. Yes, working through those books would get you to a position at any of the
best consulting firms for security. As Thomas will tell you, they used to ship
some of the books I mentioned to candidates to prepare them for interviews at
Matasano :). Those books will teach you everything you can learn from books
alone; the rest is just up to practice.

2\. If you find a Rails vulnerability, the most straightforward path to
monetizing it is reporting it directly to the Rails core dev team and
registering for a CVE number recognizing you as the researcher. Once the
vulnerability is patched, report the fact that you found it and it was patched
to Hackerone's Internet Bug Bounty (IBB) program. The IBB program rewards
researchers for reporting serious flaws in major software used around the
internet.

Your interpretation is correct. I use "bug bounties" colloquially to mean web
application vulnerabilities, but technically Hackerone's IBB is a bug bounty.

The point is that web application vulnerabilities are worth less as a general
rule than vulnerabilities that impact a plurality of websites, due to things
like vulnerability half life.

Hope that helps!

------
startupdiscuss
Could you automate this?

Could you have some scripts running that automatically try various attacks on
sites, present the results, or does each attack have to be hand crafted?

~~~
dsacco
You could certainly _try_ , but no off the shelf software, commercial or open
source, could fully replicate what the author did. It's sort of the golden
dream of the security world to fully automate this work to intelligent
scanners like Acunetix or Fortify.

When doing this work I personally find it helpful to frame vulnerabilities as
areas in development where an engineer's mental model and design expectations
were inadequate (or simply flawed). This is in contrast to the way most
automated security scanning software implicitly understands vulnerabilities as
lists of things that are known to go wrong.

Both are helpful perspectives, but the reason why humans are much better at
the actual work is because the former encompasses the latter without missing
the more abstract issues.

This is all a long-winded way of saying that in order to do this, you'd
probably need to design an excellent machine learning system, preferably with
supervised learning, and train it to classify vulnerabilities in source code
and applications by running through the same things successful security
engineers do. Depending on your definition of automated this would probably
start to border on AGI in order to be really effective at fully removing all
the schlep work.

If I had to guess, I'd say the first company that will develop anything
realistically close to this will be Hackerone or Bugcrowd. They are the
companies with the most data, and they have already started working on machine
learning systems that can classify bug bounty reports as likely signal or
likely noise in production. I could even see a very long term Uber-esque plan
where they attempt to replace their bug bounty participants with systems
developed on their training data.

------
ch
I think the best advice in that article is this:

 _At all times, when someone found something in an area or program I didn 't
find, I took it as inspiration. Viewing colleagues and friends in bug bounties
as competition is purely counter-intuitive as it doesn't really help any
parties and leads to even more severe burn out._

------
cloudjacker
tl;dr he did bug bounty work on the side and made $80,000 in six months.

