High frequency security bug hunting: 120 days, 120 bugs
shubs.io
shubs.io
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.
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".
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.
Don't forget that 120days for normal people is
actually 120 business days, or 40 weeks...
120 business days / 5 days per week == 24 weeks
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.
I'm ready to adopt my final form.
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.
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.
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.
Hope that helps!
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?
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.
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.