Scary Tickets：第三方服务系统存在的安全风险（上）

 

一、前言

在阅读本文前，强烈建议大家先参考下Inti之前发表关于Ticket Trick的一篇研究文章（原文，译文），以便对这方面内容有个整体的了解。

在Inti那篇文章刚发表时，包括我在内的许多黑客都对这种技术的工作原理非常感兴趣，想在实际目标中进行测试。有多个黑客成功在漏洞奖励计划中找到并反馈了存在这方面漏洞的一些目标。由于许多公司开始修复漏洞，我开始思索Zendesk以及其他服务系统的工作原理，想了解这些系统中是否还有被人们忽略的更大问题。今年我在参与学校的安全俱乐部活动时，我们决定举办名为“第三方服务威胁”主题的研讨会。借此机会，我也能够理解这些支持系统的工作原理以及利用这些系统的不同方法，在本文中，我将向大家介绍Ticket Trick技巧在Zendesk和Help Scout中的利用方式，这种利用方式更加危险，并且攻击方法也更加有趣。在整个研究过程中，有两个小伙伴与我并肩战斗，他们分别是@cmdrsnuggle以及@rawalshree。

 

二、Zendesk概览

在向目标企业的支持系统发送垃圾邮件之前，我测试了Zendesk，研究其中某些功能的工作机理。这个过程较为耗时，涉及到各方面内容，比如研究Zendesk功能、阅读社区支持页面以及理解官方文档等。

在开始研究Zendesk时，我非常好奇其中邮件以及服务单（ticket）处理方面的内容。如果大家之前用过Zendesk，可知当我们通过邮件回复ticket时，电子邮件的内容会被添加到ticket中。最早时Inti通过向support+id<ticketid>@domain.com这个地址发送邮件来完成该操作，但我比较好奇是否还有其他方法能将邮件内容加到ticket中。在研究期间，我发现官网提到Zendesk可以通过3种方式将收到的邮件与ticket关联起来：

1、检查邮件的In-Reply-To以及References头。如果这些字段存在，就利用这些字段将ticket内容加入邮件种；

2、收件方地址列表中包含support+id<ticketid>@company.zendesk.com。如果满足该条件，邮件内容就会被添加到ticket中；

3、邮件正文中隐式引用了某个ticket。

其中第2种方式与Inti的研究成果密切相关，因此我决定不去关注这一点，将重心放在第1和第2种方式上。第1种方式不受这类攻击方法影响，因为当第三方公司向我的“受害者”发送邮件时，我无法控制其中的In-Reply-To以及References头。现在我想复现Ticket Trick，因此我决定研究一下第3种方式。

为了理解第3种方式，我往实验系统发送了一封邮件：

当支持系统收到我的邮件时，就会自动回复一封邮件，这也是ticket在Zendesk中常见的创建方式。Zendesk通过自动回复邮件表明已收到ticket。

非常好，现在我们已找到自动响应路径，我们的目标是在邮件正文中找到关于该ticket的隐式引用。为此，我使用Gmail的“显示原始邮件”功能来分析邮件内容。

这封邮件中在----==_mimepart_5c7df374e772c_27fa3f8b3e4bcf18131485之前都属于邮件头，邮件正文位于这一行之后。

在上图中共有两处----==-mimepart，第一部分是纯文本，第二部分是HTML正文。这种设计方式使得只能接收纯文本邮件的邮件客户端也能接收这封邮件并能正确显示。目前一切看起来非常正常，然而在“This email is a service from Zendesk”这句话后，情况有所变化。接下来我们可以看到一个有趣的字符串，由数字和字母组成：[M7VRMO-LV6L]。这个字符串看上去非常有趣，所以我决定记住这个值，开始下一阶段测试。

到目前为止，我只是以客户的角色发送请求。现在我想观察一下同一个信息在Zendesk agent端的情况，如下图所示：

目前一切看上去正常，因此我让一起研究的小伙伴Brandon Nguyen往support@redacted.zendesk.com发一封邮件，主题设置为[M7VRMO-LV6L]（使用前面获得的这个哈希）。我想测试一下如果另一个发送方使用了同一个哈希值，在Zendesk端会观察到什么情况。结果agent端的确出现了非常奇怪的情况：

我很快就发现服务端会把小伙伴发送的邮件当成私人信息（private note），而没有当成公开评论（public comment）。我想澄清为什么会出现这种情况，于是检查了ticket的警告标志，看到一个提示信息：“Brandon Nguyen was not a part of this conversation. ”，官方也给出了为什么会出现这种情况的原因。

在官方解释页面中，我注意到一句话：“如果想允许新用户在ticket中公开评论，那么ticket相关的agent、requester（请求者）以及CC（抄送方）需要将新用户添加为CC角色”。因此当前发送者同样需要作为抄送方，所以我将小伙伴的邮件地址添加为ticket的CC地址。完成该操作后，我让小伙伴再次发送同一主题的邮件。与预期的一样，这封邮件顺利通过并被服务端当成公开消息：

图. Zendesk Agent页面信息

图. 客户端邮件页面

以上就是Zendesk整体情况，在深入分析利用方式之前，让我们再来看一下另一个支持系统。

 

三、Help Scout概览

在寻找Zendesk的替代解决方案时，我找到了另一款支持平台：Help Scout。这个系统的工作方式与Zendesk类似，但减少了一些功能。为了分析该系统，我决定注册并使用试用版来了解相关功能。

为了更好理解Help Scout的工作流程，我决定采用与Zendesk相同的分析步骤。这里有一点不同，Help Scout并没有太多官方文档介绍系统工作流程，因此我决定自己研究。与前面一样，首先我向测试环境发送了一封邮件，因为我在Help Scout上启用了自动回复功能，因此会收到一封自动回复邮件。

收到回复邮件后，我决定检查一下该系统是否也采用与Zendesk类似的模式。查看邮件源代码后，我很快就发现其中包含一个特殊的哈希：

找到该哈希后，我决定检查是否可以借助该信息将我的电子邮件内容添加到ticket中。为了测试这一点，我使用第二个账户向支持邮箱发送了一封邮件，在邮件正文中我添加了这个哈希值。

邮件发送完毕后，我发现Help Scout与Zendesk类似，也会将我的邮件附加到ticket中。然而，这里还有一个小问题。当在agent端操作时，我发现第二封邮件现在已经变成原始的发送者。这意味着来自agent的后续信息都会发送给第二封邮件，而不会发送给原始发件人（攻击者）。

因此我觉得很难利用这个过程，因为我们使用的攻击者邮箱无法再收到服务端返回的任何响应。然而当再次检查时，我才发现为什么第二个邮件地址会变成“原始发送者”，这是因为该地址是最近一封邮件的发送方。

因此，我们需要做的就是使用攻击者邮箱再往这个ticket发一封新的邮件，邮件正文中包含正确的哈希值。这样操作后，我们的攻击者邮箱就会再次变成“原始发送方”，可以接收后续邮件。

现在我们已经大概了解这两个系统，接下来讲一下具体的利用方式。