FavoriteLoading
0

滲透測試技術之另類Windows提權

前言


如果你獲得了一臺機器的低權限Meterpreter會話,并且當你嘗試了一些常用方法,仍然提權失敗時,是不是就意味著沒法提權呢?不必著急,你仍然可以試試很多其它的技術。下面我們就來列舉出幾種提權方法。

一、Windows服務路徑沒加雙引號


通常,如果一個服務的可執行文件的路徑沒有用雙引號封閉,并且包含空格,那么這個服務就是有漏洞的。

如果你想驗證這個漏洞,你可以在你的試驗環境中增加一個有漏洞的服務,自己測試一下,下面咱們添加名為“Vulnerable Service”的服務,可執行文件放在“C:\Program Files (x86)\Program Folder\A Subfolder\”目錄中。

/Article/UploadPic/2017-1/2017121101654256.png

為了識別出沒有加雙引號的服務,你可以在Windows命令行中運行以下命令:

/Article/UploadPic/2017-1/2017121101655881.png

運行上面的命令后,所有沒有加雙引號的服務將會被列出來:

/Article/UploadPic/2017-1/2017121101655717.png

如果你從注冊表中查看注冊的服務,你會看到“ImagePath”的值是:

/Article/UploadPic/2017-1/2017121101656874.png

安全的值應該是:

/Article/UploadPic/2017-1/2017121101656850.png

/Article/UploadPic/2017-1/2017121101656275.png

當Windows嘗試啟動這個服務時,它會按照下面的順序尋找可執行文件,并運行第一個找到的:

/Article/UploadPic/2017-1/2017121101658535.png

這個漏洞是由系統中的“CreateProcess”函數引起的,更多信息請看這里

如果我們能成功的把惡意EXE程序放在這些路徑下,當服務重新啟動時,Windows就會以SYSTEM權限運行我們的EXE。當然,我們需要有進入其中一個目錄的權限。

為了檢查一個目錄的權限,我們可以使用Windows內建的一個工具,icals,下面我們用這個工具檢查“C:\Program Files (x86)\Program Folder”目錄的權限。

/Article/UploadPic/2017-1/2017121101658492.png

好幸運吶,你可以看到,“Everyone”用戶對這個文件有完全控制權。

“F”代表完全控制。“CI”代表從屬容器將繼承訪問控制項。“OI”代表從屬文件將繼承訪問控制項。

這意味著我們可以隨意將文件寫入這個文件夾。

從現在開始,你要做什么取決于你的想象力。我比較傾向于生成一個反彈shell載荷,并用SYSTEM權限運行。

這個工作可以使用msfvenom來完成:

/Article/UploadPic/2017-1/2017121101659492.png

然后將生成的載荷放到“C:\Program Files (x86)\Program Folder”文件夾:

/Article/UploadPic/2017-1/2017121101659711.png

然后,在下一步啟動這個服務時,A.exe就會以SYSTEM權限運行,下面我們試著停止,并重啟這個服務:

/Article/UploadPic/2017-1/2017121101659275.png

訪問被拒絕了,因為我們沒有停止或啟動服務的權限。不過,這不是一個大問題,我們可以等,直到有人重啟機器,或者我們自己用“shutdown”命令重啟:

/Article/UploadPic/2017-1/2017121101659574.png

正如你看到的,低權限的會話中斷了,說明命令執行了。

我們的機器正在重啟,現在,我們的載荷將會以SYSTEM權限運行,我們需要立即在本地建立監聽:

/Article/UploadPic/2017-1/201712110170124.png

現在,我們獲得了一個SYSTEM權限的meterpreter shell。

但是,我們新得到的會話很快就中斷了,為什么呢?

不必擔心,當一個服務在Windows系統中啟動后,它必須和服務控制管理器通信。如果沒有通信,服務控制管理器會認為出現了錯誤,并會終止這個進程。

我們所有需要做的就是在終止載荷進程之前,將它遷移到其它進程,你也可以使用自動遷移。

