Part1 前言
大家好，上期分享了一个IIS短文件名猜解在实战中拿权限的利用，本期将会分享一个特殊的上传漏洞的利用案例。很多时候遇到一个存在漏洞的点，只要有一线希望，就不愿意轻言放弃。对一个网站进行测试前，扫描目录和扫描敏感文件是经常使用的方法，有时候会扫描出上传功能的后端页面，这时候不知道包体是怎么构造的，也不知道上传漏洞需要提交哪些参数，所以就需盲猜包体了。类似的案例我成功过好几次，接下来详细说一下具体方法及详细过程。
Part2 技术研究过程
- 扫描目录
首先，目标网站就是一个空白页面，对于这种网站，只能对URL进行目录扫描了，最后一层层扫目录得到类似于如下URL地址（以下是虚拟机环境的截图）：
http://www.xxx.com/Temp/servlet/UploadFile，打开页面如下：
做过Javaweb的朋友一眼就能看出这是Java站点的常见提示，通过URL的路由地址UploadFile猜测，这可能是一个上传功能的后端页面。由于没有前端的用户交互页面，就无法得到具体需要提交哪些参数。接下来讲讲如何对这个功能页面进行利用。
- 本地搭建环境
首先拿一个本地搭建的网站举例说明一下，我们平常见到的可能存在上传漏洞的页面是如下所示的一个前端页面：
查看浏览器源码，可以得知，真正处理用户上传数据的URL实际上是以下这个地址：
直接浏览器打开，页面如下，很多都是一个空白页面：
上传一个文件，使用burpsuite抓包，得到如下数据包，发现filepath和FileName是常见的用户提交给上传功能后端页面去处理的参数。其中，filepath是Web应用保存上传文件的地址，FileName是文件名称。
接下来我就想了，可不可以盲猜一下上传功能的包体呢？上传功能的POST包体常用的参数就是那几个。万一猜对了，就可以直接上传webshell了。
- 盲猜包体过程
于是使用burpsuite手工尝试filename、FileName、fileName、name、Name、FilePath、filePath等参数名，不断地构造上传包体，不断地进行变换构造，当构造出如下包体时，提示“文件上传成功”，这同时也说明这是一个存在未授权访问功能的上传页面。这个案例是好多年前的了，当时具体是哪几个参数我也不记得了，大致与以下截图类似。
当构造出如上图包体时，该页面提示“文件上传成功！”。上述包体的那个name字段应该是没起什么作用，但是不影响上传功能的正常使用。
- 寻找Webshell路径
接下来难点就来了，Web应用虽然提示“文件上传成功”，但是没给出文件上传的路径，那这个webshell传到哪里去了呢？接下来又得猜解目录及文件地址了。
假设扫描到了如下敏感目录（以下虚拟机环境的截图，项目图就不放出来了），/images/、/files/显得尤为重要。
于是打开网站访问/images/test123.txt，/files/test123.txt等等，发现均提示404，页面不存在，这就麻烦了。Webshell究竟传到哪里去了呢？
- 按照研发人员的思维渗透
后来思路转变了一下，既然是Java站点，而且目录中又有一个/temp/目录，程序员估计会以时间戳去重命名文件名做测试用。
于是打开IDE，找了一篇Java生成时间戳的文章，照着写了几行代码，生成了一个时间戳：
如下图所示，本地生成了一个时间戳：
由于本地操作时间与服务器文件落地的时间肯定不能完全一致，一定是有差别的，所以需要以当前时间戳为基准，前后取一定的时间差，生成一个几万行的字典，用burpsuite枚举一下：
结果没有那么简单，发现均是404响应码，没有找到响应码200的记录，也就是说没有找到webshell的地址。原因可能是时间戳不对，也可能是存放上传文件的目录没有找到，也可能是服务器压根就没有以此时间戳命名的文件。后来重新理了一下思路，我本地先生成了一个时间戳字典，然后使用burpsuite发上传数据包，再用burpsuite枚举时间戳文件名，中间大概有个几秒钟甚至是10秒钟的间隔，可别小看这个时间间隔，做个涵盖这个时间间隔的字典，也得上百万行、上千万行字典了。
后续为了加快扫描速度，也为了减少服务器的压力，我将GET请求转换成了HEAD请求，然后经过几百万行字典的爆破，成功找到了webshell地址，最终getshell成功。
- 寻找准确时间戳的新思路
后续经过Magic_Zero的提醒，他给出了一个更好用的思路，可以先查看服务器返回的Date响应头的时间，然后做成时间戳字典地址，这样准确度更高。这个思路真的没想到，感谢提供。
Part3 总结
1. 理解一个技术问题要理解它的实质。
2. 按照程序员、研发人员的思维去搞站，事半功倍。
3. 大批量扫目录、扫文件时，记得把GET请求换为HEAD请求，有些网站可能不支持HEAD请求，需要提前手工判断一下。
