Azure Functions 提權漏洞分析,azure ad介紹-ESG跨境

Azure Functions 提權漏洞分析,azure ad介紹

Azure函數(shù)提升能力的脆弱性分析

Azure Functions是一個無服務器的解決方案，可以讓用戶減少代碼編寫，減少要維護的基礎結構，節(jié)省成本。不需要擔心服務器的部署和維護。Cloud 基礎架構提供了保持應用運行所需的所有最新資源。你只需要關注對你來說最重要的代碼，Azure Functions會處理剩下的。Azure Functions允許你提供一個帶有不同“鉤子”的簡單應用程序來觸發(fā)它運行。這些可以是簡單的Web掛鉤或其他基于云的服務上的事件(例如，寫入OneDrive的文件)。Azure函數(shù)的一個很好的優(yōu)勢是，它們可以很容易地綁定到其他供應商的服務，比如Twilio或GitHub。

過渡到云服務的一個最常見的好處是，他們可以分擔保護資產(chǎn)的責任，但云提供商無法避免安全漏洞，如漏洞或錯誤配置。這是Azure Functions的研究人員在過去幾個月里發(fā)現(xiàn)的第二個權限提升(EoP)漏洞。

今年2月，安全公司Intezer的研究人員發(fā)現(xiàn)，微軟的無服務器計算服務Azure Functions存在一個權限提升漏洞，程序代碼可以從Azure Functions DockerDocker逃逸到Docker host。但微軟認為這個漏洞并不影響用戶安全。

Azure Functions允許用戶簡單地開始執(zhí)行程序代碼，而無需配置和管理基礎設施。它可以由HTTP請求觸發(fā)，每次只能執(zhí)行幾分鐘來處理這個事件。用戶的程序代碼會在Azure托管的Docker中執(zhí)行，逃不出受限環(huán)境。然而，Azure函數(shù)的這個新漏洞允許程序代碼逃到Docker主機。

當程序代碼逃到Docker時，獲得root權限就足以摧毀Docker主機，獲得更多控制權。除了逃離可能被監(jiān)控的Docker，還可以轉移到安全性往往被忽略的Docker主機。

這一次，英特爾研究人員正與微軟安全響應中心(MSRC)合作，報告新發(fā)現(xiàn)的漏洞。他們確信這種行為對Azure Functions用戶沒有安全影響。因為被發(fā)現(xiàn)的Docker主機實際上是一個HyperV客戶端，而且是由另一個沙盒層保護的。

然而，像這樣的情況仍然表明，漏洞有時是未知的或不受云用戶的控制。推薦一種雙管齊下的云安全方法:做一些基礎的工作，比如修復已知漏洞和加固系統(tǒng)以降低被攻擊的可能性，以及實施運行時保護以在漏洞和其他內存攻擊發(fā)生時檢測/響應它們。

Azure Functions Docker中的漏洞分析

Azure FunctionsDocker使用privileged Docker標志運行，這使得/dev目錄中的設備文件在Docker主機和Docker客戶端之間共享。這是標準的特權碼頭工人行為。但是，這些設備文件對“其他”文件具有“rw”權限，如下所示。這就是我們提出的漏洞的根本原因。

Azure Functions Docker與低權限的應用程序用戶一起運行。Docker的主機名包含單詞“sandbox”，這意味著將用戶包含在低特權中是很重要的。使用container – privileged標志運行，這意味著如果用戶可以升級到root，他們可以使用各種Docker轉義技術來轉義到Docker主機。

設備上的松散權限不是標準行為。從我的本地privilege Docker設置中可以看到，默認情況下/dev中的設備文件不是很松散:

Azure Functions environment包含52個帶有ext4文件系統(tǒng)的“pmem”分區(qū)。起初，我們懷疑這些分區(qū)屬于其他Azure Functions客戶端，但進一步評估發(fā)現(xiàn)，這些分區(qū)只是同一個操作系統(tǒng)使用的普通文件系統(tǒng)，包括pmem0，這是Docker主機的文件系統(tǒng)。

