为何Uber漏洞赏金计划让我分文未赚

 

写在前面的话

根据Uber在HackerOne上发布的公开漏洞奖励计划，如果谁能够在Uber的应用程序或信息资产中发现一个安全漏洞的话，他们将至少奖励500美金。我自己平时也会带领一堆渗透测试人员来给企业客户进行安全培训，所以我打算来试试Uber的水。

 

挖洞过程

为了对Uber的信息资产进行安全分析，我花了好几天的时间收集了一些资源，并使用子域名枚举以及应用指纹等方式构建出了一个相对全面的Uber终端“地图”。我在对Uber的Android SDK进行了好几个小时的分析之后，我已经在ARM模拟器中完成了Uber APK的配置和运行了，这对我来说速度可真的是太慢了 …

经过分析之后，我成功地绕过了Uber .apk所绑定的安全证书，并且成功映射出了Uber移动端节点。由于网络流量中存在指向Microsoft Phone API的引用，所以我又进入了微软应用商城，然后对Uber的Surface/Windows Phone应用程序进行了安全测试。

研究后发现，它并没有采用任何的证书绑定机制，这就违反了Uber本身的安全应用机制，所以按理来说我应该可以得到这个至少500美金的漏洞奖励了吧？

Uber在其所有的移动端身份认证流中都使用了OAuth2令牌，而这种方法相较于之前基于Cookie的身份认证方式而言，其安全优势非常的大。我自己开发了一个基于Python的客户端，并用它来跟Uber的后台进行交互，然后收集OAuth2令牌来进行熵分析，因为我想看看他们所采用的伪随机数生成器存不存在安全问题。可奇怪的是，我所捕捉到的OAuth2令牌压根就不会发生任何变化，而且我在Uber的开发者文档中也没有找到任何关于令牌过期的问题。每次我所得到的令牌，都跟我第一次注册Uber测试账号时所得到的令牌“字面上”完全相同。无论我使用Surface应用程序登录和注销多少次，我所得到的令牌都是一样的。难道Uber要每隔几天才会去更新这些令牌吗？

我待会儿在讨论这个问题，我们先看看Uber的促销节点。由于这里既没有实现任何的多因素身份验证，而且也没有对推广代码POST请求进行任何类型的频率限制，因此这里存在两个非常明显的安全漏洞。换句话来说，这个漏洞将允许我利用一个HTTP加载测试套件来向这个节点发送无数次的推广代码POST请求，然后枚举出OAuth2令牌。只需要花几分钟的时间，我就能够枚举出超过一百万个OAuth2令牌，而且不会受到IP黑名单或请求频率的限制。

那么我们回到令牌过期这个问题上。如果我可以通过某种方法搞清楚Uber如何处理令牌过期的问题，那我就可以导出无数个OAuth2令牌，并使用某些可视化工具来对令牌模式进行分析，进而使用函数等数学方法来推测出有效的OAuth2令牌。但是这个Surface应用程序在处理注销事件时，并不会跟Uber的后台服务器进行交互，而我却能够在Surface应用程序注销之后使用我自己的OAuth2令牌来访问所有Uber乘客的终端。

这也就意味着，Uber的移动端应用程序是在本地处理注销操作的，而且没有部署任何类型的令牌过期以及验证机制。这是一个非常严重的安全问题，我现在终于知道为什么Uber的开发者文档里面没有提到任何关于令牌过期的问题了：因为当用户创建好一个Uber账户之后，Uber给用户发送的OAuth2令牌将永远不会过期，而Uber的移动端应用程序只会在客户端本地来处理注销事件。毫无疑问，这些严重的安全漏洞肯定符合公开CVE或OWASP对安全漏洞的定义，所以我把我所发现的问题提交到了HackerOne上，并希望能够得到漏洞奖金。

 

问题及回复

问题1：Uber的客户推广节点没有采用任何类型的多因素身份验证机制，这将导致攻击者能够枚举出成千上万名Uber司机以及乘客的OAuth2令牌。

