321–330 of 437 posts
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.
https://zendeskcompetitor.com is still available.
Reported this exact bug to Zendesk, Apple, and Slack in June 2024, both through HackerOne and by escalating directly to engs or PMs at each company. I doubt we were the first. That is presumably the reason they failed to pay out. The real issue is that non-directory SSO options like Sign in with Apple (SIWA) have been incorrectly implemented almost everywhere, including by Slack and other large companies we alerted i…
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-...
I don't understand what this tries to accomplish. The problem is bad, botching the triage is bad, and the bounty is relatively cheap. I understand that this feels bad from an egg-on-face perspective, but I would much rather be told by a penetration tester about a bug in a third-party service provider than not be told at all just to respect a program's bug bounty policy.
Also I think this is a good reminder that using sequential IDs for anything public facing is almost always a bad idea (or at the very least something you should think very hard about). It would be pretty easy to make ticket ID, for example, a sequential 5 digit number followed by 4 random alphanumeric characters. Everyone could still easily refer to the ticket number, but it wouldn't be guessable.
Reported this exact bug to Zendesk, Apple, and Slack in June 2024, both through HackerOne and by escalating directly to engs or PMs at each company. I doubt we were the first. That is presumably the reason they failed to pay out. The real issue is that non-directory SSO options like Sign in with Apple (SIWA) have been incorrectly implemented almost everywhere, including by Slack and other large companies we alerted i…
Imagine Bob works at Example Inc. and has email address bob@example.com
Bob can get a Google account with primary email address bob@example.com. He can legitimately pass verification.
Bob then gets fired for fraud or sexual harassment or something else gross misconduct-y and leaves his employer on bad terms.
Bob still has access to the Google account bob@example.com. It didn't get revoked when they fired him and locked his accounts on company systems. He can use the account indefinitely to get Google to attest for his identity.
Example Inc. subscribes to several SaaS apps, that offer Google as an identity provider for SSO. The SaaS app validates that he can get a trusted provider to authenticate that he has an @example.com email address and adds him to the list of permitted users. Bob can use these SaaS apps years later and pull data from them despite having left the company on bad terms. This is bad.
I think the only way for Example Inc. to stop this in the case of Google would be to create a workspace account and use the option to prove domain ownership and force accounts that are unmanaged to either become managed or change their address by a certain date. https://support.google.com/a/answer/6178640?hl=en
Other providers may not even offer something like this, and it relies on Example Inc. seeking out the identity providers, which seems unreasonable. How do you stop your corporate users signing up for the hot new InstaTwitch gaming app or Grinderble dating service that you have never heard of and using that to authenticate to your sales CRM full of customer data?
Earlier quoted context omitted.
If it's anything like ServiceNow, they have insane feature bloat and poor overall software architecture.
Every single click in ServiceNow takes a full 2 seconds to do anything. For a ticketing system. Insane. What’s more insane is that it is still better than the vast majority of ticketing software. I don’t know what it is about ticketing and Helpdesk that it ALwAYs ends up like that.
The curse of B2B software is that every new big customer wants some custom feature or configuration that is the "deal breaker" for their multi-million dollar contract signing. And everyone except engineering is eager to give it to them because it's not their problem once the ink is dry. Support and renewals are the next guy's problem.
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.
Search engine chaff has been in the toolbag of "reputation management" PR firms for a while. Boris Johnson (former UK PM) deployed it many years ago to drown out a viral picture of him in front of a red bus bearing an ad he no longer wanted to associated with, so he was coached to tell an interviewer he has a hobby of painting model buses red.
Earlier quoted context omitted.
That helps, but I still don't have a full picture. What's the threat here? Is it that: if a hacker gains temporary access to Bob's email bob@example.com, they can create an Apple account attached to it, and use that account to sign in with a service ABC, then that hacker gains access to Bob's private info in service ABC? But if the hacker already has email access, can't he just log into service ABC directly anyway? A…
> Also, is it impossible to have a Google account with a non-gmail address? You can have your own domain if it is a workspace account
This can be done with an account that you once had control over but don't anymore, like if you leave an employer.
You can't send mail from it, but many apps will take having a google account with a given email is proof of ownership, or an @example.com email address is proof that you are an employee of Example Inc. when they are a customer of the app and have a tenant set up.
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-...
So when the researcher said it was a bug, they said, "No, it's fine. No bug bounty, sorry." THEN the researcher eventually goes public. Later, Zendesk announces the bug and the fix and says there will be no bug bounty because the researcher went public. Is that how it went? I mean if so, that's one way to save on bug bounties.
I am 100% certain that every one of the companies that paid the researched would consider the way this was handled by that researched "the best alternative to HackerOne rules 'ethical disclosure' in the face of a vendor trying to cover up serious flaws".
In an ideal world, in my opinion HackerOne should publicly revoke Zendesk's account for abusing the rules and rejecting obviously valid bug payouts.
Reported this exact bug to Zendesk, Apple, and Slack in June 2024, both through HackerOne and by escalating directly to engs or PMs at each company. I doubt we were the first. That is presumably the reason they failed to pay out. The real issue is that non-directory SSO options like Sign in with Apple (SIWA) have been incorrectly implemented almost everywhere, including by Slack and other large companies we alerted i…
I do web app testing and report a similar issue as a risk rather often to my clients. You can replace Google below with many other identity providers. Imagine Bob works at Example Inc. and has email address bob@example.com Bob can get a Google account with primary email address bob@example.com. He can legitimately pass verification. Bob then gets fired for fraud or sexual harassment or something else gross misconduct…