順便說一句,有一個檢查和利用這個漏洞的Metasploit模塊:exploit/windows/local/trusted_service_path

在運行這個模塊前,需要將它和一個已經存在的meterpreter會話(實際上就是你的低權限會話)關聯起來,如下圖:

/Article/UploadPic/2017-1/201712110170389.png

具體過程可以看這里

二、Windows服務帶有易受攻擊的權限


大家知道,Windows服務是以SYSTEM權限運行的。因此,它們的文件夾、文件和注冊的鍵值,必須受到強訪問控制保護。在某些情況下,我們能遇到沒有受到有效保護的服務。

不安全的注冊表權限

在Windows中,和Windows服務有關的信息存儲在“HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services”注冊表項中,根據我們上面的測試實例,我們可以找到“HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Vulnerable Service”鍵值。

/Article/UploadPic/2017-1/201712110170970.png

當然,我們建的“Vulnerable Service”服務存在漏洞。

/Article/UploadPic/2017-1/201712110170594.png

但問題是,我們怎樣才能從命令行檢查這些權限?讓我們從頭開始演示。

你已經得到了一個低權限的Meterpreter會話,并且你想檢查一個服務的權限。

/Article/UploadPic/2017-1/201712110171812.png

你可以使用SubInACL工具去檢查注冊表項的權限。你可以從這里下載它,但是你要意識到這個程序是一個msi文件。如果目標機器上的AlwaysInstallElevated策略設置沒有啟用,那么你沒法以低權限安裝msi文件,當然,您可能也不想在目標機器上安裝新的軟件。

我建議你在一個虛擬機中安裝這個軟件,并在它的安裝目錄中找到“subinacl.exe”文件。它能順利工作,并且無需安裝msi文件。然后將SubInACL上傳到目標機器。

/Article/UploadPic/2017-1/201712110171701.png

現在SubInACL工具可以用了,下面我們來檢查“HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Vulnerable Service”的權限。

/Article/UploadPic/2017-1/201712110171132.png

請看第22、23行,“Everyone”在這個注冊表項上有完全的控制權。意味著我們可以通過編輯ImagePath的值,更改該服務的可執行文件路徑。 這是一個巨大的安全漏洞。

我們生成一個反彈shell載荷,并將它上傳到目標機器中,然后把服務的可執行文件路徑修改為反彈shell載荷的路徑。

首先,生成一個載荷:

/Article/UploadPic/2017-1/201712110171549.png

上傳到目標機器中:

/Article/UploadPic/2017-1/201712110171526.png

將ImagePath的值改成我們載荷的路徑:

/Article/UploadPic/2017-1/201712110172213.png

在下一次啟動該服務時,payload.exe將會以SYSTEM權限運行。但是請記住,我們必須重新啟動電腦才能做到這一點。

/Article/UploadPic/2017-1/201712110172771.png

如上圖,我們的目標機正在重啟,請將監聽進程準備好,我們的載荷將會以SYSTEM權限運行。

/Article/UploadPic/2017-1/201712110172799.png

但是不是忘了,我們利用服務的方式和前面講的方式(服務路徑沒加雙引號)原理上實際是一樣的,返回的高權限很快會斷掉(可以使用自動遷移,如AutoRunScript)。

不安全的服務權限

這和前面講的不安全的注冊表權限很相似,只是這次我們沒有修改ImagePath的值,我們直接修改了服務的屬性。

為了檢查哪個服務有易受攻擊的權限,我們可以使用AccessChk工具,它來源于SysInternals Suite工具集。

將AccessChk工具上傳到目標機器中:

/Article/UploadPic/2017-1/201712110173734.png

為了檢查易受攻擊的服務,我們運行以下命令:

/Article/UploadPic/2017-1/201712110173954.png

如圖,通過上面的命令,所有“testuser”用戶可以修改的服務都被列出來了。SERVICE_ALL_ACCESS的意思是我們對“Vulnerable Service”的屬性擁有完全控制權。

