一个简单的目录列表导致的RCE

声明：文章中涉及的程序(方法)可能带有攻击性，仅供安全研究与教学之用，读者将其信息做其他用途，由用户承担全部法律及连带责任，文章作者不承担任何法律及连带责任。

信息搜集

目标为 redacted.com

使用的子域名枚举工具有：

$ subfinder -d redacted.com -o subfinder.txt
$ amass enum -d --passive redacted.com -o amass.txt
$ echo redacted.com | assetfinder --subs-only | tee assetfinder.txt
$ cat subfinder.txt amass.txt assetfinder.txt | sort -u | anew subdomains.txt
$ cat subdomains.txt | alterx | anew subd.txt

如上所示，在收集了所有子域之后，将它们保存在一个名为subd.txt的文件中。

解析子域并检查有多少子域是活的或状态码为200的。使用httpx，然后将输出保存在一个文件中，例如这里为live.txt。

$ cat subd.txt | httpx -mc 200 | tee live.txt

再次使用httpx工具来找出每个子域的标题和技术栈。

$ cat live.txt | httpx -td -title

发现一个子域名hr.redacted.com的index of/，(这里笔者简单解释一下:"Index of" 是一个目录列表页面，用于显示网站上一个目录下的所有文件和子目录,可能会包含敏感信息)

要想不费吹灰之力找到目录列表，请使用所有的技术收集所有的子域，然后用上述标志[-title -sc]运行httpx

在后台的所有活的子域上启动了nuclei，并开始手动寻找目录列表的错误配置和人力资源管理子域。

从/uploads这个端点上启用的目录列表中，没有泄露任何敏感或内部数据

开始通过删除端点来查看子域，发现子域的端点/teamlevel以层次结构的形式保存了所有员工的信息。可以通过点击任何员工的名字来查看他们的详细信息

发现子域名本身泄露了员工的PII数据，如专业电子邮件id，个人电话号码，名字，姓氏，爱好/兴趣等。

继续深入挖掘

开始模糊测试，发现一个接口/hrms，要求员工的电子邮件地址来登录/授权。我已经从子域的每个员工的电子邮件id。目前已经有了子域中每个员工的电子邮件ID。

输入了一个电子邮件ID，没有任何密码或OTP，我登录到他们的后台(Dashboard)，发现可以更改其中的数据

现在，有了可以使用的输入框和文件上传功能。

开始使用输入框，首先尝试在所有四个框中输入XSS有效负载<img src=x onerror=prompt()>，然后单击提交按钮。

啥都没有，再次访问子域，使用员工的电子邮件ID登录到后台。

输入的所有四个有效载荷都有警告框。由于访问控制不当和PII数据泄露，带来了4个存储的XSS漏洞。

文件上传功能测试

再次登录到仪表板，这次上传了一个扩展名为png的图像，并使用Burp-Suite拦截了请求。

将截获的请求发送到Repeater，并更改图像的扩展名，以检查web应用程序允许的所有扩展名。发现大多数图像扩展都是允许的，并且没有大小限制。

换个思路，尝试上传一个php文件，发现成功地上传它！

但问题是不知道它的存储路径。因为在不知道存储端点的情况下，无法执行命令

开始检查JS文件，每一个Burp请求，以获得任何东西，但是没有发现什么东西，突然检查了同一子域的目录列表，发现上传的php文件也在那里。

点击了那个php文件，现在能够执行系统命令!一个RCE就此发现!

有问题可以加我v: richardo1o1

福利视频

原文始发于微信公众号（迪哥讲事）：一个简单的目录列表导致的RCE