短文件名漏洞修复

短文件名漏洞其实在13年时仍是很使人耳熟能详的，不过随着所在公司的编码语言转型，目前使用ASP.NET的新项目基本上没有了，而更多的是对原来的采用ASP.NET语言开发的项目进行维护或打个补丁。

 

事出忽然，12月的某个下午被项目组喊去帮个忙，第一感受就是“是否是线上的项目被人黑了？”。因而乎就跑去看下具体的状况，项目组负责人见到我第一句话就是“某个项目被某国家单位进行线上项目巡检时发现了一个漏洞，可是不会修”。

 

往他所指的电脑上简单一看，映入眼帘的就是“存在短文件名漏洞，定级为高”。是的，就是这么一个漏洞搞得项目组大伙都紧张。

 

短文件名漏洞是不少没有作过安全测试的项目的痛，由于发生的几率仍是很高的，这一点能够经过谷歌来证明。无论是如今的国产安全扫扫器仍是国外的安全扫描器都是能轻易的扫出的，且安全危险定级都不低。

 

短文件名漏洞的产生原理是啥呢？这一块网上资料不少，我就不细讲，有兴趣能够查下维基，我这里着重地贴上一个图来简单地解释下：

 

 

 

首先咱们来发现一些细节：

1. 从Windows 2003到Windows 2008 R2系列都有存在短文件名漏洞的可能；

2. Windows 2008 以后的利用场景更为苛刻

 

那么短文件名漏洞利用原理是啥，这里贴个内容：

 

Windows 还以 8.3 格式生成与 MS-DOS 兼容的（短）文件名，以容许基于 MS-DOS 或 16 位 Windows的程序访问这些文件。在cmd下输入“dir /x”便可看到短文件名的效果。通配符”*” 和 “?”发送一个请求到IIS，当IIS接收到一个文件路径中包含”~”的请求时，它的反应是不一样的。基于这个特色，能够根据HTTP的响应区分一个可用或者不可用的文件。

 

为了去复现短文件名，咱们通常不建议用手工，耗时又耗力，伟大的GITHUB上已经有无数能人写了脚本，这里我贴一个，若你有更好的，欢迎留言分享下：https://github.com/lijiejie/IIS_shortname_Scanner 

要存在短文件名就会所有列出来，没有就会提示没有，简单易用。

 

漏洞怎么修呢？

 

这里我首先列一下网上收集的所有修复手段：

1. 禁止url中使用“~”或它的Unicode编码；

2. 关闭windows的8.3格式功能；

3. 将.NET Farrmework升级至4.0

 

正好，本次的需求下，让运维一个一个地试，一组一组地尝试。结果“真理仍是出于实践”：

1. 系统框架已为4.0版本，经扫描漏洞依然存在；

2. 禁止url中使用“~”或它的Unicode编码，手段太复杂，基本上不多运维懂；

3. 单纯地关闭windows的8.3格式功能是没有鸟用的

 

*注：咱们的漏洞环境为Windows 2008 R2，程序使用的是ASP.NET 2.0。

 

咱们最终的方案是（大家仅做参考哈，毕竟偶是不会对你负责的）：

1. 修改注册表项：（重启服务器生效）
   HKLM\SYSTEM\CurrentControlSet\Control\FileSystem\NtfsDisable8dot3NameCreation
   值为1；

2. 执行DOS命令， fsutil behavior set disable8dot3 1；

3. 删除现有的IIS目录从新部署，完成此步骤才能彻底修复

 

*注：注册表项说明见微软官方文档：