vulntarget-m | MssnHarvey

type

status

date

summary

前言

拓扑

入口机为双网卡，外网可以根据自身情况，设置桥接或nat模式，内网ip固定位192.168.137.20

内网机02为仅主机模式，ip固定位192.168.137.10，该ip不能变更。

内网机03为仅主机模式，ip固定位192.168.137.30

三台机子的账号密码均为vulntarget，该密码仅限调试环境使用，并不是给你用来应急的，应急需要从漏洞打进去才能应急

注意事项

本次环境vulntarget-m内网靶场主要为内网渗透+应急响应设定，其中应急部分主要涉及java内存马、后门等，因为在靶标中含有多个内存马，所以您在本地使用Vmware复现该环境时，只能够通过回滚快照的方法来重置环境，不能够将环境直接重启，重启会导致内存马失效。

同样因为内存马的特殊性，可能会导致在攻防时出现一些问题，例如在注入内存马时因为路径问题、类型问题导致的覆盖、冲突等，这时可能需要多次尝试。

环境描述

某公司将自己公司的业务搬到了云上，并存在内网服务，公司运维人员主要通过远程ssh登录入口机，对服务进行日常维护和管理。

在前段时间，某国外黑客发现该公司的入口机存在漏洞，并入侵了该机器，同时可能入侵了内网系统。

运维在今日登录维护的时候，发现ssh无法登录，经过排查发现ssh密码目前已经被修改。

由于环境特殊，暂时无法通过其他的方法对机器进行重置密码，且由于业务的重要性，不能够对服务器进行重启等。

根据以上条件：

请利用先攻再应急的特殊思维方法来进行应急。

任务目标

对3台机器进行应急排查，对其中可能的后门进行排查

不能够重启机器（重启则判定应急失败）

在你认为应急成功之后，请获取对应的flag，并对你获取的flag进行check

信息收集

扫描存活主机和端口，发现开放了22、80、7848、8848、9848、9849端口

访问80端口界面如下：

存在一个登录口，经典fastjson靶机界面

然后看7848、8848这几个端口应该就是nacos服务，直接请求8848端口是它的Web控制台如下：

web打点

Nacos Hessian 反序列化

可利用Nacos身份绕过漏洞登录后台，后台可以得到一些配置信息，但是都没太大用处无法拿到权限

接着尝试Nacos Hessian 反序列化漏洞利用成功

一、冰蝎内存马： 1、需要设置请求头x-client-data:rebeyond 2、设置Referer:https://www.google.com/ 3、路径随意 4、密码rebeyond
二、哥斯拉内存马： 1、需要设置请求头x-client-data:godzilla 2、设置Referer:https://www.google.com/ 3、路径随意 4、密码是pass 和 key
三、CMD内存马： 1、需要设置请求头x-client-data:cmd 2、设置Referer:https://www.google.com/ 3、请求头cmd:要执行的命令

这里有个问题，用冰蝎始终连不上，可能这同时注入内存马出bug了

换成哥斯拉就成功连上了

应急响应Ⅰ

线索：运维在今日登录维护的时候，发现ssh无法登录，经过排查发现ssh密码目前已经被修改。

查看passwd和shadow文件，在passwd文件中可以发现bt用户给出的用户内容格式是个不寻常的格式，通常不会在正常用户中出现（正常的用户应该包含用户名、经过加密的密码哈希值、以及其他相关的用户信息）

接着我们发现异常用户bt曾经登陆过，还是个特权用户

于是删除bt用户（回显用户不存在我还以为失败了

应急成功，拿下flag1：flag{6c3742aaf26a6dea7fe9d7731de59517}

内网渗透

代理配置搭建就忽略了~

发现第二张网卡：192.168.137.20

直接上fscan扫，发现存活IP：192.168.137.10和192.168.137.11

接着再单独扫一下这两个IP，两个均开放了22和80端口

shiro CB链反序列化

192.168.137.11的80端口访问如下：

抓包测试可以发现请求包的 Set-Cookie 中出现 rememberMe=deleteMe，说明存在shiro框架

在前面nacos的配置文件中可以得到shiro的key

直接工具检测一下发现有可利用链

成功注入内存马

应急响应Ⅱ

查看passwd和shadow文件，同样发现一个可疑用户guest

接着再来查看系统日志、登录历史等信息，发现guest用户也在9.26登录过

于是删除guest用户，并且执行get_flag检测失败

接着在/home/vulntarget目录下找到可疑文件app.jar，下载下来反编译看一下即可确认就是这个文件有问题

然后利用工具arthas实现内存马热更新

首先把jar包反编译导出后，将反编译有问题的地方修改下，再把/bin/sh给改一下让它不能执行

接着分别将arthas-boot.jar和arthas-tunnel-server-3.7.1-fatjar.jar以及编译好后解压得到的UserController.class都上传到/tmp目录下，首次运行会出现如下报错：

这里需要在本地去执行一下，它会将.arthas保存在用户的隐藏文件下

然后再把它打包上传，由于该靶机没有unzip，我们将其打包成tar包，在/root目录下上传并解压

解压后再去执行就可以成功进入Arthas工具中

最后重新转换已加载的类文件实现热更新，再反编译这个类的源代码，可以发现修改成功了

应急成功，拿下flag2：flag{4b15f4d146ef4c128064f952ba11b874}

fastjson c3p0链二次序列化

接着来看192.168.137.10的就是前面192.168.230.128的web登录页面，探测具体版本发现被拦截了

PS: 前面拿burp的插件直接打bcel没成功应该也是被拦截了的缘故

利用Fastjson默认会去除键、值外的空格、\b、\n、\r、\f等特性，并且还会自动将键与值进行unicode与十六进制解码

在fastjson中，当解析json字符串时，它会自动解码Unicode和hex编码字符。因此我们可以尝试利用该特征来实现编码绕过。我们先来尝试将利用报错回显来判断版本号的poc进行Unicode/hex编码，可以看到这里抛出异常显示出fastjson版本号1.2.47，说明可以通过Unicode/hex编码成功绕过waf

或者拿yakit的插件可以检测到其版本为fastjson 1.2.47

现在已知fastjson版本1.2.47，能打的链子就是bcel、c3p0和common-io链，并且测试可知是不出网的，jndi就不适用了，于是尝试利用Unicode编码绕过来打一下bcel，payload如下，tomcat那里需要换着测试

https://github.com/Getshell/Mshell/tree/main/03-%E5%86%85%E5%AD%98%E9%A9%AC%E5%AE%9E%E6%88%98/01-Tomcat

但是这个应该是没tomcat打不了bcel

然后common-io链靶机应该也没有那么多依赖（估计实战中才会遇到这种，坑很多），所以就只能打c3p0链了，因此下一步探测存在的依赖，利用Character转换报错可以判断存在何种依赖

参考文章：
https://xz.aliyun.com/t/12492#toc-3
https://www.sec-in.com/article/950
https://y4tacker.github.io/2022/03/30/year/2022/3/%E6%B5%85%E8%B0%88Fastjson%E7%BB%95waf/

依赖检测项目

RequestMapping本身为SpringBoot下的类，当存在该类时会报出类型转换错误，说明为SpringBoot项目