使用debugfs讀取Azure FunctionsDocker主機的磁盤

為了進一步研究如何在不潛在影響其他Azure客戶的情況下利用這個可寫磁盤，研究人員在本地容器中模擬了該漏洞，并與無特權用戶“bob”建立了一個本地環(huán)境:

使用設備文件o+rw

在我們的本地設置中，/dev/sda5是根文件系統(tǒng)，它將成為我們的目標文件系統(tǒng)。

使用debugfs實用程序，攻擊者可以遍歷文件系統(tǒng)，正如我們在上面成功演示的那樣。Debugfs還通過w標志支持寫模式，因此我們可以將更改提交到基礎磁盤。重要的是要注意，寫入一個掛載的磁盤通常不是一個好主意，因為它可能會導致磁盤損壞。

通過直接文件系統(tǒng)編輯和利用

為了演示攻擊者如何更改任意文件，我們希望獲得/etc/passwd的控制權。首先，我們嘗試通過直接編輯文件系統(tǒng)塊的內容并使用zapblock命令來編輯文件的內容。在內部，Linux內核處理對*device file* /dev/sda5的這些更改，它們被寫入并緩存在與*regular file* /etc/passwd不同的位置。因此，有必要刷新對磁盤的更改，但這種刷新是由debugfs實用程序處理的。

使用debugfs用(0x41)覆蓋/etc/passwd的內容

類似地，Linux內核為最近加載到內存中的頁面提供一個讀緩存。

不幸的是，由于我們在寫緩存中解釋的同樣的限制，對/dev/sda5的更改不會傳播到/etc/passwd文件的視圖，直到其緩存的頁面被丟棄。這意味著我們只能覆蓋最近沒有從磁盤加載到內存的文件，或者等待系統(tǒng)重新啟動以應用更改。

經(jīng)過進一步的研究，研究人員找到了一種方法，可以指示內核放棄讀取緩存，以便他們的zapblock更改可以生效。首先，我們通過debugfs創(chuàng)建了一個到Docker的diff目錄的硬鏈接，這樣更改就可以傳播到Docker:

硬鏈接仍然需要root權限才能編輯，所以研究人員仍然要使用zapblock來編輯其內容。然后，研究人員使用posixfadvise來指示內核從讀緩存中丟棄頁面，這是受一個名為pagecache management的項目的啟發(fā)。這會導致內核加載研究人員的更改，并最終能夠將它們傳播到Docker主機文件系統(tǒng):

刷新緩存

Docker主機文件系統(tǒng)中的/etc/passwd。刷新后，我們可以看到“AAA”字符串。

摘要

通過編輯屬于Docker主機的任何文件，攻擊者可以通過類似地更改/etc/ld.so.preload并通過Docker的diff目錄提供惡意共享對象來啟動預加載劫持。該文件可以預加載到Docker主機系統(tǒng)中的每個進程中(HiddenWasp惡意軟件以前就是使用該技術記錄的)，因此攻擊者將能夠在Docker主機上執(zhí)行惡意代碼。

漏洞利用的概念驗證總結如下:

微軟目前對這一發(fā)現(xiàn)的評估是，這一行為對Azure Functions用戶沒有安全影響。因為我們探查的Docker主機實際上是一個HyperV客戶端，它受到另一個沙盒層的保護。

無論您如何努力保護您的代碼，有時漏洞是未知的或不可控的。因此，當攻擊者在您的運行時環(huán)境中執(zhí)行未經(jīng)授權的代碼時，您應該具有運行時保護功能來檢測和終止攻擊。

及參考資料來源:https://www . intezer . com/blog/cloudsecurity/royalflushprivilegeescalationvulnerabilityinazurefunctions/

特別聲明：以上文章內容僅代表作者本人觀點，不代表ESG跨境電商觀點或立場。如有關于作品內容、版權或其它問題請于作品發(fā)表后的30日內與ESG跨境電商聯(lián)系。