指纹系统服务器,利用JARM指纹进行TLS服务端标记

本文介绍了JARM,一种用于快速验证TLS服务器配置的主动式指纹工具。JARM通过发送多个定制的ClientHello数据包获取ServerHello的唯一响应,生成服务端指纹。虽然JARM不能直接用于识别特定应用如CobaltStrike,但可以作为辅助手段,用于标记TLS服务端特征,结合其他信息进行威胁检测。文章还探讨了JARM在TLS服务端标记和主动测绘中的应用和潜在价值。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

原标题:利用JARM指纹进行TLS服务端标记

f70c88eb6ad216d1041f54abc58151a2.png

0x01

背景

对网络空间测绘数据的分析和发掘,是Quake团队一直以来的核心目标。

十几年来Web应用的飞速发展使其毋庸置疑的成为了互联网的主流。为了弥补Web应用和HTTP协议的各类安全问题,HTTP over SSL/TLS在互联网中的比例也逐年提升。因此,对全网SSL/TLS相关测绘与数据分析一直是Quake系统关注的重点之一。

当前Quake系统 已经支持任意端口、任意协议使用的SSL/TLS证书提取、分析、握手包的解析与留存。

注册用户在 证书 窗口中就可以看到TLS证书按照x509格式进行解析后的内容,同时 付费会员(高级会员、终身会员、企业会员)可以在 tls协议 窗口中看到完整的TLS握手过程,并提供格式化解析后的数据,在 server_certificates 中就包含了对服务端证书的指纹采集计算。如下图所示:

3d22e8242ff441f7bb7f9ae50301b66c.png

11fe503260494eeaac9544c951b9f77f.png

与此同时,我们也在持续关注TLS主动测绘方向的前沿研究。近期,我们留意到有关研究人员在发布了一篇名为Easily Identify Malicious Servers on the Internet with JARM的文章,并在github上发布了一个JARM扫描工具,相关内容引起了国外部分研究人员的讨论。在Quake团队小伙伴一致努力下,现已将此功能集成入Quake系统。

经过一段时间的分析研究,我们也总结出一些关于JARM的认识与大家交流和分享。抛砖引玉,希望大家多多指正。

0x02

JARM介绍

JARM 是一个主动式TLS服务端指纹工具,主要用途如下:

快速验证一组TLS服务器是否使用相同的TLS配置;

2.1 JARM工作原理

想要理解JARM工作原理,必须要了解TLS工作的流程,这里就不再详细讲解,我们用一句话简单概括下TLS握手的大致目的:客户端和服务端双方基于彼此的配置进行沟通、协商和校验,在达成一致后生成密钥。

而JARM的核心在于:TLS Server根据TLS Client Hello中参数的不同,返回不同的Server Hello数据包。而Client Hello的参数可以人为指定修改,因此通过发送多个精心构造的Client Hello获取其对应的特殊Server Hello,最终形成TLS Server的指纹(有点类似于Fuzz的感觉)。

具体能够产生影响的参数包括但不限于:

操作系统及其版本

OpenSSL等第三方库及其版本

第三方库的调用顺序

用户自定义配置

......

2.2 JARM工作流程

JARM通过主动向TLS服务器发送10个TLS Hello数据包并对Server Hello中的特定字段进行分析,以特定方式对10个TLS服务器响应进行哈希处理,最终生成JARM指纹。

JARM中的10个TLS客户端Hello数据包经过特殊设计,目的就是提取TLS服务器中的唯一响应。例如:

JARM以不同的顺序发送不同的TLS版本,密码和扩展;

TLS Clint将密码从最弱到最强排序,TLS Server将选择哪种密码?

......

总之JARM与我们在进行流量分析威胁时常用的JA3、JA3/S不同:

JA3、JA3/S主要基于流量

JARM则是完全主动的扫描并生成指纹

因此有了上述的理论基础,我们尝试分析JARM工具的具体代码。

2.3 JARM工具代码分析

首先在main函数,jarm定义了10种TLS Client Hello数据包生成的结构,分别包含了待扫描的目标、端口、tls客户端加密套件、TLS扩展列表:

89dae6f28dad89b661e7dc297cfef248.png

然后依次遍历这10种TLS Client Hello结构生成数据包,并使用packet_building函数生成对应的TLS Client Hello数据包,然后依次发送数据包:

dc57ecf6c4bdf2af78f8c40b11100199.png

通过send_packet发送数据包以后,使用read_packet解析返回TLS Server Hello,并拼接为如下格式:

6856fc1543b71f48bd5b3e7b06808aae.png

字段含义:

服务器返回的加密套件 |服务器返回选择使用的TLS协议版本 |TLS扩展ALPN协议信息 |TLS扩展列表

通过发送10次TLS Client Hello并解析为以上格式,将10次解析的结果拼接以后最终调用jarm_hash算出最终的结果。

jarm_hash前30个字符由加密套件和TLS协议版本分别使用cipher_bytes、version_byte函数计算拼接而来,其余的32个字符是由TLS扩展ALPN协议信息和TLS扩展列表通过sha256哈希并截取而来:

b13f4e62ca953c69d3b3a9cb2b45de31.png

0x03

JARM的应用与问题

3.1 利用JARM搜寻服务端

