IIS是有微软使用微软windows功能扩展模块创建的一套web服务器应用程序，是世界上第三个最流行的服务器。
漏洞描述:
漏洞研究小组发现了一个微软IIS的漏洞,攻击者可以利用一个包含"~"的get请求,来让服务器上的文件和文件夹被泄漏、
影响版本:
IIS 1.0, Windows NT 3.51
IIS 2.0, Windows NT 4.0
IIS 3.0, Windows NT 4.0 Service Pack 2
IIS 4.0, Windows NT 4.0 Option Pack
IIS 5.0, Windows 2000
IIS 5.1, Windows XP Professional and Windows XP Media Center Edition
IIS 6.0, Windows Server 2003 and Windows XP Professional x64 Edition
IIS 7.0, Windows Server 2008 and Windows Vista
IIS 7.5, Windows 7 (远程开启了错误或者没有web.config配置文件的情况下)
IIS 7.5, Windows 2008 (经典托管管道模式)
漏洞分析与利用:
如果网站是运行在IIS服务器上，可以通过"~"来发现一些文件和文件夹,攻击者可以发现重要的文件或者文件夹，如果这些文件或者文件夹是正规的可见文件.
关于此漏洞的深入分析可以参考以下连接中的文章：
http://soroush.secproject.com/blog/2012/06/microsoft-iis-tilde-character-vulnerabilityfeature-short-filefolder-name-disclosure/
漏洞详细说明:
一直在寻找一种方法，如果我可以使用通配符"*" 和"?"发送一个请求到iis,我意识到当IIS接收到一个文件路径中包含"~"的请求时，它的反应是不同的.基于这个特点，我们可以根据http的响应区分一个可用或者不可用的文件.在以下的表中,文件validxxx.xxx是存在于网站服务器根目录的.(备注:xxx.xxx是指不确定,还需要继续猜解判断).下图主要是不同版本的IIS返回根据请求的返回错误来判断是否存在某个文件.
举例说明如果一个IIS6网站http://www.xxx.com的短文件猜解方法
请求http:// /a*~1*/.aspx 返回404，就说明存在a开头的一个axxx.xxx的文件.(其中xxx.xxx还需要进一步确定判断是什么字母,什么后缀).
请求http://www.xxx.com/a*~1*/.aspx 返回400,说明不存在a开头的一个axxx.xxx的文件.(其中xxx.xxx还需要进一步确定判断是什么字母,什么后缀).
IIS5.X的判断方法如下:
请求/a*~1* 返回404 说明存在a开头的一个文件。
请求/a*~1* 返回400 说明不存在a开头的一个文件.
IIS7.x.net 2 no error handing判断方法如上图，各位仔细看.
下面附上一个IIS6猜解文件的全过程。
测试地址：http://sdl.me/AcSecret.html acsecret.html是存在于服务器上的.猜解过程如下图:
附上详细的poc和漏洞利用说明文件:
PoC: http://www.exploit-db.com/sploits/19525.zip
Paper: http://www.exploit-db.com/download_pdf/19527
漏洞修复方案：
使用微软或者安全厂商提供的解决方案
使用配置好的Web应用防护系统(拒绝丢弃掉包含"~"线的Web请求)可能会起到对此漏洞进行防范的作用.
漏洞发现者:
Soroush Dalili (@irsdl)
Ali Abbasnejad
漏洞参考：
http://support.microsoft.com/kb/142982/en-us
http://soroush.secproject.com/blog/2010/07/iis5-1-directory-authentication-bypass-by-using-i30index_allocation/
站长评论：
其实这是个很鸡肋的“漏洞”……
首先，如果文件名符合8.3规范的文件（文件名主体部分小于等于8个字节、扩展名部分小于等于3个字节），则根本没有短文件名。
其次，汉字和特殊符号等字符的猜解，也是很蛋疼的问题……
最后，即使猜出来了，也只有前六位，只能靠运气碰碰看了……
不过，它还是有不小的用处，也算是很另类的一个“漏洞”吧……
（提示：如果目标站自定义了400、404 错误页面，那么该扫描器是无法判断的……）
可以参考下表：
2012/07/04 20:46 <DIR> !@#!@#~1.TXT !@#!@#!@#.txt
2012/07/04 20:46 <DIR> !@#!@#.txt
2012/07/04 20:44 <DIR> 012345~1 0123456789
2012/07/04 20:44 <DIR> 1
2012/07/04 20:44 <DIR> 123
2012/07/04 20:44 <DIR> 123456
2012/07/04 20:44 <DIR> 1234567
2012/07/04 20:44 <DIR> 12345678
2012/07/04 20:44 <DIR> 123456~1 123456789
2012/07/04 20:46 <DIR> 啊.txt
2012/07/04 20:46 <DIR> 啊啊啊~1.TXT 啊啊啊啊啊啊啊啊啊.txt
2012/07/04 20:43 29 012345~1.TXT 0123456789.txt
2012/07/04 20:43 29 1.txt
2012/07/04 20:43 29 123.txt
2012/07/04 20:43 29 123456.txt
2012/07/04 20:43 29 1234567.txt
2012/07/04 20:43 29 12345678.txt
2012/07/04 20:43 29 123456~1.TXT 123456789.txt
摘自 Nuclear'Atk 网络安全研究中心
下面是针对漏洞的解决方法：
一直在寻找一种方法，如果我可以使用通配符"*" 和 "?"发送一个请求到iis，我意识到当IIS接收到一个文件路径中包含"~"的请求时，它的反应是不同的.基于这个特点，我们可以根据http的响应区分一个可用或者不可用的文件。在以下的表中，文件validxxx.xxx是存在于网站服务器根目录的。(备注:xxx.xxx是指不确定，还需要继续猜解判断)。下图主要是不同版本的IIS返回根据请求的返回错误来判断是否存在某个文件。
举例说明如果一个IIS6网站http://www.xxx.com的短文件猜解方法。（注意一定要支持aspx，可用x.aspx判断）
请求 http://www.xxx.com/a*~1*/.aspx 返回404，就说明存在a开头的一个axxx.xxx的文件(其中xxx.xxx还需要进一步确定判断是什么字母,什么后缀)。
请求http://www.xxx.com/a*~1*/.aspx 返回400，说明不存在a开头的一个axxx.xxx的文件(其中xxx.xxx还需要进一步确定判断是什么字母,什么后缀)。
防范方法
危害级别：轻微
IIS短文件名泄露漏洞
WASC Threat Classification
描述： Microsoft IIS在实现上存在文件枚举漏洞，攻击者可利用此漏洞枚举网络服务器根目录中的文件。
1.Internet Information Services（IIS，互联网信息服务）是由微软公司提供的基于运行Microsoft Windows的互联网基本服务。
Microsoft IIS在实现上存在文件枚举漏洞，攻击者可利用此漏洞枚举网络服务器根目录中的文件。
危害： 攻击者可以利用“~”字符猜解或遍历服务器中的文件名，或对IIS服务器中的.Net Framework进行拒绝服务攻击。
解决方案：
1.关闭NTFS 8.3文件格式的支持。该功能默认是开启的，对于大多数用户来说无需开启。
如果是虚拟主机空间用户，请联系空间提供商进行修复。
修改方法：
1）修改注册列表HKLM\SYSTEM\CurrentControlSet\Control\FileSystem\NtfsDisable8dot3NameCreation的值为1,或者，可以直接点此下载，然后运行,再重启下机器。(此修改只能禁止NTFS8.3格式文件名创建,已经存在的文件的短文件名无法移除)，
2）如果你的web环境不需要asp.net的支持你可以进入Internet 信息服务(IIS)管理器 --- Web 服务扩展 - ASP.NET 选择禁止此功能。
3）升级net framework 至4.0以上版本.
将web文件夹的内容拷贝到另一个位置，比如D:\www到D:\www.back，然后删除原文件夹D:\www，再重命名D:\www.back到D:\www。如果不重新复制，已经存在的短文件名则是不会消失的。
攻击者可以利用“~”字符猜解或遍历服务器中的文件名，或对IIS服务器中的.Net Framework进行拒绝服务攻击。
以上就是IIS短文件和文件夹泄漏漏洞的分析。前途一片光明，可我找不到出路。感悟：把自己封闭起来，再光明也是虚无。人到老年，放飞自己，才是真正的出路。更多关于IIS短文件和文件夹泄漏漏洞的分析请关注haodaima.com其它相关文章！
