实战 | 记一次5000美金的文件上传漏洞挖掘过程
记一次5000美金的文件上传漏洞挖掘过程
大家好，最有趣的功能之一是文件上传，文件上传中的漏洞通常会导致您进入关键或高严重性，所以让我们从我在bug bunting时遇到的这个场景开始
假设我们的目标域是 target.com
在寻找我们的目标时，我遇到了 edu.target.com 子域，该程序提供的服务是一个教学平台，因为有不同类型的用户，如学生和教师，旨在帮助学生学习与技术相关的主题，如软件工程机器人等…
开始我们的故事吧 我遇到了上传功能，试图上传一张图片来分析这个功能是如何工作的
让我们尝试上传 PHP 脚本
我发现服务器没有响应
经过对应用程序行为的一些分析，我发现如果请求没有通过验证，连接将被关闭，服务器将不会响应请求
现在让我们尝试绕过对 php 扩展的验证
让我们首先通过尝试上传随机扩展来确定应用程序是在进行白名单验证还是黑名单验证，如果成功上传，这意味着应用程序在执行黑名单，如果不是，则意味着应用程序对特定扩展程序进行白名单验证
我试图上传 image.omar
文件已成功上传，这意味着应用程序正在执行黑名单验证
所以我尝试使用 rce.pHp 绕过验证
上传成功了
当时，我预计几天后我的银行账户会收到 5000 美元的奖金
所以让我们请求我们的 PHP 脚本来执行 phpinfo() 函数
rce.pHp 未执行
所以当时我想到的是，我们似乎能够绕过黑名单验证，但开发人员遵循的安全设计阻止了我获得 RCE
这可以通过多种方式发生，其中之一是将此标志添加到 .htaccess 文件中，这将使服务器不执行图像上传目录上的 PHP 文件
php_flag 引擎关闭
如果您不知道什么是 .htaccess 文件
.htaccess笔记：
.htaccess 文件是分布式配置文件，提供了一种基于每个目录进行服务器配置更改的方法，我希望开发人员在图像上传目录上使用它来防止 RCE
所以根据这个，我想到了2个场景
重写配置 && 路径遍历：
第一个场景：
注意：假设我的图像的url是：
https://target-domain.com/edu/sub-dir-1/sub-dir-2/sub-dir-3/our-image-here
1.1
也许开发人员将他们的“.htaccess”文件上传到sub-dir-1 / 目录，因此根据这个sub-dir-1 / 目录和子目录，包括我上传我的 php 脚本的目录不能运行 php 脚本，所以我们可以利用通过使用此配置在sub-dir-1 / sub-dir-2 / sub-dir-3 /.htaccess上上传不同的“.htaccess”文件来进行此错误配置，这将允许我更改 sub-dir-3/ 上的配置允许我执行 php 脚本
允许运行 php 脚本的配置
php_flag 引擎开启
1.2
好吧，也许开发人员没有进行这种错误配置，并且已经在我的目录sub-dir-1 / sub-dir-2 / sub-dir-3 /.htaccess 上上传了 .htaccess 文件，在这种情况下，我将通过上传文件名重写 .htaccess 文件.htaccess 与以前的配置，这将允许我执行 php 脚本
但不幸的是，我记得文件名被重写了，所以如果我们上传 .htaccess 将被重写为 /sub-dir-1/sub-dir-2/sub-dir-3/32-random-characters.htaccess 哪个对服务器配置没有影响
第二种情况：
2.0
在第二种情况下，我们将测试它以防第一种情况失败，方法是对文件名参数进行路径遍历，以从包含 .htaccess 文件的目录中退出，该文件阻止我的 php 脚本执行，因此我的文件将被上传到另一个目录，不在阻止执行 php 脚本的配置下https://target-domain.com/edu/edu/32-random-chars.pHp
开发人员从文件名中获取扩展名并将其放入端点扩展名中，因此开发人员可能使用弱正则表达式，将点后面的任何内容放入端点扩展名中，这样我们就可以通过添加点 (.)然后使用路径遍历payload将我们的脚本上传到另一个目录
没用，因为如您所见，开发人员似乎以正确的方式实现正则表达式验证（以防他们使用它而不使用像 php function pathinfo() 这样的内置函数）
SQL注入：开发人员在上传我们的图片时需要将每张图片与其用户连接起来
那么他们怎么能做到呢？
正确，使用数据库
如您所见，开发人员也将我们的文件名参数保存在某处
所以下一步测试 SQLI 的文件名参数，我为此使用了 BurpSuite来fuzz
但一无所获
公共漏洞：
但也许上传功能中的开发人员使用库来处理可能存在漏洞的上传图像
所以我开始测试一些利用 ImageMagick 库的常见库的漏洞，比如 ImageTragic
CVE-2016-3714、CVE-2016-3718、CVE-2016-3715、CVE-2016-3716、CVE-2016-3717
你可以在这里找到漏洞利用https://imagetragick.com/
但也没有工作所以如果我不能得到严重的漏洞所以让我们试着得到高严重性的漏洞
存储型 XSS：
第一个场景：开始通过上传包含我们的 XSS payload的 SVG 图像来测试存储的 XSS
让我们请求我们的 svg XSS payload
但不幸的是，应用程序响应强制 Content-Type: image/jpeg 所以我们无法以这种方式实现 XSS
第二种情况：在https://edu.target.com/teacher/profile-id
正如我之前告诉你的那样，服务器端将扩展名放在图像名称中
所以似乎文件名参数中的扩展名是注入 XSS payload的最佳位置
XSS.omar" onmouseover=alert(1)
但似乎他们为我们的payload进行 HTML 实体编码，所以我们无法逃避双引号
应用级DOS攻击：
该应用程序在客户端验证图像大小并仅允许上传小于 1 MB 的图像
所以我试图通过上传一个大图像来获取 DOS，所以我只使用了一个大小超过 1 MB 的图像来测试服务器端的大小是否有验证，但是连接再次关闭并且服务器没有响应这意味着对图像大小进行验证以防止此类攻击
信息披露：
但我注意到我的payload没有改变，这意味着如果我上传一张图片，图片中的所有元数据都不会改变
好吧，是时候射出最后一颗子弹了
所以我上传了包含 GPS 位置数据的图像
你可以在这里找到它
https://github.com/ianare/exif-samples/blob/master/jpg/tests/67-0_length_string.jpg
将图像上传到 Web 应用程序后，我再次下载它以检查地理位置数据是否被条带化
我们可以使用 ExifTool 进行检查以提取元数据
┌──(omar㉿kali)-[~/Downloads] └─$ exiftool /Downloads/exif-test.jpg
看起来网络应用程序没有从图像中剥离地理位置数据
提交漏洞后，安全团队接受其为P2，原因是教育平台的大多数用户都是未成年学生，这种信息泄露侵犯了他们的隐私
修复建议：
1-从 ImageMagick 下载最新版本
2-使用 stripImage() 方法从图像中剥离此元数据
$imageFilePath = '上传的图片'; $img = new imagick(); $img->readImage($imageFilePath); $img->stripImage(); $img->writeImage($imageFilePath); $img->destroy(); ?>
