Java安全笔记两篇-某国防系统的黑盒审计

本篇文章是安全笔记类,共两篇,节选自习科内部黑皮书第12章第2篇以及第79章第3篇,每篇篇幅不长,但是小编以为这两篇应该是属于较为经典的Java安全案例。两则案例第一篇出自某国防系统,第二篇出自欧洲某银行斯德哥尔摩总部内网。

某国防代码黑盒审计

本系统使用struts1.2 + hibernate开发,服务器基于Windows IBM System x3550 32bit系统,由IBM公司负责搭建维护以及安全防护,已经无故障运行11年。

根据web.xml继续下载web-inf-status-onfig.xml并搜索file关键字发现了2个类处理file文件

继续下载这个2个文件反编译看源代码是否有上传漏洞。

上传组件审查不严 

第一个ResourcFileAct的文件源码里发现很多处理文件的,通过对程序源码的审计分析出upload部分确实有上传文件。
进一步通过对ResourceFileOP文件逆向源码分析出变量t取值为66的时候不会判断扩展名,储存的路径为/doc目录,于是可以通过代码的参数逆向出上传文件的html表单,修改后可以直接上传jsp的webshell后门。

构造html上传表单如下:

上面的表达虽然很多变量时自定义的,但是通过上面的源码可以知道上传到服务器的文件其实是根据服务器的时间自行命名的。

因为每一秒生成的文件的名称都不一样,因此很难找到上传后的路径。

本来想通过穷举访问得到系统生成的webshell地址,但是获取失败。通过http头部信息发现服务器时间与实际时间相差8个小时 -_-! 生成时间太难控制,因此另寻他路。

另外在FileManagAct代码中发现代码中有权限控制,但是可惜没绕过。只好继续回到最初的地方。上面的上传虽然提示成功,但是没返回路径,抓包也抓不到,于是用到比较笨的方法。

继续逆向相关的函数,发现有个函数是查看所有文件的,只要猜对了上传的Id。经过二分法查找,发现前面的上传文件的id为3375。

这个地址只要有内容,就说明id正确了。uId则是前面html表单中的hidden变量。继续逆向源码:

发现新的函数可以获取地址,于是shell 地址返回成功:

最终成功得到正确的webshell地址


总结起来一共有3步:

  • 构造上传的html表单利用upload函数上传
  • 二分法通过edit函数找到正确的文件id
  • 根据文件id带入modify函数得到上传后的正确路径

笔记下面部分为清理数据库痕迹,读密码,转发进内网,控制ldap等内容,均与java安全无关,这里就不贴了。

_________________________________________________________________

接下来我们来看第二篇

欧洲X部内网笔记

通过对web.xml的分析发现spring + struts2架构,并发现spring配置文件

但是我们在/WEB-INF/classs目录没找到相应的xml文件,那是放在jar包里,j2ee的jar包一般放在/WEB-INF/lib目录下。这/lib目录找到了 _wl_cls_gen.jar 这个文件文件。

(PS:如果这个目录没有,可以去容器的lib目录下找)

找到jar文件之后,打开前面出现的配置文件 applicationContext.xml

但是没有发现数据库的连接信息。看到最后发现这应该是分布式部署,比较符合银行系统的规范,整个系统通过jndi调用。

在 applicationServer-webLogic.xml 发现如下代码(重点部分已经标注)

看到上面配置文件标注出来的“t3://cc-p-d22-c02-s01.cr.root4.net:7501”,于是去找weblogic的配置文 件。可是在 config.xml 中并没有发现“t3://cc-p-d22-c02-s01.cr.root4.net:7501”这串配置信息的出现。因此估计可能是在内网的另外一台 机器上了。
那只好尝试远程桌面操控了,因为机器与外网隔绝,整个网络装有定制的企业级杀软以及硬件防火墙,wce等读管理员密码的工具根本上不去,只好自建用户。

虽然系统环境为Windows跑Java,但是因为Weblogic运行于特别配置的Weblogic权限,无法创建用户(包括shell.user组件 等)。服务器没有太多的可提权的软件,windows的提权的exp又上不去,尝试过zip打包也不行。这都不是什么大问题,最大的问题是虽然有java 环境,但是使用java上传时系统提示“Package org.apache.commons.fileupload does not exist.”

不跟系统较死劲,好在system32可读可写可,把cmd复制出来并替换掉sethc.exe做成shift后门。

在服务器上ping发现外网不通,但是DNS能解析,好在硬件防火墙允许对外网开放80端口,只好复用端口并多层转发出来了。

 

每层转发的跳板以及接收转发的控制终端都是绝对G口,但是界面还是几乎卡死,因此这是绝对的下下策。

登陆界面最值得关注的地方是“Server in Solna”,这是个在斯德哥尔摩非常近的小城市,也就是说虽然银行总部在斯德哥尔摩,但是机房总部是在Solna,如果搞一些Solna的服务器用来接收转发应该速度会快一些。

按下5下shift大约十分钟,出现了cmd界面,但是system权限添加的服务器管理员并不能登陆服务器。服务器中administrator的上次登陆时间为2007年,毅然决定将密码修改掉。

修改了administrator并没有看到回显,而且也登陆不上,administrator账户上面有个未知用户组*Tivoli_Admin_Privileg不知道是个什么用户组,net localgroup也看不到,因此在笔记中记录下。

这样就只好把cmd换成explorer了。

登陆服务器以后,在服务器发现一些遗留的配置,通过这些配置发现一些数据库连接信息,有可能是管理员留下的。

不过Weblogic的程序数据库连接一般都是用weblogic自带的,本身就用3DES加密的。

数据库配置目录一般保持在 /config/jdbc/xxxx.xml ,程序是通过

这段标签中OmegaOnlineDS的名称去调用的相应的配置,下面来说说怎么解密Weblogic中数据库配置信息的3DES加密。

首先要了解weblogic的版本号,一般在bin目录下启动文件可以看到,本次的版本是weblogic 10;

然后是DES加密的密钥,密钥肯定会有,因为密码被3DES加密后连接数据库就必须要解密才能连接。这里weblogic的密钥在

目录下有个bat的文件,下载文件到本地,有密钥就可以进行下一步了;

下面用密钥解开密码,再把weblogic解密程序拿下来就可以解决了。每个版本不一样,首先先把weblogic.jar下载下来再把些相关jar下载 到本地,然后直接调用weblogic的函数就可以解密了。相关代码已经编入习科档案库,档案提取码nojtx3。

其实还有些可以从程序本身的jar和配置文件里找,J2ee 一般大型项目都是分布式部署的+ 集群部署的,能搞到一台机器权限其他的基本上能把数据拉下来。

遗留一些数据库配置(解密时已去掉重复密码):

这是config.xml配置密码(解密时重复已去掉):

笔记到此结束,特别鸣谢习科安全团队及伍XJ同学提供的指点。

[via@习科团队 / 习科_伍XJ]