如何通过support帮助功能在漏洞挖掘中获取高额赏金呢，以下是国外白帽小哥Inti De Ceukelaire通过support帮助台功能挖掘漏洞赚取高额赏金的经历。

前言

几个月前，我发现了一个漏洞，黑客可以利用它来访问公司的内部通讯系统。只需点击几下鼠标，这个漏洞就可能访问内联网、 Twitter等社交媒体帐户，以及最常见的Yammer和Slack团队。

这个漏洞仍然存在，目前无法立即修复。在过去的几个月里，我联系了数十家公司和受影响的供应商，作为他们漏洞赏金计划的一部分，以便修复他们的系统。由于受影响的公司数量众多，无法联系到所有人。根据一些前辈的建议，并获得了受影响供应商的批准，我决定发布这篇博客，以便所有受影响的人能立即采取行动。现在介绍一下我称之为“票据伎俩”的漏洞。

THE DOOR — 使用您的 @company 电子邮件注册

流行的商业沟通工具（例如 Slack、Yammer 和 Facebook Workplace）要求员工使用其 @company 电子邮件地址进行注册。员工点击发送到其内部电子邮件地址的验证链接后，即可加入公司的实例并访问内部通信。

关键点——帮助台或电子邮件创建功能

方法 1 — 问题追踪器(类似于问题反馈接口)

事情始于我发现一种绕过GitLab身份验证的方法。任何拥有有效@gitlab.com电子邮件地址的人都可以加入他们的团队。

同时，GitLab 还提供了通过电子邮件创建问题的功能，将问题发送到唯一的 @gitlab.com 电子邮件地址。看看*这是什么意思？

我尝试使用这个问题创建的电子邮件地址加入他们的 Slack 团队，只是想看看会发生什么。

我快速刷新了我的问题列表，并看到验证电子邮件已作为问题添加到我的项目中：

最新添加的问题包含加入其内部 Slack 团队所需的神奇链接：

我点击了链接，想看看它是否真的有效——结果确实有效。我看到了可以加入的频道列表，然后立即删除了我的帐户并通知了 GitLab。

GitLab 团队在我报告的同一个周日晚上做出了回应。

他们立即将 Slack 功能设置为仅限受邀者使用，并采取额外措施告知客户此功能的危险。

方法 2 — 支持台support

只有少数网站有公开的问题跟踪器，所以我决定深入挖掘，看看是否存在更常见的利用媒介。结果发现，确实存在，而且比我想象的要常见得多：客户服务。

发送到[email protected]的电子邮件有时会出现在在线支持门户中，例如Zendesk、Kayako、 (Fresh) Desk、WHMCS或自定义工具。所以我决定试一试，看看黑客是否能以某种方式从数据库中提取链接。

大多数支持门户都可以集成单点登录：经过身份验证的用户将自动登录到支持台，以确保无缝体验。我测试的网站中有一半以上不需要电子邮件验证，这意味着任何人都可以使用*任何电子邮件地址注册并有效阅读该电子邮件地址创建的任何支持票证**。在线视频共享平台 [censored] 是众多不需要验证的公司之一。

因此我注册了一个 [censored*] 帐户，该帐户的电子邮件地址与 Slack 用于发送其神奇验证链接的电子邮件地址相同：feedback@slack.com。

使用 Slack 便捷的查找工作区功能，我找到了 [censored] slack 实例并使用电子邮件地址support@ [censored] .com进行了注册。

在幕后，[email protected]现在向*support@** [censored] .com发送一封包含验证链接的电子邮件。

当support@ [censored*] .com收到电子邮件时，它将被归类为由[email protected]创建的支持票...这正是我注册时使用的电子邮件。

所以我去了帮助中心查看我的支持票。

我有一张未解决的支持票......其中包含我加入 [censored*] 团队所需的神奇验证链接。

[censored*] 团队立即对此报告做出了回应，并作为其 Bug Bounty 计划的一部分发放了 2,000 美元的赏金。

所有集成了支持门户但没有电子邮件验证的网站都容易受到此问题的影响。而且情况甚至更加糟糕。

