彈性邊界：如何利用環境變數進行提權

簡介

儘管進程都設置了環境變數，它們往往被用戶，開發者甚至是系統本身所忽略。對於一個像樣的系統來說，環境變數就是其最根本，這裡的系統包括但不僅限於Unix (Linux, BSD), Windows以及OS X。在微軟操作系統的世界中，環境變數在其第一個版本DOS時期就已經出現，且一直沿用至今。環境變數得到重視還得從2014年9月份爆發的ShellShock漏洞說起。

關於ShellShock可參考

《ShellShock（破殼）漏洞餘威不減：新ShellShock蠕蟲掃描大量脆弱主機展開攻擊》

《SEED實驗系列：ShellShock攻擊實驗》

《破殼（ShellShock）漏洞樣本分析報告》

該漏洞在Unxi系統中通過環境變數注入，進而執行命令。

進程的環境

簡言之，環境就是一個可用於進程或者用戶讀取寫入的變數的集合。變數可由用戶，程序或者是系統進行設置，用於提升運行進程時的靈活性。比如文件系統中的路徑，用戶名和控制執行流程的標誌。

Windows下的環境

Windows下的環境變數可以使用DOS命令設置進行讀取和寫入：讀取：

set

寫入：

set =

在命令行單獨鍵入「set」會顯示所有當前可用的變數。注意本文中說描述的「當前可用」意思是非常相似的進程可用 —— 用戶運行命令解析器這裡也可以用編程的方式調用API函數代替set命令：

Kernel32!SetEnvironmentVariable

產生的結果都是一樣的。只有在當前進程及其子進程中改變這些值才會產生效果。只要條件允許，系統將替換所有%VARIABLE%的值。這個替換過程被稱作「擴展」（expansion）。例如我們在命令行下鍵入：

echo %username%

輸出的結果應該為擴展之後變數的值，與鍵入用戶名的結果是一樣的。

環境波動

正如前面所說的，環境變數已經通過一個進程設置。Windows稱這種類型的環境為「不穩定的環境」。當進程正在運行時它保持該變數，當結束進程不會留下任何痕迹。在Windows中還有另外一種類型的環境變數集合，其覆蓋整個系統範圍，在啟動過程依然持續。管理員用戶可以在系統屬性頁面下進行設置，通過使用setx命令影響所有用戶，或者直接通過設置註冊表值：

HKEY_CURRENT_USEREnvironment

註冊表值中的擴展

Windows註冊表支持REG_EXPAND_SZ類型的值，一個字元串類型的註冊表值，其命令讀取進程以擴展其內的所有變數，擴展進程在程序使用該值之前執行。這個過程保證了需要依賴註冊表中值的程序能正常運行，開發者不必再跟蹤環境變數值。

Windows程序下的擴展

通過註冊表進行搜索，很顯然其中使用了一個擴展過的路徑引用了許多程序，函數庫，對象。即反過來依賴於環境。最常見的變數為「SystemRoot」，在正常情況下，其指向Windows安裝路徑，一般為「C:Windows」。

簡單總結

我們擁有可用於Windows進程的環境變數，且能自動擴展以及可以由用戶設置。通過這些路徑可以引用部分Windows函數庫。以下為基於環境變數擴展的攻擊場景

場景1：」DLL注入」

假設：

如果通過一個擴展了的環境字元串載入DLL文件，攻擊者通過改變環境變數可獲得一個進程來載入該文件，但需在創建之前提供給這個進程。

換句話說，任何一個在攻擊者控制下的進程，攻擊者都可以對它進行環境設置。

可能性：

載入的DLL文件，不管是被複制，修改，完全替換，對於載入它的進程來說許可權都是一樣的。「注射」一個DLL到不同的進程中而不使用任何注射技術。

應用：

最簡單粗暴的方法便是使用命令行。大概流程如下：

在C:Wherever中創建C:Windows副本

設置環境變數set SystemRoot=C:Wherever

結束並重啟explorer.exe進程taskkill /F /IM explorer.exe C:Windowsexplorer.exe

資源管理器將會啟動並從攻擊者目錄載入相當多的DLL。攻擊者可以替換它們並改變執行流程。

場景2：遠程載入DLL

除了需要添加到等式這個因素以外，基本與上一個場景一樣。在Windows，API在請求一個文件或是目錄路徑時通常會接收一個指向遠程機器的UNC路徑。這個過程將會使用SMB協議嘗試訪問指定的路徑。

假設：

如果攻擊者將%SystemRoot%擴充到一個UNC網路路徑，Windows將使用SMB協議嘗試從遠程路徑載入該圖片

可能性：

從一個被攻擊者控制的伺服器上遠程載入DLL，同時也泄漏了受害者機器的IP地址。

