一、 什么是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在2017年2月的数据显示，IIS在“百万最繁忙网站”中的市场份额为10.19％，成为全球第三大网络服务器，落后于Apache 41.41％和 Nginx 28.34％。目前流行的Windows版本都默认安装IIS服务 ,但同时 IIS的安全性一直被业内诟病，一旦IIS出现高危漏洞威胁将会非常严重。

推荐（免费）：iis

在接触IIS漏洞之前我们先来了解下不同Windows系统下默认内置的IIS版本，以便更好的理解和区分IIS漏洞的影响范围：

图1 各Windows版本默认IIS版本

二、 IIS漏洞大全

千里目实验室搜集了下近十五载的IIS相关漏洞，中、高危漏洞共计39个，其中15年爆发的(MS15-034)HTTP.sys 远程执行代码漏洞和16年的(MS16-016)WebDAV 特权提升漏洞影响范围尤其广泛。

图2 近15年IIS漏洞大全

看了上面IIS 近十几年的漏洞后，你也许会问，怎么没有看到本文的主人公“IIS短文件漏洞”呢？！在了解IIS漏洞大家庭前，我们先通过IIS短文件来了解下Windows下IIS的一些特性。

三、 IIS短文件

1. 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年开始就已经存在，但是已经证明难以发现，难以解决或容易被完全忽略。

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”即可看到短文件名的效果：

图3 IIS短文件名

如上图是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版本返回信息的不同：

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

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

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

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

图5 利用IIS 状态码猜解过程

以上方法是在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.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

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

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

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

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

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

5) 不支持中文文件名，包括中文文件和中文文件夹。一个中文相当于两个英文字符，故超过4个中文字会产生短文件名，但是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以上版本

郑重声明：本文由网友发布，不代表盛行IT的观点，版权归原作者所有，仅为传播更多信息之目的，如有侵权请联系，我们将第一时间修改或删除，多谢。