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

阅读量161583

|评论1

|

发布时间 : 2017-12-27 10:01:28

x
译文声明

本文是翻译文章,文章原作者 Gregory Perry,文章来源:medium.com

原文地址:https://medium.com/bread-and-circuses/how-i-got-paid-0-from-the-uber-security-bug-bounty-aa9646aa103f

译文仅供参考,具体内容表达以及含义原文为准。

 

写在前面的话

根据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并不能保证厂商一定会支付“最少的漏洞奖金”,而且他们也不会为你的权益去跟厂商作斗争。
本文翻译自medium.com 原文链接。如若转载请注明出处。
分享到:微信
+10赞
收藏
WisFree
分享到:微信

发表评论

内容需知
  • 投稿须知
  • 转载须知
  • 官网QQ群8:819797106
  • 官网QQ群3:830462644(已满)
  • 官网QQ群2:814450983(已满)
  • 官网QQ群1:702511263(已满)
合作单位
  • 安全客
  • 安全客
Copyright © 北京奇虎科技有限公司 360网络攻防实验室 安全客 All Rights Reserved 京ICP备08010314号-66