点击手动备份之后，需要输入登录密码和一个加密密码，加密密码是可以任意输入的；确认之后，就会返回给你一个压缩包，打开一看是这样的一个结构

看到这个properties文件还是有点激动，当时还以为这里面可能会有数据库密码之类的东西，数据库拿下了getshell的几率不就大大增加了吗（这个公网ip是开放了一个mysql服务的）；

于是怀着激动忐忑的心情点击解压，但输入了登录密码、加密密码都不对，这个时候我就有点懵逼了，敢情你这个加密密码就是个摆设？

怀着*了狗的心情，又去看了下这里的还原功能，发现就是备份的逆逻辑，在你上传一个压缩包之前同样需要输入加密密码；于是猜测这里的加密密码后端是做了一些处理的，单纯的使用加密密码无法解压备份文件

这个时候，首要任务是找到后端对这个加密密码的处理逻辑；首先我抓包看了下这里的包，发现这里的登录密码和加密密码传送到后端时是经过加密了的，于是我大胆猜测这里前端的加密可能和后端的一致；

经过一天对前端 JS 的分析，总算是分析出了前端的加密逻辑，然而我还是低估了这个系统的开发人员，加密后的密码依然不能解压备份文件

PS：这个时候我真心觉得这系统是真TM安全啊

没办法了，和小伙伴吐槽了一通，他建议我去官网找下产品手册，也许手册里有写相关的内容呢；我只好抱着死马当做活马医的心态去官网翻了一遍，手册没找到，倒是找到了一个修复补丁包

里面不但有后台的部分代码（class文件），还贴心的告诉了你补丁包的具体使用方法，比如安装路径等等。

真就离大谱，这种东西为啥会直接放出来。直接代码包解压，导入idea，开审！

首先要找到备份相关逻辑，直接全局搜索对应的路由关键字，找到了后端对加密密码的处理逻辑，用加密后的加密密码去解压备份文件，可惜的是备份文件中并没有我想要的信息，只有这个后台相关的一些数据库数据，没任何鸟用；没办法了，只有对这残缺的代码继续审了，幸运的是，很快就从这个系统引入的依赖发现了突破口

这里引入的 ant.jar 包版本是漏洞的，在它对压缩包进行解压时，没有正确的对 ../ 进行处理，会导致目录穿越的发生；由于之前补丁包中告诉了我们正确的web路径，所以这里大概率是能getshell的

首先我们构造一个形如这样的压缩包

opt里面即是该系统的具体web路径+webshell文件，构造完之后还需要使用加密后的加密密码对该压缩包进行加密

PS：这一步其实坑挺多的，构造目录穿越压缩包的脚本很多，但基本没有提供压缩包加密功能；提供压缩包加密软件的又不能构造形如 ../ 的目录（当时脑子卡了，后面才想到用linux的命令应该可以构造），最后是使用了某国产数字压缩软件成功进行了构造（国产YYDS）

将构造好的压缩包通过备份还原功能上传，成功getshell

文章来源：先知社区（zerotwo）

原文地址：https://xz.aliyun.com/t/11526

转自：李白你好