其实在我们之前的文章【浅析 CobaltStrike Beacon 扫描】中,有心的小伙伴已经留意到了在某些支持SSL/TLS的端口 端口响应 标签文本末尾有一串形如“JARM:xxxxxxxxxxxxxxx”的字符串,这便是该端口的JARM指纹。Quake搜索语法如下,注意替换JARM:之后的字符串:

response:"JARM:07d14d16d21d21d07c42d41d00041d24a458a375eef0c576d23a7bab9a9fb1"

现目前Quake注册用户就能够在端口响应 文本的末尾看到其JARM指纹。该内容为系统自动追加后的数据,并不是该端口原始返回数据,请注意区分。

c4c281ff03a23dd0f1003ce98a528929.png

7e3f5c573c138ae8db0acd788041ee9f.png

经过一段持续测绘后,我们发现了一些有趣的现象,下面让我们一起看看。

3.2 利用JARM识别C2与问题

在Easily Identify Malicious Servers on the Internet with JARM 原文中,作者给出了一份C2和JARM对应的清单,这里我们就不赘述了。

78357437f88783464a8bafebb4a066a9.png

当我们得到这些C2和JARM的时候是十分高兴的,因为在理想情况下如果JARM与C2唯一对应,那么我们就多了一种主动发现C2节点的特征。可是事与愿违,搜索上面的那个CS对应的JARM:

response:"07d14d16d21d21d07c42d41d00041d24a458a375eef0c576d23a7bab9a9fb1"

3e2d6411d812d57bb55662072d9db2e0.png

我们发现数量不少,独立IP有2338个。但是 TOP5的应用为:

应用

数量

Cobalt Strike团队服务器

1,137

CobaltStrike-Beacon服务端

373

Tomcat-Web服务器

40

Weblogic应用服务器

21

WordPressCMS博客系统

14

可以看到和上面CobaltStrike相同JARM的还有 Tomcat、Weblogic和WordPress等开启TLS的Web应用,也就是说CobaltStrike这个应用只是该JARM对应TLS服务器其中的一个子集。

继续在本地搭建环境进行测试,Cobalt Strike 4.0 在JDK 11.0.9.1下 JARM为:

07d2ad16d21d21d07c42d41d00041d24a458a375eef0c576d23a7bab9a9fb1

137d927c426b63e0ab37fc409d14fb2b.png

在Quake中搜索:

response: "CobaltStrike Beacon configurations"ANDresponse: "07d2ad16d21d21d07c42d41d00041d24a458a375eef0c576d23a7bab9a9fb1"

发现没有CobaltStrike Beacon为这个JARM。

回到本地环境切换JDK版本,同一个Cobalt Strike 4.0,在JDK 1.8.0_212情况下JARM为:

9aba80da55a582fbee640bd00a1b74d0.png

看来JARM似乎和CobaltStrike无关,为了证明这一点,在相同JDK环境下搭建Tomcat服务配置TLS。结果如下:

JDK 11.0.9.1 Tomcat 9.0.41 JARM 07d2ad16d21d21d07c42d41d00041d24a458a375eef0c576d23a7bab9a9fb1

进一步对多个JDK版本进行测试得到如下结果:

f0577c28463e0896c759f48cce36f003.png

dd360ad7d3ae2ac544909a6ec9f9512e.png

8f06b2ec2461a01ef996561c55b4258f.png

看来,我们并不能直接通过JARM去判定CobaltStrike;同样,对于CobaltStrike而言JARM也并不唯一,其JARM与不同JDK环境下TLS服务有关。

JARM只能作为一个辅助手段,结合之前CobaltStrike的特征,我们提取了部分CobaltStrike服务器的JARM数据放置在Quake的开源仓库中,仅供业界研究使用(不作为精准威胁情报),仓库地址:https://github.com/360quake/CobaltStrike-JARM

843e2f804a0da5c41939c6ba7a7bae20.png

0x04

结论与思考

但是,也不是说JARM完全没有作用,JARM的本质是对TLS服务进行标记,例如:我们可以结合已知的JDK版本对应的JARM可以看到公网上运行在特定版本JDK环境下的服务,如图为运行在JDK 11.0.9.1的ELasticSearch,运行在JDK 11.05的Weblogic。

131f7688db8bf85e2bf3f097ae408406.png

b23c4181cfce0990a6dcd842b703366c.png

JARM仅仅是一种TLS服务端特征的标识方式, 不能完全被用作Web上层应用的唯一指纹。

总归来说,JARM提供的思路大于其本身价值: 利用主动测绘的方式,向目标发送各类数据包,根据不同的返回进而发掘、分析、提取目标特征。

正如在A Red Teamer Plays with JARM中提到的:

This is a commoditized threat intelligence practice. If your blue team uses this type of information, there are a lot of options to protect your infrastructure.

基于主动测绘的威胁情报正在各个方向落地生根。通过对主动测绘数据各个维度的统计、分析信息,能够提供新的防护思路。

更多网络空间测绘领域研究内容,敬请期待~

Happy hunting by using 360-Quake.

0x05

https://engineering.salesforce.com/easily-identify-malicious-servers-on-the-internet-with-jarm-e095edac525a

https://github.com/salesforce/jarm

https://blog.cobaltstrike.com/2020/12/08/a-red-teamer-plays-with-jarm/

责任编辑:

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值