利用PowerShell代碼注入漏洞繞過受限語言模式
一、 前言
受限語言模式是一種非常有效的機(jī)制，能阻止在PowerShell中執(zhí)行任意未簽名的代碼。當(dāng)Device Guard或者AppLocker處于強(qiáng)制模式時(shí)，它是最實(shí)際有效的強(qiáng)制安全措施，因?yàn)槲幢徊呗栽试S的任何腳本或者模塊都位于受限語言模式下，這嚴(yán)重限制了攻擊者執(zhí)行未簽名的代碼。通過限制語言模式限制了Add-Type的調(diào)用。限制Add-Type明顯是考慮到了它能編譯并加載任意的C#代碼到你的運(yùn)行空間中去。但策略允許的PowerShell代碼運(yùn)行在“Full Language”模式下，允許執(zhí)行Add-Type。這樣，微軟簽名的PowerShell的代碼就能調(diào)用Add-Type。不相信嗎?運(yùn)行下面的命令你就會(huì)發(fā)現(xiàn)我是正確的。
二、漏洞利用
現(xiàn)在，想像一下如果下面的PowerShell模塊代碼(姑且稱為“VulnModule”)有微軟的簽名：
- ls C:\* -Recurse -Include '*.ps1', '*.psm1' |
- Select-String -Pattern 'Add-Type' |
- Sort Path -Unique |
- % { Get-AuthenticodeSignature -FilePath $_.Path } |
- ? { $_.SignerCertificate.Subject -match 'Microsoft' }
那么有什么可以影響來自受限語言模式的Add-Type的輸入呢?
好了，讓我們一起思考下吧：
1. Add-Type作為類型定義傳遞給一個(gè)全局變量。因?yàn)樗侨值模梢员蝗魏稳嗽L問，包括我們和攻擊者。
2. 問題是，簽名的代碼先于調(diào)用Add-Type就定義了全局變量，因此如果我們使用自定義的惡意的C#代碼，這將會(huì)被合法的代碼覆蓋。
3. 你知道能用Set-Variable cmdlet來設(shè)置變量只讀嗎?你知道我現(xiàn)在在想什么了吧?
三、武器化利用
好了，為了從受限語言模式注入代碼到Add-Type中，攻擊者需要定義他們的惡意代碼為一個(gè)只讀變量，拒絕簽名代碼設(shè)置全局變量“Source”。下面是PoC：
- $Global:Source = @'
- public class Test {
- public static string PrintString(string inputString) {
- return inputString;
- }
- }'@
- Add-Type -TypeDefinition $Global:Source
簡要說明下Add-Type注入缺陷。受限語言模式的一個(gè)限制是你不能調(diào)用非白名單類的.NET方法，但有兩個(gè)例外：屬性(getter方法)和ToString方法。在上面的PoC中，我選擇了實(shí)現(xiàn)一個(gè)靜態(tài)的ToString方法，因?yàn)門oString允許傳遞參數(shù)(getter不行)。我的類也是靜態(tài)的，因?yàn)?NET類的白名單只在New-Object實(shí)例化對象時(shí)適用。
那么上面的漏洞代碼是否聽起來不切實(shí)際呢?你可以這么認(rèn)為，但是Microsoft.PowerShell.ODataUtils 模塊中的Microsoft.PowerShell.ODataUtils也有這個(gè)漏洞。微軟在 CVE-2017-0215, CVE-2017-0216, CVE-2017-0219中修復(fù)了它。說實(shí)話，我不太記得了。Matt Nelson 和我都報(bào)告了這些注入bug。
四、阻止措施
最簡單的阻止這種注入攻擊的方式是，直接在Add-Type使用單引號的here-string給TypeDefinition。單引號的字符串不會(huì)擴(kuò)展任何內(nèi)嵌的變量或者表達(dá)式。當(dāng)然，這個(gè)場景假設(shè)了你是編譯靜態(tài)代碼。如果你動(dòng)態(tài)生成代碼給Add-Type，要特別注意攻擊者可能影響你的輸入。為了理解影響PowerShell中代碼執(zhí)行的方法，可以參見我在PSConf.EU上的演講“Defensive Coding Strategies for a High-Security Environment”。
五、緩解措施
盡管微軟在推動(dòng)解決這個(gè)漏洞，我們有什么可以做的呢?
有個(gè)關(guān)于UMCI繞過二進(jìn)制的有效的黑名單規(guī)則是文件名規(guī)則，其能基于PE文件中版本信息資源中的原始文件名來阻止程序執(zhí)行。PowerShell很明顯不是個(gè)PE文件，它是文本文件，因此文件名規(guī)則不適用。但是，你可以通過使用哈希規(guī)則強(qiáng)制阻止有漏洞的腳本。Okay…要是相同腳本有不止一個(gè)漏洞呢?目前為止你只阻止一個(gè)哈希。你開始注意這個(gè)問題了嗎?為了有效的阻止之前所有有漏洞的版本的腳本，你必須知道所有有漏洞的版本的哈希。微軟意識(shí)到了問題并盡最大努力來掃描所有之前發(fā)布的有漏洞腳本，且收集哈希將他們整合到了黑名單中。通過他們的哈希阻止所有版本的有漏洞的腳本有一定挑戰(zhàn)性，但能一定程度上阻止攻擊。這就是為什么一直迫切需要只允許PowerShell 5的執(zhí)行并要開啟scriptblock日志記錄。Lee Holmes 有篇關(guān)于如何有效的阻止老版本的PowerShell的博文。
另一種方式是系統(tǒng)中大部分腳本和二進(jìn)制都是catalog和Authenticode簽名的。Catalog簽名不是意味著腳本有內(nèi)嵌的Authenticode簽名，而是它的哈希存儲(chǔ)在微軟簽名的catalog文件中。因此當(dāng)微軟更新時(shí)，老版本的哈希將會(huì)過期，將不再是被簽名的了?，F(xiàn)在，一個(gè)攻擊者也能將老的簽名的catalog文件插入到catalog存儲(chǔ)中。你不得不提權(quán)執(zhí)行操作，關(guān)于這個(gè)，有很多方法可以繞過Device Guard UMCI。作為一個(gè)搜索有漏洞腳本的研究員，首先要尋找具有內(nèi)嵌Authenticode簽名的有漏洞腳本(有字符串“SIG # Begin signature block”的提示)。Matt Nelson說這種bypass腳本存在。
六、報(bào)告
如果你找到了一種繞過，請將它上報(bào)給secure@microsoft.com ，你將得到一個(gè)CVE。PowerShell團(tuán)隊(duì)積極解決注入缺陷，但是他們也主動(dòng)解決用于影響代碼執(zhí)行的一些方式。
七、總結(jié)
盡管受限語言模式能有效的阻止未簽名代碼的執(zhí)行，PowerShell和它的簽名過的模塊或腳本還是有很多攻擊面。我鼓勵(lì)每個(gè)人都來尋找更多的注入缺陷，上報(bào)他們，通過官方的MSRC獲得榮譽(yù)，并使得PowerShell生態(tài)變得更加安全。同時(shí)希望，PowerShell的代碼作者要自我檢視。
現(xiàn)在我解釋了所有的內(nèi)容，但是因?yàn)樵O(shè)計(jì)缺陷允許利用競爭條件，所以調(diào)用Add-Type還是有注入的漏洞。我希望能繼續(xù)闡述這些問題，且希望微軟將考慮解決這個(gè)基礎(chǔ)問題。
