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.
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".
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.
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?
Oh, even in the summary table? Wow, that's even more impressive! And as a side project while working full time too. Have you estimated your earnings if you made this your full time job (ignoring burnout for the moment)?
No it's not, it's terrible. These are not stupid software bugs like the wrong icon or colors, these are usually security bugs that can be the beginning of a nightmare for a company. A security consultant will make more than that working for 120days. Don't forget that 120days for normal people is actually 120 business days, or 24 weeks, A bit over 6 months. So would you still $40k for 6months of high specialized work as not being terrible?
Don't forget that 120days for normal people is
actually 120 business days, or 40 weeks...
I believe your math is a bit off there.
120 business days / 5 days per week == 24 weeks
So a bit under six months as some months have 5 weeks in them. This would project out to over $80k per annum, but as indicated in the article, attempting to keep this pace up for an entire year would be grueling.
For very good, proven talent, in tight local markets, negotiating for the best job based primarily on compensation and not, for instance, how interesting the targets are, $150k/yr as salary+cash bonus is a reasonable expectation.
Plenty of very good security researchers make less, for any of the reasons I just implied and many others. $80k-$90k is roughly the threshold where I'd say that if you're talented and have a track record, you're needlessly underpaid.
On the other hand: $150k as consulting returns sounds a little on the low side. At 80% utilization (hard, but possible, to maintain) and a reasonable bill rate, you might expect to gross somewhere north of $250k.
For specialist talent, this all goes out the window, of course.
Curious -- can you do that without having to socialize with anyone? I'm not a social reject. Just looking for a period of full and unconstrained immersion.
There are non-monetary rewards. To work as a security consultant, you have to be ... a consultant.
Being able to sit at home (or wherever), have no boss, no schedule commitments, and no constraints on my dress, no need to be social / politic sounds pretty sweet to me.
If this were full-time freelance work (in Sydney, Australia no less), $40k in 120 days is hardly sufficient for the skills involved. That is to say, bug bounties should probably be higher...
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.
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.
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.
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.
You'll probably never get there. Either you're born a phreaker, cracker, pentester, or you're a kid who does other things during HS and college. The kind of people that do sec have been doing it since they were 10. You'll have a hard time competing. (And yes, I am the former.)
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.
In my experience automated tools are generally fairly rubbish for this kind of work... which is not to say it's impossible, just that you'd want some real smarts in said tool
Unfortunately, I will say no. Most blackbox and greybox testing are very manual. The reason is because we know what we are testing. Context matter. Computers don't understand /signup and /register are common page for user account registration. Automation tools thus far are very primitive. Let's imagine a user registration process. It seems simple, but really not scalable.
What can you write? Some examples:
* check HTTP security headers
* check page and requests are made over HTTPS
* try to verify CSRF token is working
* try to fuzz input fields (for all kinds of injection attacks)
First two automation are pretty simple to implement. CSRF validation automation is quite common and also not terribly hard to implement (if you use commonly used web framework the implementation should be fairly standard). But testing injection? There's reflected and there's stored. Stored can be quite tough. Supposed you finish your registration successfully, you either see stored XSS immediately from within your profile page, or you will see the stored XSS somewhere on the web site. In the latter case, you are waiting. Where do you go? You can pick a few hot spots (forum page, profile page, email, etc), but website A is different from website B, how can you write a tool that's scalable? Effectively, you are now writing a tool specifically for one website.
Now move on something more interesting. A lot of the vulnerabilities depend on state. By state I mean not only session, but the path of how the user gets to that page. Going back to stored XSS, yes, the input is in the database, but the user may only see this XSS if and only if he was on this page performing this action.
IMO, recording and learning how a real human would use the website is one of the ways to automate and to attack a website because your goal is to generate large set of test cases. If you are lucky you can hit a jackpot and reproduce a real vulnerability that someone is actually using against you. Change the input, replay the whole scenario, and repeat the cycle. Want to be smarter, not dumb fuzzer? Add some rules. Another way to replay is by leveraging your tests. For example, let say my API can create objects, well, first I need to register myself, then I need to authenticate myself, and I need to fill in a form with my authorization token or whatever. My tests would be making multiple API calls. What if now I do a permutation? Add/remove/modify one step at a time? Swap the steps around? Privilege escalation, maybe? Anything? Using your functional tests you can now generate new test cases and it is very possible you will find real vulnerability that way.
There are other complications. Take gmail.com. The source is obfuscated and minified. Try to make sense of the source is a challenge. DOM can change, so now you have to update your script. The incredible Gmail.js made this easier, but still require author to maintain the ever-changing DOM.
Really, the many little steps you take to perform penetration test can be automated. But there are too many steps and the number of states could overwhelm. Writing generic tool is very much a hard problem. In a way, I guess you can, creating an effective, kind of smart penetration automation software is like creating a model for determining which Spotify's Discovery recommendation algorithm is better. Very data driven and evolutionary-based.
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.
