滲透測試的WINDOWS NTFS技巧集合（一）

來自專欄看雪論壇6 人贊了文章

——————————————————————————————————————

由於篇幅過長，故將《滲透測試的WINDOWS NTFS技巧集合》分為兩個部分發，今日為第一部分，內有技巧1-4。

明日將發布第二個部分，內有技巧5、技巧6。

——————————————————————————————————————

這篇文章是來自SEC Consult Vulnerability Lab的ReneFreingruber (@ReneFreingruber)，分享了過去幾年從各種博客文章中收集的或者是他自己發現的文件系統技巧，這些技巧不可以直接被利用。但是它們會在特殊情況下間接地產生可以被攻擊者利用的漏洞。

請注意，這篇文章只說明有關於如何利用這些問題以及影響的信息(沒有關於Windows API的技術底層細節)，因為這樣會超出本篇文章的技術範圍。

第一個文件系統技巧(技巧1 - CVE-2018-1036)被微軟修補了，其他技巧還有沒有安全補丁。

技巧1:創建沒有許可權的文件夾(CVE-2018-1036/NTFS EOP)

在Windows上，可以為文件夾分配「特殊許可權」，例如允許用戶在文件夾中創建文件但不允許創建文件夾的許可權。

此類文件夾的一個示例是C:WindowsTasks，用戶可以在其中創建文件，但不允許創建文件夾：

而管理員或程序可能會配置這樣的許可權，並假設用戶不允許在其中創建文件夾。

這個ACL策略可以在用戶創建文件時被繞過。如果在文件名的末尾添加「::$INDEX_ALLOCATION」將創建一個文件夾而不是一個文件。Windows當前不包含對該類情況的檢查。

如上圖所示，已成功創建了一個文件夾，用戶可以在這個文件夾中創建任意的文件或文件夾（如果管理員/程序認為缺少許可權而無法執行創建文件夾的操作，這個技巧可能會導致特權提升 ）。

附註：如果應用程序只允許刪除文件，:: $ INDEX_ALLOCATION技巧也可用於刪除文件夾。

譯者註：使用以下命令即可刪除文件夾。

rd test::$INDEX_ALLOCATION

微軟漏洞聯繫時間表：

2018年3月1日： 通過secure@microsoft.com進行初步聯繫。發送PGP加密的博客帖子。2018年3月1日： Microsoft分配了MSRC Case 43968 CRM：04610398822018年3月5日： 微軟要求延長披露期限。2018年3月5日： 同意延長90天的截止日期。2018年3月27日： 詢問微軟是否可以重現漏洞以及何時可以獲得補丁。2018年3月28日： 微軟證實，「技巧1」漏洞已成功重現並分配給了編號CVE-2018-1036。該漏洞將由5B（5月補丁星期二）修復。2018年4月27日： 微軟與我們聯繫，提議的修復方案導致回退。微軟要求將修補的最後期限延長至2018-06-12(6月補丁周二)。2018年4月30日： 了解微軟的情況，截止日期延長至2018-06-12。詢問微軟是否還會修補其他技巧。2018年4月30日： 微軟回應稱其他技巧「不會收到低級安全更新」。2018年6月12日： Microsoft發布補丁（請參閱此處的發布 https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/CVE-2018-10362018年6月13日： 博客發布。

技巧2：使用供選數據流繞過路徑限制

你可能想知道為什麼上面的方法有效。

<文件名>:<數據流名稱>:<類型>

如果我們創建一個名為test的文件。它將在內部存儲為test.test::$DATA，因為數據流名為空，且$DATA是默認類型。第一個技巧的原理是將數據流類型更改為INDEX_ALLOCATION，而INDEX_ALLOCATION對應於文件夾類型，所以創建了一個文件夾。

但是，也可以將數據存儲在不同的流中。(這就是所謂的Alternate Data Stream – ADS)。如果我們寫的例子是「test.txt」，我們在實際寫入的是「test.txt::$DATA」(數據流名稱為空)。我們也可以寫入「test.txt:foo」 或「test.txt:foo:$DATA」（兩者都相同，因為$DATA是默認類型）。也可以使用不同的流名稱用於存儲文件的信息。如果你從互聯網下載文件(或通過電子郵件接收)，Windows系統會通過流名稱悄悄地添加區域標識符（如果你想執行會顯示出一個附加的警告對話框）例如，如果我們下載「putty.exe」，Windows也會創建」putty.exe:Zone.Identifier:$DATA「。使用dir /r命令可以看到這些流名稱：

正如我們所看到的，帶有數據流的文件是不能通過type命令直接讀取的(使用更多的命令就可以了)，如果我們使用notepad讀取文件，那麼可以忽略冒號最末尾的$DATA類型。我們還可以把重要的信息(包括應用程序!)在ADS中存儲。例如putty.exe就可以複製到ADS中，然後通過wmic調用(不可以用start直接調用)：

