声明：文章中涉及的程序(方法)可能带有攻击性，仅供安全研究与教学之用，读者将其信息做其他用途，由用户承担全部法律及连带责任，文章作者不承担任何法律及连带责任。 |
相信这个页面大家很熟悉吧？看到此类页面，你会怎么做？让我们来看看国外小哥的做法，也许能给你带来一些启发。
首先使用 https://github.com/irsdl/IIS-ShortName-Scanner 进行IIS短路径的模糊测试，看是否存在短路径漏洞。
发现一些文件后，使用ffuf进行进一步的发现，然后就发现了一个EVOLUTION 的目录！
这个ChatEngine.svc 是开源的吗？经过简单的 搜索，发现确实是开源的！
居然是一个10多年前的开源项目，那它的 安全性也许就没有那么好了…
深入研究源代码，小哥发现了如下片段：
https://github.com/eStream/eStreamChat/blob/2417a12c0999609e3feedbf5281d07393b126c23/eStreamChat/Thumbnail.ashx.cs
查看源代码，在本例中是 img 参数，它采用参数“img”，并根据其值以两种不同的方式解析它，如果它在该参数的值中找到 UserFiles，它将尝试从直接连接服务器（LFI），因此可以使用路径遍历（LFI）轻松绕过（UserFiles/../wheredoyouwannago）
然而，通过分析可以发现响应并不是直接返回的，而是进入了 ResizeImage 函数，遗憾的是该函数不会接受我们尝试返回的数据类型，除非它是图像。
因此可以通过简单地访问该端点来过滤服务器上的图像或执行 SSRF 盲注。
在本地服务器上尝试 LFI 时，发现并不需要指定 UserData 路径：
往期回顾
原文始发于微信公众号（迪哥讲事）：IIS页面中存在的LFI
免责声明:文章中涉及的程序(方法)可能带有攻击性，仅供安全研究与教学之用，读者将其信息做其他用途，由读者承担全部法律及连带责任，本站不承担任何法律及连带责任；如有问题可邮件联系(建议使用企业邮箱或有效邮箱,避免邮件被拦截，联系方式见首页)，望知悉。
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论