一次几年前全程代码审计打点


一.    SOAP突破口

某个子域名下一眼就是那种很有可能突破的老旧jsp网站,单线程开扫,很容易在/services目录下发现一个AXIS报错。

合理猜想,这个网站肯定也经过几轮安全测试,AXIS这种直接展示SOAP接口肯定被当作漏洞报了上去。

但是,修复方案却可能是/services不再展示所有SOAP接口,而实际的SOAP接口,还是能够访问的。

修复之前是这样的。


/services                   展示/services/getUserInfo?wsdl/services/getUserInfo?wsdl  未授权获取用户信息

修复之后是这样的。


/services                  AXIS报错。/services/getUserInfo?wsdl 未授权获取用户信息

也就是说本质上只是把接口隐藏起来了,那么只需要从其他地方获取到原本的/services即可,通过fofa指纹搜索,成功在其他系统的上发现修复之前的/services。

然后就可以一个SOAP接口一个SOAP接口的尝试,发现确实有一部分无法访问了,但还是有可能从剩下的找到突破口。


通过接口名称,定位down相关接口,发现了一个任意文件下载。

通过读取/proc/self/environ和/proc/self/cmdline定位到tomcat的绝对路径,再通过指纹猜测到web目录名,最终成功下载到war包获得源码。

这个老旧系统确实写的有点漏洞百出,很快就找到了一个未授权任意文件上传的jsp入口。

但实战的过程中发现这个系统最初可能是为windows设计的,代码中的upload目录都写死了为【upload】。

而实际服务器是linux的,这使得最终会生成【uploadimgesxxxx.jsp】,而这种文件在tomcat中是无法访问到的。


继续审计,发现绝大部分功能都需要登录,包括一个zip解压接口,可以制作恶意zip包,用../穿越到web目录的漏洞。

因此获得用户登录态就迫在眉睫。


将目光重新转回/services,结合代码审计,发现了一个传输用户的uuid就可以查询用户信息的SOAP接口。

这个uuid毫无疑问肯定存储在数据库中,又在代码中某个test类的main方法中,找到了一个开发自己测试时用的uuid。

使用这个uuid+查询用户信息接口成功泄露所有用户信息,包括password字段,批量解hash,终于成功登录系统。


然而之前委以重任的zip解压接口却掉了链子,抄了代码在本地能够成功用恶意zip包解压穿越目录,服务器上却不行,不知道什么原因。

没办法,只能重新找其他能够RCE的漏洞。

在最终的不懈努力下,终于找到一个不用反斜杠的文件上传漏洞,获得webshell,进入内网。


由于机器存在负载均衡,内存马比较难用,因此仅打入一个简单命令回显内存马作为权限维持,快速使用webshell进行横向。


而最简单也最容易的横向莫过于它的数据库,是一个Oracle dba权限,因此可以直接使用MDUT进行命令执行。

测试后发现数据库服务器是一台出网的windows机器,上面只有一个360,是非常理想的权限维持手段,因此仅仅是在这台机器上部署了代理工具,方便进内网。


通过逐行写VBS绕过360下载文件,一直到演练结束这台内网机器都没掉。

成果:
172.x.x.57-59,三台负载均衡的老系统
10.x.x.161,Oracle服务器


二.    hr系统

通过简单的探测发现内网一台服务器的redis存在弱口令且权限很高,写ssh key成功getshell。


翻找bash_history发现它有着-uroot -pXXXXX的mysql本地连接记录,导致泄露了mysql密码。

随手su一下发现mysql和ssh密码是复用的。


那么果断拿这个密码去撞内网其他系统,最终撞到包括它自己在内的6个ip连续的主机,经过摸索,发现这6台主机为一个hr系统的集群,每台都独立运行一到两个服务,包括redis/mysql/nginx/多个springboot,且为测试环境。

那这么一想ssh密码6台主机复用就很合理了。


但测试环境上的数据很少,因此想通过测试环境横向到生产环境,生产环境是直接外网就可以访问的。


显然那就又避免不了代码审计了。

这次的hr系统相比于之前的jsp系统更加现代化,唯一的突破口是低版本fastjson。

但是fastjson唯一的parseObject入口藏得非常深,不但需要登录权限,而且构造参数很复杂。


但是通过认真审计后发现,hr系统使用的这个集群微服务模式,有个很大的缺陷就是它的鉴权系统也是单独一个springboot微服务。

也就是说,只要我不通过nginx反代,而是直接在内网访问它的其他springboot,就是完全不鉴权的。


那么hr系统生产环境通过内网fastjson+becl链打入filter内存马,并且将filter的路径设置在一个可以未授权访问的地方,比如css之类的路径,就可以在外网用冰蝎/哥斯拉连接了。


不过遗憾的生产环境没有密码复用的问题。

成果:
10.x.x.71-76,hr测试系统集群
172.x.x.224,hr生产系统

三.    办公网

hr生产系统中配置了一个邮箱账户密码,该邮箱是用来给重置密码的用户发邮件的,同时ldap地址指向了Exchange Server。

