某某管家：从错误堆栈到root shell ; 论野生技术&二次元

发了CNVD，来来回回让我修改也不知道到底想让我写什么。估计他们也不在意，直接公开了。

一天晚上看到了某某管家的某活动，想做个一键脚本，于是打开Quantumult抓包。

跟踪请求发现关键参数来源于一个base64编码的迷之字符串request。

解码后发现是无意义的字符。猜想这个参数来自于app中用户的登陆，但是又不想重新实现整个登陆流程，所以开始研（xia）究（gao）这个request参数。

错误堆栈

尝试构造request，发现服务端竟然返回了错误堆栈

堆栈忘记截图了，我们来看看这个错误回显的开头部分：

<!doctype html><html lang=”zh”><head><title>HTTP Status 500 – Internal Server Error</title><style type=”text/css”>body {font-family:Tahoma,Arial,sans-serif;} h1, h2, h3, b {color:white;background-color:#525D76;} h1 {font-size:22px;} h2 {font-size:16px;} h3 {font-size:14px;} p {font-size:12px;} a {color:black;} .line {height:1px;background-color:#525D76;border:none;}</style></head><body><h1>HTTP Status 500 – Internal Server Error</h1><hr class=”line” /><p><b>Type</b> 异常报告</p><p><b>消息</b> 在 [46] 行处理 [/xxxxx/index.jsp] 时发生异常</p><p><b>描述</b> 服务器遇到一个意外的情况，阻止它完成请求。</p><p><b>Exception</b> <pre>org.apache.jasper.JasperException: 在 [46] 行处理 [/xxxxx/index.jsp] 时发生异常
43: return;
44: }
45: String requestStr0 = request.getParameter("request").toString();
46: String requestStr = AESCoder.decrypt(requestStr0, "一个base64");
47: System.out.println("requerst======"+requestStr);
48: JSONObject object = JSONObject.parseObject(requestStr);
49: String hgUserid= "";

我好像看到了一个密钥一个base64，解开是16个字节，因为没看到IV，盲猜了AES-128-ECB。在python中尝试后，发现成功解密之前的迷之request。

>>> cipher.decrypt(cc.decode('base64'))
'{"account":"一个手机号","area_no":"430074","timestamp":1582631414314}\n\n\n\n\n\n\n\n\n\n'

1 2	>>> cipher.decrypt(cc.decode('base64')) '{"account":"一个手机号","area_no":"430074","timestamp":1582631414314}\n\n\n\n\n\n\n\n\n\n'

果然request中并没有存储完整的登陆信息，只有一个登陆手机号；因此可以任意构造手机号，完成整个流程。

一键脚本就这样搞定惹。

root shell

有了AES密钥之后，脑子里奇怪的想法就变多了。

通过构造可以正确AES解密，但是不合法的JSON字符串，我们可以使服务端返回下几行的代码。

47: System.out.println("requerst======"+requestStr);
48: JSONObject object = JSONObject.parseObject(requestStr);
49: String hgUserid= "";
50: if(object.containsKey("account")
51: StringUtils.isNotBlank(object.getString("account"))){
52: hgUserid = object.getString("account");
53: System.out.println("hgUserid======"+hgUserid);

查阅各种文档后，没有发现其他行会有丢出异常的条件，所以看不到其他行的代码了。但是48行引起了我的注意，从（忘记截图的）堆栈中，我们可以知道这个JSON库是阿里爸爸的fastjson。

一说到fastjson我们就想到反序列化漏洞~~，今年下半年，中美合拍的……~~但是仍然要赌一把运维小哥有没有升级库和关闭AutoType。在网上随便找了一个POC之后，返回了新的错误堆栈（还是没截图），异常为”className not found”。说明确实有打开AutoType。

一顿Google之后，使用marshalsec 搭建RMI/LDCP reference server的方式利用。

起一个nginx，放入编译的反射到的类文件，需要编译成class文件，我们这里用了一个反弹shell
运行marshalsec的RMI服务器，这个服务器的作用是将来自受害主机的JNDI请求重定向到受我们控制的url。在这个例子里，我们重定向到第一步中的class
起一个nc等反弹shell

发现nc虽然接收到连接，却对命令没有回显。

Connection from xx.xx.xx.xx xxxxx received!
id



ls


as



^C

Connection from xx.xx.xx.xx xxxxx received!

查看nginx日志，发现Java版本是8u181。

xx.xx.xx.xx - - [26/Feb/2020:08:43:19 -0800] "GET /xx.class HTTP/1.1" 200 655 "-" "Java/1.8.0_181"

1	xx.xx.xx.xx - - [26/Feb/2020:08:43:19 -0800] "GET /xx.class HTTP/1.1" 200 655 "-" "Java/1.8.0_181"

通过一顿Google了解到，RMI方式在8u113之后被Java屏蔽，所以改用LDAP方式。

这次成功了，而且记得截了个图。

20202年了，为什么还要用root跑web服务。

结末的教训

别用root别用root别用root别用root别用root
出站流量规则同样很重要，可以挡住一些任意端口的反弹shell
使用fastjson如无必要，请关闭AutoType；反射一时爽，运维火x场
生产环境关闭错误回显，这次能成功利用到fastjson的洞，根本原因还是AES密钥的泄漏
- 2020/02/28 观察到已关闭