验证是否存在写文件漏洞小技巧

问题背景

在安全黑盒测试时遇到一个疑似能写任意文件的漏洞点,想要验证漏洞是否存在。

这里就猜测后端代码可能如下:存在可能的任意写文件漏洞,可写的内容部分可控、服务权限未知

1
2
3
content = "something start" + "用户可控的内容" + "something end"
f = open("用户指定的文件路径", "w")
f.write(content)

最开始用”写入ping dnslog命令到crontab”来验证写文件漏洞是否存在,不过验证失败了,可能因为下面两个原因:

  • 目标机器没启动cron服务
  • 服务身份可能不是root,没有权限写 /var/spool/cron目录和/etc/crontab

也可以写内容到 .bashrc、web路径、常用文件(比如bash、ping等),但这些方式都有一点限制:

  • /root/.bashrc因为服务身份不一定是root,所以可能写入失败
  • .bashrc需要登陆到机器才能触发
  • web路径位置未知
  • 写常用文件(比如bash、ping等)可能影响目标系统的稳定性,并且需要等待目标操作才能触发

我这里只想要快速验证”写文件漏洞”是否存在,确认存在后,再来尝试上述或者别的方法来做漏洞利用。

为了验证”写文件漏洞”是否存在,我的思路是 能不能找到一个特殊文件,写内容到此文件会造成延时或者产生dnslog。

我能想到的特殊文件包括:

  • 管道文件
  • /dev/tcp/{host}/{ip}
  • socket文件
  • 标准描述符 (/proc/self/fd/0、/proc/self/fd/1)

下面就是验证这些文件,哪个符合需求

分析过程

  • 管道文件

    思路:找到系统上默认的管道文件,并且验证写入文件是否阻塞

    1. 找出系统默认的管道文件

      1
      find / -type p

      可以看到CentOS 7.9系统默认存在一些管道文件

      1
      2
      3
      4
      5
      /run/dmeventd-client
      /run/dmeventd-server
      /run/systemd/ask-password-block/136:4
      /run/systemd/sessions/1.ref
      /run/systemd/initctl/fifo
    2. 验证上面的管道文件,有一个可以利用

      echo 1 > /run/systemd/ask-password-block/136:4 会阻塞

      这个文件在其他系统文件名略微有点不同,并且只有root用户可以读写

      1
      2
      另一个CentOS7.9: /run/systemd/ask-password-block/136:0
      ubuntu:/run/systemd/ask-password-block/136:2

    小结:可以用 /run/systemd/ask-password-block/136:{id} 文件来探测是否存在文件写漏洞,前提是服务有root权限

  • /dev/tcp/{host}/{ip}

    在bash反弹shell中会用到这个。

    它不是文件,只是bash解释器会对/dev/tcp对特殊处理,代表了一个tcp socket。

    所以它不满足需求。

  • socket文件

    操作socket文件不是open、write、close这一套流程,所以肯定不行。

总结

  • 可以用 /run/systemd/ask-password-block/136:{id} 文件来探测是否存在文件写漏洞,前提是服务有root权限。

最后,感谢和我讨论这个小问题的朋友。