不合理的使用OAuth，导致账号被分分钟登录

扫码领资料

获网安教程

原文在此->Signing-Into-Billion-Mobile-Apps-Effortlessly-With-OAuth20(https://www.blackhat.com/docs/eu-16/materials/eu-16-Yang-Signing-Into-Billion-Mobile-Apps-Effortlessly-With-OAuth20-wp.pdf)。
译文在不改变原文的基础进行了部分调整。
术语：

• implicit flow(https://labs.hybris.com/2012/06/05/oauth2-the-implicit-flow-aka-as-the-client-side-flow/)

主流的身份提供商（IdP）使用OAuth2.0协议来支持单点登录服务。由于此协议最初设计用于满足第三方网站的授权需求，所以在使用OAuth来支持移动应用程序（app）身份验证时，研究人员已经发现了很多的缺陷。据我们所知，之前包括BlackHat USA'16 [3]，CCS'14 [2]和ACSAC'15 [5]提到的所有攻击都需要与受害者进行交互。例如通过恶意应用程序网络窃听等。但我们发现了第三方app开发人员不合理的使用OAuth导致的一种影响甚广的新型攻击手法，攻击者可以远程利用该攻击，悄无声息的登录受害者的app帐户。为了证明该漏洞的普遍性和严重影响，我们编写了一个exp来检测在美国和中国排名前600的android应用，这些应用都使用了顶级IdP（即Facebook ，Google或新浪）提供的基于OAuth2.0的身份验证服务。结果令人震惊：这些应用程序平均有41.21％容易受到新的攻击。我们已经向受影响的IdP汇报了我们的发现，并收到了他们不同形式的确认/奖励。

1. 介绍

由于第三方网站采用的基于OAuth2.0的单点登录（SSO）服务广受用户喜爱，最近，许多主流身份提供商（IdP）（如Facebook，Google和Sina）已经将OAuth2.0协议进行了调整，以在其社交媒体平台上支持第三方app的SSO。但由于移动应用程序SSO服务的端到端系统设置和操作环境的差异，原来的OAuth2.0协议不够用了。这一点尤其体现在OAuth2.0标准没有定义关键的安全要求和协议细节用来管理SSO过程中第三方（客户端）移动应用程序与其对应的后端服务器之间的交互。因此，各个IdP厂商基于OAuth2.0的应用程序编程接口（API）开发了不同的扩展用来以支持自己平台上的第三方移动应用程序的SSO服务。不幸的是，第三方移动应用程序开发人员无法完全理解IdP提供的文档，同时文档上也并未清晰的记录了可能的安全问题和API使用说明。更糟的是，第三方应用程序开发人员缺乏SSO-API的安全使用指南规范。

由于上述的问题，我们进一步对使用了顶级IdP服务的第三方移动应用程序进行了测试，发现了一种影响非常广的基于OAuth2.0的SSO服务的问题。这个问题的本质非常普通，仅仅是因为第三方应用的服务器在接受来自客户端app的授权信息不需经过认证，反过来看，这个漏洞其实是依赖于IdP客户移动app发送的信息被篡改所导致的。根据这个新发现的漏洞，我们写了exp，攻击者可以通过OAuth2.0 1毫不费力地登录受害者的移动应用程序帐户，而无需欺骗或与受害者进行交互，例如通过恶意应用程序或网络窃听等等。就目前来说我们的攻击是基于Android平台进行展示的，但攻击手法本身是平台无关的：只要使用了基于OAuth2.0的SSO服务的app，iOS或Android用户都会受到影响。

2. 背景

第三方移动应用的SSO服务细节涉及到四个部分：

• a. 第三方移动应用程序的后端服务器（app Server）

• b. IdP的后端服务器（IdP Server）

• c. 第三方移动应用（App）

• d. IdP的移动应用（IdP App）

OAuth的最终目的是让IdP服务器（IdP Server）向app Server发出身份证明，比如access token。通过access token，app Server可以获取到由IdP服务器管理的用户信息，并进一步根据该信息识别用户并授权登录。

图1描述了OAuth协议在网站和移动平台上实现的流程。为简单起见，我们首先介绍移动端OAuth实现的协议流程，然后指出与Web站点SSO服务的差异。请注意，由于OAuth不是为手机app设计的，所以RFC和IdP不会为第三方移动应用程序开发人员提供完整的调用流程图。尽管如此，但早已有研究员针对移动端的OAuth安全方面投入了大量的精力[2,3,5,6]，一个被认为是安全的实施方案如下：

1. 用户访问app，并尝试通过IdP进行登录。app通过手机操作系统（Android）提供的安全通道将应用信息（如包名，签名和请求的权限等）发送给IdP的客户端。

2. 通过调用低级系统API，IdP客户端（IdP app）可以验证app的应用信息。如果信息无误，那么IdP客户端（IdP app）会向IdP服务器（IdP Server）发送授权请求。

3. IdP Server收到请求后，会比较来自IdP客户端（IdP app）的授权请求的信息和由第三方移动应用开发者预先注册的信息。如果相同，则IdP服务器（IdP Server）将通过自己的IdP客户端（IdP App）向第三方手机客户端（app）发出access token（AT）和可选的用户信息。

4. IdP app通过安全通道将access token（AT）返回给app（第三方客户端应用程序）。

5. 第三方客户端应用程序（app）将AT发送到其后端服务器（app Server）。

6. 第三方后端服务器（app Server）调用由IdP提供的重要安全SSO-API来调试access token。

7. 在验证access token的有效性之后，IdP服务器（IdP Server）会向第三方应用服务器（app Server）发送授权信息，同时指明access token发给哪个app。

8. 只有在授权信息正确的情况下，第三方应用服务器（app Server）才能通过access token获取用户数据。

9. IdP服务器（IdP Server）返回与access token关联的用户信息。

10. 通过用户信息，第三方应用程序服务器（app Server）可以识别用户并授权登录。

由于OAuth2.0最初是为授权而设计的，为了适应认证需求，这就涉及了多次高延迟的请求，即图1（b）的步骤6到步骤9。为了更好地支持使用OAuth2.0进行身份验证（即减少请求次数），像Google和Facebook这样的IdP开发了OpenID Connect（OIDC）协议[4]和拓展。具体而言，IdP服务器需要对用户信息进行数字签名。如图2所示，签名的用户信息以及原始的access token，随后会被发送到app Server（第三方移动应用程序的后端服务器）。由于签名不能被攻击者篡改/伪造，app Server现在可以通过签名直接识别用户。换句话说，app Server可以立即从签名中提取用户信息，而不需要进行高延迟的API调用。

从图1所示的协议实现流程图去看，网站和移动端的差异看起来似乎很简单，但实际上正是因为这种简单的不同，导致重要的安全结论并促使OAuth在移动平台上实现的复杂化。可以看到在网站使用OAuth过程中，有三个部分在交互：
（i）第三方web服务器（Client Server）
（ii）IdP的后端服务器（IdP Server）
（iii）终端用户的浏览器（Browser），要求能够支持第三方网站OAuth2.0的SSO。
而之前聊到过的移动端SSO交互过程，却涉及到了4个部分（a、b、c、d）。首先，（c）和（d）都在用户设备上运行，并且可能被篡改。其次，OAuth2.0协议标准并未涉及到（a）和（c）以及（c）和（d）之间的交互和安全问题。第三，在同一用户设备上可能同时存在（c）和（d），第三方移动应用程序开发人员可能会忍不住直接在（c）和（d）之间进行认证交换（恰好与（a）和（b）之间的直接验证相反，就像OAuth2.0标准中定义的（i）和（ii）之间的直接验证交换一样）。这里再看一个例子，与web服务供应商不同，IdP供应商要求移动应用程序开发人员在OAuth中使用与IdP特定业务逻辑（即授权代码流与隐式流）紧密相关的授权流程，即授权码流程vs无授权码流程（参考文章第二段第二句话implicit flow）。此外，典型的移动应用程序的客户端负责更多的消息交换，相反，在第三方网站（及其相应的web服务）的情况下，这些消息是由后端服务器管理。

3. 不同的错误实现形式

尽管平台之间差异巨大，但IdP没有提供明确的开发手册来降低OAuth用于移动端可能发生的隐患。所以，第三方移动应用程序开发人员早就犯了各种各样的错误，比如下面这些：

1. 如图3（a）所示，当IdP服务器会返回用户信息和OAuthaccess token（例如，用户ID /电子邮件地址）时，许多第三方应用的后端服务器根据收到的用户信息来授权登录，而不验证收到的用户信息是否真的绑定到已发布的OAuth access token。

2. 图3（b）显示了Facebook和Google采用OpenID Connect协议的另一种情况。在这种情况下，IdP需要对用户信息进行数字签名，以便第三方应用的后端服务器可以通过签名验证来对用户进行鉴别。但是，某些第三方应用程序根本不验证此签名，只从签名中提取用户ID，然后不验证ID就将其作为身份证明。

3. 还有些第三方移动应用程序直接从其正在运行的移动设备获取用户信息，直接忽视IdP接收到的OAuth token。（例如，图4(a)所示的IdP服务器提供API，应用通过调用获取用户信息或图4(b)所示设备上有个账户系统存储了用户Google账户信息，可以用来支持SSO服务）。移动应用程序仅将用户标识符作为身份证明发送到其后端服务器。如果没有access token，第三方后端服务器无法验证返回的用户标识符是否绑定了OAuth access token。

4. 漏洞利用

因为第三方应用程序开发人员的不规范开发，攻击者可以利用受害者信息登录到存在问题的app，这一切只需要下面这些步骤：

1. 如图5所示，攻击者在自己的移动设备上启用了ssl的MITM代理（比如mitm-proxy），监控往来的网络流量。

2. 攻击者在自己的移动设备上安装了易受攻击的第三方应用程序。

3. 攻击者通过自己的IdP用户密码，用OAuth登录了易受攻击的移动应用程序。

4. 在步骤3触发的OAuth消息交换过程中，攻击者通过ssl的MITM代理将受害者的用户标识替换为自己的用户标识（IdP或电子邮件地址中的用户标识）。受害者的用户ID是可公开获得的信息（信息来源于受害者公开网页，比如G+和新浪），一般也易于猜测（前提是使用电子邮件地址作为用户名的情况下）。虽然自2014年5月以来Facebook已经开始为每个第三方应用程序发布独立用户ID，但为了向后兼容，Facebook仍然使用公共用户标识来识别第三方应用程序的早期使用者。所以，只要用户在2014年5月之前通过OAuth登录过应用程序，那么即使用最新版本应用程序，仍容易受到攻击。

5. 由于第三方后端服务器直接使用客户端应用程序返回的用户身份证明来标识app用户，因此攻击者可以用受害者的身份登录app，并且在大多数情况下拥有完整的权限访问第三方app服务器管理的受害者敏感信息。
   

除了受SSL / HTTPS保护外，应对第三方移动应用程序的客户端与其后端服务器之间的消息交换进行加密或签名。否则的话，篡改IdP服务器返回的用户标识信息是很容易的。

在IdP客户端应用程序（例如Facebook的应用程序）应用证书锁定的情况下，如果攻击者通过MIMT代理篡改了IdP服务器发送给其客户端应用程序的消息，那该消息不会被接受。那攻击者该如何继续攻击？这儿有一种解决思路，通过卸载IdP客户端应用程序，以便IdP SDK（通常是由OAuth2.0第三方移动应用程序广泛使用）将自动降级，然后通过内置webview浏览器进行OAuth身份验证。对于常见的内置浏览器来说，webview不支持特定IdP的证书锁定。所以，攻击者又能继续篡改消息了。

除了IdP不支持基于webview的OAuth授权情况，还有一些其他的情况。对于这些情况下的IdP来说，攻击者可以使用现成的工具，如SSLUnpinning（如果他们使用原生的Android框架来实现证书锁定），或对IdP客户端应用程序进行逆向来达到手动删除证书锁定的目的（前提是他们使用了cutomized方法）。为了解释这种方法的可行性，我们已成功地在Facebook的app上进行了poc验证，通过手动禁用其证书锁定功能，以便我们通过ssl-enabled-MITM代理为app提供假的用户标识信息。

5. 现实的惨状

我们研究了由三家顶级IdP（即新浪，Facebook和Google）提供的基于OAuth2.0的API，这三家IdP支持全球许多第三方移动应用的SSO服务。如表1所示，这些IdP的注册用户数量从8亿以上到超过25亿。由于支持SSO服务的中国app越来越多，所以我们选择了使用了新浪服务的Top200移动应用程序，另外选择了Top400使用了Google和Facebook服务的移动应用程序。接着我们识别出使用了多个IdP的SSO服务的应用程序，最后使用基于OAuth2.0开发的exp进行测试。结果令人担忧：平均有41.21％的被测移动应用容易受到新的攻击。表2列出了目前为止识别出的易受攻击app中的一部分：这张不完整的列表已经包含两个排名前五的旅行计划app，一个受欢迎的旅馆预订应用程序，一个为情侣/合作伙伴设计的顶级私人聊天应用程序，一个排名前5的约会应用程序，两个顶级的个人金融应用程序，以及其他流行的视频或网上购物应用程序，这里仅列举几例。请注意，这张不完整列表所包含的流行app，总下载量已经超过24亿次。根据Janrain [1]最近的调查，以51％的SSO用户采用率进行保守估计的话，截至撰写本文时，有超过10亿的不同类型的移动应用账号容易受本文所讲述的攻击。

攻击者通过exp登录受害者手机应用账号，并且大多数情况下他们是拥有完整的权限，能够访问受害者的隐私，尽管这些信息由被黑app的服务器管理。单纯是针对表2中列出的易受攻击的应用程序，我们可以通过漏洞获取大量极其敏感的个人信息：包括详细的旅行行程，个人/亲密通信档案，家庭/私人照片，个人财务记录以及受害者的观看或购物历史。对于某些特殊的app来说，攻击者甚至可以随意操作与受害者账户相关联的线上货币。

6. 建议

我们的研究已经展示了这个问题的危害性，对于第三方开发来说在实现或使用基于OAuth2.0的服务时应采取如下措施进行补救：

1. IdP应该提供基于OAuth2.0的SSO API更清晰、更侧重安全性的使用准则。

2. app的后端服务器不应该信任任何信息，即使信息被app或IdP的app签了名。最好只相信来自IdP服务器的信息。

3. IdP不应依赖全球用户标识符来进行第三方应用程序认证/授权，而应根据每个移动应用程序发布私人用户标识符。事实上，自2014年5月以来，Facebook已经采用了这种做法。但是，Facebook仍然坚持在2014年5月之前用户开始使用移动应用程序的全球用户标识符。因此，对于易受攻击app的老用户来说，攻击仍存在。

4. IdP应对第三方移动应用程序进行更加全面的安全测试，特别是通过OAuth2.0或其他类似协议（如OpenID Connect（OIDC）协议）实施单点登录服务这块。

7. 结论

本文中，我们已经确定了一个以前未知的漏洞，攻击者无需交互就能利用这个漏洞劫持受害者的移动应用账户。我们已经检查了美国Top200的app和中国Android app情况，当然这些app都是使用了三家顶级IdP的OAuth2.0授权服务。同时我们展示了这些流行应用程序在多大程度上会受到这种新漏洞的攻击。我们的发现表明，各方迫切需要重新审视他们的SSO实施并据此采取补救。

8. 引用

[1] “Social login continues strong adoption,” 2014. [Online]. Available:

http://janrain.com/blog/social-login-continues-strong-adoption/

[2] E. Y. Chen, Y. Pei, S. Chen, Y. Tian, R. Kotcher, and P. Tague, “OAuth demystified for mobile application developers,” in Proceedings of the 2014 ACM SIGSAC Conference on Computer and Communications Security. ACM, 2014.

[3] C. Eric, P. Tague, R. Kotcher, S. Chen, Y. Tian, and Y. Pei, “1000 ways to die in mobile OAuth,” in BlackHat USA, 2016.

[4] N. Sakimura, J. Bradley, M. Jones, B. de Medeiros, and C. Mortimore, “OpenID Connect core 1.0,” The OpenID Foundation, p. S3, 2014.

[5] H. Wang, Y. Zhang, J. Li, H. Liu, W. Yang, B. Li, and D. Gu, “Vulnerability assessment of OAuth implementations in Android applications,” in Proceedings of the 31st Annual Computer Security Applications Conference. ACM, 2015.

[6] Q. Ye, G. Bai, K. Wang, and J. S. Dong, “Formal analysis of a Single Sign-On protocol implementation for Android,” in 20th International Conference on Engineering of Complex Computer Systems, ICECCS 2015, 2015.

来源: https://xz.aliyun.com/t/1526

声明：⽂中所涉及的技术、思路和⼯具仅供以安全为⽬的的学习交流使⽤，任何⼈不得将其⽤于⾮法⽤途以及盈利等⽬的，否则后果⾃⾏承担。所有渗透都需获取授权！