概述

Java序列化对象（Java Serialization Object，JSO）是 Java 语言中在不同Java程序之间进行数据交换的机制，通过 序列化 和反序列可以在程序保存和恢复Java执行态的对象，JSO给Java开发带来极大的方便，但同时也是个极大的安全隐患。JSO给攻击者提供了一个稳定可靠的载体，来实现对Java APP的攻击和远程控制。近年JSO的反序列化漏洞层出不穷，针对JSO的攻击也越来越多。比如知名Java框架Stuts 2，基本上成了一个筛子，一股脑暴露了几十个安全漏洞，其中很多都是反序列化漏洞。近期知名安全Rapid7近期发布了一份关于JSO的安全研究报告，论述了有关JSO的安全问题，反序列化漏洞的影响，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中。

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

WebLogic T3部署调查

由于最近报告的漏洞都涉及Oracle WebLogic T3协议。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.0nAS:2048nHL:19nn

字符串”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%是中国，其他国家和地区：

分布最多的10个国家是：

数量最多的十个组织是：

对JSO的服务 渗透测试

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

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

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

JSO漏洞监控

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

对JSO进行被动监控

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

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

ac ed 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的研究表明，这些产品很多可以在互联网上公开访问，并且经常接受用户提供数据，而没有任何特殊过滤。

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