之後將嘗試使用已登錄用戶的憑證對遠程伺服器進行身份驗證，為攻擊者提供更多的參考信息。

應用:

與場景1類似，但是需要使用遠程路徑。例如我們可以使用本地機器上共享的C盤：

set SystemRoot=\127.0.0.1c$Windows

場景3：啟動時載入DLL

就目前而言，此攻擊還算不上持久性攻擊。這也意味著重啟系統，或者是重啟進程，我們之前的努力都白費了。

假設：

攻擊者可以設置永久性(non-volatile)環境變數，將影響到系統控制流程而不論是否進行重啟。

可能性：

在操作系統啟動期間或在滿足特定條件時遠程載入DLL

應用：

與場景1類似，但是攻擊者可以使用setx命令來代替set命令：

setx SystemRoot C:Wherever

重啟系統，開始從攻擊者的目錄下將DLL載入到各種進程中。

場景4：提升許可權 #1

到目前為止，我們討論了攻擊者控制下可能對其他進程有影響的環境變數。 這些其他進程都屬於首先執行命令的用戶，並且以中等完整性級別運行。

如果用戶被允許以較高許可權執行進程，由微軟的用戶帳戶控制機制所定義。該進程將作為svchost.exe的子進程在用戶控制以外的預設環境下被創建。

問題來了，創建的子進程將得到當前用戶環境的一個副本。

繞過Windows UAC機制到底能不能算是特權提升，這就看讀者的理解了。雖然微軟不認為這是一個漏洞，但通常又會採取行動來解決這些問題。

基於道德要求，我們已經向微軟報告了此問題，並且在發文前收到「非漏洞」的響應。

假設：

基於默認配置，在用戶不知情的情況下，有特定的進程被授予高完整性（或特權提升）。一般來說，有一個由微軟選定的允許靜默運行的可執行文件集合。

這份清單是應該是在系統安全性和用戶友好體驗之間提出的一個合理折中方案。 攻擊者可以利用這種妥協，使操作系統在載入不受信任的DLL時運行這些特殊的可執行文件，從而繞過安全機制運行具有提升特權的DLL。

可能性：

在沒有用戶同意或對用戶通知的情況下提升許可權，這在默認配置下是可能發生的。管理員可以選擇通過重寫默認UAC設置來提高安全性，從而使Windows顯示請求此許可權的所有進程的提示。

然而，攻擊者仍然可以放置惡意的DLL文件，之後在用戶的同意下進行載入。這種套路可以使用許多合法進程來設置，Windows任務管理器（taskmgr.exe）就是一個例子。

應用：

按照場景3中所述設置環境。

以管理員身份運行自動提權進程。在本例中，我們使用lpksetup.exe：

ShellExecute(0,」runas」,」C:\Windows\System32\lpksetup.exe」,NULL,NULL,0);

情景5：提升許可權＃2

在前面的例子中，我們已經演示了使用ShellExecute來運行提權程序， Windows還提供COM對象供用戶載入。

COM組件的概念及其內部工作原理不在本文探討範圍之內，對於我們而言，其與使用不同機制載入的常規進程，可執行文件或函數庫沒有太大的不同。

假設：

如果有一個COM對象允許在用戶不知情的情況下以更高許可權載入 – 攻擊者可以使用該機制，來替代執行命令以及創建自己的進程。

可能性：

不產生新進程的前提下，進行特權提升。

應用：

本例中，選擇的對象是由Windows提供的允許更改防火牆設置的COM介面。

該對象的CLSID為{752438CB-E941-433F-BCB4-8B7D2329F0C8}

1.與場景4/1相同

2.

CoInitialize();

CoCreateInstance() with the given CLSID, returning a pointer to an IFwlCpl interface.

IFwlCpl->LaunchAdvancedUI()

這會載入mmc.exe，在Windows的管理控制台中的svchost.exe子進程得到特權提升，與此同時從攻擊者的C:Wherever載入一個DLL。

結論

Windows中的環境變數擴展允許攻擊者在攻擊之前收集系統的相關信息，並最終通過運行單個用戶級命令或者更改一個註冊表鍵值來對系統進行完全和持久的控制。

該向量還允許攻擊者以DLL形式的代碼載入到其他合法軟體的進程或操作系統本身，並將其行為偽裝為目標進程的操作，而不必使用代碼注入技術或使用內存處理。以管理員身份運行的第三方服務也可能受到此攻擊，允許普通用戶提升其在系統內的許可權。

概念驗證可以看看BreakingMalware提供的Python腳本 <點擊文末閱讀全文按鈕查看>

*參考來源：breakingmalware，FB小編鳶尾編譯，轉載請註明來自FreeBuf