你听说过谷歌的漏洞跟踪管理平台（ Google Issue Tracker）吗？ 我想大多数人可能没有，除非你是谷歌内部雇员或是最近上报过谷歌相关产品漏洞的开发者。我也不知道这个东西，直到最近我通过上报给谷歌的漏洞才发现，谷歌除了通常的邮件通知外，还采取了这个新的漏洞跟踪反馈处理机制（如下图所示），所以，我决定想办法来搞搞它。
根据相关文档介绍，该漏洞跟踪反馈平台在谷歌内部称为Buganizer，是谷歌内部用于产品开发周期内对漏洞和需求问题进行跟踪反馈的系统。为满足多方和特定项目合作需求，它同样提供了外部访问接口。
也就是说，如果谷歌产品存在被人上报的漏洞问题，这些问题就会显示在该平台中，有点道理，对吧？作为外部用户的我们，只能看到其中的冰山一角：显示给我们的仅只是预先审核分类过的信息，或一些内部用户添加外部账户的问题，包括白帽们上报的一些漏洞报告。而在这些表面信息之下又存在着多少不为人知的深层漏洞信息呢？我们来一探究竟。
看看漏洞和问题的最近排序ID，我们能估计出该平台的大概处理工作量，峰值时最多第小时能接收2000至30000个问题报告，而谷歌选择公开的，仅只是这些问题或漏洞的0.1%，如果该平台存在信息泄露漏洞，那就好玩了，好吧，我们一起来看看！
第一个漏洞：通过更改Buganizer平台关联邮箱地址绕过谷歌身份认证
经研究发现，Buganizer平台在对问题和漏洞的跟踪处理过程中，会以以下特殊邮箱格式向漏洞上报人发送一些漏洞相关的交流信息：
buganizer-system+componentID+issueID@google.com
其中，componentID代表分类，issueID代表特定的漏洞问题编号。
这让我想起了最近有研究人员披露的helpdesk服务控制台欺骗技巧，利用该技术可以结合以上邮箱模式对某些公司的内部聊天系统进行成功渗透。考虑到该邮箱地址是以@google.com结尾的，所以我用以上谷歌的一个邮箱地址为账户去尝试登录谷歌的Slack服务，虽然出现了一个登录确认页面，但却没有任何Slack的返回信息，有可能是谷歌内部团队没有开启或利用Slack服务。
接下来我能想到的就是，想办法获取一个谷歌内部雇员邮箱@google.com了，这样或许能对这样或许能对Buganizer平台的访问提供特殊权限，这种内部雇员邮箱一般通过外网是注册不了的，只有内部员工或外包商才能拥有。
于是我尝试利用一种方法来绕过这种机制：在使用谷歌Buganizer平台过程中，Buganizer平台的Google账户关联邮箱可以任意更改，所以我把其更改为了buganizer-system+123123+67111111@google.com，之后，Buganizer平台会向我之前旧的关联邮箱发送来一封
关于当前Buganizer平台Google账户关联邮箱地址变更的确认邮件，其中包含了一个确认链接：
这一改，Buganizer平台就已经默认我是谷歌内部员工了！点击返回的确认链接之后，就直接转到了谷歌的内部登录系统了：
答案是肯定的，在此，这个新注册邮箱buganizer-system+123123+67111111@google.com当然是不能成功登录进入的。但已经能够说明问题了：利用这种漏洞，我能对其它谷歌服务的安全性作出测试，或许能享受其车辆定位服务系统的免费搭车。这依然是一个存在安全隐患的漏洞。最终我上报了该漏洞，谷歌安全团队在11个小时之后进行了采纳修复，我也获得了$3,133.7的赏金，该漏洞严重程度为危急。
第二个漏洞：获取谷歌内部相关凭据的通知提示信息
Buganizer平台的另外一个让我觉得有意思的地方就是其星标条目，标记为星标的条目表示你个人对该漏洞问题比较关注，并希望接收Buganizer平台上其他人对该漏洞的一些实时评论。
该功能比较有意思的是，当我用它标记一些不具备访问权限的漏洞条目时，竟然缺少一些错误提示。这貌似说明Buganizer平台未采用某些访问控制规则，于是，我用我的另外一个账户登录进入Buganizer平台，并尝试通过替换请求中的issueID来对上个主账户中的某个漏洞报告进行星标标记，于是，我看到了以下这条信息，表示标记行为成功：
1 person has starred this issue.
这样就能侧面监控一些谷歌漏洞的最新状态了吗？于是，我很快对该星标漏洞条目进行了评论，看看我的虚构账户是否能收到其状态提示通知。但可惜，还是没有任何邮件反馈。
由于某种原因，我决定对此问题继续进行一些深入测试。所以，我选择了一个近期的漏洞条目issueID，并推断出了Buganizer平台上最近数千个漏洞条目的ID范围，然后把它们全部标记为星标条目。几分钟之后，我的收件箱出现了这些情况：
我想，这应该中奖了吧！但是，仔细查看后发现，这些提示邮件中并没有太多有价值的信息，更多的是一些不同语言的评论和对话内容。
我希望后期对此漏洞进行一些深入研究，想办法找出更严重的问题，所以，它一直在我手上耽搁了几个小时。但之后，我想谷歌安全团队应该会对该漏洞感兴趣吧，于是，我就上报了该漏洞。最终，谷歌安全团队以高优先级方式在5小时之后确认了该漏洞，我也因此获得了$5000赏金。
第三个漏洞：Buganizer平台存在无访问权限验证机制导致可以查看任意上报漏洞
当你作为外部用户访问Buganizer平台（Issue Tracker）时，其实大部分功能是被剥离的，给你的权限非常有限， 而根据JavaScript文档中API服务端点可以发现，谷歌内部员工可以进行很多酷炫操作。这些操作功能对外部用户来说，很多都被完全禁用了，也有一些被简单地隐藏在接口之中。
在设计这个对外部用户有功能限制的系统时，开发者预留了邮件抄送列表的删除功能，也就是说，如果我们对某个漏洞问题不感兴趣而不需要对其状态进行关注时，那么该漏洞的状态信息将不会发送到我们的邮箱中。该抄送列表功能可以通过以下POST方式来实现：
POST /action/issues/bulk_edit HTTP/1.1 {
"issueIds":[
67111111,
67111112 ],
"actions":[
{
"fieldName":"ccs",
"value":"test@example.com",
"actionType":"REMOVE" }
]
} 但是，这种功能的实现却导致了严重的问题：
不当的访问控制规则：在尝试执行给定操作之前，对当前用户是否具备访问issueID中特定漏洞的权限无任何明确检查行为；
不报错机制：如果你提供的邮箱地址不在当前漏洞问题状态的邮件抄送列表中，客户端就会返回一条消息称该邮箱地址被成功删除；
返回消息中包含了完整的漏洞信息：如果在操作期间没有发生错误，系统的另一部分服务就会假设当前用户具备适当的操作管理权限，因此，那些特定ID的漏洞细节信息都会出现在返回的HTTP响应内容中。
根据以上存在的三个问题，我现在可以通过在请求中替换掉issueid来查看Buganizer平台数据库中每个漏洞的详细信息，超赞！
我只尝试性地查看了几个连续的漏洞ID，然后用一个无关帐户进行了验证，确认这个问题的严重性。是的，我可以看到漏洞报告的所有详细信息，包括Buganizer平台上托管的其他内容。更严重的是，我可以在单个请求中窃取到多个用户凭据的相关数据内容，因此，这样甚至可以无限制地实时监控Buganizer平台的所有内部活动！
我把该漏洞及时上报给了谷歌安全团队，他们在一小时之内紧急进行了修复，并禁用了相关存在漏洞的服务终端，好快的响应速度！我也因此获得了 $7500的赏金。
后记
当我第一次挖掘Buganizer平台的信息泄露漏洞时，我就认为这将会是“谷歌漏洞的圣杯”(Holy Grail of Google bugs)，因为Buganizer平台本身就是谷歌的漏洞跟踪管理系统，其一旦存在漏洞，攻击者就能访问谷歌产品中那些尚未修复的漏洞信息，进一步深入利用这些漏洞，会对谷歌自身和全球用户造成严重的安全影响。但幸运的是，谷歌安全团队第一时间就修复了Buganizer平台的漏洞，及时堵塞了漏洞，化解了风险。
*参考来源：medium，freebuf小编clouds编译