IIS短文件名漏洞

IIS短文件名介绍

为了兼容基于 MS-DOS 或 16 位 Windows 的程序，Windows 为文件名较长的文件（和文件夹）生成了对应的DOS 8.3 短文件名。

这里介绍一下 MS-DOS 和 DOS 8.3 规则

首先是MS-DOS，如下

image-20240418093636517

image-20240418093735060

以及 DOS 8.3 规则，如下

image-20240418093841395

如果要在Windows下查看对应的短文件名，可以使用命令 dir /x

image-20240418093953373

image-20240418101653901

IIS短文件名的特征：

  1. 只有前六位字符直接显示，后续字符用~1指代。其中数字1还可以递增【即如果存在多个文件名类似的文件（名称前6位必须相同，且后缀名前3位必须相同）】
  2. 后缀名最长只有3位，多余的被截断，超过3位的长文件会生成短文件名
  3. 所有小写字母均转换成大写字母
  4. 长文件名中含有多个“.”，以文件名最后一个“.”作为短文件名后缀
  5. 长文件名前缀/文件夹名字符长度符合0-9和Aa-Zz范围且需要大于等于9位才会生成短文件名，如果包含空格或者其他部分特殊字符，不论长度均会生成短文件

IIS短文件名漏洞

漏洞描述

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

漏洞成因

当IIS接收到一个短文件名的路径请求时，根据文件是否存在，所回显（或者说响应）的HTTP状态码和错误信息不同。即基于这个特点，可以根据回显的HTTP状态码和错误信息判断一个文件是否存在。具体的如下：

  • 访问存在文件的短文件名，会返回404状态码
  • 访问不存在文件的短文件名，会返回400状态码

注意，依据请求方法不同（如：GET、OPTIONS、TRACE）返回的HTTP状态码类型会有些许出入，但都存在回显不一致的问题，所以都可以根据回显的HTTP状态码和错误信息判断一个文件是否存在。

具体的，比如 IIS 8.0/IIS 8.5/IIS 10.0，是通过OPTIONS 和 TRACE方法进行猜解的。使用OPTION方法，猜测成功返回404，猜测失败返回的是200；使用 TRACE方法，猜测成功返回404，猜测失败返回的是501

受影响的IIS版本

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（经典管道模式）
# 以上受影响范围主要是针对HTTP GET方法，且需要同时安装ASP.NET应用程序
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
# 以上受影响范围即使没有安装ASP.NET应用程序，通过OPTIONS和TRACE方法也可以猜解成功

注意：IIS使用.Net Framework 4时不受影响

从受影响的IIS版本中不难看出，IIS短文件名漏洞影响范围极大

这里附一张不同Windows系统下默认内置的IIS版本图

image-20240418140115046

漏洞危害及利用

  • 敏感文件泄露：先通过IIS短文件漏洞猜测出来的短文件名称，在通过短文件名称继续猜测出全名（因为IIS由于安全原因不支持短文件名直接访问，所以需要全名），最后通过全名访问导致敏感文件泄露。

    这里可以结合其他支持短文件特性的软件（如Apache、Wordpress等）做一个延申

    当Apache运行在windows下，如果创建了一个长文件，那么无需猜解长文件，直接用短文件就可以下载。例如，一个名为backup_20180101.sql的长文件，其短文件是BACKUP~1.SQL，攻击者只需要提交BACKUP~1.SQL就可以直接访问并下载该文件

    敏感文件泄露可以关注.rar、.zip、.bak、.SQL文件等

    这里基于上面的【漏洞成因】，说一下手动猜解的方法，便于理解漏洞原理

    还是做一个术语的约定，猜测 == 猜解。

    因为是手动的过程，如果用工具的话就是所谓的"爆破"、“暴力破解”、“暴力猜解”

    image-20240418113326410

    这里再附一张漏洞发现者Soroush Dalili的利用IIS返回的http状态码猜解文件过程图，如下

    image-20240418115241113

  • 猜解后台地址：利用逻辑和敏感文件泄露一致，不再赘述

  • 拒绝服务攻击：更准确的描述是针对IIS服务器中的.Net Framework进行拒绝服务攻击。攻击者如果在文件夹名称中发送一个不合法的.Net文件请求，.Net Framework将递归搜索所有的根目录，消耗网站资源进而导致DOS问题。这里使用漏洞发现者Soroush Dalili的原话做一个描述，如下

    image-20240418105905476

  • 结合绕过Directory Authentication验证（目录身份验证）漏洞，猜解认证目录下的文件：注意并不是所有版本的IIS都能够绕过认证，这里仅验证了IIS5.1。方法是，添加:$i30:$INDEX_ALLOCATION到目录名以绕过身份验证，再使用敏感文件泄露的手法，去猜解认证目录下的文件。下面举个例子

    # 先说绕过Directory Authentication验证
# 比如要访问受目录身份验证保护的AuthNeeded文件夹下的secretfile.asp【即/AuthNeeded/secretfile.asp】
# 可以使用 /AuthNeeded:$i30:$INDEX_ALLOCATION/secretfile.asp 进行目录身份验证的绕过

# 再说猜解认证目录下的文件
/AuthNeeded::$Index_Allocation/*~1*/.aspx
/AuthNeeded:$I30:$Index_Allocation/*~1*/.aspx

    注意，是在可绕过的前提下猜解，属于一种漏洞组合拳。这里提到，很大一部分原因是，这两个漏洞都是Soroush Dalili发现的

漏洞局限性

  1. 此漏洞只能确定前6个字符，如果后面的字符太长、包含特殊字符，很难猜解
  2. 如果文件名本身太短（无短文件名）也是无法猜解的
  3. 如果文件名前6位带空格，8.3格式的短文件名会补进，和真实文件名不匹配
  4. 如果文件夹名前6位字符带点“.”，扫描程序会认为是文件而不是文件夹，最终出现误报
  5. 不支持中文文件名，包括中文文件和中文文件夹。一个中文相当于两个英文字符，故超过4个中文字会产生短文件名，但是IIS不支持中文猜测

漏洞相关工具

这里推荐3个工具：

鸣谢

Comments

⬆︎TOP