首先我们来看一下QRLJacking的实际原理：.攻击者首先进行客户端QR会话，并将登录QR码复制到网络钓鱼网站。“现在，一个精心制作的网络钓鱼页面有一个有效和定期更新的QR码可以被发送给受害者。”
本文作者：gh0stkey
前言
某天晚上，key在研究了一下朋友圈在传的QQ点击劫持，直接导致QQ冻结24小时。然后我们一起交流着聊着聊着扯到了二维码劫持这个话题上，发现国内也没有一些实战性的文章，所以针对微信展开了二维码劫持的实战。（顺便让我安静的做个小小的标题党）
原理
首先我们来看一下QRLJacking的实际原理：
1.攻击者首先进行客户端QR会话，并将登录QR码复制到网络钓鱼网站。“现在，一个精心制作的网络钓鱼页面有一个有效和定期更新的QR码可以被发送给受害者。”
2.攻击者将钓鱼页面发送给受害者。
3.受害者使用特定目标移动应用扫描QR码。
4.攻击者获得受害者帐户的控制权。
5.该服务正在与攻击者的会话交换所有受害者的数据。
这个原理的缺陷在于 -> 攻击者需要打开客户端QR会话，所以就只能进行1V1的实时性攻击，缺陷较大。
而我们实验室的成员在交流的时候发现其实可以实时撒网式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/jslogin
POST正文：
appid=wx782c26e4c19acffb&fun=new&lang=zh_CN
返回结果：
2. 获取的uuid与链接https://login.weixin.qq.com/qrcode/组合-> https://login.weixin.qq.com/qrcode/ob8jLaxD6Q==
返回结果：
aHR0cHM6Ly9sb2dpbi53ZWl4aW4ucXEuY29tL2wvb2I4akxheEQ2UT09 (二维码自动识别)
（这就是二维码的地址）
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:
前端用ajax请求后端 将返回的结果转换为Javascript表达式
当全局里面的code为408的时候说明没有扫描
继续递归调用当前函数
当全局里面的code为400的时候说明二维码过期了
自动刷新当前界面获取新的二维码
当全局里面的code为201的时候说明扫描成功了
但没有在移动终端点击确认 将返回的用户头像渲染到界面中 继续递归调用当前函数
当全局里面的code为200的时候说明用户在移动终端点击确认了
这时候将返回的redirect_uri传入到后端 接着跳转返回的redirect_uri
扫描成功时调用的route:
钓鱼实践
You died.戏剧性的是这里key自己日了自己了，奶权并没有上当~
研究人员gh0stkey 来自米斯特安全攻防实验室 @ 奶权 & vulkey
参考资料：