登陆 注册

滑动验证码攻防对抗

CDL路飞 2020-02-10 安全文摘

续上篇,实战笔记之X厂滑动验证码漏洞挖掘

关键字:接口XSS、重复校验、灰黑产识别

阅读简介:第二节,绕过和攻击

                 第三节:风控防御

一、背景介绍  

    在业务安全领域,滑动验证码已经是国内继,传统字符型验证码之后的标配。众所周知,打码平台和机器学习这两种绕过验证码的方式,已经是攻击者很主流的思路,不再阐述。冷渗透介绍的是一个冷门的绕过思路和防御方案。这些积累,均来自于实战之中,希望有用。

二、黑产攻击者

知己知彼,百战不殆。

如果不清楚攻击者的手段,又如何能制定防御方案?

1. 滑动验证码绕过思路

漏洞名字:session参数重复校验漏洞

思路介绍:

    此思路来源于一次对黑产路径的溯源复现,由于每次拖动滑块后,会发送一个Request请求数据包到服务器,服务器会验证这个Request请求数据包里携带的位移参数,来判断是否是拖动滑块到了正确的缺口位置。而服务器接收的数据包有很多,除了你发送的,也还会有其他人发送的请求,所以需要一个session参数来作为标识。本文中的"rid"值就是一个session标识。

    其中"rid"值是加引号的,因为它只是一个参数。针对不同的滑动验证码厂商,可能参数命名不一样。


漏洞详情:

    在用户客户端完成一次正确的验证码滑动后,发送到服务器的session参数,会在服务器后端,默认隐含生成一个有效时间和一个有效次数的值。前提条件是正确的滑动。想想这里会不会存在问题?

    曾在黑盒测试中发现,有的滑动验证码厂商的后端逻辑设计存在缺陷,一个session参数的有效时间是10分钟,有效使用次数是5次。那么如何利用呢?这是我在风控后台的真实业务环境下,挖掘到的一条黑产绕过滑动验证码的手法。


思路剖析:

①首先,触发滑动验证机制,如下图类似。

②接着,滑动滑块到正确缺口位置,然后抓包。

    分析数据包,寻找session参数。通过测试找到"rid"值为session参数。

    这里再强调一下,不同的厂商开发的代码,可能对session参数命名不一样。比如下图,"sessionId"值是另一家厂商的session参数,需要我们去分析判断。

③每次滑动正确位移后,使用Brupsuite或者其它中间人代理工具,抓包提取数据包里的session参数("rid"值),保存到本地。

    因为服务器后端默认隐含对我们本地保存的session参数有一个有效时间和有效次数,所以我们不需要再去滑动验证码,直接在session的有效期内发送Request请求数据包到服务器即可验证成功!

④上述操作,我用python编写了一个小工具使其流程化。全自动化过程:调用打码平台滑动验证码滑块到正确位置,使用python的mitmproxy库配合正则提取rid,并写入保存到本地rid.txt。

    最后黑产在实际批量注册,薅羊毛或刷赞过程中,遇到触发的滑动验证码机制,只要session在有效期内,只需使用python读取本地的rid.txt内容,调用requests库发送请求数据包,即可绕过滑动验证码。

    至此,滑动验证码绕过思路剖析完成。

2. 滑动验证码js接口XSS攻击

    众所周知的跨站脚本攻击—XSS,攻击手法可能很平常,但把常用的攻击手法用在一个不被人注意的地方,有时候会给你意想不到的效果。

    在某次实战中,对一个安全公司的真实后台登录页面做黑盒测试。

    ①首先,给到的只有一个这种后台登录页面。

    ②对常规的地方进行一番测试后,并没有发现什么脆弱缺陷。既是一家安全公司,安全防护做的比较高,也是意料之中的事。在屏幕前发了很久的呆,没有思路的时候,喜欢倒退,会回到渗透测试最本质的起点,信息收集。

    ③因为这家公司做的是业务安全,了解到这个后台是一个风控数据监测的登录后台。

    风控面对的业务场景有:注册、登录、浏览,支付,活动等。

    面对的威胁有:恶意爬虫、批量注册、薅羊毛、盗号撞库等。

    风控策略有:限制注册登录频率、恶意IP识别、验证码等。

    【恶意/正常行为】——【风控策略】——【业务场景】,风控在其中扮演者中间人的角色,无论是一个正常用户的行为还是群控设备的恶意行为,风控一方面会使用策略进行过滤行为,另一方面会将恶意/正常行为会被记录到日志中,进而在后台展示。

    ④至此,信息收集完毕,我们整理一下思路。

    我们先看一下手里拿到的测试页面,再对比分析一下上面那段信息。

    ⑤我们发现这个登录页,是有滑动验证码的。而对比上面的信息,我将红色框圈出来的文字,构建了一个我的漏洞测试想法。如果我能控制滑动验证码的输入,那在后台的输出也可能将是可控的。红色框圈出的最后四个字,“后台展示”,第一反应就是用XSS攻击手法再合适不过了。

