聚合国内IT技术精华文章,分享IT技术精华,帮助IT从业人士成长

攻击者视角对AntiSpam工作的分析

2022-03-11 18:31 浏览: 1124 次 我要评论(0 条) 字号:

2019年曾经深入研究了一个产品的AntiSpam机制,目标是通过机器人程序(以下简称BOT),绕过防御机制,自动进行一些提交动作。他们主要使用一家著名CDN服务厂商的BotManager服务进行防御,另外也有一些自己在数据层面的管控。

 

当时就感叹这家CDN厂商的BotManager在技术方面的强大,但毕竟话题比较敏感,如今,已经过去三年,就单从技术方面把相关的一些信息整理出来,供大家参考,也欢迎加微信交流(微信号:selfimpr)。

 

文中一律使用“X-产品代表目标产品,使用“Y-CDN”代表该CDN厂商,使用“Y-BotManager”代表该CDN厂商的AntiSpam服务。

 

Y-BotManager的总体架构

 

 

要接入使用Y-CDNBotManager产品,必须使用他们的CDN产品,并在自己的产品内部,嵌入他们的SDK,该SDKAndroidiOSWeb等应用都有支持。

 

X-App在使用Y-BotManager产品后,全部需要保护的业务请求,都需要从Y-BotManager-SDK获取一个SensorData,并携带这个SensorData通过Y-CDN的节点访问后端服务。Y-CDN的节点收到请求之后,会对携带的SensorData进行分析,确认是否是机器人访问,对于非机器人访问,直接放行到X-Server,对于机器人访问,可以选择路由到假的Server上给出混淆视听的结果,或者直接返回错误。

 

从业务视角看,这里的可选择路由到假的Server给出混淆视听的结果,是一个很好的思路。因为攻防之间,永远都是一个持续性的过程,混淆视听的事情做的好,一方面可以麻痹攻击者,延缓攻击者的进一步行动,另一方面,明确的错误实际上为攻击者提供了额外的信息,给出看起来正常但实际无效的数据,会很大程度增加攻击者迭代的成本。

 

不过,Y-BotManager的核心,还是在SensorData本身。

 

SensorData生成过程的逆向分析

 

Y-BotManager对抗的第一个工作,就是对SensorData生成过程的逆向分析。

 

逆向分析的工作分两个步骤:1)反编译;2)分析。

 

反编译主要依赖工具,但还是需要做一些额外的工作。因为一般产品都会进行混淆,反编译工具输出的代码可读性极差,为了降低第二步分析工作的难度,要尽可能的对反编译之后的代码,作进一步的还原。

 

这个工作也会伴随分析的过程,在分析过程中,随着对源代码中的业务逻辑有进一步的理解,将其中相关的部分替代成可读性更高的代码(比如已知意图的函数、变量等,就可以替换成表意更清晰的名字),这样,随着逆向分析的深入,难度会逐步降低。

 

在逆向分析这一步,比较考验的是技术的全面性、对大量代码的结构把控、对作者的意图猜测、耐心。

 

Y-BotManagerJavascript-SDK大约1000行代码,Android-SDK大约2000行代码,总体大概用了一周半时间还原其逻辑。

 

SensorData数据本身

 

关于SensorData分两个方面介绍:1)数据结构的设计;2)数据包含的内容。

 

SensorData的目标,是存储各类特征信息,据此唯一标识一个用户,并根据其特征识别是否BOT

 

识别的服务端,应该聚集更多的信息,以便做出更准确的判断,但作为客户端,又需要支持多样化的场景。因此SensorData的数据结构,需要是可扩展的,大体如下:

 

SensorData := 加密特征类型特征值特征类型特征值;... ; 特征类型特征值;校验和)

 

不同特征类型互相独立,它所收集的特征,主要包含以下两类:

 

设备相关特征

 

设备特征中,主要包括四类:

 

1)设备硬件特征:主要包括设备型号,屏幕尺寸等信息。

 

