[gavingmiller]

The piece the author is missing, and why zendesk likely ignored this is impact, and it's something I continually see submissions lacking. As a researcher, if you can't demonstrate impact of your vulnerability, then it looks like just another bug. A public program like zendesk is going to be swamped with reports, and they're using hackerone triagers to augment that volume. The triage system reads through a lot of reports - without clear impact, lots of vulnerabilities look like "just another bug". Notice that Zendesk took notice once mondev was able to escalate to an ATO[1]. That's impact, and that gets noticed!

[1] https://gist.github.com/hackermondev/68ec8ed145fcee49d2f5e2b...

[patcon]

Yes. But respectfully (residual frustration at zendesk might make me curt here) if their security triage team can't see how dangerous it is for an attacker to get access to an arbitrary thread on a their CLIENT's corporate email chains (in this world of email logins and SSO), then they have a big lapse in security culture, no?

Yes, the researcher could have tee'd himself up better, but this says way more about zendesk than it does about the 15-year-old researcher.

[XCabbage]

Unauthorized read access to private emails you were never legitimately CCed on already is impact. It should not be necessary to come up with a further exploit daisy chained on top of that in order to be taken seriously. (Otherwise why stop at Slack access? Why is that automatically "impact" if email access isn't?)

[lysp]

Exactly.

It's possible that some chains could have credentials or other sensitive information in ticket chains.

[ec109685]

The researcher showed how they could hop onto any Zendesk support ticket thread with zero authentication, so that should have been enough given Zendesk was exposing customer data via that attack path.

Clearly Zendesk needs to change things so that the email address that is created for a ticket isn’t guessable.

[Aachen]

Exploit or no, the bug and potential impact are the same. I personally find it a waste of time to sink evenings into an exploit when they're going to fix the bug anyway if I simply tell them about the problem. They also know the system better than I do and can probably find a bigger impact anyway

Of course, this is only a good strategy if you're just wanting to do a good deed and not counting on getting more than a thank you note, but Zendesk or Hackerone (whoever you want to blame here) didn't even accept the bug in the first place. That's the problem here, not the omission of an exploit chain

[dclowd9901]

The dude demonstrated the ability to infiltrate a client’s Slack instance via their vulnerability. If that’s not enough to make the hairs on your neck stand on end as an engineer, go fucking do something else.

[thrdbndndn]

He didn't demonstrate this in his initial report to Zendesk.

[tptacek]

I think this is (descriptively) correct, but it's a difficult point to make in a message board argument because of hindsight bias.

[gavingmiller]

It’s a good callout, shouldn’t have editorialized like that.

[davedx]

I don't think it is. Getting arbitrary access to corporate support ticket chains seems pretty high impact to me? Isn't that a gigantic data breach (also probably a GDPR breach) already, before you get to the Slack takeover?

[23B1]

"If you won't illustrate the impact of our mistake, we aren't obligated to listen to you" is peak CYA

[gavingmiller]

Not even close to the point I was making: If you want to get taken seriously, write to audience.