Web漏洞知识：短文件漏洞利用
当你的才华
还撑不起你的野心时
那你就应该静下心来学习
目录
短文件漏洞利用
一、 什么是IIS？
二、 IIS 短文件漏洞
1. IIS短文件漏洞的由来
2. IIS短文件漏洞影响范围及危害
3. IIS短文件漏洞复现和利用
4. IIS短文件漏洞局限性
5. IIS短文件漏洞解决方案
额外拓展知识
二、IIS短文件名泄漏漏洞防护
查看是否开启短文件名功能
关闭功能
验证方法
让当前已有文件生效
今天在网上看文章，看到了一篇之前没了解过得漏洞，IIS 短文件漏洞，该漏洞存在的前提条件是Windwos环境+ASPX 。
其中，如果为容器为apache且运行在windows下，遇到可以下载的文件，并且文件名还很长，那么无需猜解长文件名，直接用短文件名就可以下载，就是这么骚的骚操作。
短文件漏洞利用
一、 什么是IIS？
Internet Information Services（IIS，以前称为Internet Information Server）互联网信息服务是Microsoft公司提供的可扩展Web服务器，支持HTTP，HTTP/2，HTTPS，FTP，FTPS，SMTP和NNTP等。起初用于Windows NT系列，随后内置在Windows 2000、Windows XP Professional、Windows Server 2003和后续版本一起发行，但在Windows XP Home版本上并没有IIS。IIS目前只适用于Windows系统，不适用于其他操作系统。
根据Netcraft数据显示，IIS在“百万最繁忙网站”中的市场份额为10.19％，成为全球第三大网络服务器，落后于Apache 41.41％和 Nginx 28.34％。目前流行的Windows版本都默认安装IIS服务 ,但同时 IIS的安全性一直被业内诟病，一旦IIS出现高危漏洞威胁将会非常严重。
在接触IIS漏洞之前我们先来了解下不同Windows系统下默认内置的IIS版本，以便更好的理解和区分IIS漏洞的影响范围：
| IIS 默认版本 | Windows 系统 |
| IIS 1.0 | Windows NT Server 3.51 |
| IIS 2.0 | Windows NT Server 4.0 |
| IIS 3.0 | Windows NT Server 4.0 SP3 |
| IIS 4.0 | Windows NT Server 4.0 SP3 + Option Pack |
| IIS 5.0 | Windows 2000 |
| IIS 5.1 | Windows XP Professional, Windows XP Media Center |
| IIS 6.0 | Windows Server 2003, Windows XP Professional x64 |
| IIS 7.0 | Tindovs Vista (Home Premium, Business, Enterprise，Ultimate），Windows Server 2008 |
| IIS 7.5 | Windows 7，Windows Server 2008 R2 |
| IIS 8.0 | Windows 8，Windows Server 2012 |
| IIS 8.5 | Windows 8.1，Windows Server 2012 R2 |
| IIS 10.0 | Windows 10，Windows Server 2016 |
二、 IIS 短文件漏洞
1. IIS短文件漏洞的由来
为了兼容16位MS-DOS程序，Windows为文件名较长的文件（和文件夹）生成了对应的windows 8.3 短文件名
此漏洞实际是由HTTP请求中旧DOS 8.3名称约定（SFN）的代字符（〜）波浪号引起的。它允许远程攻击者在Web根目录下公开文件和文件夹名称（不应该可被访问）。攻击者可以找到通常无法从外部直接访问的重要文件，并获取有关应用程序基础结构的信息。
Microsoft IIS 波浪号造成的信息泄露是世界网络范围内最常见的中等风险漏洞。这个问题至少从1990年开始就已经存在，但是已经证明难以发现，难以解决或容易被完全忽略。
1.1 ISS 短文件漏洞存在必要条件
短文件名漏洞存在两个要求:
• 网站是用aspx
• 是windows环境
2. IIS短文件漏洞影响范围及危害
2.1 受影响的版本：
IIS 1.0，Windows NT 3.51
IIS 3.0，Windows NT 4.0 Service Pack 2
IIS 4.0，Windows NT 4.0选项包
IIS 5.0，Windows 2000
IIS 5.1，Windows XP Professional和Windows XP Media Center Edition
IIS 6.0，Windows Server 2003和Windows XP Professional x64 Edition
IIS 7.0，Windows Server 2008和Windows Vista
IIS 7.5，Windows 7（远程启用或没有web.config） IIS 7.5，Windows 2008（经典管道模式）
注意：IIS使用.Net Framework 4时不受影响
以上数据来源：https://www.securityfocus.com/archive/1/523424
经验证，以上受影响范围主要是针对HTTP GET方法，且需要同时安装ASP.NET应用程序。该漏洞发现者在2014年再次披露：在测试IIS 7.5(Windows 2008 R2)和IIS 8.0(Windows 2012)过程中，当使用OPTIONS来代替GET 方法时，如果请求中的短文件名是存在的，IIS就会返回一个不一样的错误信息。利用这种特点，攻击者就可以在最新的IIS版本中，实现基于短文件名的文件或目录扫描了。
目前IIS支持短文件名猜测的HTTP方法主要包括：DEBUG、OPTIONS、GET、POST、HEAD、TRACE六种，经千里目实验室验证，IIS 8.0、IIS 8.5和IIS 10.0的短文件名称均可以通过OPTIONS和TRACE方法被猜测成功。所以上述受影响版本需要再加上如下版本：
IIS 8.0，Windows 8, Windows Server 2012
IIS 8.5，Windows 8.1,Windows Server 2012 R2
IIS 10.0，Windows 10, Windows Server 2016
可以看到，IIS全部版本都存在短文件名泄漏的问题，微软似乎忽视了这个问题。从微软回复该漏洞发现者的消息可以看出，IIS短文件漏洞未达到安全更新标准，且需要确定何时在下一个逻辑版本中解决它。
2.2 漏洞危害
2.2.1 利用“~”字符猜解暴露短文件/文件夹名 （主要危害）
Windows 支持以 8.3 格式生成与 MS-DOS 兼容的（短）文件名，以允许基于 MS-DOS 或 16 位 Windows的程序访问这些文件。在cmd下进入IIS网站根目录C:\inetpub\wwwroot输入“dir /x”即可看到短文件名的效果：
如上图是Windows 10内置的IIS 10.0默认站点根目录，iisstart.htm和iisstart.png是网站默认文件，文件名前缀字符长度均没有达到9位，所以没有短文件名。IIS10test.html是人为添加的网站文件，文件名前缀字符长度达到了9位，对应的短文件名为IIS10T~1.HTM。根据此特性，我们能够通过访问短文件名间接访问它对应的文件。
由于短文件名的长度固定（xxxxxx~xxxx），因此攻击者可直接对短文件名进行暴力破解 ，从而访问对应的文件。
举个例子：
有一个数据库备份文件 backup_20190101.sql ，它对应的短文件名是 backup~1.sql 。因此攻击者只要暴力破解出backup~1.sql即可下载该文件，而无需破解完整的文件名。
IIS短文件名有以下几个特征：
1. 只有前六位字符直接显示，后续字符用~1指代。其中数字1还可以递增，如果存在多个文件名类似的文件（名称前6位必须相同，且后缀名前3位必须相同）
2. 后缀名最长只有3位，多余的被截断，超过3位的长文件会生成短文件名
3. 所有小写字母均转换成大写字母
4. 长文件名中含有多个“.”，以文件名最后一个“.”作为短文件名后缀
5. 长文件名前缀/文件夹名字符长度符合0-9和Aa-Zz范围且需要大于等于9位才会生成短文件名，如果包含空格或者其他部分特殊字符，不论长度均会生成短文件
6. 访问构造的某个存在的短文件名，会返回404
7. 访问构造的某个不存在的短文件名，会返回400
Windows 还以 8.3 格式生成与 MS-DOS 兼容的（短）文件名，以允许基于 MS-DOS 或 16 位 Windows的程序访问这些文件。在cmd下输入“dir /x”即可看到短文件名的效果。
我们可以在启用.net的IIS下使用GET方法暴力列举短文件名，原因是攻击者使用通配符“*”和“?”发送一个请求到IIS,当IIS接收到一个文件路径中包含“~”请求时，它的反应是不同的，即返回的HTTP状态码和错误信息不同。基于这个特点，可以根据HTTP的响应区分一个可用或者不可用的文件。
如下图所示不同IIS版本返回信息的不同：
IIS 5.0 ~ IIS 7.X短文件猜解HTTP响应信息
| IIS Version | URL | Result/Error Message |
| IIS 6 | /valid*~1*/.aspx | HTTP 404 - File not found |
| IIS 6 | /Invalid*~1*/.aspx | HTTP 400 - Bad Request |
| IIS 5.x | /valid*~1* | HTTP 404 - File not found |
| IIS 5.x | /Invalid*~1* | HTTP 400 - Bad Request |
| IIS 7.x .Net.2 No Error Handling |
/valid*~1*/ | Page contains: "Error Code 0x00000000" |
| IIS 7.x.Net.2 No Error Handling |
/Invalid*~1*/ | Page contains: "Error Code 0x80070002" |
注：从上表中可以看出，只能确定前6个字符，如果后面的字符太长、包含特殊字符，那么就很难猜解。另外如果文件本身太短也是无法猜解的。
上表是由此漏洞发现者Soroush Dalili在其研究报告中给出的IIS短文件合法和不合法猜解响应信息的图解：
• 访问构造的某个存在的短文件名，会返回404
• 访问构造的某个不存在的短文件名，会返回400
利用IIS 状态码猜解过程
| URL | Result |
| http://sdl.me/*~1*/.aspx | 404 - Valid： one or more file(s)/folder(s) with short name is/are available on the server |
| http://sdl.me/a*~1*/.aspx | 404 - Valid： It starts with "A" |
| http://sdl.me/aa*~1*/.aspx | 400 - Invalid: The second letter is not "A" |
| http://sdl.me/ab*~1*/.aspx | 400 - Invalid： The second letter is not "B" |
| http://sdl.me/ac*~1*/.aspx | 404 - Valid： The second letter is "C" |
| http://sdl.me/ac%3f~1*/.aspx | 400 - Invalid： It has more than three characters |
| http://sdl.me/ac%3f%3f%3f%3f~1*/.aspx | 404 - Valid： It has 6 or more than 6 characters |
| http://sdl.me/acsecr~1*/.aspx | 404 - Valid： It starts with "ACSECR" |
| http://sdl.me/acsecr~1/.aspx | 400 - Invalid： It is not a folder and it has an extension |
| http://sdl.me/acsecr~1.%3f/.aspx | 400 - Invalid： Extension has more than 1 character |
| http://sdl.me/acsecr~1.%3f%3f%3f/.aspx | 404 - Valid： Extension has 3 or more characters |
| http://sdl.me/acsecr~1.a%3f%3f/.aspx | 400 - Invalid： Extension does not start with "A" |
| http://sdl.me/acsecr~1.h%3f%3f/.aspx | 404 - Valid： Extension starts with "H" |
| http://sdl.me/acsecr~1.htm/.aspx | 404 - Valid： Extension starts with "HTM" |
以上方法是在IIS较低版本+ASP.NET环境下使用GET方法反复循环猜测，直到猜解出短文件名。
注：在IIS高版本（如：IIS 8.0/IIS 8.5/IIS 10.0），即使没有安装asp.net，通过OPTIONS和TRACE方法也可以猜解成功。这两种方法猜解返回的HTTP状态码类型和上述截图有些许出入，但是不失为另一种利用方式。
2.2.2 .Net Framework的拒绝服务攻击 （副危害）
据Soroush Dalili在研究表明，攻击者如果在文件夹名称中向发送一个不合法的.Net文件请求，.NeFramework将递归搜索所有的根目录，消耗网站资源进而导致DOS问题。微软认为此危害是可恢复的DOS，将在后续SP版本修改，此处不做探讨研究。
3. IIS短文件漏洞复现和利用
3.1 IIS短文件漏洞复现
3.1.1 漏洞环境搭建
基于Win 10安装默认IIS 10.0 （未安装APS.NET）
IIS短文件漏洞扫描Java程序（需要配置Java环境变量）
3.1.2 漏洞环境调试准备
IIS 安装成功以后，会默认在C盘目录下生成intpub目录，网站的根目录位于C:\inetpub\wwwroot，此时查看下根目录是否存在短文件名：
由上图可知，默认IIS 10.0 网站根目录不存在短文件名，只有默认的htm和png文件，且名称长度未达到生成短文件的要求。下面使用IIS短文件扫描程序检测下有无短文件信息泄漏漏洞：
3.1.3 漏洞环境复现
手动创建网站长文件名“IIS10test.html” ,自动生成对应短文件名“IIS10T~1.HTM”
使用IIS短文件扫描程序再次扫描，扫描发现存在短文件漏洞，且通过HTTP OPTIONS方法成功猜解出短文件名称：IIS10T.HTM
修改漏洞扫描程序，注视掉OPTIONS方法，尝试是否还有其他HTTP方法可以猜解成功。
验证发现，除了OPTIONS方法外，HTTP TRACE方法也能成功猜解出短文件名称。
3.1.4 IIS漏洞OPTIONS、TRACE方法猜解分析
OPTIONS方法猜解分析
由于上述OPTIONS方法请求了196次才猜测出短文件名，猜测成功返回404，猜测失败返回的是200，失败的组合比较多，所以下面主要分析下404猜测成功的请求如何通过OPTIONS方法获取短文件名IIS10T.HTM的。如下图：
TRACE方法猜解分析
通过TRACE方法猜解的过程基本同上，只不过此HTTP方法猜解失败返回的状态码不是200，而是501（未执行）。
3.2 IIS短文件漏洞利用
1. 深入爆破猜测文件全名
通过IIS短文件漏洞猜测出来的短文件名称，需要继续猜测出全名才可以在IIS上进行访问，即IIS由于安全原因不支持短文件名访问。以下是Soroush Dalili给出的几种猜测文件全名的方法：
1) 通过对目标网站或同类型网站进行爬虫，爬出建立一个字典库，再与得到的短文件名来猜剩下的字符
2) 利用fuzzdb(一个应用程序模糊测试(fuzzing)数据库)来猜解
3) 结合OWASP的dirbuster（一款路径及网页暴力破解的工具）Github上有研究人员已经用python将上述方法实现，并且获取到了网站后台的用户名和密码，很好的利用了IIS短文件漏洞。
注：
研究报告地址：https://webbreacher.com/2014/10/23/tilde-enumeration/ （推荐）
Python程序下载：https://github.com/WebBreacher/tilde_enum （推荐）
2. 结合支持短文件特性软件（Apache、Wordpress）
Acunetix研究指出当Apache运行在windows下，如果创建了一个长文件，那么无需猜解长文件，直接用短文件就可以下载了。例如一个backup_20180101.sql的长文件，其短文件是BACKUP~1.SQL，攻击者只需要提交BACKUP~1.SQL就可以直接访问并下载该文件。
此外，有学者表明，其在安装Wordpress备份插件之后，通过短文件名成功地访问到了了WordPress博客的备份文件。
3. 绕过Basic and Windows认证
Soroush Dalilide研究中还提到，在某些IIS服务器配置下，可以绕过Basic and Windows认证，猜解出认证目录下的文件。举例，如果需要访问一个开启认证的目录下文件时，比如这个目录是“AuthNeeded”，那么可以通过如下方式访问：
/AuthNeeded::$Index_Allocation/*~1*/.aspx
或者
/AuthNeeded:$I30:$Index_Allocation/*~1*/.aspx
4. IIS短文件漏洞局限性
此漏洞存在以下几个局限点：
1) 此漏洞只能确定前6个字符，如果后面的字符太长、包含特殊字符，很难猜解
2) 如果文件名本身太短（无短文件名）也是无法猜解的
3) 如果文件名前6位带空格，8.3格式的短文件名会补进，和真实文件名不匹配
4) 如果文件夹名前6位字符带点“.”，扫描程序会认为是文件而不是文件夹，最终出现误报
5) 不支持中文文件名，包括中文文件和中文文件夹。一个中文相当于两个英文字符，故超过4个中文字会产生短文件名，但是IIS不支持中文猜测5. IIS短文件漏洞解决方案
5.1 通用漏洞修复方案
1) CMD关闭NTFS 8.3文件格式的支持
举例：（1代表关闭，0代表开启）
Windows Server 2008 R2：
查询是否开启短文件名功能：fsutil 8dot3name query
关闭该功能：fsutil 8dot3name set 1
Windows Server 2003：
关闭该功能：fsutil behavior set disable8dot3 1
不同系统关闭命令稍有区别，该功能默认是开启的，对于大多数用户来说无需开启。
2) 修改注册表禁用短文件名功能
快捷键Win+R打开命令窗口，输入regedit打开注册表窗口
找到路径：
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem，将其中的 NtfsDisable8dot3NameCreation这一项的值设为 1，1代表不创建短文件名格式
修改完成后，需要重启系统生效
注：此方法只能禁止NTFS8.3格式文件名创建,已经存在的文件的短文件名无法移除，需要重新复制才会消失。
以下两种方法仅适用于缓解GET 方法，其他方法依旧可以猜解。
3) 关闭Web服务扩展- ASP.NET
4) 升级netFramework至4.0以上版本
5) 将web文件夹的内容拷贝到另一个位置
例如：D:\www到D:\www.back，然后删除原文件夹D:\www，再重命名D:\www.back到D:\www。如果不重新复制，已经存在的短文件名则是不会消失的。
6) 对于虚拟主机空间用户，如果还不能彻底修复该问题，可以联系空间提供商协助修改
7) 删除现有的IIS目录重新部署，完成此步骤才能完全修复
例如：原来是wwwjb51先新建一个目录wwwjb512然后再改回wwwjb51就可以了
8) 禁止url中使用“~”或它的Unicode编码
9) 执行DOS命令， fsutil behavior set disable8dot3 1
参考链接：https://www.freebuf.com/articles/web/172561.html
额外拓展知识
二、IIS短文件名泄漏漏洞防护
查看是否开启短文件名功能
Windows Server 2008 R2：fsutil 8dot3name query
默认为2是开启，设置为1为关闭
关闭功能
WindowsServer2008R2：fsutil 8dot3name set 1
WindowsServer2003：fsutil behavior set disable8dot3 1
验证方法
进入要验证目录，使用命令dir /x
注：修改后，对当前的文件是不生效的，需要进行复制让其生效。
让当前已有文件生效
如果是站点文件，简单来说过程就是把WEB站点文件复制一份出来，然后将旧的删除掉，再将新名换为旧名
eg:
把D:\wwwroot文件夹复制成名为D:\wwwwroot2文件夹，然后删除原文件夹D:\wwwroot，再把D:\wwwwroot2重命令成D:\wwwwroot，这样一来就解决了当前文件不生效的问题，再次验证正常
参考链接：https://www.landui.com/help/show-7449
我不需要自由，只想背着她的梦
一步步向前走，她给的永远不重