Today we held a webinar where @kymberlee gave her presentation from Black Hat 2015, titled: “HI THIS IS URGENT PLZ FIX ASAP: Critical Vulnerabilities and Bug Bounty Programs.”
If you have any questions for Kymberlee please ask them in this thread.
Presentation description:
In this presentation we will discuss several highly critical vulnerabilities that have been uncovered through a variety of bug bounty programs and their impact on the customers. With participation from researchers and vendors, attendees will not only see some sweet vulnerabilities broken down, but also why wading through another submission from @CluelessSec might be worth it.
The emergence of bug bounty programs is increasing the volume of vulnerability submissions, but how many of those can be found by running an automated scanning tool? Are any really critical bugs being found in the sea of clickjacking and weak password policy reports? How do you separate the signal from the noise, and more importantly, how do you shift the balance of bug reports to greater signal/less noise overall? Price will address all of these questions.
I know you were towards the end of the webinar when I asked my question, so I’ll post it here. We talk about researchers with bad behavior a lot, but we rarely ever talk about companies with bad behavior. Isn’t it bad behavior when a bug is flagged won’t fix and then the company fixes it without a reward? Isn’t it bad behavior to remove a file after a researcher spent hours upon hours doing research, so you can save money? Isn’t it bad behavior to flag something as invalid when it is clearly defined in-scope and can be used against your company? Also, one thing that has been confusing to me is if there is a life cycle to a reported bug. If I report a bug and the company says they won’t fix it, but then six months to a year later they do, then should that be rewarded? What about seven years later? I actually can provide a link where WordPress waited seven years to fix a bug…
Isn’t it bad behavior when a bug is flagged won’t fix and then the company fixes it without a reward?
–> Yes, though sometimes it isn’t a matter of the issue being intentionally fixed later, but the developers changing something else in the application that happens to remove the issue. A regression that results in a security fix as it were. In which case it can’t hurt to send email and ask about your bug report.
Isn’t it bad behavior to remove a file after a researcher spent hours upon hours doing research, so you can save money?
–> It is definitely not promoting a healthy partnership with the security researchers that submit bugs to the program to patch bugs before the full repro/report is complete. Researchers submit bugs to bounty programs as quickly as possible so they are first to report but also because the goal is to secure customers quickly. Sometimes a researcher will have a moderate bug that they are still working on POC code to exploit at a more critical level. If they have communicated this to the customer and the customer doesn’t give them reasonable time to finish their POC, that is creating ill-will with the researcher. On the other hand… what is reasonable? Highly motivated customers want to fix bugs as quickly as possible, so asking them to leave a vulnerability un-patched for an indeterminate amount of time so the researcher can continue POC exploit development isn’t reasonable either. So I guess the answer here for both sides is try to work together and do the right thing. And if you’re on one of Bugcrowd’s customer programs, we’ll help where we can in facilitating that communication.
Isn’t it bad behavior to flag something as invalid when it is clearly defined in-scope and can be used against your company?
–> In scope security vulnerabilities are in scope. If the scope is not defined precisely enough, that is not the researcher’s fault, they worked in good faith. We encourage customers to reward if a valid in scope bug is reported that results in code change, and if necessary, then update their brief to more explicitly include or exclude those sorts of issues in the future.
tl;dr - YES! Neither side of the offense/defense equation is always perfectly behaved. Researchers that submit low impact bugs/best practices and then hound the customer for hall of fame credit exist, while companies that don’t treat researchers respectfully are going to have a failing program, where the best researchers refuse to work with them.
This is why my job is all about building bridges and seeking balance.
You have a very hard job and do a really good job at it. My comment about removing files was worded incorrectly. I totally agree that companies should remove vulnerable files. There is one specific company that support was working with last I checked that said the vulnerability was never there, despite the fact that I had tested it and the only reason I sent in the report. It’s highly important to note that’s only happened once and that overall companies behave very well on bugcrowd and we as researchers need to do better on not sending in invalid bugs for them. Sometimes it is very hard to figure out what’s valid and invalid before submitting.
I wish I was at Black Hat to see this but there’s truth in both sides of the equation. @zombiehacker I totally feel the “don’t fix” stuff… I find it’s more often than not just a lack of security awareness amongst developpers… I too have lost count of obvious security problems that I flagged to have the company turn around and say “meh, that’s not a problem for us.”
