Java序列化对象：流行性调研、漏洞渗透、利用开发和安全识别 – 作者:ijzmesec

概述

Java序列化对象（Java Serialization Object，JSO）是Java语言中在不同Java程序之间进行数据交换的机制，通过序列化和反序列可以在程序保存和恢复Java执行态的对象，JSO给Java开发带来极大的方便，但同时也是个极大的安全隐患。JSO给攻击者提供了一个稳定可靠的载体，来实现对Java APP的攻击和远程控制。近年JSO的反序列化漏洞层出不穷，针对JSO的攻击也越来越多。比如知名Java框架Stuts 2，基本上成了一个筛子，一股脑暴露了几十个安全漏洞，其中很多都是反序列化漏洞。关于JSO的安全和Java反序列化漏洞的原理，JSO漏洞流行度，以及如何使用Metasploit 框架验证和测试JSO有关的漏洞，小编参考有关报告总结分析和大家一起分享学习。

首先列举一下关于JSO现实数据：

2017年和2018年两年间分配给JSO相关漏洞CVE在大幅度增加。两年内公增加了大概100个，而此前2013年至2016年四年内也仅仅有7个。

基于JSO的应用程序通常可通过互联网远程访问。在2019年1月的Rapid7  Sonar安全扫描统计（基于JSO的T3协议）显示有11831个可通过互联网访问的WebLogic服务器。

JSO的使用和滥用

虽然正对JSO漏洞的攻击防御已经为广大开发者和安全人员熟知。但是关于JSO以及由于JSO滥用导致的漏洞许多人并不了解。所以我们首先来解释一下：

关于JSO

JSO允许Java服务在没有严格定义的结构的情况下相互通信。它为Java服务之间交换数据提供了一种灵活方便的方法，通常使用文件对Java对象持久化并通过网络连接。发送方传递数据字节码，包括数据结构和数据类型（序列化对象JSO），而接收方通过接受序列化对象，并将其反序列化为内存中的Java对象，这个过程就可以把Java运行时、状态和数据实现隔空转移。JSO将类型信息与数据一起保留，并用于传输复杂的Java对象，而不会过多操心其内容。例如，Java应用程序的一个组件可能构建了一个“顾客”对象，其中包含诸如“姓名”，“性别”等的字段，甚至包括整数型的“消费金额”等元素。包括一些整数和字符串。如果组件可以只是将这些“顾客”对象堆到一起，那么接口就不需要知道或关心“顾客”对象中的实际内容。只需要将其序列化和反序列化，不用不考虑其内容，其他交给发送者和接收者就是了。

JSO滥用

然而，这样是不行的。反序列化过程可能会接收的对象字节码转换为一些良好的类型定义的字符串和整数，但如果不对其进行认真校验，很容易就会引入安全漏洞，攻击者可以控制的进程，在反序列化之前增加恶意代码和指令从而实现攻击。事实上，很多程序的接收者都未对接收的序列化字节码进行验证，所以可以构建自定义JSO并注入远程代码执行（RCE）并将其发送到给反序列化接口执行，当反序列化毫无验证执行反序列化过程时候就会引入一个“Web shell”或在远程服务器上执行一些恶意脚本。

JSO处理通常作为Java标准模块被融入到产品中，要对这些产品修改其这通信方式通常很难，所以反补序列化漏洞的修复非常麻烦，造成的影响也很大。

为了缓解由此带来的安全威胁，供应商通常会通过有针对性的黑名单，通过黑名单防止使用特定库可能会导致的RCE，而不是进行更全面的修补漏洞，重新设计有漏洞输入的接口。所以，当开发人员通过禁用某些可能引入攻击的库，暂时解决了漏洞的发作，但是有问题的JSO通信漏洞还存在，当有个新0 day爆发时，这就变成了一颗炸弹。

一旦攻击者识别出具有类似功能的另一个库，就可以快速而傻瓜化的攻击这个新库。比如Chris Frohoff的ysoserial这样的工具可以使用任意数量的库构建一个JSO，并将有效载荷包装在几十个JSO之一中。这些工具大大简化了漏洞演示和JSO相关的漏洞测试。这意味着，单单通过类库黑名单来解决漏洞的方法是临时无效的策略。

JSO相关漏洞（CWE-502）流行性调研

Java反序列化攻击并不新鲜，但攻击者越来越多地发现这类漏洞利用来越越简单。反序列化漏洞成了攻击者最喜欢的王牌，还能长久的利用不衰。

CVSS逐年分布统计

