如何彻底修复IIS短文件漏洞?

Windows 还以 8.3 格式生成与 MS-DOS 兼容的(短)文件名,以允许基于 MS-DOS 或 16 位 Windows的程序访问这些文件。在cmd下输入“dir /x”即可看到短文件名的效果。

通配符”*” 和 “?”发送一个请求到iis,当IIS接收到一个文件路径中包含”~”的请求时,它的反应是不同的。基于这个特点,可以根据http的响应区分一个可用或者不可用的文件。

如下图所示不同IIS版本返回信息的不同:

IIS短文件

其实, 也就只能确定前6个字符,如果后面的字符太长、包含特殊字符,那么就很难猜解。另外如果文件本身太短也是无法猜解的。

补充一点额外的资料:

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

另外可以绕过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).Net Framework的拒绝服务攻击
Soroush Dalilide研究发现,当请求文件夹名称包含~1的请求,会导致不存在该文件的.Net framework去递归所有根目录。特别是第一次请求时,会造成的文件读取特别多。

修复建议:

禁止url中使用“~”或它的Unicode编码。

关闭windows的8.3格式功能。

附:网上有建议将.net Farrmework升级至4.0能修复此漏洞,但系统框架已为4.0版本,经扫描漏洞依然存在。那怎么办?试试下面的。

1、修改注册表项:(重启服务器生效)

HKLM\SYSTEM\CurrentControlSet\Control\FileSystem\NtfsDisable8dot3NameCreation

值为1。

2、执行DOS命令, fsutil behavior set disable8dot3 1

3、删除现有的IIS目录重新部署,完成此步骤才能完全修复。
相关推荐:
这就简单地啦~ 1、进入到系统盘,找到用户目录进去后找到当前的用户目录; 2、或者直接在资源管理器的左侧操作; 3、右键打开属性,切换到位置的标签; 4、自己改路径,OK了~ …
其实这个问题从jdk9之后开始就会存在,之后的版本将不再提供tools.jar和dt.jar了,也不需要在classpath里面配置这些jar了,那么怎么配是最科学的? 配置可参考这样: JAVA_HOME=jdk安装路径 JRE_HOME=jre安装路径 PA …
首先认识下,regsvr32.exe是32位系统下使用的DLL注册和反注册工具,使用它必须通过命令行的方式使用,格式是: regsvr32 [/u] [/s] [/n] [/i[:cmdline]] DLL文件名 命令可以在“开始→运行”的文本框中,也可以事先在ba …
有时候我们想要用不同色彩的文字来区分下,但是在Windows上不同于Mac或Linux,无法使用\033的方法,那怎么办呢?这里我们将对Windows下命令行输出彩色文字进行分析。 首先我们来看一段代码,品味下是怎么生成彩色的 …
在没有接互联网的 Win7/2008 R2 系统上安装微软.NET框架时,安装过程会报错“无法建立到信任根颁发机构的证书链”。 这个错误是因为微软.NET框架的数字签名所对应的根证书没有安装。微软现在自己的软件安装时都要强制 …
拿起手机扫一扫即可带走我!