I am somewhat sympathetic to Zendesk's initial response (because bug bounty programs these days have a TERRIBLE signal:noise ratio). But I absolutely don't understand why (when it's a proven...
I am somewhat sympathetic to Zendesk's initial response (because bug bounty programs these days have a TERRIBLE signal:noise ratio). But I absolutely don't understand why (when it's a proven issue) they skimp out on paying the bounty. Tens of thousands for a legit bounty is nothing for a company of Zendesk's size and it saves them a ton of face with developers.
Zendesk wrote a small retrospective with respect to this article: https://support.zendesk.com/hc/en-us/articles/8187090244506-Email-user-verification-bug-bounty-report-retrospective It’s worth...
It’s worth noting in their response that they leave out their original response which effectively ignores the first report. Their justification for not paying the bug bounty is that the bounty hunter did not wait for remediation before talking to third parties, but from the bounty hunter’s article, it looked like Zendesk themselves were not interested in remediation.
I’m curious about any thoughts here, because I don’t think Zendesk should pay someone who caused them to allegedly lose business, but they also ignored the bug.
Zendesk characterizing the people the researcher contacted as "third parties" feels disingenuous too. They're the potential victims of the exploit that Zendesk was refusing to remediate.
Zendesk characterizing the people the researcher contacted as "third parties" feels disingenuous too.
They're the potential victims of the exploit that Zendesk was refusing to remediate.
Imo both Zendesk and the bounty hunter come away looking a little bad. Zendesk for ignoring what was obviously a big data breach in the ticket access bug, and the researcher for not submitting a...
Imo both Zendesk and the bounty hunter come away looking a little bad. Zendesk for ignoring what was obviously a big data breach in the ticket access bug, and the researcher for not submitting a new report after discovering they could escalate the bug to full on SSO access before telling third parties.
I disagree. ZenDesk ignored a problem that was already very serious; knowingly leaving in an exploit that lets third parties see companies' support tickets places those companies — and countless...
I disagree. ZenDesk ignored a problem that was already very serious; knowingly leaving in an exploit that lets third parties see companies' support tickets places those companies — and countless people whose data may be held by those companies — at potentially major risk (IMO, potentially much worse than an exploit to access Slack channels; Slack is already notoriously insecure).
After ZenDesk's lackluster response to his first two attempts to warn them about this exploit, the only ethical way forward was to start directly warning ZenDesk's clients. They have a right to know how unseriously ZenDesk takes their security.
If he instead just contacted ZenDesk a third time, best case scenario is that ZenDesk would (finally) agree to tackle the bug. But this wouldn't address the deeper issue, which is that ZenDesk is coasting on clients' trust. This strategy wouldn't be enough to cause a shakeup in the company culture or let clients make an informed decision about their business partnership with ZenDesk.
Maybe he should have contacted ZenDesk a third time as well, in addition to warning clients, but he would have known that those clients would reach out to ZenDesk anyway and that ZenDesk wouldn't understand the gravity of their lax attitude until it bit them in the pocketbook.
I am somewhat sympathetic to Zendesk's initial response (because bug bounty programs these days have a TERRIBLE signal:noise ratio). But I absolutely don't understand why (when it's a proven issue) they skimp out on paying the bounty. Tens of thousands for a legit bounty is nothing for a company of Zendesk's size and it saves them a ton of face with developers.
Zendesk wrote a small retrospective with respect to this article: https://support.zendesk.com/hc/en-us/articles/8187090244506-Email-user-verification-bug-bounty-report-retrospective
It’s worth noting in their response that they leave out their original response which effectively ignores the first report. Their justification for not paying the bug bounty is that the bounty hunter did not wait for remediation before talking to third parties, but from the bounty hunter’s article, it looked like Zendesk themselves were not interested in remediation.
I’m curious about any thoughts here, because I don’t think Zendesk should pay someone who caused them to allegedly lose business, but they also ignored the bug.
It's unethical to contact third parties during remediation, but Zendesk actively refused to remediate.
Zendesk characterizing the people the researcher contacted as "third parties" feels disingenuous too.
They're the potential victims of the exploit that Zendesk was refusing to remediate.
Imo both Zendesk and the bounty hunter come away looking a little bad. Zendesk for ignoring what was obviously a big data breach in the ticket access bug, and the researcher for not submitting a new report after discovering they could escalate the bug to full on SSO access before telling third parties.
I disagree. ZenDesk ignored a problem that was already very serious; knowingly leaving in an exploit that lets third parties see companies' support tickets places those companies — and countless people whose data may be held by those companies — at potentially major risk (IMO, potentially much worse than an exploit to access Slack channels; Slack is already notoriously insecure).
After ZenDesk's lackluster response to his first two attempts to warn them about this exploit, the only ethical way forward was to start directly warning ZenDesk's clients. They have a right to know how unseriously ZenDesk takes their security.
If he instead just contacted ZenDesk a third time, best case scenario is that ZenDesk would (finally) agree to tackle the bug. But this wouldn't address the deeper issue, which is that ZenDesk is coasting on clients' trust. This strategy wouldn't be enough to cause a shakeup in the company culture or let clients make an informed decision about their business partnership with ZenDesk.
Maybe he should have contacted ZenDesk a third time as well, in addition to warning clients, but he would have known that those clients would reach out to ZenDesk anyway and that ZenDesk wouldn't understand the gravity of their lax attitude until it bit them in the pocketbook.