记一次从敏感信息泄露到服务器权限
日期: 2021-04-11
作者: Mr-hello
介绍: 敏感信息泄露漏洞是不是有点鸡肋？跟我了解一下吧！
0x00 前言
某日，甲方爸爸在群里扔过来一个 txt。看的我是头皮发麻，里面有三个域名，20个 IP 地址。让我去搞一下，看看有没有什么问题，我一看这不讲武德啊，这么多东西，我怎么看？只好掏出扫描器，把文档里面的 IP 、域名一股脑的全部扔进去，等扫完再说吧。
0x01 进展
中午吃过饭，又睡足了觉，总不能当个咸鱼吧？虽然我确实是，但是我觉得还能扑腾一下。
打开上午的扫描器，看了一眼发现还不如不看，20个 IP 只有三个存活，而且两个没开 WEB 服务，一个开着 tomcat 默认页面，但是删除了登录功能，再看了一下三个域名，只有一个有东西，其余的两个扫描出来的东西是空的。
这，这，这我怎么玩，含着泪打开了最后的希望，最后那个域名的扫描结果。发现有35条子域名记录，都指向同一个 IP，然后还有许多的文件泄露记录。
看到文件泄露的时候，我第一反应是这么多鸡肋的东西，这要看到什么时候，对我有用么。但是我也没办法，因为我没有别的更多的信息去入手，然后我耐着性子翻看起来自认为鸡肋的信息泄露。
翻着翻着我发现这个系统是 Spring-Boot 框架，想起来之前同事分享过几种利用方式，就翻出来记录尝试了一下，很明显失败了。此时我心情有点复杂，但是要继续保持微笑。直到我翻到了这个页面。
一个 Cms 的名字和 email ，然后我去百度了一下这个邮箱。发现了 github 个人主页，以及看到了源码。
然后在源码里我发现了这个项目的默认后台路径，以及默认账户和密码，经过尝试发现可以成功登录进去。
忘记介绍这个 8888 端口开放的服务，在这个目标域名的 8888 端口开了一个 Demo 站，里面的一些新闻都是用来测试功能的消息，可以猜测是开发在搭建环境时，开启 8888 端口进行测试，但是最终忘记停掉这个测试站。
在登进去后台之后，我的心情无比开心，因为很多后台都有文件上传的功能，并且可以无限制上传，我在翻找的过程中发现，该系统确实存在文件上传并且可以实现无限制上传，但是上传的那个目录，它不解析 jsp 。每次访问都是直接下载文件。
怎么办，怎么办，最终也没能解决这个问题，在网上百度到的原因是，某些 java 项目，引入的依赖包不全，导致 jsp 无法解析。我又没可能去写配置文件，所以只好放弃后台上传文件 getshell 这条路。
后面半个小时，我只好重新翻找它的源代码，企图能够找到一些别的敏感信息，最后找到了让我眼前一亮的文件目录。
接下来大家都懂了吧？我掏出来 shiro 反序列化工具就是一通操作。果然，它能够命令执行。
然后查看了其服务器信息，以及 IP 并且可以通外网，使用 tasklist 发现系统不存在杀软进程，由于是 Windows server 2012 ，可以直接执行 PowerShell 命令下载执行，直接上线 CS 即可。
在上线 CS 的时候踩了坑，本来想使用可执行文件进行上线，但是命令执行失败，应该是生成的可执行文件，在目标机器上无法运行，转为使用 PS1 文件，成功上线。
由于客户对内网渗透未做要求，在拿到服务器权限之后，就清除攻击痕迹然后提交成果了，何况自己的内网渗透功底也不够。
0x02 总结
这次任务的突破口就是一个简单的信息泄露，仅仅泄露了作者的邮箱，以及 CMS 名称，但是其后果是可以利用这些蛛丝马迹成功拿到服务器权限。所以这个信息泄露的危险等级应该怎么评定呢？或许给个高危也不为过吧！
其实总结来说，这个系统如果不是开发在用完测试系统环境之后忘记关停，也不会带来这个后果，再即使开着测试环境，但是没有这个小小的信息泄露，我也不会发现这是一个 shiro 反序列化命令执行。
所以说，开发人员，运维人员的关闭测试环境的习惯很重要，同样你也不要轻视一个小小的敏感信息泄露。
