【Hacker News搬运】1个bug，5万美元的赏金，一个Zendesk后门

hackernews

Title: 1 bug, $50k in bounties, a Zendesk backdoor

1个bug，5万美元的赏金，一个Zendesk后门

Text:

Url: https://gist.github.com/hackermondev/68ec8ed145fcee49d2f5e2b9d2cf2e52

很抱歉，作为一个AI，我无法直接访问或处理外部链接，如GitHub Gist。如果您能提供链接中的内容或具体问题，我可以帮助您分析和总结。如果您需要帮助理解或分析GitHub上的代码，请复制相关代码片段到这里，我将尽力帮助您。

Post by: mmsc

Comments:

eatbots: 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 in June.Non-directory SSO should not have equal trust vs. directory SSO. If you have a Google account and use Google SSO, Google can attest that you control that account. Same with Okta and Okta SSO.SIWA, GitHub Auth, etc are not doing this. They rely on a weaker proof, usually just control of email at a single point in time.SSO providers are not fungible, even if the email address is the same. You need to take this into account when designing your trust model. Most services do not.

eatbots: 2024年6月，通过HackerOne和直接升级到每家公司的工程师或项目经理，向Zendesk、苹果和Slack报告了这个确切的错误 我怀疑我们是第一个。这大概就是他们没有付款的原因 真正的问题是，几乎所有地方都错误地实施了非目录SSO选项，如使用苹果登录（SIWA），包括Slack和我们在6月份提醒的其他大公司 非目录SSO不应与目录SSO具有同等的信任。如果您拥有Google帐户并使用Google SSO，Google可以证明您控制该帐户。Okta和Okta SSO也是如此 SIWA、GitHub Auth等没有这样做。他们依赖于较弱的证据，通常只是在单个时间点控制电子邮件 SSO提供者是不可替代的，即使电子邮件地址相同。在设计信任模型时，您需要考虑到这一点。大多数服务都没有。

bsuvc: It sounds like the author got stiffed by Zendesk on this bug, $0 due to email spoofing being out of scope.The $50k was from other bug bounties he was awarded on hackerone.It's too bad Zendesk basically said "thanks" but then refused to pay anything. That's a good way to get people not to bother with your big bounty program. It is often better to build goodwill than to be a stickler for rules and technicalities.Side note: I'm not too surprised, as I had one of the worst experiences ever interviewing with Zendesk a few years back. I have never come away from an interview hating a company, except for Zendesk.

bsuvc: 听起来作者在这个bug上被Zendesk搞砸了，因为电子邮件欺骗超出了范围，所以0美元 这5万美元来自他在hackerone上获得的其他bug赏金 它；遗憾的是，Zendesk基本上是这么说的；谢谢&quot；但随后拒绝支付任何费用。那；这是一个让人们不要为你的巨额赏金计划而烦恼的好方法。建立善意往往比坚持规则和技术细节要好 附注：I；我并不太惊讶，因为几年前我在Zendesk的面试经历是最糟糕的。除了Zendesk，我从来没有在面试结束时讨厌过一家公司。

junto: I help corporates evaluate and buy software. Having an ineffective bug bounty program, especially one that rewards black market activity on a terms & conditions technicality like this, is enough for me to put a black mark on your software services.I don’t care if you’re the only company in the market, I’ll still blackball you for this in my recommendations.Zendesk should pay up, apologize and correct their bug bounty program. After doing so, they should kindly ask the finder to add an update to this post, because otherwise it will follow them around like dogshit under their shoe.

junto: 我帮助企业评估和购买软件。有一个无效的漏洞赏金计划，尤其是一个按条款奖励黑市活动的计划；像这样的技术性条件，足以让我在你们的软件服务上留下污点 我不在乎你是不是市场上唯一的公司，我仍然会在我的推荐中禁止你这样做 Zendesk应该付清费用，道歉并纠正他们的漏洞赏金计划。这样做之后，他们应该请发现者为这篇文章添加一个更新，否则它会像鞋子下面的狗屎一样跟着他们。

maeil: A $1.3 billion revenue company being too tight to pay this after all, even on their 2nd chance, is so short-sighted it's absurd. They're putting out a huge sign saying "When you find a vuln, definitely contact all our clients because we won't be giving you a penny!".Incredible. This must be some kind of "damaged ego" or ass-covering, as it's clearly not a rational decision.Edit: Another user here has pointed out the reasoning> It's owned by private equity. Slowly cutting costs and bleeding the brand dry

maeil: 一家收入达13亿美元的公司，即使在第二次机会时，也因资金紧张而无法支付这笔费用，这是如此短视；这太荒谬了。他们；重新竖起一块巨大的牌子，上面写着&quot；当您发现漏洞时，一定要联系我们所有的客户，因为我们赢了；我不会给你一分钱的&“ 难以置信。这一定是某种&quot；自我受损&quot；或屁股覆盖物，因为它；这显然不是一个理性的决定 编辑：这里的另一位用户指出了原因&gt；它；s由私人股本公司持有。慢慢削减成本，让品牌干涸

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] <a href="https://gist.github.com/hackermondev/68ec8ed145fcee49d2f5e2b9d2cf2e52#aftermath" rel="nofollow">https://gist.github.com/hackermondev/68ec8ed145fcee49d2f5e2b...</a>

gavingmiller: 作者缺少的那篇文章，以及为什么zendesk可能忽略了这一点，这是一种影响；这是我经常看到的提交不足之处。作为一名研究人员，如果可以的话；如果不能证明你的漏洞的影响，那么它看起来就像另一个bug。像zendesk这样的公共程序将被报告淹没，他们；重新使用hackerone试用者来增加这一数量。分流系统通读了大量报告，但没有明确的影响，许多漏洞看起来像&quot；只是另一个bug”；。请注意，一旦mondev能够升级为ATO，Zendesk就会注意到这一点[1]。那；它的影响，这会引起人们的注意 [1]<a href=“https:”gist.github.com“hackermondev”68ec8ed145fcee49d2f5e2b9d2cf2e52#after“rel=”nofollow“>https:”&#x2F；github.com；hackermondev；68ec8ed145fcee49d2f5e2b</一