译者：blueSky
预估稿费：200RMB
投稿方式：发送邮件至linwei#360.cn，或登陆网页版在线投稿
前言
你听说过Buganizer吗？可能没有，除非你是谷歌的员工或最近在谷歌工具中上报过程序缺陷的开发人员。我之前也没听说过，直到我发现我的漏洞报告除了正常的邮件通知外，还同时会被一个新打开的线程处理。自然而然的，我立即开始试着去“渗透”它。
Buganizer
那么这个网站究竟是什么？根据文档，问题跟踪器（内部称为Buganizer系统）是Google内部使用的一种在产品开发过程中跟踪错误和特性请求的工具。它可供谷歌以外的外部用户和需要在特定项目上与谷歌团队进行协作的合作伙伴使用。
换句话说，当有人使用谷歌产品遇到问题时，它会出现在问题跟踪器中。这非常有意义不是吗？作为外部用户，我们只能看到冰山一角，比如漏洞报告。但是在这些表层信息之下还潜藏了多少问题呢？
通过观察分配的最新的数字ID，我们可以很容易地估计这个工具在内部获得了多大的使用量。在谷歌工作时间内，每小时大约会产生2000到3000个问题，其中只有0.1%是公开的。看来这个系统在数据泄露这方面可以大做文章。让我们来破解它吧！
攻击1：”黑掉”谷歌员工账号
在研究这个问题追踪器的时候，我第一个注意到的问题就是：可以通过发送邮件到一个特殊的邮箱来参与到一个讨论。它看起来像这样：
其中componentID是代表一种类别的数字编号，issueID是正处于处理周期的Bug唯一识别码。
这让我想起了最近一个叫做Ticket Trick的发现，它允许黑客利用一种电子邮件系统渗透到某些组织的内部聊天系统中。介于这是一个@google.com的电子邮件地址，我尝试使用它登录Google的Slack团队，然后我真的看到了有希望成功渗透的确认页面：
遗憾的是，Slack并没有回复我任何邮件。
我能想到的获得谷歌账户的第二个好办法是利用@google.com为后缀的电子邮件去做点什么。它很有可能帮助我在Buganizer系统上获得一些额外的权限。如下图所示，从谷歌外部注册一个这样的账户是不允许的。
但是我找到了一种绕过这种过滤器的方法：
如果我随便用一个假的电子邮箱去注册，当点击邮件中的链接去认证这个新邮箱失败了的时候，系统是允许我无条件变更邮箱。用这个办法，我把一个新的谷歌账户的绑定邮箱改成了[email protected]
很快，我收到了一封如下图页面所示的认证邮件：
我点击了这个认证链接，然后登录问题追踪器，然后……
我被重定位到了企业的登录页面，但我的谷歌账户在这里失效了。不过，这个账户在互联网上的其他地方让我“收获颇丰”，所以这仍然是一个安全漏洞，它为那些不怀好意的人大开了方便之门。
采纳时间：11小时|赏金：3133.7美元|优先级：P1
攻击2：获取内部的通知
当我在熟悉用户界面的时候，问题追踪器的另一个特点很快抓住了我的眼球：它能够给每个条目标星号。给一个条目标出星号意味着你对这个条目很感兴趣，想要探究它，并且希望只要有人对它发表评论你就可以立刻收到邮件提醒。
对于这个功能，我注意到一个有趣的事情：在我没有权限访问的问题上尝试使用它时，居然没有报错。访问控制规则似乎没有应用于这个工具，所以我登录到我的第二个帐户，并尝试通过替换请求中的issue ID来从我的主帐户标记漏洞报告。然后我看到如下这个消息，这意味着这个方法是可行的：
有一个人标注了这个问题。
这个方法能否让人轻而易举去监控开放的Google漏洞呢？我很快发布了一个关于这个问题的评论，看看我的虚构的攻击者帐户是否会收到通知。
不过再次失败了，没有邮件出现。
由于某些我已经记不清了的原因，我决定对此进行进一步的测试。所以我利用一个最近的issue ID，并推出了数千个ID的范围，这应该与数据库中的最新问题相吻合。然后我把它们全部都标注了星号。
几分钟之内，我的收件箱列表如下图所示：
打开收件箱时，我的第一个想法是“中奖了！”。
然而，经过进一步的检查，发现在这些线程中并没有什么特别有趣的事情发生。显然，我只能窃听与Bug讨论相关的对话。我甚至考虑了很久干脆不去提交这个问题，我希望自己能找到某种方法提高一下这个问题的严重性。最后，我意识到谷歌安全团队可能已经意识到了这个安全漏洞，所以我最终还是发送了相关的细节。
攻击3：游戏结束
当你作为外部用户访问问题跟踪器时，其大部分功能被剥离，留给你的权限非常有限。如果你想查看谷歌的员工们可以使用的全部功能有哪些，您可以在javascript脚本中查找一些API，虽然其中一些功能被完全禁用，其他功能则隐藏在界面中。
当设计这个有限权限的系统时，如果我们对某个问题失去兴趣，或者根本就不想再收到有关这个问题的电子邮件，那么有人非常好心的给我们预留了从CCs列表中删除问题列表的方法。可以通过发送如下的POST请求来实现这个功能：
POST /action/issues/bulk_edit HTTP/1.1
{
"issueIds":[
67111111,
67111112
],
"actions":[
{
"fieldName":"ccs",
"value":"[email protected]",
"actionType":"REMOVE"
}
]
}然而，我注意到这里的一些疏忽导致了一个巨大的问题:
1. 不正确的访问控制：在尝试执行给定操作之前，没有明确地检查当前用户是否实际访问了issueID中指定的问题。
2. 静默失效：如果您提供的电子邮件地址当前不在CCs列表中，终端将返回一条消息，告诉你电子邮件已成功删除。
3. 可获得完整的问题详细信息：如果在操作过程中没有发生错误，系统的另一部分会假设用户有适当的权限。因此，关于给定的issue ID的每个细节都将返回给HTTP响应主体中。
显然，我现在可以通过仅仅是简单替换上一条问题的issueID的方式，就能够看到数据库中每一个问题的详细信息了！我只尝试查看了几个连续的ID，然后从一个无关的帐户攻击自己，以确认这个问题的严重性。是的，我可以看到有关漏洞报告的详细信息，以及Buganizer上托管的其他内容。 更糟糕的是，我可以在单个请求中渗透有关多个Bug的数据，然后可能在不触发任何限制的情况下实时监控所有内部活动。
我及时将漏洞详细信息发送给谷歌，其安全团队在一小时后修改了Bug。真是令人印象深刻的响应速度！
采纳：1小时|赏金：7500美金|优先级：P0
当我刚开始攻克这个信息泄露的问题时，我以为它将会成为谷歌漏洞里最顶级的发现，因为它公开了关于其他所有bug的信息。然而，在找到它之后，我很快意识到它的影响将被最小化，因为所有危险的漏洞都在一小时内被处理掉了。因此，我还是很开心能够获得这笔额外的赏金，并期待在其他谷歌产品中找到漏洞。
还没有评论，来说两句吧...