短文件名漏洞修復

短文件名漏洞其實在13年時仍是很使人耳熟能詳的，不過隨着所在公司的編碼語言轉型，目前使用ASP.NET的新項目基本上沒有了，而更多的是對原來的採用ASP.NET語言開發的項目進行維護或打個補丁。

 

事出忽然，12月的某個下午被項目組喊去幫個忙，第一感受就是「是否是線上的項目被人黑了？」。因而乎就跑去看下具體的狀況，項目組負責人見到我第一句話就是「某個項目被某國家單位進行線上項目巡檢時發現了一個漏洞，可是不會修」。

 

往他所指的電腦上簡單一看，映入眼簾的就是「存在短文件名漏洞，定級爲高」。是的，就是這麼一個漏洞搞得項目組大夥都緊張。

 

短文件名漏洞是不少沒有作過安全測試的項目的痛，由於發生的機率仍是很高的，這一點能夠經過谷歌來證明。無論是如今的國產安全掃掃器仍是國外的安全掃描器都是能輕易的掃出的，且安全危險定級都不低。

 

短文件名漏洞的產生原理是啥呢？這一塊網上資料不少，我就不細講，有興趣能夠查下維基，我這裏着重地貼上一個圖來簡單地解釋下：

 

 

 

首先咱們來發現一些細節：

1. 從Windows 2003到Windows 2008 R2系列都有存在短文件名漏洞的可能；

2. Windows 2008 以後的利用場景更爲苛刻

 

那麼短文件名漏洞利用原理是啥，這裏貼個內容：

 

Windows 還以 8.3 格式生成與 MS-DOS 兼容的（短）文件名，以容許基於 MS-DOS 或 16 位 Windows的程序訪問這些文件。在cmd下輸入「dir /x」便可看到短文件名的效果。通配符」*」 和 「?」發送一個請求到IIS，當IIS接收到一個文件路徑中包含」~」的請求時，它的反應是不一樣的。基於這個特色，能夠根據HTTP的響應區分一個可用或者不可用的文件。

 

爲了去復現短文件名，咱們通常不建議用手工，耗時又耗力，偉大的GITHUB上已經有無數能人寫了腳本，這裏我貼一個，若你有更好的，歡迎留言分享下：https://github.com/lijiejie/IIS_shortname_Scanner 

要存在短文件名就會所有列出來，沒有就會提示沒有，簡單易用。

 

漏洞怎麼修呢？

 

這裏我首先列一下網上收集的所有修復手段：

1. 禁止url中使用「~」或它的Unicode編碼；

2. 關閉windows的8.3格式功能；

3. 將.NET Farrmework升級至4.0

 

正好，本次的需求下，讓運維一個一個地試，一組一組地嘗試。結果「真理仍是出於實踐」：

1. 系統框架已爲4.0版本，經掃描漏洞依然存在；

2. 禁止url中使用「~」或它的Unicode編碼，手段太複雜，基本上不多運維懂；

3. 單純地關閉windows的8.3格式功能是沒有鳥用的

 

*注：咱們的漏洞環境爲Windows 2008 R2，程序使用的是ASP.NET 2.0。

 

咱們最終的方案是（大家僅做參考哈，畢竟偶是不會對你負責的）：

1. 修改註冊表項：（重啓服務器生效）
   HKLM\SYSTEM\CurrentControlSet\Control\FileSystem\NtfsDisable8dot3NameCreation
   值爲1；

2. 執行DOS命令， fsutil behavior set disable8dot3 1；

3. 刪除現有的IIS目錄從新部署，完成此步驟才能徹底修復

 

*注：註冊表項說明見微軟官方文檔：