讓我們看一下“Vulnerable Service”服務的屬性:

/Article/UploadPic/2017-1/201712110175529.png

BINARY_PATH_NAME參數指向了該服務的可執行程序(Executable.exe)路徑。如果我們將這個值修改成任何命令,那意味著這個命令在該服務下一次啟動時,將會以SYSTEM權限運行。如果我們愿意,我們可以添加一個本地管理員。

首先要做的是添加一個用戶:

/Article/UploadPic/2017-1/201712110175657.png

在修改了binpath的值后,用“sc stop”和“sc start”命令重啟服務:

/Article/UploadPic/2017-1/201712110176209.png

當你嘗試啟動服務時,它會返回一個錯誤。這一點我們之前已經討論過了,在Windows系統中,當一個服務在Windows系統中啟動后,它必須和服務控制管理器通信。如果沒有通信,服務控制管理器會認為出現了錯誤,并會終止這個進程。上面的“net user”肯定是無法和服務管理器通信的,但是不用擔心,我們的命令已經以SYSTEM權限運行了,并且成功添加了一個用戶。

現在我們以同樣的方式,再將剛才添加的用戶,添加到本地管理員組(需要再次停止服務,不過此時服務不在運行狀態,因為剛才發生了錯誤,進程被終止了)。

/Article/UploadPic/2017-1/201712110176714.png

下面可以享受你的新本地管理帳戶了!

/Article/UploadPic/2017-1/201712110176831.png

同樣,你也可以將一個反彈shell載荷上傳到目標機器中,并將binpath的值改成載荷的路徑。

只是這次不用再手動使用這個方法了,有現成的metasploit模塊:exploit/windows/local/service_permissions

你需要將這個模塊和一個已經存在的Meterpreter會話(已經得到的低權限會話)關聯起來:

/Article/UploadPic/2017-1/201712110176287.png

三、不安全的文件/文件夾權限


和前面我們講過的“服務路徑沒加雙引號”很相似,“服務路徑沒加雙引號”利用了“CreateProcess”函數的弱點,結合了文件夾權限與服務可執行文件路徑。但是在這部分,我們轉換思路,試著直接替換可執行文件本身。

例如,如果對測試環境中“Vulnerable Service”服務的可執行文件路徑的權限進行檢查,我們可以看到它沒有被保護好:

/Article/UploadPic/2017-1/201712110177785.png

僅僅需要將“Executable.exe”文件替換成一個反彈shell載荷,并且當服務重啟時,會給我們返回一個SYSTEM權限的meterpreter 會話。

四、AlwaysInstallElevated設置


AlwaysInstallElevated是一個策略設置,當在系統中使用Windows Installer安裝任何程序時,該參數允許非特權用戶以system權限運行MSI文件。如果啟用此策略設置,會將權限擴展到所有程序。

實際上,啟用這個值,就相當于給非特權用戶授予了管理員權限。但是有一點我理解不了,有時候系統管理員會啟用這個設置:

/Article/UploadPic/2017-1/201712110177899.png

你需要檢查下面這兩個注冊表鍵值,來了解這個策略是否被啟用:

/Article/UploadPic/2017-1/201712110177791.png

如果你獲得了一個低權限的Meterpreter會話,reg內建命令可以幫你檢查這些值:

/Article/UploadPic/2017-1/201712110178273.png

如果,你得到了一個錯誤,就像是“ERROR: The system was unable to find the specified registry key or value.”,它的意思是這個注冊表值沒有被創建,也就是說這個策略沒有啟用。但是如果你看到了下面的輸出結果,那意味著該策略設置是啟用的,你可以利用它。

/Article/UploadPic/2017-1/201712110178134.png

正如我前面說過的,在這種情況下,Windows Installer會使用高權限來安裝任何程序。因此,我們需要生成一個惡意的“.msi”文件,并運行它。Msfvenom工具可以完成這個工作。

