IIS短文件漏洞（搬运整理）

 

0x01. IIS短文件漏洞的由来

 

Microsoft IIS 短文件/文件夹名称信息泄漏最开始由Vulnerability Research Team（漏洞研究团队）的Soroush Dalili在2010年8月1日发现，并于2010年8月3日通知供应商（微软公司）。微软公司分别于2010年12月1日和2011年1月4日给予答复下个版本修复。2012年6月29日，此漏洞公开披露（中危）。

此漏洞实际是由HTTP请求中旧DOS 8.3名称约定（SFN）的代字符（〜）波浪号引起的。它允许远程攻击者在Web根目录下公开文件和文件夹名称（不应该可被访问）。攻击者可以找到通常无法从外部直接访问的重要文件，并获取有关应用程序基础结构的信息。

Microsoft IIS 波浪号造成的信息泄露是世界网络范围内最常见的中等风险漏洞。这个问题至少从1990年开始就已经存在，但是已经证明难以发现，难以解决或容易被完全忽略。

 

 

0x02. 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（远程启用<customErrors>或没有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_20180101.sql，它对应的短文件名是 backup~1.sql 。因此攻击者只要暴力破解出backup~1.sql即可下载该文件，而无需破解完整的文件名。

 

IIS短文件名有以下几个特征：

 

1.只有前六位字符直接显示，后续字符用~1指代。其中数字1还可以递增，如果存在多个文件名类似的文件（名称前6位必须相同，且后缀名前3位必须相同）；

2.后缀名最长只有3位，多余的被截断，超过3位的长文件会生成短文件名；

3.所有小写字母均转换成大写字母；

4.长文件名中含有多个“.”，以文件名最后一个“.”作为短文件名后缀；

5.长文件名前缀/文件夹名字符长度符合0-9和Aa-Zz范围且需要大于等于9位才会生成短文件名，如果包含空格或者其他部分特殊字符，不论长度均会生成短文件；

 

我们可以在启用.net的IIS下使用GET方法暴力列举短文件名，原因是攻击者使用通配符“*”和“?”发送一个请求到IIS,当IIS接收到一个文件路径中包含“~”请求时，它的反应是不同的，即返回的HTTP状态码和错误信息不同。基于这个特点，可以根据HTTP的响应区分一个可用或者不可用的文件。如下图所示不同IIS版本返回信息的不同：

 

IIS 5.0 ~ IIS 7.X短文件猜解HTTP响应信息

 

上图是由此漏洞发现者Soroush Dalili在其研究报告中给出的IIS短文件合法和不合法猜解响应信息的图解：

 

访问构造的某个存在的短文件名，会返回404；

访问构造的某个不存在的短文件名，会返回400；

 

利用IIS 状态码猜解过程

 

以上方法是在IIS较低版本+ASP.NET环境下使用GET方法反复循环猜测，直到猜解出短文件名。

在IIS高版本（如：IIS 8.0/IIS 8.5/IIS 10.0），即使没有安装asp.net，通过OPTIONS和TRACE方法也可以猜解成功。这两种方法猜解返回的HTTP状态码类型和上述截图有些许出入，但是不失为另一种利用方式。

##以下部分为其他报道较少提及的。

 

还是这个短文件/文件夹名暴露漏洞，acunetix研究指出当Apache运行在windows下，如果创建了一个长文件，那么无需猜解长文件，直接用短文件就可以下载了。例如一个backup-082119f75623eb7abd7bf357698ff66c.sql的长文件，其短文件是BACKUP~1.SQL，攻击者只需要提交BACKUP~1.SQL就可以直接访问该文件。原文http://www.acunetix.com/blog/web-security-zone/articles/windows-short-8-3-filenames-web-security-problem/

 

另外，Soroush Dalilide研究中还提到可以绕过Basic and Windows认证，猜解认证目录下的文件。以下是II5.0绕过认证的方法：

详细可见原文研究：

http://soroush.secproject.com/blog/2010/07/iis5-1-directory-authentication-bypass-by-using-i30index_allocation/

“/AuthNeeded:$i30:$INDEX_ALLOCATION/secretfile.asp”

Instead of:

“/AuthNeeded/secretfile.asp”

但是并不是所有版本的IIS都能够绕过认证。应该是在可绕过的前提下猜解，形式如下：

/AuthNeeded::$Index_Allocation/*~1*/.aspx

或者

/AuthNeeded:$I30:$Index_Allocation/*~1*/.aspx

 

2.2.2 .Net Framework的拒绝服务攻击 （副危害）

据Soroush Dalili在研究表明，攻击者如果在文件夹名称中向发送一个不合法的.Net文件请求，.NeFramework将递归搜索所有的根目录，消耗网站资源进而导致DOS问题。微软认为此危害是可恢复的DOS，将在后续SP版本修改，此处不做探讨研究。

 

3. IIS漏洞OPTIONS、TRACE方法猜解分析

OPTIONS方法猜解分析

由于上述OPTIONS方法请求了196次才猜测出短文件名，猜测成功返回404，猜测失败返回的是200，失败的组合比较多，所以下面主要分析下404猜测成功的请求如何通过OPTIONS方法获取短文件名IIS10T.HTM的。如下图：

 

 

TRACE方法猜解分析

通过TRACE方法猜解的过程基本同上，只不过此HTTP方法猜解失败返回的状态码不是200，而是501（未执行）。

 

 

 

4. IIS短文件漏洞的意义

 

这个漏洞的意义何在：

1、猜解后台地址。

2、猜解敏感文件，例如备份的rar、zip、.bak、.SQL文件等。

3、在某些情形下，甚至可以通过短文件名web直接下载对应的文件。比如下载备份SQL文件。

 

5. IIS短文件漏洞局限性

此漏洞存在以下几个局限点：

 

1) 此漏洞只能确定前6个字符，如果后面的字符太长、包含特殊字符，很难猜解；

2) 如果文件名本身太短（无短文件名）也是无法猜解的；

3) 如果文件名前6位带空格，8.3格式的短文件名会补进，和真实文件名不匹配；

 

4) 如果文件夹名前6位字符带点“.”，扫描程序会认为是文件而不是文件夹，最终出现误报；

 

 

 

5) 不支持中文文件名，包括中文文件和中文文件夹。一个中文相当于两个英文字符，故超过4个中文字会产生短文件名，但是IIS不支持中文猜测。

 

6. IIS短文件漏洞解决方案

 

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以上版本

 

0x07. 工具介绍

java版：https://github.com/irsdl/IIS-ShortName-Scanner

python版： https://github.com/lijiejie/IIS_shortname_Scanner

 

0x08.  参考链接

http://www.freebuf.com/articles/web/172561.html

http://www.freebuf.com/articles/4908.html

http://www.lijiejie.com/iis-win8-3-shortname-brute/