吐槽 | 为何Uber的漏洞奖励计划让我一分钱没赚到?

2017-12-29 216661人围观 ,发现 9 个不明物体 WEB安全

根据Uber在HackerOne上发布的公开漏洞奖励计划,如果有人可以在Uber的应用程序或在线服务中找到安全漏洞的话,Uber将至少给这个人奖励500美金。近些年来,我一直在给企业客户进行渗透测试培训,因此我准备尝试看看能否找到Uber的漏洞。

1.png

寻找漏洞

在对Uber的客户端以及在线服务进行安全分析,我花了好几天的时间收集了一些资源,然后利用子域名枚举以及应用程序指纹构建出了比较全面的Uber节点地图。接下来我又对Android SDK进行了分析,并且花了好几个小时才在ARM模拟器中成功运行了Uber的Android端应用,确实是有点慢了…

经过了研究和分析之后,我成功绕过了Uber的APK所绑定的安全证书,并且成功映射出了Uber的移动端节点。因为我在APK的网络流量中发现了指向Microsoft Phone API的引用,所以我来到了微软的应用商城,然后对Uber的Surface/Windows Phone应用程序进行了分析测试。

经过研究后发现,Uber的移动端应用并没有实现任何的证书绑定机制,这已经违反了Uber本身的安全机制,因此按理来说我至少能够拿到500美金的漏洞奖励了吧!

Uber在所有的移动端身份认证流中都使用了OAuth2令牌,而跟基于Cookie的身份认证机制相比,这种技术要更加的安全。我自己写了一个Python客户端,它可以跟Uber的后台进行交互,然后收集OAuth2令牌来进行熵分析,因为我想看看他们所采用的伪随机数生成器有没有安全漏洞。

可奇怪的是,我获取到的OAuth2令牌一直都没有改变过,而且我在Uber的开发者文档中也没有找到任何关于令牌到期的问题。所以我每次得到的令牌,都跟我在第一次注册Uber账号时所得到的令牌完全一样。无论我使用Surface应用程序进行多少次登录和注销,我得到的令牌都是一样的。难道Uber不会更新这些令牌的吗?

我待会儿再跟大家讨论这个问题,我们先来看看Uber的营销推广节点。由于该节点既没有实现任何形式的多因素身份验证,也没有对推广代码的POST请求进行任何类型的频率限制,因此这里存在两个非常明显的安全漏洞。也就是说,攻击者将能够利用这个漏洞并配合HTTP测试工具来向这个节点发送无数次POST请求,然后枚举出OAuth2令牌。在测试的过程中,我只需要几分钟的时间就能够枚举出超过一百万个OAuth2令牌,而且还不会被IP黑名单或请求频率所限制。

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

这也就意味着,Uber的移动端应用程序是在本地处理注销操作的,而且没有采用任何类型的令牌到期以及身份验证机制。这是一个非常严重的安全问题,我现在终于知道为什么Uber的开发者文档里面没有提到任何关于令牌到期的问题了:因为当用户创建好一个Uber账户后,Uber给用户发送的OAuth2令牌永远都不会到期,而Uber的移动端应用程序只会在本地处理注销行为。因此这些安全问题应该符合CVE或OWASP对安全漏洞的定义,所以我把这些问题提交到了HackerOne上,以期够拿到漏洞奖金。

2.png

报告及厂商回复

问题1:Uber的营销推广节点没有实现多因素身份验证机制,这将导致攻击者能够枚举出成千上万名Uber司机及乘客的OAuth2令牌。

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

问题3:Uber的MicrosoftSurface/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的安全性,它们并不在Uber漏洞奖励范畴之内。我知道这很令人沮丧,但Uber已经查看了你的漏洞报告,并且会重视这个问题。我希望你能够继续帮助HackerOne完成更多的漏洞项目,祝你生活愉快。”

我恼火了!现在打算给Uber演示一个更加严重的漏洞。

3.png

努力并不一定会有结果

通过进一步分析之后,我发现我能够从Uber的移动端节点https://m.uber.com反射出查询参数。他们的内容安全策略中包括一个*.cloudfront.net白名单。因此,我能够启动我亚马逊Web服务终端的Cloudfront,并托管任何我想要的JavaScript代码,然后最终在https://m.uber.com上执行这些代码。简而言之,除了内容安全策略中的那个问题之外,我又发现了一个反射型XSS,并将它们一并提交给了Uber。

除此之外,我还绕过了Uber OneLogin SSO门户网站的验证机制,并成功获取到了Uber内部uChat员工信息系统的源代码。虽然这个问题跟之前的相比没那么严重,但我还是将其写到了第二份漏洞报告中一并提交给了Uber。

但Rob Fletcher这一次给我的回复如下:

“我们接下来会对你所提交的漏洞再次进行审核,但就目前的情况来看,你所提交的漏洞并不能在现代浏览器中实现JavaScript执行,而且你所说的‘通过单引号实现任意文本生成’听起来就像是简单的内容注入攻击一样,它们都不在我们的漏洞奖励范畴之内。请你按照我们的漏洞奖励计划来提交相关安全报告,并对漏洞的安全性影响做出理论上的论证。”

如果我必须努力去证明一个应用程序或服务是多么地容易受到攻击,那我干嘛不直接把漏洞利用方式卖给犯罪分子拉倒?

而现在,HackerOne上的Uber漏洞奖励报告提交按钮已经变成这样了:

4.png

总结

1.   Uber拥有美国以及其他国家数以千万计用户的GPS定位数据,所以Uber的安全问题几乎成为了公众的安全问题。

2.   近期所有关于Uber企业文化的负面新闻都是真的。

3.   Uber并没有像他们所声称的那样在安全方面做出了多大的努力,而且他们在HackerOne上发布的漏洞奖励计划纯粹是个摆设。

4.   HackerOne并不能保证厂商一定会支付其声明的“最少漏洞奖金”,而且他们也不会为了保护白帽子的利益而去跟厂商撕破脸。

* 参考来源:medium,FB小编Alpha_h4ck编译,转载请注明来自FreeBuf.COM

这些评论亮了

  • 周杰伦 回复
    一天就知道吐槽厂商怎么怎么的 但事实上发的确实是辣鸡漏洞
    )22( 亮了
发表评论

已有 9 条评论

取消
Loading...
css.php