2)设备软件特征:主要包括操作系统的名称、版本等相关信息,浏览器(Web端)的名称、版本等信息,以及浏览器中对某些函数的支持情况等。

 

3)非法设备特征:主要包括无头浏览器、模拟器等非正常用户使用的环境的特征数据。

 

4)设备计算特征:主要包括做一些耗时计算评估其耗时情况,Web端利用Canvas绘图的指纹签名(不同浏览器Canvas绘图产生的二进制数据不一样)等。

 

用户交互特征

 

用户交互特征,主要是收集用户在进行触屏、键盘、鼠标等操作时候的轨迹数据,以及对于App端,设备自身的运动轨迹数据也会被收集。

 

Y-BotManager的对抗过程

 

打入灰产内部

 

当时我们的目标是编写一个BOT程序,能够大规模的模拟正常用户,在X-产品上进行数据提交的动作。X-产品因利益相关,其实已经有比较多灰产在做这个BOT

 

灰产的结构比较清晰,有卖IP代理的,有写BOT程序的,有卖BOT程序的,也有付钱使用BOT程序的。写BOT程序的,处于最顶端,付钱使用BOT程序的地位次之,另外两个角色更偏向于中间的生意人角色。

 

我们在早期就打入灰产内部,因为我们是BOT程序的编写者,所以比较容易能够聚集到其他的角色。之所以要聚集这些人,是因为他们在这个圈子里时间长,掌握了大量的信息,另外他们也可以作为中间人,帮助我们和其他BOT的作者做一些沟通。

 

BotManager对抗中做的一些工作

 

最早期,先是使用无头浏览器,js-dom做一些尝试,后来逆向分析完成之后,就用golang写了SensorData的自动生成程序、请求管理相关的框架(之所以采用Golang是希望后期能够更大规模的运行)。

 

但这个阶段的尝试没有成功,我的第一个推测,就是随机生成的相关特征数据,真实性有问题,会被对方拦截。所以,我们采集了大量的真实设备相关的特征信息,形成一个库。在BOT运行时,从这个库中获取成套的特征信息。

 

做了这个调整之后,就第一次获得了成功,但大概一两天之后,就发现这个版本无法正常运行了。

 

第二个阶段,我就在用户交互行为特征这块儿下了功夫。开始阶段尝试模拟生成用户行为和设备运动轨迹相关的特征数据,后来还让一位同事,写了个单片机程序控制机械臂运动,以此生成真实的运动轨迹数据。

 

同样的,昙花一现,当我们提升了这方面的特征数据真实性之后,正常工作一两天之后,就又不能正常工作。

 

这个工作就陷入了停滞状态,因为我们站在对对方SDK理解的角度上,好像该做的工作都做了。后来,我就开始了解Y-CDN这个厂商在BotManager这个产品方面的一些产品宣传文档和技术文档,从中找到一些端倪。

 

原来,唯一标识并识别一个用户,并不只依赖于显性的SensorData中的数据。SensorData产生之后,需要通过网络进行发送,这就要经过完整的协议栈:HTTPTLS/SSLTCP/IP等,这些协议本身是标准的,但每种具体的实现,有各自的差异,所以可以根据这些差异,对客户端进行签名和识别。

 

以下是一些参考资料:

https://www.net.in.tum.de/fileadmin/TUM/NET/NET-2020-04-1/NET-2020-04-1_04.pdfTLS指纹签名)

https://www.giac.org/paper/gsec/159/tcp-ip-stack-fingerprinting-principles/100625TCP/IP指纹签名)

https://www.blackhat.com/docs/eu-17/materials/eu-17-Shuster-Passive-Fingerprinting-Of-HTTP2-Clients-wp.pdfHTTP指纹签名)

 

比如:golanghttp2实现,和FireFoxhttp2实现中,scheme/method/path这几个伪头的发送顺序是不一样的

 

