站長資訊網
一、 什么是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. 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:inetpubwwwroot輸入“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. IIS短文件漏洞復現和利用
3.1 IIS短文件漏洞復現
3.1.1 漏洞環境搭建
基于Win 10安裝默認IIS 10.0 （未安裝APS.NET）
IIS短文件漏洞掃描Java程序（需要配置Java環境變量）
3.1.2 漏洞環境調試準備
IIS 安裝成功以后，會默認在C盤目錄下生成intpub目錄，網站的根目錄位于C:inetpubwwwroot，此時查看下根目錄是否存在短文件名：
由上圖可知，默認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
4. IIS短文件漏洞局限性
此漏洞存在以下幾個局限點：
1) 此漏洞只能確定前6個字符，如果后面的字符太長、包含特殊字符，很難猜解；
2) 如果文件名本身太短（無短文件名）也是無法猜解的；
3) 如果文件名前6位帶空格，8.3格式的短文件名會補進，和真實文件名不匹配；
4) 如果文件夾名前6位字符帶點“.”，掃描程序會認為是文件而不是文件夾，最終出現誤報；
5) 不支持中文文件名，包括中文文件和中文文件夾。一個中文相當于兩個英文字符，故超過4個中文字會產生短文件名，但是IIS不支持中文猜測。
5. 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_MACHINESYSTEMCurrentControlSetControlFileSystem，將其中的 NtfsDisable8dot3NameCreation這一項的值設為 1，1代表不創建短文件名格式
修改完成后，需要重啟系統生效
注：此方法只能禁止NTFS8.3格式文件名創建,已經存在的文件的短文件名無法移除，需要重新復制才會消失。
以下兩種方法僅適用于緩解GET 方法，其他方法依舊可以猜解。
3) 關閉Web服務擴展- ASP.NET
4) 升級netFramework至4.0以上版本
