研究产出时间：2017年08月17日

相关作者：奶权 & key

前言

实验室内一起交流技术，聊着聊着扯到了二维码劫持这个话题上，发现国内也没有一些实战性的文章，所以针对微信展开了二维码劫持的实战。（顺便让我安静的做个小小的标题党）

原理

首先我们来看一下QRLJacking的实际原理：

1.攻击者首先进行客户端QR会话，并将登录QR码复制到网络钓鱼网站。“现在，一个精心制作的网络钓鱼页面有一个有效和定期更新的QR码可以被发送给受害者。”
2.攻击者将钓鱼页面发送给受害者。
3.受害者使用特定目标移动应用扫描QR码。
4.攻击者获得受害者帐户的控制权。
5.该服务正在与攻击者的会话交换所有受害者的数据。

这个原理的缺陷在于 -> 攻击者需要打开客户端QR会话，所以就只能进行1比1克隆的实时性攻击，缺陷较大。

而我们实验室的成员在交流的时候发现其实可以实时撒网式QRLJacking（命名为：Netting-QRLJacking），恰好之前研究过微信的WEB协议，所以这里拿微信来当作“实验靶机“。

Netting-QRLJacking的原理如下：

1.攻击者首先精心制作一个网络钓鱼页面，钓鱼页面获取真实页面的二维码。
2.攻击者将钓鱼页面发送给受害者。
3.受害者使用特定目标移动应用扫描QR码。
4.攻击者后台获得受害者帐户的认证链接。
5.攻击者打开认证链接后直接控制受害者的微信权限。

协议分析
因为写过微信机器人，所以第一时间想起了wxpy这个神奇的模块，不过很有意思的写第一条命令的时候就遇到挫折：

from wxpy import *bot = Bot()

Bot()需要执行完之后才会执行下一条代码，但是我用的Flask框架的代码就无法执行。
那怎么办？只能自己去分析微信QR快速登陆的WEB协议：

1. 获取UUID

这个uuid是一个很关键的东西，我们可以通过接口去获取：

接口：https://login.weixin.qq.com/jsloginPOST正文：appid=wx782c26e4c19acffb&fun=new&lang=zh_CN

返回结果：

2. 获取的uuid与链接https://login.weixin.qq.com/qrcode/组合-> https://login.weixin.qq.com/qrcode/ob8jLaxD6Q==

返回结果：

3. 监听接口https://login.wx.qq.com/cgi-bin/mmwebwx-bin/login?loginicon=true&uuid=uuid&tip=1&r=855749254&_=1502382803479
GET请求参数中的uuid也就是上面的uuid，正常组合就行。

这个监听接口打开，只要有人扫描2的二维码那么就会返回消息：

这个返回的其实就是微信头像而已：

真的只是头像而已么？有心的人已经注意到了最开始有一个window.code=201，这个window.code=201是扫描成功后会返回的，而如果二维码时效性过期就会返回window.code=400。

window.userAvatar是头像，window.redirect_uri是用户凭证链接（这里只要我们点开链接直接可以进入用户微信WEB界面进行任意操作）

代码编写
这里使用一个能够快速开发flask的框架来完成
首先定义一个index的route当用户访问index时调用获取uuid的接口将其渲染到模板中：

模板获取后端传过来的uuid，并用img标签去调用获取二维码的接口 在客户端上显示出来，紧接着轮询二维码扫描的API，并且判断各种情况尽可能实现地和微信一样，前端轮询代码：

二维码扫描的route：

代码逻辑：

0. 前端用ajax请求后端，将返回的结果转换为Javascript表达式
1. 当全局里面的code为408的时候说明没有扫描，继续递归调用当前函数
2. 当全局里面的code为400的时候说明二维码过期了，自动刷新当前界面获取新的二维码
3. 当全局里面的code为201的时候说明扫描成功了，但没有在移动终端点击确认，将返回的用户头像渲染到界面中，继续递归调用当前函数
4. 当全局里面的code为200的时候说明用户在移动终端点击确认了，这时候将返回的redirect_uri传入到后端，接着跳转返回的redirect_uri

扫描成功时调用的route:

钓鱼实验

投放诱饵

受害者咬钩

成功劫持账户

参考资料
https://www.owasp.org/index.php/Qrljacking
http://wxpy.readthedocs.io

本文始发于微信公众号（米斯特安全团队）：微信Netting-QRLJacking分析利用-扫我二维码获取你的账号权限