一. 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，会议系统
靶标的普通用户权限
原文始发于微信公众号（珂技知识分享）：一次几年前全程代码审计打点