问题2：Uber的客户推广节点没有采用任何类型的频率限制以及IP黑名单机制，这将导致攻击者能够枚举出成千上万名Uber司机以及乘客的OAuth2令牌。

问题3：Uber的Microsoft Surface/Phone应用程序没有采用证书绑定机制，而且还允许使用自签名的证书，而这违反了Uber自身的安全条例。

问题4：Uber的移动端应用程序只会在本地处理注销事件，这将导致OAuth2令牌永不过期，当用户登出了自己的Uber移动端应用之后，攻击者将能够访问司机以及乘客的账号。

而Uber安全团队的Rob Fletcher针对上述问题给我的回应却是：

问题1回复：Uber已经知道了这个问题，我们将会修复它，但没有奖金。

问题2回复：Uber已经知道了这个问题，我们将会修复它，但没有奖金。

问题3回复：Uber已经知道了这个问题，我们将会修复它，但没有奖金。

问题4回复：Uber目前还无法让已发布的OAuth2令牌过期，我们将会在我们的下一代身份验证框架中修复该问题，还是没有奖金。

但是目前为止，我已经花了一周左右的时间来尝试获取这个价值“高达”500美金的漏洞奖励，而我所发现的安全漏洞既没有被发布在Uber的漏洞奖励网站中，也没有记录在HackerOne的页面上，这就让我非常恼火了！

HackerOne的工作人员Kevin Rosenbaum给我的回复是：“我很抱歉，你所提交的漏洞没有通过审核，我们联系了Uber的应用安全团队，而他们并不认为你所提交的这些会成为安全问题，而且它们并不在Uber漏洞奖励计划的范畴之内。我知道这很令人沮丧，但我可以保证，他们已经查看了你的漏洞报告，并且会重视这个问题。我希望你能够继续帮助HackerOne找到更多的漏洞，祝你好运。”

非常好，现在打算给Uber来点猛料了，我准备演示一个更加严重的漏洞，让Uber没办法逃避我。

 

继续努力但毫无作用

经过进一步分析之后，我发现我能够从Uber的移动端节点https://m.uber.com 反射出查询参数。他们的内容安全策略包括一个针对*.cloudfront.net的白名单。我能够启动我亚马逊Web服务终端的Cloudfront，并托管任何我想要的JavaScript代码，并在https://m.uber.com 上执行这些代码。因此，我在Uber的内容安全策略中发现了两个严重的安全问题。当然了，我再一次将漏洞报告（一个反射型XSS+CSP问题）提交给了Uber。

除此之外，我还绕过了Uber OneLogin SSO门户，并成功获取到了Uber内部uChat雇员信息系统的源代码。虽然这个问题跟之前的相比没那么严重，但我还是将其写到了第二份漏洞报告中并提交给了Uber的安全响应团队。

而Rob Fletcher给我的回应是：“我们之后会对你所提交的漏洞进行二次审核，但目前来看这并不是一个安全漏洞。你所提交的漏洞并不能在现代浏览器中实现JavaScript执行，而且你所说的‘通过单引号实现任意文本生成’听起来就像简单的内容注入一样，它们都不在我们漏洞奖励的范畴之内。请你针对我们的漏洞奖励计划来提交相关安全报告，并对漏洞的安全性影响做出理论上的证明。”

如果我必须努力去证明一个应用程序或服务是多么地容易受到攻击，那我为什么不直接把漏洞利用信息卖给黑市呢？就因为我是一个白帽子吗？
而现在，HackerOne上的Uber漏洞奖励报告提交按钮已经变成这样了：

 

总结

1. Uber手上拥有美国以及其他国家数以千万计用户的GPS坐标定位数据，所以Uber信息资产的安全问题几乎相当于公众的安全问题。
2. 近期所有关于Uber企业文化的负面新闻在我看来都是真实的。
3. Uber并没有在安全方面做多大的努力，而且他们在HackerOne上发布的漏洞奖励计划纯粹是“瞎扯淡”。
4. HackerOne并不能保证厂商一定会支付“最少的漏洞奖金”，而且他们也不会为你的权益去跟厂商作斗争。