CWE-502是MITRE 通用缺陷分类（Common Weakness Enumeration）JSO专用标识符，用来跟踪不受信任数据进行反序列化（Java或OO语言语言）导致的漏洞。在过去的五年中，我们看到基于反序列化的CVE急剧增加，包括那些CVSS分数高于7.0的高危漏洞：

这些CVE都存在于广泛使用的大众软件产品中，比如Oracle WebLogic，IBM WebSphere，思科安全访问控制系统（ACS），HPE智能管理中心（IMC）和VMware的vSphere Integrated Containers中。

攻击者可以使用MetasploitFramework中的各种公共漏洞利用来获取到这些产品的未经身份验证的RCE，可以利用MF模块包括：

WebLogic T3部署调查

由于最近报告的漏洞都涉及Oracle WebLogicT3协议。WebLogic本身使用T3之外的各种协议进行通信，但它与在给定端口上仅使用一种协议的许多其他产品和服务不同。例如，WebLogic实例的默认配置提供了一个默认端点7001/TCP，它使用几种不同的协议，包括T3，HTTP，SNMP和LDAP。

 Rapid7利用其Project Sonar来扫描了2019年1月暴露在公网上WebLogic服务器。

Project Sonar是Rapid7 2013年9月发起的一个公共安全分析项目，旨在通过对公网网络活动的分析来提高安全。为了更多地了解WebLogic如何在公网的开放程度，Rapid7利用了Sonar HTTP和HTTPS研究的一部分收集的数据，这些研究大约每周扫描几十个端口。通过检查超过1.2亿个HTTP响应服务以获取大多数WebLogic实例回应。结果显示有18693个IPv4地址开放了67个不同的TCP端口，这些端口显示为WebLogic。结果还显示，WebLogic最常见开放的端口是80（HTTP，占44%）和7001（默认端口，占36%）。

公共互联网上的WebLogic服务器监听TCP端口可能有443,80,7001,8001和8002。通过对这些端口扫描，发送指令，接受相关指令可以用更准确地识别T3协议。

具体指令为发送一个23字节的T3协商消息：

t3 9.2.0.0\nAS:2048\nHL:19\n\n

字符串“t3”发起T3协议。’9.2.0.0’是我们客户端WebLogic版本banner，服务器需要使用它来确定兼容性。 ‘AS’和’HL’参数分别控制JVM消息头大小和近似表大小，其值根据观察到的默认值设置。

实验证实，T3端点用类似的消息响应，该消息描述了T3协商的结果，分为两组：

1.确认T3成功协商的T3端点。由此，我们可以识别服务器开放了WebLogic。

2.确认T3端点，其中T3由于连接过滤器或类似限制而未成功协商，或者某些类型的错误配置（例如许可问题和WebLogic版本不兼容）以及其他可能的情况。

检查来这些先前已识别的常见WebLogic端口：80,443,7001,8001和8002。

结果显示超过8700万个IPv4端点的响应，确定其中了11831个确认运行了WebLogic的系统。这比我们之前基于HTTP的估计值低35%,这种差异有几种可能的原因，可能由于一般的互联网规模扫描时候网络波动，或者这些WebLogic实例明确配置HTTP屏蔽了T3信息。进一步的分析显示有1183个服务器对T3探测器给了负面的反馈，可能是由于T3对探测器进行了限制。

在WebLogic使用的默认端口端口7001/TCP上，有4577个反馈了是T3。这比前面基于HTTP估算的3439要少。可能原因是7001/TCP上的WebLogic实例，只反馈了T3信息，没有指明为HTTP。

端口8001/TCP也是WebLogic默认安装在7001/TCP不可用或安装额外实例时使用的备用端口。我们在8001/TCP上有1157个反馈是T3的主机。端口8002是WebLogic的不台常用的替代端口，它显示有大概300多个WebLogic系统。

在默认的HTTP和HTTPS端口（80和443）上，分别有5672和1133个IPv4终端，被确认启用可T3协议。

已确认得所有T3终端的WebLogic版本分布显示涉及各种版本：包括从7.0.1.0（2002年发布）到12.2.1.3最新版本（2019年初）：

 

Sonar endpoint研究的一部分，还包括了IP归属地的分布相关元数据，包括可IP归属组织和位置详细信息，比如国家和城市。所有T3结果中IP归属地的统计数据显示：

有超过25%的暴露T3的IP由Oracle所有，WebLogic发行商，其余大部分由各种云提供商拥有。

所有IP归属中超过36%为美国，32%是中国，其他国家和地区：

国家	数量
美国	4279
中国	3875
伊朗	511
韩国	307
德国	241
印度	236
英国	138
加拿大	120
法国	118
巴西	115

 

