The requirements of the program.
Generally, when you do work for a bug bounty program you’re expected to provide a few things. The first is a write up of the bug you’ve discovered. It should cover what the bug is, where it’s located, relevant source code, etc. Second is a reproducer file, or proof-of-concept (PoC). Lastly, some programs want to know the remedy for the bug. Doing all these things can take a significant amount of time.
The issue from a bug hunters perspective
For me, finding the bugs is quite trivial and not terribly time consuming. The real time consuming part is trying to figure out how to trigger the bug. To do that I usually approach the problem by back tracking the code and laying out the function chain, determining which “state” variables need to be set up what way etc. From there you need to figure out how to get those state variables massaged into the way you need them so you can drive the program flow to your vulnerable function.
Once you understand how the general state of the program should look like you need to actually get the state to look like that. From there you need to find some sort of tooling to interface with the vulnerable code. Since I’ve been auditing and reporting bluetooth bugs recently we’ll use that as an example. The tooling I had to go find was the bluetooth spec, some bluetooth dongles, and some example bluetooth code. Luckily for bluetooth the BlueZ project has excellent code that I’ve referenced in order to build PoCs. Sometimes, however, the bugs are so far out-of-spec that the libraries aren’t useful. The libraries are made to build in-spec packets/or call functions the way they’re supposed to be called so many times you end up having to re-implement entire libraries to trigger bugs.
The last time consuming part, at least for a independent researcher like myself, is I have no one to turn to when I can’t figure something out. I can ask for help on twitter, but that only works for general questions. I can’t go too deep into details for fear of exposing a bug. If I have a bug and I cant get one of the states to match so I can enter the function with x,y,z who do I ask? I’ve in the past emailed developers on projects asking for some general advice but I have a 90% failure rate with return of emails. This generally leads me to adding tons of log messages to the code and trying different things until I get it to work.
The thing that keeps you going through this mess when you’re on one of those “I know this is a bug but why the fuck wont this work?” is the fact you’re going to get a $2-10k pay day in the next two months for this work. So you keep grinding at it for another week or 4, until everything works as intended.
You do your write-up submit your poc and wait.
Then you get the dreaded:
Or you look at the fixes for the newest security bulletin and see half of your bugs fixed.
Someone beat me to this one:https://t.co/9igEs2h4hH— Scott Bauer (@ScottyBauer1) March 5, 2018
I'll upload a PoC After work.
The issue of duplicates has changed the way I submit bugs to programs. I don’t submit PoCs until a couple weeks after the initial report. The reason or this is two fold. The first is because bug hunting is too much of a race. Once I am fairly certain I have a bug If I want to get paid I have to beat everyone else. That means I have to submit first. The only designation is that your report is first, the rules don’t say “the first report with a PoC” it’s just the first report they receive, period. So that being said I just send the report THEN work on the PoC now adays. The second reason is while I am working on the poc I may hear back that it’s a duplicate and I can stop wasting my time.
The issue from the Security teams perspective
Bug hunters aren’t the only ones who end up having to waste time due to duplicates. The security teams have to review each report, talk with the engineering team dedicated to that portion of code, reproduce the issue, communicate with researcher, etc. Doing all this takes time too.
If they have to wait weeks just to get a PoC only to find out the PoC already triggered a previously reported bug, that’s a bunch of time wasted on their end too. Or, if the security team is the team required to do an initial debug, they’ve wasted time working on their own PoC, or getting their system in the correct state to trigger the bug too.
The general thing I am trying to point out here is duplicates are wasting time on both sides of the program.
Ideas for a remedy?
I don’t know if any of these are feasible, I’ll outline the pros and cons, but would love to hear others opinions.
Communicating with other researchers.
Derrek and I work together, we have a shared repository where we both submit our bugs to before reporting. We chat about what each of us are working on and generally try to stay away from each others subsystems. The pros of this method are we know about each others bugs, so we wont double report them. This benefits the Security teams the most. The Cons mostly fall to the researchers. If we the security community were to have a shared repo of our bugs it opens up the possibility to bug scooping. If I see someone push a bug for a subsystem I am going to go look at that subsystem too. So that means people wont push their bugs until they’ve audited it all, which means you STILL don’t know what one another is working on and you could duplicate that way. The second issue which will come up a few times is who do you invite to this repo? Obviously you don’t want randos in on this repo, and you’d have to clear it with the security teams for your programs. All the programs have a “If you disclose this before we do you won’t get paid” type clause. Does pushing it to a private repo with other researchers count as disclosure?
Having some select researchers have access to the private bug reporting software.
For Google that would mean people they deem “trustworthy” would have access to the security buganizer, and for Qcom we would be able to see the reports on H1. The cons of this method mostly fall onto the security teams. Who do you deem trustworthy? Do you have to abide by export laws if you’re a US company? Can you only give US researchers access? How do you prevent abuse (giving bugs to govts/shady people)? The cons for the researchers are like above, you could have bug scooping, If I see you report something I’ll look at that subsystem too.
Paying out for duplicates. Perhaps the best method would be that companies pay out for duplicates. They’re essentially getting extremely cheap QA on their code bases. So they could just pay out if you duplicate. The obvious problem with that is people will clearly abuse this system, so it would have to be on a trustworthy basis again. If you’ve submitted REAL bugs in the past that weren’t dups you could get paid for your dups.
Grants. Google does have a grant for researchers, this is good for people who do this full time and don’t have another job. It can help keep income steady. For me this doesn’t really matter, I don’t get all my wasted time back, that’s what I want to eliminate is me wasting engineering time.
I think something needs to be done, but I am unsure if there is actually a good solution. Perhaps the right solution is to just work for a security team instead of doing it independently. As always If you have a good idea or a comment hit me up on twitter or shoot me an email.