附註:本文撰寫於2018-03-01，並報告給微軟。與此同時，微軟的Windows Defender被更新以檢測WMIC進程調用。

你可能會問為什麼有人會這樣做?首先，ADS可以用來隱藏數據（dir沒有使用/r開關不會顯示文件中的ADS;explorer.exe也不會顯示ADS;稍後介紹如何能夠隱藏dir /r開關的內容…）而ADS還有一個很好的特性——我們可以在文件夾中添加ADS。這樣做的前提是在文件夾里擁有「創建文件夾」的許可權(而且文件夾名稱不能是數字)。這樣做可以使文件夾上的ADS看起來像是來自父文件夾的文件!

在Windows上一個普通用戶無法在C:Windows創建文件(只有管理員可以寫這個文件夾)。因為只有管理員可以創建這些文件,所以應用有可能認為文件在C:Windows是可以受信任的。可是普通用戶在C:WindowsTracing文件夾中是可以創建文件和文件夾的，因此普通用戶可以創建一個ADS在這個文件夾中。

假設用戶寫入文件C:WindowsTracing:test.dll。如果這個路徑現在被傳遞給一個遍歷文件夾的Windows API，這個API將從路徑的末尾開始，直到找到第一個「」。將「」中剩下的所有內容作為文件夾返回。而C:WindowsTracing:test.dll 將返回C:Windows作為文件夾。正如前面提到的,一個普通用戶不允許使用這個技巧創建文件在Windows文件夾。但是我們可以通過這個方法創建了一個文件，而且是存儲在C: Windows文件夾內 !

這裡是不同Windows函數遍歷文件夾的輸出(我們可以看到它總是C: Windows):

注:上述存儲dll可以開始與Windows內置的control.exe應用程序啟動，命令為: control.exe C:Windows racing:foobar.dll

此行為可用於繞過某些應用程序白名單解決方案，也可以在各種情況下繞過安全檢查。例如程序員認為檢查文件是否存儲在特定的文件文件夾中就足夠了並且假設當管理員通過設置ACL後寫入這個文件夾。

考慮應用程序允許上傳數據，上傳的數據存儲在applicationFolder uploadedData 中。而應用程序允許從applicationFolder啟動腳本/應用程序，而不允許從applicationFolder uploadedData(使用黑名單方法)啟動腳本/應用程序。如果用戶上傳一個名為「:foo.ps1」的文件，系統將創建一個類似於applicationFolderuploadedData:foo.ps1的ADS。此文件似乎存儲在applicationFolder中，因此繞過安全檢查。

另一個有趣的事情是ADS可以包含通常文件名禁止使用的「或*符號(必須使用本機Windows API創建這些文件;cmd.exe會過濾這些字元):

這本身就可能導致幾個問題。 （例如，如果文件名以「開頭和路徑被」包圍結尾，正如James Forshaw在他的博客中提到的方法;請參見參考資料部分）。另一個有趣的攻擊向量可以是XSS(或命令注入)。假設一個網站在IIS上運行並允許上傳文件，並且很容易出現CSRF。上傳文件後，將顯示包含文件名的成功對話框。如果文件名未被處理，這可能會導致XSS，但是如果文件名不允許包含像<或>之類的符號(因此我們不能用它來執行JavaScript代碼)。如果允許ADS文件包含這些符號，那麼攻擊者可以嘗試使用ADS文件名發送上傳請求:

技巧3:創建無法通過「…」文件夾找到的文件

每個文件夾都包含默認的兩個特殊條目，也就是指當前文件夾「.」文件夾和指向父文件夾（父目錄）「..」文件夾。在Windows上不能用名稱中的點創建文件/文件夾，最有可能防止將解析器與點混淆的攻擊。

上面的截圖顯示,不能創建一個「…」或「....」的文件夾。但是可以使用上面提到的:$INDEX_ALLOCATION技巧來繞過:

「…」文件夾是用上面提到的技巧創建的，但是這樣的文件夾也可以將名稱傳遞兩次來創建，如「…」示例中所示。(mkdir 「.... ....「 創建文件夾」....」,但裡面還有一個文件夾「….」。僅僅通過mkdir 」....xyz「不起作用。)

使用第二個技巧，我們還可以輸入這些文件夾，在那裡存儲文件，甚至從這個位置執行程序:

如圖所示，無法僅使用名稱進入文件夾(例如:「cd …」或「cd …」或「cd ……」不起作用)，必須使用「cd ……」的語法。進入文件夾之後可以在這個文件夾里創建文件。(有趣的是:如果你在這個文件夾里輸入「cd .」，你又會回到這個文件夾，因為路徑是混亂的)。