我在Kayako和 Zendesk中发现了另外两个漏洞，它们让我能够绕过它们常用设置中的电子邮件验证过程。**这样，即使未启用 SSO 且需要电子邮件验证，我也能始终执行攻击。**我于 6 月 1 日将这些问题作为其负责任披露计划的一部分报告了，两家公司都已修复了问题。

除此之外，那些要求用户在注册时验证其电子邮件地址，但在之后更改时无需验证的网站也存在漏洞。

漏洞影响范围

如果一家公司不使用 Slack 并认为它很安全……那么这家公司可能运气不佳，因为我发现这个问题非常普遍。例如：Yammer 等其他商业通信工具也容易受到这种攻击：

而且由于我们可以阅读发送到support@ 的电子邮件，我们还可以看到发送到该电子邮件地址的任何密码重置链接。事实证明，不少公司都使用这个电子邮件地址注册第三方服务和Twitter等社交媒体。

这意味着攻击者还可以劫持与support@邮件地址相关的任何帐户：

在某些情况下，该电子邮件地址在网站本身上也拥有特权帐户。通过注册 [email protected]，您可以拦截 [email protected] 的密码重置令牌，并访问可访问所有客户信息的特权帐户。

如果以上方法都不起作用，攻击者仍然可以阅读和回复通过电子邮件创建的过去和将来的支持单。我的一个朋友曾经向一家公司的支持地址发送了一封电子邮件，因为有些东西无法正常工作。在调查这个问题时，我发现这家公司很容易受到攻击，所以我用他的电子邮件地址注册，点击“我的支持案例”选项卡，然后看到那封特定的电子邮件出现了。我几乎可以阅读和回复人们发送给客户服务的每封电子邮件，只要他们没有支持台的账户。用户以为他们在与客户服务交谈，其实是在与黑客交谈。

供应商和公司回应

有趣的是看到每家公司处理披露的方式不同。

• 大多数受影响的公司都非常专业地处理了我的报告。有些公司甚至决定提供高达 8,000 美元的漏洞赏金。我偶尔会收到负面回应，有些则选择完全忽略我的披露。

• 问题追踪器GitLab（#21823，已披露）迅速采取行动，禁用了对自己公司域的信任并更改了 Slack 设置。他们还更新了文档，以防止用户犯同样的错误。

• 我向Slack披露了这个问题（#23923，待披露），以检查我们是否可以在更高层面上防止这种情况发生。尽管他们不直接负责这个问题，但它影响了他们很大一部分客户。Slack认真对待这个风险，并将他们的无回复电子邮件地址更改为包含一个随机令牌。这有效地防止了帮助台软件中的攻击。问题跟踪器和其他电子邮件集成仍然存在此问题。尽管这不是 Slack 本身的漏洞，但 Slack 还是决定为我的报告提供 1,500 美元的丰厚赏金。

• 我也尝试就此问题联系Yammer。起初我没有得到任何回复。两周后，我发送了一封后续电子邮件，他们回复说他们已将其转发给 Yammer 团队，并附上安全漏洞的定义。到目前为止，他们还没有像 Slack 那样采取任何主动措施在更高层面上解决此问题。

• 我联系了Kayako和Zendesk（# 235139，已披露），咨询有关 SSO 绕过的问题，这是他们漏洞赏金计划的一部分。这两家公司都解决了这个问题，并分别奖励了我 1000 美元和 750 美元的赏金。

总结

• 一旦进入内部，大多数公司的安全性就会大大减弱。内部影响评估显示，员工将密码、公司机密和客户信息粘贴在团队中每个人都可以访问的渠道中。

• 我们需要在所有可能的地方不断寻找安全问题。这个漏洞多年来一直存在于数百个经过安全专家筛查的网站中，但据我所知，没有人发现它。

• 大公司根本不知道他们的员工在做什么。我曾与一家大型支付处理公司的 CISO 讨论过这个漏洞。他向我保证这不会是个问题，因为他们的员工不应该通过 Slack 进行交流。他们建立了自己的内部网来处理这些事情。我加入了全球 332 名员工积极使用的 8 个 Slack 频道，证明了他错了。我最终获得了 5,000 美元的赏金。
  

原文始发于微信公众号（白帽子左一）：如何巧妙利用support帮助台漏洞获取高额赏金