英文 | https://medium.com/@alex.birsan/messing-with-the-google-buganizer-system-for-15-600-in-bounties-58f86cc9f9a5
翻译 | web前端开发（ID：web_qdkf)
你听说过Google错误问题追踪器吗？可能不是，除非你是最近报告了Google工具错误的Google员工或开发人员。我也没有，直到我注意到我的漏洞报告现在电子邮件通知之外的地方，并通过在其中打开新线程来处理时。
我才立即开始尝试去了解它。
那么这个网站到底是什么？根据文档，问题跟踪器（内部称为Buganizer系统）是Google内部使用的工具，可用于在产品开发过程中跟踪错误和功能请求。它可以在Google外部使用，供需要在特定项目上与Google团队合作的外部公共和合作伙伴用户使用。
换句话说，当某人发现Google产品有问题时，它就会出现在问题跟踪器中。有道理吧？ 我们作为外部用户，我们只能看到冰山一角：一小部分预先批准的类别，以及Google有人明确添加外部帐户（例如漏洞报告）的问题。但是到底有多少信息呢？
通过观察分配给最新公共线程的数字ID，我们可以轻松估计该工具在内部获得了多少使用。在Mountain View的工作时间内，每小时大约有2000–3000个问题被打开，其中只有0.1％是公开的。似乎该系统中的数据泄漏会产生很大的影响。让我们一起来了解它！
1、获取Google员工帐户
发现问题跟踪器后，我注意到的第一件事就是能够通过将电子邮件发送到特殊地址来参与讨论，如下所示：
（其中componentID是代表类别的数字，issueID是你正在响应的线程的唯一标识符）
这使我想起了一个最新的发现，即“票务技巧”，它使黑客能够利用这种电子邮件系统渗透到组织的聊天系统中。考虑到这是一个@ google.com电子邮件地址，我尝试使用该地址注册Google的Slack团队，并且确认页面看上去非常有希望：
之前从未出现来自Slack的电子邮件。
我能想到的第二件事是获得一个具有@ google.com主要电子邮件地址的Google帐户，希望这可以给我Buganizer带来的额外特权。Google不允许从Google外部注册这样的邮箱帐户：
但是，我找到了一种绕过此过滤器的方法：如果我使用任何其他伪造的电子邮件地址进行了注册，但无法通过单击电子邮件收到的链接来确认帐户，则可以无限制地更改我的电子邮件地址。使用这种方法，我将新的Google帐户的电子邮件更改为[email protected]。
不久之后，我在相应的问题页面上收到了一封确认电子邮件，作为一条消息：
真好！我单击了确认链接，登录了“问题跟踪器”，然后…
我被重定向到公司登录页面。不，我的Google帐户凭据在那里不起作用。
但是，此帐户为我在Internet上其他地方提供了许多额外的好处，包括搭便车的能力（免费，也许吗？），因此，这仍然是一个安全问题，为恶意用户打开了许多大门。
接受时间：11小时 | 赏金：3,133.7美元 | 优先级：P1
2、获取有关内部票证的通知
在熟悉UI时引起我注意的另一个问题跟踪器功能是为项目加注星标的功能。为问题加注星标意味着你对正在讨论的问题感兴趣，并且希望有人添加评论时收到电子邮件通知。
我注意到的有关此功能的有趣之处在于，当我尝试在无法访问的问题上使用该功能时，明显没有错误。访问控制规则似乎从未应用到此终结点上，因此我登录了第二个帐户，并尝试通过替换请求中的“问题ID”来从主帐户中添加漏洞报告。然后，我看到了此消息，表示该操作已成功完成：
有1人为该问题加注了星标。
监视公开的Google漏洞是否容易？我很快就此问题发表了评论，以查看我的虚构攻击者帐户是否会收到通知。
但是同样，没有电子邮件出现过。
出于某种原因，我真的不记得了，我决定对此进行一些进一步的测试。因此，我得到了最近的问题ID，并推断出数千个ID的范围，这些ID应该与数据库中的最新问题一致。然后，我将所有星标了。
几分钟后，我的收件箱看起来像这样：
打开收件箱时，我的第一个念头是“ Jackpot！”。
但是，经过仔细检查，这些线程中没有发生特别有趣的事情。显然，我只能窃听与翻译相关的对话，在该对话中，人们将辩论用不同语言传达短语含义的最佳方法。
我甚至考虑过几个小时不报告此情况，希望能找到一种提高严重性的方法。最后，我意识到Google安全团队可能会对寻找可能的枢轴方法和变体感兴趣，所以我发送了详细信息。
接受时间：5小时|赏金：5,000美元|优先级：P0
3、游戏结束
当你以外部用户身份访问问题跟踪器时，其大多数功能都会被剥夺，从而使您拥有极其有限的特权。如果你想查看Google员工可以完成的所有出色工作，则可以在JavaScript文件中查找API端点。这些功能中的某些功能被完全禁用，其他功能只是隐藏在界面中。
在设计此系统的受限版本时，如果有人对某个问题失去兴趣或不想再收到有关该问题的电子邮件，那么有人会为我们提供一种方法，让我们将自己从抄送列表中删除。这可以通过发送POST请求来实现，如下所示：
POST /action/issues/bulk_edit HTTP/1.1{ "issueIds":[ 67111111, 67111112 ], "actions":[ { "fieldName":"ccs", "value":"[email protected]", "actionType":"REMOVE" } ]}
但是，我注意到这里的一些疏忽导致了一个巨大的问题：
不当的访问控制：在尝试执行给定操作之前，没有明确检查当前用户是否实际有权访问issueIds中指定的问题。
静默失败：如果你提供的电子邮件地址当前不在抄送列表中，则端点将返回一条消息，指出该电子邮件已成功删除。
完整的问题详细信息作为响应：如果操作期间未发生错误，则系统的另一部分认为用户具有适当的权限。因此，有关给定问题ID的每个细节都将在HTTP响应正文中返回。
现在，我可以通过替换上面请求中的issueIds来查看有关数据库中每个问题的详细信息。
我只尝试查看几个连续的ID，然后从一个不相关的帐户进行攻击以确认此问题的严重性。
是的，我可以看到有关漏洞报告的详细信息以及Buganizer上托管的所有其他内容。
更糟糕的是，我可以在一个请求中提取有关多个票证的数据，因此，实时监视所有内部活动可能不会触发任何限速器。
我立即将漏洞利用细节发送给Google，一小时后，他们的安全团队停用了受影响的端点。令人印象深刻的响应时间！
接受时间：1小时|赏金：7,500美元|优先级：P0
当我第一次开始寻找这种信息泄漏时，我以为这是Google错误的圣杯，因为它会披露其他所有错误的信息（例如，HackerOne至少要为类似的问题支付10,000美元）。
但是在找到它之后，我很快意识到，将影响降到最低，因为无论如何，所有危险漏洞都会在一小时内被消除。
我对额外的现金感到非常满意，并期待发现其他Google产品中的错误。
