Azure Functions 提權(quán)漏洞分析,windows azureAzure Functions 提權(quán)漏洞分析Azure Functions 是一種無服務(wù)器解決方案,可以使用戶減少代碼編寫、減少需要維護(hù)的基礎(chǔ)結(jié)構(gòu)并節(jié)省成本。無需擔(dān)心部署和維護(hù)服務(wù)器,云基礎(chǔ)結(jié)構(gòu)提供保持應(yīng)用程序運(yùn)行所需的所有最新資源。你只需專注于對(duì)......
Azure Functions 是一種無服務(wù)器解決方案,可以使用戶減少代碼編寫、減少需要維護(hù)的基礎(chǔ)結(jié)構(gòu)并節(jié)省成本。無需擔(dān)心部署和維護(hù)服務(wù)器,云基礎(chǔ)結(jié)構(gòu)提供保持應(yīng)用程序運(yùn)行所需的所有最新資源。你只需專注于對(duì)你最重要的代碼,Azure Functions 處理其余代碼。Azure Functions允許您提供一個(gè)帶有不同“鉤子”的簡單應(yīng)用程序,以觸發(fā)它運(yùn)行。這些可以是簡單的Web掛鉤或其他基于云的服務(wù)上的事件(例如,寫入OneDrive的文件)。Azure Functions的一個(gè)很好的好處是它們可以輕松地與其他供應(yīng)商的服務(wù)綁定,例如Twilio或GitHub。
過渡到云服務(wù)的一個(gè)最常見的好處是可以共同承擔(dān)保護(hù)資產(chǎn)的責(zé)任,但是云提供商也不能避免安全漏洞,比如漏洞或錯(cuò)誤配置。這是研究人員在過去幾個(gè)月在Azure Functions中發(fā)現(xiàn)的第二次權(quán)限升級(jí)(EoP)漏洞。
今年2月份,安全公司Intezer研究人員發(fā)現(xiàn)微軟的無服務(wù)器運(yùn)算服務(wù)Azure Functions,存在一個(gè)特權(quán)提升漏洞,且程序代碼可從Azure Functions DockerDocker逃脫(Escape)至Docker主機(jī)。但微軟認(rèn)為,這個(gè)漏洞不影響用戶安全。
Azure Functions讓用戶不需要配置和管理基礎(chǔ)設(shè)施,就能簡單地開始執(zhí)行程序代碼,可由HTTP請(qǐng)求觸發(fā),并且一次最多只能執(zhí)行數(shù)分鐘處理該事件,用戶的程序代碼會(huì)在Azure托管的Docker中執(zhí)行,無法逃脫受限的環(huán)境,但是這個(gè)Azure Functions的新漏洞,卻可讓程序代碼逃脫至Docker主機(jī)。
當(dāng)程序代碼逃脫到了Docker,取得根訪問權(quán)限,就足以破壞Docker主機(jī),并獲得更多的控制權(quán),除了逃脫可能受到監(jiān)控的Docker,還能轉(zhuǎn)移到安全性經(jīng)常被忽略的Docker主機(jī)。
這一次,Intezer研究人員是與微軟安全響應(yīng)中心(MSRC)合作并報(bào)告的新發(fā)現(xiàn)的漏洞。他們確定這種行為對(duì)Azure Functions用戶沒有安全影響。因?yàn)榘l(fā)現(xiàn)的Docker主機(jī)實(shí)際上是一個(gè)HyperV客戶端,而它又被另一個(gè)沙箱層保護(hù)起來了。
不過,類似這樣的情況仍然表明,漏洞有時(shí)是未知的,或者不受云用戶的控制。推薦一種雙管齊下的云安全方法:做一些基礎(chǔ)工作,例如修復(fù)已知的漏洞和加固系統(tǒng)以減少受到攻擊的可能性,并實(shí)現(xiàn)運(yùn)行時(shí)保護(hù),以便在漏洞利用和其他內(nèi)存攻擊發(fā)生時(shí)檢測/響應(yīng)它們。
Azure Functions Docker中的漏洞分析
Azure FunctionsDocker以privileged Docker標(biāo)志運(yùn)行,從而導(dǎo)致/dev目錄下的設(shè)備文件在Docker主機(jī)和Docker客戶端之間共享。這是標(biāo)準(zhǔn)的特權(quán)Docker行為,然而,這些設(shè)備文件對(duì)“其他”文件具有“rw”權(quán)限,如下所示,這是我們提出的漏洞會(huì)發(fā)生的根本原因。
Azure Functions Docker與低權(quán)限的應(yīng)用程序用戶一起運(yùn)行。Docker的主機(jī)名包含“沙箱”一詞,這意味著將用戶包含在低權(quán)限中是很重要的。容器使用–privileged標(biāo)志運(yùn)行,這意味著,如果用戶能夠升級(jí)為root用戶,則他們可以使用各種Docker轉(zhuǎn)義技術(shù)逃到Docker主機(jī)。
設(shè)備文件上的寬松權(quán)限不是標(biāo)準(zhǔn)行為,從我的本地特權(quán)Docker設(shè)置中可以看到,/dev中的設(shè)備文件默認(rèn)情況下不是很寬松:
Azure Functions環(huán)境包含52個(gè)帶有ext4文件系統(tǒng)的“pmem”分區(qū)。起初,我們懷疑這些分區(qū)屬于其他Azure Functions客戶端,但進(jìn)一步評(píng)估表明,這些分區(qū)只是同一個(gè)操作系統(tǒng)使用的普通文件系統(tǒng),包括pmem0,它是Docker主機(jī)的文件系統(tǒng)。
使用debugfs讀取Azure FunctionsDocker主機(jī)的磁盤
為了進(jìn)一步研究如何利用此可寫磁盤而不會(huì)潛在地影響其他Azure客戶,研究人員在本地容器中模擬了該漏洞,并與非特權(quán)用戶“bob”一起建立了本地環(huán)境:
利用設(shè)備文件o+rw
在我們的本地設(shè)置中,/dev/sda5是根文件系統(tǒng),它將成為我們的目標(biāo)文件系統(tǒng)。
使用debugfs實(shí)用程序,攻擊者可以遍歷文件系統(tǒng),如我們上面成功演示的那樣。debugfs還通過w標(biāo)志支持寫入模式,因此我們可以將更改提交到基礎(chǔ)磁盤。請(qǐng)務(wù)必注意,寫入已掛載的磁盤通常不是一個(gè)好主意,因?yàn)樗赡軙?huì)導(dǎo)致磁盤損壞。
通過直接文件系統(tǒng)編輯利用
為了演示攻擊者如何更改任意文件,我們希望獲得對(duì)/ etc/passwd的控制權(quán)。首先,我們嘗試通過直接編輯文件系統(tǒng)塊的內(nèi)容,使用zap_block命令來編輯文件的內(nèi)容。在內(nèi)部,Linux內(nèi)核將這些變化處理到*device file* /dev/sda5,并且它們被寫入緩存到與*regular file* /etc/passwd不同的位置。因此,需要刷新對(duì)磁盤的更改,但是這種刷新由debugfs實(shí)用程序處理。
使用debugfs用A(0x41)覆蓋/etc/passwd內(nèi)容
類似地,Linux內(nèi)核為最近加載到內(nèi)存中的頁面托管了一個(gè)讀取緩存。
不幸的是,由于與我們?cè)趯懭刖彺嬷姓f明的約束相同,對(duì)/dev/sda5的更改將不會(huì)傳播到/etc/passwd文件的視圖中,直到其緩存的頁面被丟棄。這意味著,我們只能覆蓋最近未從磁盤加載到內(nèi)存的文件,或者等待系統(tǒng)重新啟動(dòng)以應(yīng)用更改。
經(jīng)過進(jìn)一步研究,研究人員找到了一種方法來指示內(nèi)核放棄讀取緩存,以便他們的zap_block更改可以生效。首先,我們通過debugfs創(chuàng)建了一個(gè)到Docker的diff目錄的硬鏈接,以便更改可以輻射到Docker:
該硬鏈接仍然需要root權(quán)限才能進(jìn)行編輯,因此研究人員仍然必須使用zap_block來編輯其內(nèi)容。然后,研究人員使用posix_fadvise指示內(nèi)核從讀取緩存中丟棄頁面,這受一個(gè)名為pagecache management的項(xiàng)目的啟發(fā)。這導(dǎo)致內(nèi)核加載研究人員的更改,并最終能夠?qū)⑺鼈儌鞑サ紻ocker主機(jī)文件系統(tǒng):
刷新讀取緩存
Docker主機(jī)文件系統(tǒng)中的/etc/passwd,刷新后我們可以看到“AAA”字符串
總結(jié)
通過編輯屬于Docker主機(jī)的任意文件,攻擊者可以通過類似地對(duì)/etc/ld.so.preload進(jìn)行更改并通過Docker的diff目錄提供惡意共享對(duì)象來啟動(dòng)預(yù)加載劫持。該文件可以預(yù)加載到Docker主機(jī)系統(tǒng)中的每個(gè)進(jìn)程中(之前使用此技術(shù)記錄了HiddenWasp惡意軟件),因此攻擊者將能夠在Docker主機(jī)上執(zhí)行惡意代碼。
對(duì)漏洞利用的PoC進(jìn)行總結(jié)如下:
微軟目前對(duì)此發(fā)現(xiàn)的評(píng)估是,這種行為對(duì)Azure Functions用戶沒有安全影響。因?yàn)槲覀兲綔y的Docker主機(jī)實(shí)際上是一個(gè)HyperV客戶端,所以它被另一個(gè)沙箱層保護(hù)。
無論你如何努力保護(hù)自己的代碼,有時(shí)漏洞都是未知的或無法控制的。因此你應(yīng)該具備運(yùn)行時(shí)保護(hù)功能,以便在攻擊者在你的運(yùn)行環(huán)境中執(zhí)行未經(jīng)授權(quán)的代碼時(shí)檢測并終止攻擊。
參考及來源:https://www.intezer.com/blog/cloudsecurity/royalflushprivilegeescalationvulnerabilityinazurefunctions/
特別聲明:以上文章內(nèi)容僅代表作者本人觀點(diǎn),不代表ESG跨境電商觀點(diǎn)或立場。如有關(guān)于作品內(nèi)容、版權(quán)或其它問題請(qǐng)于作品發(fā)表后的30日內(nèi)與ESG跨境電商聯(lián)系。
二維碼加載中...
使用微信掃一掃登錄
使用賬號(hào)密碼登錄
平臺(tái)顧問
微信掃一掃
馬上聯(lián)系在線顧問
小程序
ESG跨境小程序
手機(jī)入駐更便捷
返回頂部