如果你想生成一個“.msi”文件,并向目標機器中添加一個本地管理帳戶,你可以使用“windows/adduser”作為載荷:

/Article/UploadPic/2017-1/201712110178966.png

但是在這個例子中,我要生成一個反彈shell載荷(Payload.exe),并使用一個msi文件執行這個載荷,首先,產生Payload.exe:

/Article/UploadPic/2017-1/201712110178137.png

然后使用“windows/exec”生成一個malicious.msi。請確定你填寫了Payload.exe的正確路徑:

/Article/UploadPic/2017-1/201712110178994.png

然后我們將這兩個可執行文件上傳到目標機器中。

/Article/UploadPic/2017-1/201712110179993.png

在執行“.msi”文件前,在另一個窗口中開啟一個新的監聽,等待高權限的shell連接:

/Article/UploadPic/2017-1/201712110179762.png

現在,我們準備執行!

/Article/UploadPic/2017-1/201712110179314.png

“/quiet”表示安靜模式,無用戶交互。“/qn”表示沒有GUI。“/i”表示安裝或配置產品。

如下圖,成功返回:

/Article/UploadPic/2017-1/201712110179120.png

除了手動使用這個技術,你也可以使用現成的metasploit模塊:exploit/windows/local/always_install_elevated

該模塊SESSION參數需要設置為一個已經存在的Meterpreter會話: 

/Article/UploadPic/2017-1/201712110179778.png

五、DLL劫持


假如上面的方法都沒成功,不要放棄。我們開始研究一下正在運行的進程。

/Article/UploadPic/2017-1/201712110179311.png

如上圖,如果我們的shell是以低權限運行的,我們不會看到進程的詳細信息(運行在高權限上的進程),如用戶、路徑、結構。但是我們可以了解到有哪些進程運行在高權限上。如果其中的一個進程存在漏洞,我們就可以利用它來提升我們的權限。

在對進程研究過程中,Vulnerable.exe進程引起了我的注意,讓我們來找一找它的位置,并下載它:

/Article/UploadPic/2017-1/2017121101710674.png

當我對它進行檢查后,我意識到它試圖加載一個名為“hijackable.dll”的DLL。

/Article/UploadPic/2017-1/2017121101710697.png

在這個例子中,Vulnerable.exe進程存在DLL劫持漏洞。當然,實際上這個Vulnerable.exe只是一段簡單的代碼,在沒有做檢查的情況下加載了一個DLL:

/Article/UploadPic/2017-1/2017121101710513.png

回到我們的話題,什么是DLL劫持呢?微軟的一篇文章是這樣解釋的:

當應用程序動態加載動態鏈接庫而不指定完整的路徑名時,Windows會嘗試通過一個特定的目錄順序,來搜索定位DLL,在這里有目錄的搜索順序。如果攻擊者得到了其中一個目錄的控制權限,他可以用一個惡意軟件來替代DLL。這種方法有時被稱為DLL預加載攻擊或二進制移植攻擊。如果系統在搜索到受感染的目錄前,沒有找到合法的DLL,那它將會加載惡意的DLL。如果這個應用程序是以管理員權限運行的,那么攻擊者就可以成功的得到本地權限提升。

當一個進程嘗試加載DLL時,系統會按以下順序搜索目錄:

1.應用程序加載的目錄。

2.系統目錄。

3.16比特系統目錄。

4.Windows目錄。

5.當前目錄。

6.PATH 環境變量中列出的目錄。

因此,為利用這個漏洞,我們按以下步驟:

1.檢查進程加載的DLL是否存在于磁盤中。

2.如果不存在,將惡意DLL放在我剛才提到的其中一個目錄中。當進程執行時,它可能會找到該DLL,并加載DLL。

3.如果DLL在上述其中一個目錄中存在,那么將惡意DLL放在比當前目錄的搜索優先級更高的目錄中,例如,如果源DLL在Windows目錄中,并且我們獲得了應用程序加載目錄的權限時,我們可以將惡意DLL放到應用程序加載目錄,當應用程序加載DLL時,它會首先加載該目錄的DLL。最終,我們的惡意代碼會以高權限執行。

