Mildly Infuriating

I couldn’t help but find it amusing—they were now asking me to keep the report confidential, despite having initially dismissed it as out of scope.

"Sorry, but per your own guidelines this is out of scope. Because of this, this bug is not part of the agreement and guidelines on Hackerone. You can find my full disclosure, that I wrote after your dismissal here: " /s

I specially liked the part where he collected $50k by clueing the affected companies.

At the end of the day tens of thousands for companies is a small price to pay for something that could cost millions. As bonus this person now has a foothold in big companies. Sounds like a great way to get a well paying job.

My sides went into orbit!

The way that the Github comment is phrased, it implies that the link contains additional info that hackermondev didn't mention. It doesn't - instead it contains a subset of that info, missing critical bits:

1. That Zendesk initially dismissed hackermondev's report.
2. That the "third parties" in question were Zendesk's clients.

Both pieces of info were omitted to back up a lie present in the text, that the bug hunter would have "violated key ethical principles". He didn't - as he noticed that Zendesk gives no flying fucks about the security issue, and that remediation was unlikely, he warned the people affected by the issue, so they can protect themselves against it.

Zendesk is not just being irresponsible - it's also being manipulative, and doubling down instead of doing the right thing ("we incorrectly dismissed that report. It was our bad. Here's your 2k.") They have no grounds to talk about ethical principles.

They aren't trying to actually send from that email, they are trying to create an Apple ID that lets them log in using that email effectively as a username. And Slack will add people to the internal Slack if the email is a company email address.

To open that account, they need to prove to Apple they own the account. They sign up with Apple and say their email address is [email protected], then Apple sends them a code to verify it's their email.

They can't actually receive the verification email, because it's not their email. That's where the exploit comes in. It's very important that this email address is the one that forwards emails to Zendesk. The verification email from Apple goes to Zendesk, then they use the exploit to see the history of the zendesk ticket, which includes the verification code.

Someone on the Github mentioned that @Zendeskteam may not even be official.

I doubt most of those comments are from Lemmy. Probably Reddit and other places.

What "should be done" is irrelevant - what matters is what "is done". And plenty servers don't enforce SPF, DKIM and DMARC. (In fact not even Google and Yahoo did it, before February of this year.)

And, when you know that your product has a flaw caused by a third party not doing the right thing, and you can reasonably solve it through your craft, not solving it is being irresponsible. Doubly true if it the flaw is related to security, as in this case.

Let us learn with Nanni: when Ea-nāṣir sold him shitty copper, instead of producing shitty armour, weapons and tools that might endanger Nanni's customers, Nanni complained with Ea-nāṣir. Nanni is responsible, Zendesk isn't. [Sorry, I couldn't resist.]

[EDIT: can you muppets stop downvoting the comment above? Dave is right, Moonrise is trying to start a discussion, there's nothing wrong with it.]

Sorry you've been downvoted for trying to start a discussion.

Is this not the swiss cheese thing? No control is perfect, so you layer them. If there is no reason why Zendesk should let this happen, then it shouldn't happen.