此外，也不可能從GUI (explorer.exe)打開這個文件夾。我遇到了兩種不同的情況。在某些情況下，雙擊這樣的文件夾沒有影響(保持在當前文件夾中，路徑保持不變)，在其他情況下，我們將保持在文件夾中，但是資源管理器中的路徑發生了更改。例如，在「打開」文件夾17次之後(注意路徑中的「…」 ):

可以嘗試根據需要隨時進入該文件夾 ，可無法在GUI中的文件夾中看到這些文件 。也無法通過在上圖中的路徑輸入欄位傳遞「C: est……」來打開文件夾。

(附註:如果試圖從GUI中刪除該文件夾，explorer.exe會崩潰;我們將看到一個對話框，其中Windows正在計算文件夾中的文件以及它所在的位置「很多文件」 ；不要在工作系統上試試這個... )

通過GUI (explorer.exe)搜索這個文件夾中的文件也不起作用，例如GUI搜索「123.txt」文件，圖形用戶界面實際上是被掛起/搜索，而不會查找文件 。

請注意， 通過cmd進行搜索是沒有問題的:

但是大多數人現在都使用Powershell，而使用Powershell又找不到這個文件，因為它會陷入無限循環:

(輸出被截斷，因為命令總是循環列印這兩個文件夾...)

搜索「123.txt」(例如:「Get-ChildItem -Path C: est -Filter 123.txt -Recurse -ErrorAction SilentlyContinue -Force」)將永遠不會找到該文件(並且永遠不會結束)。

我還用不同的AntiVirus產品進行了測試，這些產品似乎都可以正常工作(我將惡意軟體樣本放在這個...的特殊文件夾中，經過測試AntiVirus產品可以找到它們)。有些人仍然對這條路徑感到困惑，例如在「C: est…」中搜索病毒時，他們會在「C: est」中搜索。使用os.walk()的python代碼似乎也能正常工作。

請注意，只是創建一個目錄連接指向它自己的父文件夾不會在cmd或Powershell中導致無限循環 。

技巧4：「隱藏」目錄連接的指向目標

目錄連接是一個非常有用的NTFS功能，可以為攻擊者找到安全漏洞。使用它可以創建(使用普通用戶許可權)到目標文件夾的符號鏈接。

解釋目錄連接的最佳安全漏洞是AVGater，攻擊者將一個文件放在x文件夾中，然後將該文件標記為病毒，並且已安裝的AntiVirus解決方案將其移至隔離區。之後攻擊者刪除文件夾x，並用一個名為「x」的目錄連接替換它，該連接指向C:windowsSystem32。如果攻擊者現在單擊「恢復」按鈕，AntiVirus解決方案會將把文件複製到x文件夾，該文件夾現在指向具有SYSTEM許可權的system32(直接導致EoP)。

如果目標應用程序包含競爭條件類型漏洞(TOCTOU漏洞——檢查使用時間)，則目錄連接會被濫用。

使用mklink實用程序和/J參數創建一個目錄連接。可以將它與::$INDEX_ALLOCATION技巧結合使用，創建一個名為「…」的目錄連接:

第一個目錄連接「test1」是用一個普通的名稱創建的，因此目標在「dir」輸出中被正確地顯示。但是，在「…」目錄連接的情況下，不再顯示目標(而是顯示[…];見紅框)。還請注意，你可以讓連接點1指向連接點2，指向連接點3，以此類推，直到最後一個指向真正的目的地。

由於路徑混淆，您可以使用上面提到的「cd……」技巧(在system32文件夾中)進入結點，但 「.」會指向「C: est8」:

dir命令從system32文件夾列印文件（紅色標記;請注意，第一個命令在C: est8創建了hello.bat文件）

紅色標記的文件是system32文件夾中的最後一個文件(dir命令的最後一個輸出)。在藍色中我們可以看到執行的是當前目錄 (「.」)中的「hello.bat」 ，由於路徑混淆，執行了C: est8hello.bat(綠色方塊)而不是C:windowssystem32hello.bat。我不確定這是否對安全性產生直接影響。因為我們可以在任何文件夾中啟動文件。但是它可能會被用來繞過應用程序使用白名單腳本文件的白名單解決方案。

—————————————未完待續，明日續更技巧6&技巧7———————————

本文譯者：lipss（看雪ID)

轉載請註明：轉自看雪論壇

看雪閱讀推薦：

1、打造Wi-Fi 「DOS」攻擊工具——Wi-Fi_deauther

2、Asis 2016 b00ks (off by one利用)

3、[原創]網鼎杯第一場預選 babyheap

4、[原創]ctf pwn中的unsorted bin利用及chunk shrink——0ctf2018 heapstorm2 writeup

5、[原創]反虛擬機技術總結

推薦閱讀：