开始行动

a. 首先,找到获取滑动验证码的js接口

b. 分析接口参数

找到以下参数:

channel,appId,orgaization,lang,data,sdkver,callback,model,reversion

c. 黑盒XSS——FUZZ

刷新验证码,截断,抓包。

(1)蛮力碰撞,直接把所有的参数的值替换成XSS payload,但这样往往容易失败,因为有些参数是硬编码,一旦更改,服务器返回的respnse就会直接显示reject拒绝。

(2)舍近求远,9个参数,抓9次包,分别替换参数值成XSS payload,最后,几分钟后,成功打到了cookie。

(因为XSS平台更新,当时的记录未保存)

    

(3)因为是黑盒测试,在漏洞修复后,内部人员把后台触发漏洞的位置告诉了我。

下面这张图是,风控后台的滑动验证码记录的行为信息展示栏,未修复之前这里有一列language的值,就是参数里的"lang",而插入的XSS payload也就会出现在这个位置。

由于开发人员未考虑到这个隐秘的js接口,所以未做过滤防护,且未申明http only,导致XSS payload可以顺利执行。

(4)最后,在黑盒测试盲打XSS中,很大一部分靠运气。但saya师傅告诉我,使用极限语句再配合一个超短域名的XSS平台,会增加成功率。

二、风控防御方

滑动验证码可能会部署在:注册、登录、反爬、支付等场景当中,而黑产绕过滑动验证码的技术会有很多种,但凡只要有一种是当前风控策略未考虑的情况,就可能会造成比较严重的损失。

1. 攻击手法总结

从黑产/攻击者的角度,针对滑动验证码,我们介绍了一种绕过的思路:session参数重复校验漏洞,一种攻击的手法:JS接口的XSS攻击。

那么,从风控/防御方的角度,我们如何制定防守方案呢?九号才疏学浅,不敢无稽之谈,只能把平时实战之中碰到的问题,记录下来,希望有用。

2. 被动防守——针对攻击者

这里没什么特色,既然是被动防守,自然是要避免亡羊补牢。针对诸如XSS等OWASP TOP漏洞,不能依赖开发的细心。除了在业务上线之前,内部测试和攻防测试;还可以在在业务上线之后,托管类似国外Hackone平台的国内赏金平台,或自运营SRC。当然,结合考虑预算成本。

3. 主动出击——针对灰黑产

主动出击,针对的是利用滑动验证码,来精准识别灰黑产。

①在上一篇文章实战笔记之X厂滑动验证码漏洞挖掘里最后一节,提到了多缺口、滑块多样化的方案。

②在一次滑动验证码更新升级过程中,发现了一个新思路。

(1)原始过程:在用户完成一次验证码滑动后,将request请求数据包发送给服务器。

(2)升级方案:在服务器后端升级滑动验证码的js代码,使每一个滑动验证码都在用户客户端生成一个或多个随机参数,这些随机参数需要跟随request请求发送到服务器进行一个简单逻辑验证。重点在于:正常用户只有通过滑动滑块发送的request数据包才一定是携带随机参数的,但并不强制要求发送的request请求携带这些随机参数。

(3)精准识别:因为核心圈的黑产下放的工具,都是通过直接通过发送request请求数据包来进行批量注册、刷量刷赞和恶意爬虫等行为。称之为:“协议刷”或“打接口”,这种方式效率极高。加上利益化的原因,黑产不会去在乎过程,只在乎是否结果能成功。

    升级的方案:只有通过正常滑动滑块,才能发送携带随机参数的request数据包发到服务器。

    旧方案:通过以前的旧接口直接发送不携带随机参数的request数据包到服务器也可以通过验证。

    在无声无息升级后,两种方案并行运行,那么拐点就到来了。

    是不是就意味着旧方案的验证码接口过来的ip,sdk,captcha_flag等数据一定都是源于黑产池;而升级方案的验证码接口过来的ip,sdk,captcha_flag等数据不说百分百,也绝大部分都是来自正常用户群体。这就悄然无声的就达到了精准识别灰黑产的目的。

(4)持续化:在被黑产发现后,就需要做持续化更新的对抗了。

还是那句,攻防本身就是一场不公平的战斗,或许只要能大大增加黑产攻击者的成本,就是有效果的防守。

三、总结

以上理论,皆为实战总结。希望有用。

如果没有,我想下篇或许会有。

技术研究总是孤独的,

边缘化的东西更是如此。

一个只专注冷门渗透技巧,

研究灰黑产的暗侍卫。

                                                          ———冷渗透

文由微信公众号:冷渗透

请发表您的评论
请关注微信公众号
微信二维码
不容错过
Powered By HeiBaiTeam.