下面,讓我們在目標機器中搜索一下hijackable.dll的位置:

/Article/UploadPic/2017-1/2017121101710951.png

貌似在機器上不存在,但是我們實際上無法確定這一點,也許它被放在了一個我們沒有權限查看的目錄中,不要忘了,我們目前的權限仍然是低權限。

下一步是檢查可能的弱權限文件夾。我通常檢查一個軟件是否被安裝在根目錄中,如Python。因為如果一個文件夾被創建在根目錄中,通常對于所有認證的用戶(authenticated users:Windows系統中所有使用用戶名、密碼登錄并通過身份驗證的賬戶,不包括來賓賬戶Guest),默認情況下它是可寫的。像Python、Ruby、Perl等等。通常會添加到PATH環境變量中。

記著,Windows會檢查PATH環境變量中的目錄。

/Article/UploadPic/2017-1/2017121101710677.png

正如我想的,目標機器上安裝了Python,讓我們檢查一下它的權限:

/Article/UploadPic/2017-1/2017121101711720.png

太好了,認證的用戶有修改的權限。

剩下最后一項檢查了,我們需要確定“C:\Python27”目錄是否已經被添加到PATH環境變量中,檢查這個很容易,在shell中試一下“python -h”就知道了,如果幫助頁面成功顯示,意味著環境變量已經添加了:

/Article/UploadPic/2017-1/2017121101711694.png

結果非常好,下面我們創建一個DLL版本的反彈shell載荷:

/Article/UploadPic/2017-1/2017121101711626.png

將這個DLL上傳到“C:\Python27”目錄:

/Article/UploadPic/2017-1/2017121101712826.png

現在,我們重啟“Vulnerable.exe”進程,進程會加載惡意DLL,我們可以嘗試殺死進程,如果我們足夠幸運,它將會自動啟動:

/Article/UploadPic/2017-1/2017121101712347.png

好吧,我們今天運氣不好,沒有殺死。不過至少,我們可以重啟機器。如果“Vulnerable.exe”進程是一個開機啟動應用,或一個服務、一個計劃任務,那它將會再次啟動。最壞的情況是,我們得等待有人來啟動它。

/Article/UploadPic/2017-1/2017121101712776.png

機器正在重啟,讓我們開啟一個監聽,希望有好運:

/Article/UploadPic/2017-1/2017121101713997.png

成功了!

六、存儲的憑證


如果上面的方法中,有任何方法管用了,拉下來你可以試著找一些存儲的憑證。你可能想檢查這些目錄:C:\unattend.xml、C:\sysprep.inf、C:\sysprep\sysprep.xml。

你可以使用下面的查詢方法:

/Article/UploadPic/2017-1/2017121101713391.png

七、內核漏洞


在我們這篇文章中,我們主要講了不依賴內核漏洞的提權方法,但是如果你想利用一個內核漏洞來提升權限的話,也許你能用到下面的命令,它可以幫你選擇利用哪一個漏洞:

/Article/UploadPic/2017-1/2017121101713126.png

它會列出機器中的更新。

八、對有效載荷的說明


在這篇文章中,我們使用了由msfvenom生成的載荷,但是在今天,這些載荷已經被各種反病毒軟件標記了,因為它非常受歡迎,并被反病毒廠商所熟知。不過,在創建可執行文件時,使用繞過AV的技術,將會給你帶來好的結果。

【聲明】:8090安全小組門戶(http://www.jvwkvg.tw)登載此文出于傳遞更多信息之目的,并不代表本站贊同其觀點和對其真實性負責,僅適于網絡安全技術愛好者學習研究使用,學習中請遵循國家相關法律法規。如有問題請聯系我們,聯系郵箱[email protected],我們會在最短的時間內進行處理。