利用文件上传功能构造实现针对后端验证机制的RCE漏洞

*本文中涉及到的相关漏洞已报送厂商并得到修复，本文仅限技术研究与讨论，严禁用于非法用途，否则产生的一切后果自行承担。

本文讲述了作者在参与某一邀请众测项目中，针对身份验证功能的目标Web应用，对其文件上传功能点进行利用，绕过了其客户端校验方式，以Web应用后端文件核实人员为目标，构造上传了可执行Payload的文件，结合XSS Hunter实现了远程代码执行（RCE），获得了厂商$3000美金奖励。这种漏洞测试姿势算是常见，但怎么一个绕过招式就变成了高危的RCE了呢？一起来看看作者的测试分享和上报思路。

在参与厂商的众测项目之前，我会先去了解该项目的一些运行数据信息，如赏金范围和项目持续时间等，如果你觉得这样毫无必要的话，那么盲目地参与可能会与一些好项目擦肩而过。我参与这个项目就是个例子，我大约于2019年5月收到测试邀请，该项目自2016年就运行至今，有效漏洞提交量总共150多个。但不管怎样，我还是对其做了一番了解。之后，我又从其在HackerOne上的项目更新中看到，有一些新的服务端被陆续添加进入测试范围，并在测试策略（Policy）中具体描述了厂商对哪些漏洞比较感兴趣。

经验1：漏洞总是有的。前期的测试目标可能和新增测试目标一样存在很多漏洞。

从HackerOne上的项目更新策略中可知，厂商对第三方合作伙伴Web应用网站partner.program.com的某子域名站点存在的漏洞较为关注。访问该子域名网站后，我发现它是一个允许用户注册成为厂商合作伙伴或附属机构的Web应用。通常我喜欢关注Web应用的访问授权功能，一般我会在Web应用中注册至少两个账户以备测试。因为两个账户可以方便地进行越权（IDOR）测试。在注册登录之后，我发现了其中一个有意思的地方：身份验证文件上传。

这就是使用该Web应用的第一步。由于目标厂商是一家商贸公司，合作伙伴和用户需要通过上传他们的**/***等证明来通过身份验证，才能开始使用Web应用。终于遇到对手了，我非常喜欢捣鼓文件上传功能了。

经验2：不要忽视一些看似正常的功能。比如搜索栏位置可能会存在一些“致命”的XSS或SQL注入漏洞，而1337名白帽都会把它忽视。

以前我曾发现过一些文件上传功能漏洞，总结来说：需要认真分析其具体的上传机制，比如其限制属性有什么、规定上传文件格式有哪些，等等，一般这些都是问题所在。由于这是一个身份验证证明的上传功能点，所以通常会存在两种证明文件验证机制：要么其后台有一个自动程序来验证用户上传的证明文件，要么其后端有一个实际的工作人员来通过用户上传证明文件核对用户身份。该上传功能如下：

上图显示，Web应用后端只接收PNG、JPG、PDF或BMP格式文件，因此，我尝试上传了一些非可接受格式文件，看看后端服务的反应如何。但很遗憾，后端服务完全没反应。即使从Burp的请求历史中，也没有发现任何文件限制响应消息或相应的请求记录，我有点懵了。只是，如果上传有效的JPG文件（foobar.jpg）后，会产生以下样式的上传请求：

这是什么意思？

这貌似表示其中还有一种客户端校验措施，如果用Burp来拦截上传请求然后改包，很容易绕过这种客户端检查。比如，我们拦截上传请求，然后把请求修改如下，其中上传的JPG文件名被修改为了foorbar.foo：