所以该账户还是一个低权限的域内用户,Exchange Server的IP则是192.x.x.x,在这个IP的附近,探测出了域控服务器,因此可以确定 192.x.x.x就是其办公网。


尽管hr生产系统中存储的用户密码hash都带非常强的salt,无法解出明文,办公网又只有域控和邮服两个IP可以访问到。

但此时的可操作性还是很大的。

1,利用Exchange Server的历史漏洞攻击
版本较高,未成功。

2,利用域控的历史漏洞攻击
因为我们刚好有一个域内用户来创建机器用户,满足很多域控漏洞的攻击条件。

但当时对域控的知识储备不足,加上时间问题没有选择利用。

3,篡改hr系统的前端登录页面,捕获明文密码。
需要重启springboot服务,修改模板重新打包,动作较大,怕服务启动不了打坏了,不敢尝试。

4,给用户发钓鱼邮件。
因为outlook web端是可以看到已发邮件的,也就是说历史上哪些用户重置过密码都知道,因此可以用这个邮箱进行定向钓鱼,即使办公网不出网也可以钓账户密码,成功率很大。


不过当时这个邮箱已经收到了很多其他红队的钓鱼邮件,此时再去钓可能效果不大,遂没有尝试。

因为靶标也不在办公网,当时没有在办公网上消耗太多时间,现在回想起来,打下办公网甚至域控还是有机会的。

四.    门户网站

前面说到我们仔细研读了hr系统的代码,发现这种springboot的微服务将鉴权组件剥离出来,导致内网springboot接口全部可以未授权访问。

同时又发现部分springboot是开启了actuator和swagger的,这些通过外网访问都是401,内网中却一览无余,甚至端口都是一样的。

因此进行针对性扫描,发现了生产环境内网的门户网站可以进行env攻击。


于是修改eureka.client.serviceUrl.defaultZone配置,打Xstream反序列化,测试成功之后直接用CVE-2021-39139打入内存马。

拿下门户网站可以说是离靶标非常接近了,因为门户网站是用来跳转到其他网站的,其中一个就是靶标。

最开始我试图直接通过代码审计,去调用生成靶标跳转链接的接口,最终发现是徒劳的,甚至怀疑这个接口被临时移除了,因为靶标那边报的既不是500也不是401,而是404。

随后就是通过代码审计来获得web登录权限,看起来很容易,但门户网站未存储任何用户信息,登录过程被SSO接管。

难道还要打SSO?

不,配置文件中最吸引眼球的是jwt配置,其中包括RSA私钥,也就是说,我们可以用RSA私钥来伪造jwt token。

仔细阅读代码和反复尝试后,终于伪造出合格的admin用户权限的jwt token,成功登录门户网站。


此时再去通过web上的正规前端入口跳转到靶标,却发现靶标入口还是404。

谨慎起见,也可能是需要符合条件的账户才行,但最终尝试了多个用户还是404。

成果:
172.x.x.172,门户网站

五.    靶标

不知道门户跳靶标是真的失效了,还是临时失效,反正就差这一步就能碰到靶标了还是挺让人灰心的。

不过门户网站上能跳转的网站着实不少,虽然这些都只能拿到web权限而不是服务器权限,但是还是有机会的。


理论上来说门户网站不存储账户密码,它跳转的网站也不会存储,甚至SSO大概率也是接了域控,也不会存储。

但我们注意到之前的老旧jsp系统和hr系统其实都是存储了的。

这可能时因为SSO+门户网站+跳转其他网站这一套,是比较后面才开发出来的,它们在逐步接管所有需要登录的系统。

而接管之前,这些系统还是用的数据库查表这一套。

那么接管之后,数据库的user表难道会第一时间删除吗?


答案是并不会,这些user表还是会作为历史遗留问题存在很长一段时间。


最后的突破口也正是其中一个user表。

既然门户网站能够跳转到很多网站上去,于是就挨个儿点过去,在其中一个会议网站上,发现了文件上传功能。

直接上传jsp没有阻碍,正是在这个系统的数据库中,发现了残存的user表,里面储存了一些密码hash,而且日期还是比较新的。


再次批量解密,结合之前的老旧jsp网站,整理出一批高质量的用户名+密码,手动尝试登录靶标。

门户跳转靶标既然失效了,靶标当然也没有被SSO接管,最终是成功登录上去了两个用户。

靶标的后台功能还是比较多的,正在逐步尝试后台漏洞时,演练却已经结束了。


最终虽然也算拿下靶标,但不是web高权限或者服务器权限,还是比较遗憾的。

再给多一点时间,靶标域控都有机会完整拿下。

成果:
多个web的admin权限
172.x.x.177,会议系统
靶标的普通用户权限


原文始发于微信公众号(珂技知识分享):一次几年前全程代码审计打点

版权声明:admin 发表于 2024年9月30日 下午5:51。
转载请注明:一次几年前全程代码审计打点 | CTF导航

相关文章