攻击者视角对AntiSpam工作的分析
2019年曾经深入研究了一个产品的AntiSpam机制，目标是通过机器人程序（以下简称BOT），绕过防御机制，自动进行一些提交动作。他们主要使用一家著名CDN服务厂商的BotManager服务进行防御，另外也有一些自己在数据层面的管控。
当时就感叹这家CDN厂商的BotManager在技术方面的强大，但毕竟话题比较敏感，如今，已经过去三年，就单从技术方面把相关的一些信息整理出来，供大家参考，也欢迎加微信交流（微信号：selfimpr）。
文中一律使用“X-产品”代表目标产品，使用“Y-CDN”代表该CDN厂商，使用“Y-BotManager”代表该CDN厂商的AntiSpam服务。
Y-BotManager的总体架构
要接入使用Y-CDN的BotManager产品，必须使用他们的CDN产品，并在自己的产品内部，嵌入他们的SDK，该SDK对Android、iOS、Web等应用都有支持。
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-BotManager的Javascript-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产生之后，需要通过网络进行发送，这就要经过完整的协议栈：HTTP、TLS/SSL、TCP/IP等，这些协议本身是标准的，但每种具体的实现，有各自的差异，所以可以根据这些差异，对客户端进行签名和识别。
以下是一些参考资料：
https://www.net.in.tum.de/fileadmin/TUM/NET/NET-2020-04-1/NET-2020-04-1_04.pdf（TLS指纹签名）
https://www.giac.org/paper/gsec/159/tcp-ip-stack-fingerprinting-principles/100625（TCP/IP指纹签名）
https://www.blackhat.com/docs/eu-17/materials/eu-17-Shuster-Passive-Fingerprinting-Of-HTTP2-Clients-wp.pdf（HTTP指纹签名）
比如：golang的http2实现，和FireFox的http2实现中，scheme/method/path这几个伪头的发送顺序是不一样的
又比如：golang和Firefox或其他浏览器，在TLS Handshake阶段，交互的细节上也有差异，最典型的就是对加密算法的选择。
除了协议栈层面的特征，请求发送所使用的IP，也会被作为一种特征，参与BOT的识别。比如云厂商的IP、私有IP、黑产常用IP等。
得到这些信息之后，我又做了两个阶段的工作：
1、编写python、java、android等不同版本的请求发送库程序，但最终都会被拦截
2、无奈之下，就Hack了golang内核中http2、TLS的实现，将其改造为可以随机模拟其他合法客户端特征的方式运行。
做完所有这些工作之后，我们的BOT就可以完美的绕过Y-BotManager了，但好日子其实也不长久，大概稳定了一个月左右，它就又不能正常工作了。
伴随工作重心的调整，这部分工作后面就没有再继续了，但仍然有一些后续的思考，可以分享。
对Y-BotManager的进一步猜想
不论Y-BotManager内部的特征如何复杂，它的基本工作原理，就是找到一种唯一标记一个用户的方法，并携带尽可能多样化的特征数据，判定这是一个人还是一个机器。所以，突破它的全部工作，都需要围绕建立这个标识，并伪造这个标识中包含的全部特征信息。
当我们在上面所有技术细节的工作都完成之后，经过一个周期，对方仍然能够识别出BOT特征，我的猜测，是他们背后有一些机器学习相关的工作（通过对该产品公司发展历程看能够证实这一点），通过一个周期的发展，可以识别出我们比较粗糙的行为模拟（机械臂或自动生成行为轨迹）。
如果这个工作要进一步推进，可能需要使用对等的一些技术，生成出更加接近人类行为的特征数据。
另外一个角度，是需要关注特征之间的关系，所有的特征必须成套的存在，比如应用层协议提交的SensorData中告诉Server我是一个Android上的Chrome浏览器，但TLS层的指纹签名结果是一个Mac上的Firefox浏览器，这显然很容易就被降权处理。
跳出Y-BotMananger看X-App的AntiSpam工作
X-App是一个国外的产品，他们的AntiSpam工作，总体来看是非常优秀的。因为他们的产品，有很大的薅羊毛空间，所以牵动了不少国内外灰产参与其中。
但在我做这部分工作的那段时间，以及再向后的一两年中，他们很大程度上遏制了灰产从中的获利，并对其加以利用。
对于灰产来说，BOT程序是一部分，BOT使用的账号是另一部分，X-App除了使用Y-BotManager这样先进的技术之外，还有更多业务层面的考虑，根据用户的特征，对用户进行分群，对于不同分群的用户，根据运营和市场需要，采取不同的处置策略。
这种用户维度的分群处理，主要能够得到三方面的好处：
1、国内手机号实名制的大环境，国家对接码平台和卡商的大力打击，账号养成本身的成本，都很大程度压缩的这部分灰产的生存空间；
2、运营主动利用BOT用户，反向收割薅羊毛的BOT用户；
3、让BOT的开发者，很难琢磨到底有没有问题，是哪里的问题，看起来永远都可以正常工作，但有时候能薅到羊毛，有时候又薅不到羊毛！！！
总结
机器人程序薅羊毛是大部分互联网产品都会面临的问题，本文主要从攻击者的视角，对一个特定产品的防御思路进行分析，其中提到的各类技术细节的介绍，未必详细完整，主要想通过此文，介绍作为攻击者，会从哪些角度获取信息、思考问题、推测设计者的意图等。
如过对这个话题有兴趣，欢迎加微信交流（微信号：selfimpr）。
参考阅读：
本文由高可用架构翻译。技术原创及架构实践文章，欢迎通过公众号菜单「联系我们」进行投稿。