又比如:golangFirefox或其他浏览器,在TLS Handshake阶段,交互的细节上也有差异,最典型的就是对加密算法的选择。

 

除了协议栈层面的特征,请求发送所使用的IP,也会被作为一种特征,参与BOT的识别。比如云厂商的IP、私有IP、黑产常用IP等。

 

得到这些信息之后,我又做了两个阶段的工作:

 

1、编写pythonjavaandroid等不同版本的请求发送库程序,但最终都会被拦截

 

2、无奈之下,就Hackgolang内核中http2TLS的实现,将其改造为可以随机模拟其他合法客户端特征的方式运行。

 

做完所有这些工作之后,我们的BOT就可以完美的绕过Y-BotManager了,但好日子其实也不长久,大概稳定了一个月左右,它就又不能正常工作了。

 

伴随工作重心的调整,这部分工作后面就没有再继续了,但仍然有一些后续的思考,可以分享。

 

Y-BotManager的进一步猜想

 

不论Y-BotManager内部的特征如何复杂,它的基本工作原理,就是找到一种唯一标记一个用户的方法,并携带尽可能多样化的特征数据,判定这是一个人还是一个机器。所以,突破它的全部工作,都需要围绕建立这个标识,并伪造这个标识中包含的全部特征信息。

 

当我们在上面所有技术细节的工作都完成之后,经过一个周期,对方仍然能够识别出BOT特征,我的猜测,是他们背后有一些机器学习相关的工作(通过对该产品公司发展历程看能够证实这一点),通过一个周期的发展,可以识别出我们比较粗糙的行为模拟(机械臂或自动生成行为轨迹)。

 

如果这个工作要进一步推进,可能需要使用对等的一些技术,生成出更加接近人类行为的特征数据。

 

另外一个角度,是需要关注特征之间的关系,所有的特征必须成套的存在,比如应用层协议提交的SensorData中告诉Server我是一个Android上的Chrome浏览器,但TLS层的指纹签名结果是一个Mac上的Firefox浏览器,这显然很容易就被降权处理。

 

跳出Y-BotManangerX-AppAntiSpam工作

 

X-App是一个国外的产品,他们的AntiSpam工作,总体来看是非常优秀的。因为他们的产品,有很大的薅羊毛空间,所以牵动了不少国内外灰产参与其中。

 

但在我做这部分工作的那段时间,以及再向后的一两年中,他们很大程度上遏制了灰产从中的获利,并对其加以利用。

 

对于灰产来说,BOT程序是一部分,BOT使用的账号是另一部分,X-App除了使用Y-BotManager这样先进的技术之外,还有更多业务层面的考虑,根据用户的特征,对用户进行分群,对于不同分群的用户,根据运营和市场需要,采取不同的处置策略。

 

这种用户维度的分群处理,主要能够得到三方面的好处:

 

1、国内手机号实名制的大环境,国家对接码平台和卡商的大力打击,账号养成本身的成本,都很大程度压缩的这部分灰产的生存空间;

 

2、运营主动利用BOT用户,反向收割薅羊毛的BOT用户;

 

3、让BOT的开发者,很难琢磨到底有没有问题,是哪里的问题,看起来永远都可以正常工作,但有时候能薅到羊毛,有时候又薅不到羊毛!!!

 

总结

 

机器人程序薅羊毛是大部分互联网产品都会面临的问题,本文主要从攻击者的视角,对一个特定产品的防御思路进行分析,其中提到的各类技术细节的介绍,未必详细完整,主要想通过此文,介绍作为攻击者,会从哪些角度获取信息、思考问题、推测设计者的意图等。

 

如过对这个话题有兴趣,欢迎加微信交流(微信号:selfimpr)。


参考阅读:


本文由高可用架构翻译。技术原创及架构实践文章,欢迎通过公众号菜单「联系我们」进行投稿。


高可用架构
改变互联网的构建方式



网友评论已有0条评论, 我也要评论

发表评论

*

* (保密)

Ctrl+Enter 快捷回复