Last month, Google fixed a minor zero-day Chrome bug discovered by a member of Apple Security Engineering and Architecture (SEAR) during an HXP capture the flag (CTF) event. The bug was reported by someone else who also participated in the competition and not the Apple employee who found the bug.
The person who reported the bug to Google, Martin Radev, who goes by Sisu, said he did so because he was “not 100% sure it was reported to the Chromium team.” Google awarded $10,000 as a bug bounty to Radev, who reported it, and not the Apple employee who found the bug, who goes by Leonardo
Leonardo explained that he delayed reporting the bug for several reasons, primarily due to gaining the necessary sign-off within Apple to report the discovery to Google. Radev later presented a timeline of the bug’s discovery and disclosure and emphasized that there was “no malicious behavior by either Leonardo or me.” Radev said he and Leonardo are exploring “a good way to make use of the reward” and “a donation is to be made.”
As the annual Black Hat and DEFCON conferences get underway this week in Las Vegas, during which over 50 CTF events will be held, this incident underscores a central question: What are the obligations of CTF players to disclose zero-day vulnerabilities to vendors?
Bug reporting up to the CTF player’s code
CTF “is just a game,” David Brumley, Carnegie Mellon University Professor and CEO of ForAllSecure, tells CSO. It’s not the “mission” of CTF players to hunt down zero-day bugs in vendor software, he says, and therefore reporting the bugs to vendors is not typically top of mind for the players. A CTF event is just “one of those places where people have a safe space to play off a tradecraft.”
“CTFs are often about the discovery of vulnerabilities that were put there on purpose,” Casey Ellis, founder, chair, and CTO of Bugcrowd, tells CSO. “You’re finding vulnerabilities, breaking software. You’re tipping things upside down to see what falls out in the same way you would if you were doing focused bug hunting or vulnerability research to find things that you wanted to report and see fixed. But the reason that you’re doing it is different.”
Generally, it’s up to the CTF participants to use their judgment when submitting a bug report to a vendor, Ellis says. “As a vulnerability researcher, I don’t have to tell the company I found something. If I’m doing that, I’m either doing it because I feel like it’s something I should do to make sure it’s operating and disclosing vulnerabilities in the public interest and ensuring things get fixed. Or the additive reason is if there’s a bug bounty program and there’s some sort of reward for doing that, then I’m encouraged to do that. But in the absence of those two things, if I find a vulnerability as a security searcher, it’s my research, it’s my code, it’s my discovery, and what I do with it from that point forward is really still in my hands.”
Complexities surround bug reports from CTFs
Nevertheless, complexities surround discoveries of real-world bugs during CTF contests. “To people that look at it all from the outside, they just see the fact that you’ve got hackers breaking stuff and finding problems,” says Ellis. “Surely, they’re going to disclose those issues and try to get them fixed up in the public interest and all that kind of thing. It’s not necessarily a strict rule in that sense. Just because they found something doesn’t mean that they’re bound to this idea of helping the vendor. I certainly hope they do that.”
However, Chris Evans, CISO and chief hacking officer at HackerOne, thinks that bugs discovered during a CTF event should invariably be reported to vendors. “CTFs are a great way for hackers to test their skills and participate in the joy of hacking,” Evans tells CSO. “This is an excellent outcome, and any hacker achieving this should be praised,” he adds. “When this happens, standard ethics apply. The hacker has discovered a risk that could harm others and is in a position to get it addressed by reporting the issue to the affected vendor. The risk should be reported as promptly as possible to reduce the possibility of harm to others.”
Regarding the incident involving the Apple CTF player who discovered the Google flaw, Evans says, “It’s great that a CTF resulted in the discovery and fixing of a vulnerability in production software. CTFs can be chaotic and confusing environments, so it’s good that everyone worked together to get the best outcomes.”
Ellis draws an essential distinction between CTF events and bug bashes, collaborative events held by an organization designed to unearth many bugs within a short time governed by clear-cut rules that the participants agreed to beforehand. “They look a lot like a CTF, but the thing that’s different about it is that they’re actual systems that they’re going to be fixed at the end of the event. That information is meant to get to the recipient or the person, the organization running the contest. That’s literally its entire purpose. So, the rules, the process, and how that all works is clearly established.”
Capture-the-flag events are far murkier. With a CTF, the environment is usually fake, and it’s a game. “So, if vulnerabilities get inadvertently discovered in the process, which is a thing that happens, then what happens next is far less clearly defined,” Ellis says.
Further muddying the waters is the rise of hybrid events, such as will be the case with a CTF hosted by the AI Village at this year’s DEFCON. “Part of the purpose of that exercise is to disclose potential issues and AI model bias to the vendors of those models and to inform how vulnerabilities gets defined in machine learning and AI, to begin with,” Ellis says. “I think that kind of idea is starting to increase. I think people will be talking about a lot at the end of the week.”
——————————————————–
Click Here For The Original Story From This Source.
