漏洞概要 关注数(24) 关注此漏洞
缺陷编号：wooyun-2013-017306
漏洞标题：啪啪任意进入他人账号（OAuth 2.0无绑定token问题）
相关厂商：啪啪
漏洞作者： horseluke
提交时间：2013-01-14 18:32
修复时间：2013-02-28 18:32
公开时间：2013-02-28 18:32
漏洞类型：设计错误/逻辑缺陷
危害等级：中
自评Rank：10
漏洞状态：厂商已经确认
漏洞来源： http://www.wooyun.org，如有疑问或需要帮助请联系 [email protected]
Tags标签： 无
漏洞详情
披露状态：
2013-01-14： 细节已通知厂商并且等待厂商处理中
2013-01-15： 厂商已经确认，细节仅向厂商公开
2013-01-18： 细节向第三方安全合作伙伴开放
2013-03-11： 细节向核心白帽子及相关领域专家公开
2013-03-21： 细节向普通白帽子公开
2013-03-31： 细节向实习白帽子公开
2013-02-28： 细节向公众公开
简要描述：
啪啪的移动端安全其实是不错的，只是碰巧在OAuth 2.0协议的实现上躺枪了。囧，OAuth 2.0还有多少个坑大家还得中啊？Eran Hammer，你画圈圈诅咒千万别应验......
此案例在公开后，各开放平台、以及依赖各OAuth平台登录的客户端开发者（典型如手机应用）可以注意一下。理论上，遇到此问题的概率不甚大，至少我半个多月断断续续地大海捞针，才找到一两家存在此问题。
详细说明：
该漏洞原型可见2012年6月份由微软研究组报给IETF的邮件安全案例：http://www.ietf.org/mail-archive/web/oauth/current/msg09270.html
在OAuth协议上，该漏洞分属OAuth 2.0无绑定token问题：由于OAuth 2.0的“无绑定token”特性（http://zone.wooyun.org/content/674 ），导致第三方应用在使用平台方的OAuth 2.0授权（authorize）作为自身应用的认证（authenticate）手段时，缺乏一种有效的认证传递校验和来源检查，从而导致只需要拥有B应用的access token，即可登录到A应用所绑定的服务中。
在漏洞本质上，该漏洞分属于认证交换的信任检查问题：当攻击者给出一个认证凭据时，如果服务器没对此认证凭据进行来源等校验，那么攻击者就能成功完成认证交换，从而造成问题。（可以类比“xss盲打后台获得cookies登录”来理解）
啪啪手机客户端极度依赖OAuth平台登录，因此它就容易产生这种问题。啪啪的登录流程可简化如下：
（1）用户点击用新浪微博或者QQ登录，将弹出OAuth平台方的授权页面
（2）用户点击授权后，啪啪客户端获得OAuth平台方给出的access token
（3）啪啪客户端将此access token上报给api.papa.me接口，以获取啪啪的认证字符串
（4）啪啪得到此认证字符串后，即有权限操作绑定的啪啪数据。
那么这个问题就在于，如果有方法可以恶意替换OAuth平台方给出的access token，那是否就以进入他人的啪啪账号？实验证明，是可行的。
漏洞证明：
由于啪啪的代码混淆得比较多，个人时间上不允许进行全脱离模拟，所以在这里也只是在传输过程取了个巧，证明问题就可以了。
（1）配置fiddler2，使得android模拟器等一定可以解密微博api的数据；
（2）在网页端上，以A账号在X应用获取access token H。
（3）在手机上安装啪啪客户端；fiddler设置为返回拦截。
（4）启动啪啪，点击用新浪微博登录，在弹出OAuth平台方的授权页面上输入B账号，并点击授权
（5）在fiddler中，可以找到B账号在啪啪应用获取的access token I。
修改拦截内容，变成A账号在X应用获取到的access token H。
（6）登录到A账号成功。
修复方案：
危害性：
这个漏洞主要危害那些存在认证传递和交换的服务，目前比较常见的场景是用OAuth登录到自家的服务中可能会有这个疏漏。
就啪啪而言，综合认定为“中高”。原因如下：
（1）要获取用户的access token很容易，只需要注册第三方应用并诱导用户授权即可；
（2）定向攻击的最终成功率极高。
（3）啪啪的用户基数大。
（4）是否有用于access token的来源查询、证明或签名校验，要视乎开放平台的提供情况。如果有，只需要在服务器端修复即可解决此问题。
修复建议：
（1）手机客户端有关认证交换的主体部分，一定要有一个服务器把关，这是最基础的。
（2）手机服务器端在接收手机客户端的access token来对换取自家服务的认证凭据时，必须对access token进行来源查询、证明或签名校验。
具体而言，已查证的国内各开放平台已知的接口文档如下：
（A）新浪微博开放平台“授权查询”：
http://open.weibo.com/wiki/Oauth2/get_token_info
（B）QQ登录：通用参数中似乎已经进行了此问题的防御（时间问题未验证）：
http://wiki.opensns.qq.com/wiki/%E3%80%90QQ%E7%99%BB%E5%BD%95%E3%80%91OpenAPI2.0%E8%B0%83%E7%94%A8%E8%AF%B4%E6%98%8E#2._.E8.B0.83.E7.94.A8OpenAPI.E6.8E.A5.E5.8F.A3
（C）百度开放平台“判定当前用户是否已经为应用授权”（此接口本人未验证是否可防御此问题，请咨询百度开放平台）：
http://developer.baidu.com/wiki/index.php?title=docs/oauth/rest/file_data_apis_list#.E5.88.A4.E5.AE.9A.E5.BD.93.E5.89.8D.E7.94.A8.E6.88.B7.E6.98.AF.E5.90.A6.E5.B7.B2.E7.BB.8F.E4.B8.BA.E5.BA.94.E7.94.A8.E6.8E.88.E6.9D.83
（D）人人网“判断用户是否已对App授权”（此接口本人未验证可否可防御此问题，请咨询人人开放平台）：
http://wiki.dev.renren.com/wiki/Users.isAppUser
其它开放平台，建议进行相关问题的咨询。
版权声明：转载请注明来源 horseluke@乌云
漏洞回应
厂商回应：
危害等级：中
漏洞Rank：8
确认时间：2013-01-15 09:52
厂商回复：
十分感谢 horseluke 对啪啪安全方面的贡献, 已经确认这个漏洞是我们考虑不周全导致.
最新状态：
暂无
漏洞评价：
评论
-
OAuth对于初学者来说很混乱，换来换去的key，token啥的，洞主考虑给drops投稿不？
-
@horseluke 不搞未来搞现在啊
-
@horseluke 实践才是真理啊
-
@Claud 干嘛不发乌云
-
@疯狗 @xsser 找马甲胖投稿啊，剑心你懂的
-
感谢分享~
( 实习白帽子 | Rank:44 漏洞数:2 | 阅尽天下漏洞，心中自然无码。)