Azure Functions 提權漏洞分析,windows azure-ESG跨境

Azure Functions 提權漏洞分析,windows azure

Azure Functions 提權漏洞分析

Azure Functions 是一種無服務器解決方案，可以使用戶減少代碼編寫、減少需要維護的基礎結構并節(jié)省成本。無需擔心部署和維護服務器，云基礎結構提供保持應用程序運行所需的所有最新資源。你只需專注于對你最重要的代碼，Azure Functions 處理其余代碼。Azure Functions允許您提供一個帶有不同“鉤子”的簡單應用程序，以觸發(fā)它運行。這些可以是簡單的Web掛鉤或其他基于云的服務上的事件（例如，寫入OneDrive的文件）。Azure Functions的一個很好的好處是它們可以輕松地與其他供應商的服務綁定，例如Twilio或GitHub。

過渡到云服務的一個最常見的好處是可以共同承擔保護資產的責任，但是云提供商也不能避免安全漏洞，比如漏洞或錯誤配置。這是研究人員在過去幾個月在Azure Functions中發(fā)現的第二次權限升級(EoP)漏洞。

今年2月份，安全公司Intezer研究人員發(fā)現微軟的無服務器運算服務Azure Functions，存在一個特權提升漏洞，且程序代碼可從Azure Functions DockerDocker逃脫（Escape）至Docker主機。但微軟認為，這個漏洞不影響用戶安全。

Azure Functions讓用戶不需要配置和管理基礎設施，就能簡單地開始執(zhí)行程序代碼，可由HTTP請求觸發(fā)，并且一次最多只能執(zhí)行數分鐘處理該事件，用戶的程序代碼會在Azure托管的Docker中執(zhí)行，無法逃脫受限的環(huán)境，但是這個Azure Functions的新漏洞，卻可讓程序代碼逃脫至Docker主機。

當程序代碼逃脫到了Docker，取得根訪問權限，就足以破壞Docker主機，并獲得更多的控制權，除了逃脫可能受到監(jiān)控的Docker，還能轉移到安全性經常被忽略的Docker主機。

這一次，Intezer研究人員是與微軟安全響應中心(MSRC)合作并報告的新發(fā)現的漏洞。他們確定這種行為對Azure Functions用戶沒有安全影響。因為發(fā)現的Docker主機實際上是一個HyperV客戶端，而它又被另一個沙箱層保護起來了。

不過，類似這樣的情況仍然表明，漏洞有時是未知的，或者不受云用戶的控制。推薦一種雙管齊下的云安全方法：做一些基礎工作，例如修復已知的漏洞和加固系統以減少受到攻擊的可能性，并實現運行時保護，以便在漏洞利用和其他內存攻擊發(fā)生時檢測/響應它們。

Azure Functions Docker中的漏洞分析

Azure FunctionsDocker以privileged Docker標志運行，從而導致/dev目錄下的設備文件在Docker主機和Docker客戶端之間共享。這是標準的特權Docker行為，然而，這些設備文件對“其他”文件具有“rw”權限，如下所示，這是我們提出的漏洞會發(fā)生的根本原因。

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

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

Azure Functions環(huán)境包含52個帶有ext4文件系統的“pmem”分區(qū)。起初，我們懷疑這些分區(qū)屬于其他Azure Functions客戶端，但進一步評估表明，這些分區(qū)只是同一個操作系統使用的普通文件系統，包括pmem0，它是Docker主機的文件系統。

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

為了進一步研究如何利用此可寫磁盤而不會潛在地影響其他Azure客戶，研究人員在本地容器中模擬了該漏洞，并與非特權用戶“bob”一起建立了本地環(huán)境：

利用設備文件o+rw

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

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

通過直接文件系統編輯利用

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

使用debugfs用A（0x41）覆蓋/etc/passwd內容

類似地，Linux內核為最近加載到內存中的頁面托管了一個讀取緩存。

不幸的是，由于與我們在寫入緩存中說明的約束相同，對/dev/sda5的更改將不會傳播到/etc/passwd文件的視圖中，直到其緩存的頁面被丟棄。這意味著，我們只能覆蓋最近未從磁盤加載到內存的文件，或者等待系統重新啟動以應用更改。

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

該硬鏈接仍然需要root權限才能進行編輯，因此研究人員仍然必須使用zap_block來編輯其內容。然后，研究人員使用posix_fadvise指示內核從讀取緩存中丟棄頁面，這受一個名為pagecache management的項目的啟發(fā)。這導致內核加載研究人員的更改，并最終能夠將它們傳播到Docker主機文件系統：

刷新讀取緩存

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

總結

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

對漏洞利用的PoC進行總結如下:

微軟目前對此發(fā)現的評估是，這種行為對Azure Functions用戶沒有安全影響。因為我們探測的Docker主機實際上是一個HyperV客戶端，所以它被另一個沙箱層保護。

無論你如何努力保護自己的代碼，有時漏洞都是未知的或無法控制的。因此你應該具備運行時保護功能，以便在攻擊者在你的運行環(huán)境中執(zhí)行未經授權的代碼時檢測并終止攻擊。

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

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