数量最多的十个组织是：

组织	数量
甲骨文云	2,982
中国电信	1,677
中国联通	867
阿里云	340
亚马逊AWS	264
YHSRV	252
中国移动	204
SumTotal系统	143
韩国电信	136

 

对JSO的服务渗透测试

对于可远程访问的WebLogic漏洞服务，可以利用Metasploit多个模块（#11136，#11134，#11131和#10436）可以进行渗透测试。先利用手动测试，然后可以使用Burp Suite或ysoserial等工具定位易受攻击的服务。

例如，对有问题WebLogic服务器的攻击者可以通过Metasploit轻松获得未经身份验证的RCE：

更精准的攻击通过网站导航或使用Java应用程序，同时监控网络流量以获得基于JSO的交互的迹象。对包含T3标志头（或0xACEDmagic字节）的流量的简单搜索可以显示使用JSO进行通信的服务的存在：

更积极写，可使用多个工具组合来来主动扫描基于JSO的用户输入的服务。例如，专业版Burp Suite支持Java Deserialization Scanner扩展，可以主动识别和利用JSO漏洞。该扩展使用Wouter Coekaerts的SerialDOS技术的修改来执行基于JSO的服务的库无关的漏洞检查，即使库已被列入黑名单，也会识别固有的漏洞。

任何随机的二进制数据集也可能在某处存在着神奇的0xACED字节，因此对于应用程序测试人员来说这更有用（但有噪音）。

Metasploit支持JSO利用开发

在测试，开发和验证序列化攻击中使用的漏洞时，研究人员和白帽安全从业者会面临复杂的工具生态系统。将Metasploit内容纳入反序列化漏洞通常需要贡献者在将二进制blob插入到贡献模块之前对JSO进行反向工程并手动优化有效负载。

为了简化创建和验证漏洞利用程序的过程，MetasploitFramework中增加了对基于ysoserial的对象的本地使用的支持。Metasploit可以轻松生成或修改ysoserial JSO，以用于漏洞利用开发，研究和测试。这个mixin可以将重复的38行函数减少到一行：

data =::Msf::Util::JavaDeserialization.ysoserial_payload(“JSON1”,cmd)

在Metasploit安装ysoserial

为了向Metasploit贡献者提供像ysoserial这样的JSO有效负载生成，需要一种方法来提供有效负载，而无需特定版本的Java和必备库。调用这些库不仅耗时并且减慢了JSO的生成速度，还会限制Metasploit的环境。此外，ysoserial需要计算结构内对象的长度，因此在Metasploit中实现JSO有效负载生成也需要定位和更新长度。

截至19年1月，Metasploit提供了预先生成的ysoserial有效载荷和元数据的缓存，允许模块快速可靠地生成JSO。Rapid7使用Docker创建一个隔离的构建环境，在该环境中可以安装和运行Java和依赖包（类似于创建Metasploit有效负载的方式）。 Docker容器使用最新版本的ysoserial列出可以构建的库和变体，然后遍历每个尝试构建对象的库：

metasploit-framework/tools/payloads/ysoserial/Dockerfile

基于ubuntu的dockerfile如下：

注意，当Metasploit模块需要生成JSO时，不需要运行Docker环境。相反，容器的输出被缓存并随Metasploit Framework一起提供。只有当ysoserial维护者识别要集成到ysoserial工具中的新库时，才能运行Docker容器，可能每年几次。会在Metasploit GitHub wiki公布。

找到偏移值

下一个挑战是找到ysoserial输出中包含的长度值和有效负载缓冲区。需要通过手动对每个输出进行反向工程，并且不支持对ysoserial的更新。相反，Docker容器使用不同长度的有效负载生成一系列对象，然后比较它们以定位其他字节（有效负载缓冲区）和递增字节（长度值）：

metasploit-framework/tools/payloads/ysoserial/find_ysoserial_offsets.rb

删除指纹标识

事实证明，ysoserial插入字符串ysoserial/Pwner后跟一个时间戳值。由于此字符串很容易识别，渗透测试者和其他希望避免检测的攻击性从业者可能会对其感兴趣：

该指纹有助于识别ysoserial使用和确定ysoserial JSO是否在从先前的攻击中使用过。当然它还有一个副作用，就是其阻碍发现长度偏移和有效载荷缓冲区的差异技术。解决方案有两个方面：使用易于定位的字符串覆盖指纹，然后在Metasploit模块调用时在每次调用期间生成随机字符串：

metasploit-framework/tools/payloads/ysoserial/find_ysoserial_offsets.rb:

