281–290 of 437 posts
Earlier quoted context omitted.
Relies on intent of the seller, who would need to be found via a valid subpoena that needs to pass a threshold of cause who would then argue they also sold it to security researchers, journalists and assumed everyone was or didnt discriminate or have any intent at all
That’s not how this works.
Earlier quoted context omitted.
Presumably one of the PMs you’re referring to has posted this article for additional information. Feels like they’re doubling down on their initial position. https://support.zendesk.com/hc/en-us/articles/8187090244506-...
> Although the researcher did initially submit the vulnerability through our established process, they violated key ethical principles by directly contacting third parties about their report prior to remediation. This was in violation of bug bounty terms of service, which are industry standard and intended to protect the white hat community while also supporting responsible disclosure. This breach of trust resulted i…
For some of our bugs given on h1, we openly say, "Hey, we need to see a POC in order to get this to be triaged." We do not provide test accounts for H1 users, so, if they exploit someone's instance, we'll not only take the amount that the customer paid off of their renewal price, we'll also pay the bounty hunter.
Earlier quoted context omitted.
Presumably one of the PMs you’re referring to has posted this article for additional information. Feels like they’re doubling down on their initial position. https://support.zendesk.com/hc/en-us/articles/8187090244506-...
> Although the researcher did initially submit the vulnerability through our established process, they violated key ethical principles by directly contacting third parties about their report prior to remediation. This was in violation of bug bounty terms of service, which are industry standard and intended to protect the white hat community while also supporting responsible disclosure. This breach of trust resulted i…
Heads I win, tails you lose.
Our team at Zendesk has posted some more details about this bug here: https://support.zendesk.com/hc/en-us/articles/8187090244506-...
Another example of how weasley Zendesk can be: They created a fake band called "Zendesk Alternative" just in an attempt to pollute the Google results if you search for an alternative to Zendesk. http://zendeskalternative.com/ While not illegal, it shows the way they think, a sort of manipulative pettiness.
>Personally, I’ve always found it surprising that these massive companies, worth billions, rely on third-party tools like Zendesk instead of building their own in-house ticketing systems. Ah, yes, why do laymen always think this? I mean, I get it, Krupp and mining towns used to be a thing, so it is possible. But every big company should build a ticketing system? Why not an email solution, OS, network routers too?
1. zendesk allows you to add users to a support issue and view the complete issue history by sending a response email to a guessable support email from a person associated with an issue and cc'ing the person to add.
2. Zen desk depends on a spam check for inbound email validity. This check does not appear to catch instances where sender email is spoofed. Zendesk claims this is bdue to DKIM/SPF/DMARC config but I have trouble imagining that 50% of Fortune 500 would get this wrong. There are many automated checks available.
3) Apple issues an Apple ID account to anyone who can receive a verification email Sent to the mailing address (support@company.com)
4) Slack allows you to sign in to a workspace using any Apple ID associated with the workspace domain (e.g. support@company.com)
This researcher reported #2 to hackerone and was declined. Researcher later discovered full exploit with 3 and 4. Did not update hackerone, contacted affected companies directly.
it would have been prudent to update hackerone on the additional finding, but it feels like an easy oversight for a 15 year old after getting rejected on the first round.
Zendesk should take the higher ground and recognize the mistake and correct it. Not get all "ethical mumbo jumbo."
Years ago I had a similar train of thought: Zendesk is used by a ton of companies for their support site, and back then HTTPOnly cookies and javascript site isolation were much less of a thing. I found an XSS bug on Zendesk, which also translates into XSS on any site that used it as `support.fortune500.com` subdomain (which was a lot). You could then use it to exploit the main site, either by leaking user cookies or…
Huh? I don't think you can read page contents unless the origin matches exactly (scheme://host:port).