一次异常艰难的渗透测试 Link to heading

0x01 暴力破解 Link to heading

朴实无华的弱口令，我都怀疑是不是交互式蜜罐。

image-20240804223133579

0x02 文件上传 Link to heading

该系统所有文件上传功能均通过同一方式进行上传。

image-20240804193824119

文件列表，可以看到文件上传后，从文件列表处能看到FileDir+FilePath为文件路径的存放路径，文件名为GUID去掉-号。

image-20240804194207249

而系统对文件的加载方式是通过FileGUID对文件进行加载，FileGUID不存在注入。

image-20240804194659926

0x03 SQL注入 Link to heading

通过对各个功能点进行测试，最终在投票功能的修改参与人功能中发现了注入功能点，得到用户表为t_userinfo，而且看起来是可以执行多条语句的堆叠注入。

image-20240804195910697

涉及到DELETE和INSERT还是放弃使用SQLMAP，打个报错注入，嗯…吞字符串，使用substr分割就行，但是太慢了，不是我的风格。

image-20240804200913637

并且测试时发现在堆叠注入中可以把数据直接返回，开发怎么写的代码…

image-20240804201454520

哟呵，还有waf，我前面这么敏感的操作你都不拦现在给我拦了？看起来应该不会太强大。

image-20240804202038942

果不其然，最终加上左右括号就绕过了。

image-20240804202250145

最终读取到管理员的账号密码，进入后台一顿测试，终于还是什么都没有发现，回过头来研究研究注入吧，mysql拿权限的方式不多，而且是普通用户权限。

image-20240804202845708

0x04 组合漏洞 Link to heading

难道就这样结束了吗，突然灵光一闪，堆叠是吧，前面的图片加载方式貌似就是通过FileGUID从数据库查询保存的路径来读取文件，那岂不是可以通过堆叠设置文件路径读取任意文件？

image-20240804203750703

image-20240804203909321

那么下一个问题，web路径呢？有没可能目标中间件是Tomcat，~试试

image-20240804204936687

image-20240804204604100

只能说运气不错。

image-20240804204734576

0x05 读取源码 Link to heading

读取web.xml，还发现了一个/admin/login.jsp，划重点后面会考，当时没有注意这个位置。

image-20240804205514799

先读取源码如com.xxx.core.filter.SecurityFilter在tomcat的文件位置为/webapps/ROOT/WEB-INF/classes/com/xxx/core/filter/SecurityFilter.class，当然开发有可能把核心打包为jar文件放到/lib/目录，那就没办法读了，猜包名太难了。

image-20240804210310848

MD，FileDir还有长度限制，但问题不大，因为还有读取文件的方式是FileDir+FilePath，超过长度的字符写在FilePath就行。

image-20240804210739386

image-20240804210831227

依照此方法+源码内部依赖的类，我获取了部分的源码，并在其中审计了一些漏洞，如认证权限绕过，注入点等。但是还是很可惜没有办法getshell，因为这个网站的开发非常神奇，后续会为大家介绍。

0x06 后台登录 Link to heading

有点烦，后续进行了：读取tomcat日志，log4j日志（不存在log4j漏洞），配置文件、猜测jar包名、备份文件（webapps/ROOT.压缩文件后缀、绝对路径tomcat.压缩文件后缀等）各种一顿操作，虽然没啥用，但也获取到了一部分的信息，这在后续给到了我很多帮助。

回到web.xml，访问了/admin/login.jsp，大概是这样（自己画的）

image-20240804212631441

使用数据库之前读取的到前台管理用户账号密码发现登录不了，难道存在另一个表了？配置之前获取到的log4j的debug日志找到了执行的sql语句，尝试读了一下，发现居然读不到该表。

？？？惊呆了，不对，有一万分的不对，再详细的回想一下，我从数据库配置文件中读取到的明明是root用户，而注入执行的是普通用户。

image-20240804213756195

仔细的审计了一下获取到的部分源码，狗东西跟我玩这一套。

image-20240804214027481

网站的大概设计是：前台通过SourceCode和ROOT的数据库，获取数据库中的配置好的数据库配置信息，设置一个新的数据源，前台的数据都从这个数据源获得，所有导致注入点获取的是普通用户权限的配置源，而不是ROOT用户的。

不过他获取配置源的位置存在注入，也就是说我们依旧可以使用ROOT的通过注入执行语句，不过这次的是selectOne不是堆叠，问题不大，我主要是想获取它的后台密码。

image-20240804215049384

0x07 jdbc反序列化 Link to heading

在后台中第一时间发现了数据源配置的功能点，和我之前猜想的一致，第一时间想到打jdbc反序列化，很可惜目标不出网。

image-20240804215614205

0x08 RCE Link to heading

后台功能点也不算多，能测的都测差不多了，不过有个位置是用来调试sql语句的位置，至于为什么有这个功能，因为他本身就是通过后台配置功能点，来实现对网站接口动态控制，我之前获取到的源码，基本上就是公共类的实现。

找了一会找到了一个ROOT权限执行的语句的功能点。

image-20240804220524249

查询secure_file_priv

image-20240804220649620

日志写入getshell

…….这开发脑子有坑，这SQL语句还用XML解析，服了不用想就知道是<>这两个符号导致的。

image-20240804221358954

xml转换一下

< 转换为 &lt;
> 转换为 &gt;

image-20240804221917617

访问一下文件，打完收工。

image-20240804222040408

0x09 总结 Link to heading

一次很有意思的渗透测试：

从暴力破解——》普通用户权限注入——》堆叠注入+文件下载的任意文件读取——》配置文件+源码审计——》ROOT权限SELECT注入——》读取后台账号密码——》jdbc反序列化不出网——》ROOT权限执行SQL语句功能——》日志文件写shell——》xml格式踩坑

打码太多实属无奈。