metasploit-framework/lib/msf/util/java_deserialization.rb:

输出将写入由Metasploit提取的JSON文件。例如，以下是JSON缓存文件中的CommonsCollections1对象的片段：

该技术可以应用于任何动态有效载荷或对象生成框架的重新实现。特别是，使用JSON，Base64和明确定义的偏移值使其他语言或工具可以轻松使用搞缓存文件。

生成JSO漏洞利用

对Metasploit上述所有工作都缩减为一条线。考虑hp_imc_java_deserialize漏洞利用模块。

这一行调用默认情况下内置exploit和辅助模块的mixin。mixin记录在MetasploitFramework维基上。 ysoserial_payload方法有两个参数：ysoserial有效负载名称和要运行的命令。

查看完整的漏洞利用方法，该模块生成PowerShell有效负载，将其嵌入到缓存的ysoserial JSO中，然后将其全部捆绑到HTTP POST请求中。

修改JSO漏洞利用

从用户的角度来看，漏洞仍然是响应式的，JSO生成在后台发生。以下是Metasploit会话的输出，使用hp_imc_java_deserialize在HPE IMC中利用未经身份验证的RCE：

假设Metasploit用户发现该模块中使用的JSON1对象被入侵检测系统（IDS）或基于黑名单的服务补丁捕获，则可以修改该模块以使用新库（在这种情况下，要用CommonsBeanutils1库）。

例如，将Metasploit模块hp_imc_java_deserialize.rb中的第101行更改为使用“CommonBeanutils1”而不是“JSON1”会产生以下会话输出：

识别JSO漏洞

防御者可以检查其网络中的JSO依赖服务，特别关注针对公网的可访问服务。例如，检查或监视已知严重依赖JSO的服务的HTTP标头。此外，使用Nmap等网络扫描工具，它们集成了脚本来识别基于JSO的T3协议。最后，监控并使用MetasploitFramework对已知的易受攻击服务进行实际测试。

对JSO进行被动监测

持续监控和响应这些漏洞会非常乏味。为了预先防御这类漏洞，主动防御者可以搜索有问题的协议以及针对这列攻击的指纹和文件标识。由于JSO具有明确定义的结构，因此可以在文件和网络流量中查看其标志字串。最明显得标志是JSO开头的“魔术字节”序列。例如，监视HTTP参数和二进制协议中的模式很有用：

aced是标识JSO的“魔术字节”序列的十六进制表示。

aced 00 05表示Java序列化格式的常用版本5。

%C2%AC%C3%AD%00%05与上面一样，不过格式为URI编码。

rO0AB与上面一样，格式为Base64编码。

需要明确的是，这些模式既不是JSO必须的，也不是JSO独有的。对他们需要进一步分析，因为他们预计这有权访问该文件或网络流的攻击者能够注入恶意JSO。

如果这些模式被确认为是JSO的服务在使用，则需要更密切地监视它们，对它们进行沙箱化以减少潜在的危害，或者与供应商进行讨论研究，以了解它们是否已经使用可以被利用的有漏洞的库超。

对JSO服务的积极扫描

许多基于Web的服务在HTTP标头中或响应主体内包含版本字符串，允许管理员和攻击者识别响应Web请求的软件名称和版本。对于Oracle WebLogic，HTML响应包含以下字符串：

端口扫描工具（如Nmap）可以监视上述字符串，然后使用T3协议与主机协商，以提取有关服务器版本和状态的更多信息。

最后，Oracle WebLogic和其他依赖JSO的服务有一些公共漏洞。 Metasploit中包含许多此类漏洞并且会不断更新。

结论

对于基于Java的服务中未经身份验证的RCE类攻击，JSO是一种越来越可靠的手段。NIST CVE公告和公开的此类漏洞在过去三年都有大幅度的增加。由于Java对文件和网络流的固有信任导致了JSO相关功能的潜在缺陷，因此各种基于Java的软件产品很容易受到反序列化攻击。Rapid7的研究表明，这些产品很多可以在互联网上公开访问，并且经常接受用户提供数据，而没有任何特殊过滤。 Metasploit Framework支持基于ysoserial的JSO的本地使用的支持，可以简化其测试，安全开发和实现的研究。

除了对依赖Java的主机和服务进行持续漏洞修补和监控之外，防御者还可以考虑为JSO事务中存在的签名添加监控，既可以使用基于JSO的通信主动识别服务，也可以识别针对反序列化漏洞的攻击。

来源：freebuf.com 2019-03-29 17:07:28 by: ijzmesec