這篇文章主要為大家展示了“如何利用Winrm.vbs繞過(guò)白名單限制執(zhí)行任意代碼”，內(nèi)容簡(jiǎn)而易懂，條理清晰，希望能夠幫助大家解決疑惑，下面讓小編帶領(lǐng)大家一起研究并學(xué)習(xí)一下“如何利用Winrm.vbs繞過(guò)白名單限制執(zhí)行任意代碼”這篇文章吧。

成都創(chuàng)新互聯(lián)自2013年起，先為陸豐等服務(wù)建站，陸豐等地企業(yè)，進(jìn)行企業(yè)商務(wù)咨詢(xún)服務(wù)。為陸豐企業(yè)網(wǎng)站制作PC+手機(jī)+微官網(wǎng)三網(wǎng)同步一站式服務(wù)解決您的所有建站問(wèn)題。

僅供參考學(xué)習(xí)。

繞過(guò)方法描述    

winrm.vbs（一個(gè)位于system32目錄下的具有Windows簽名的腳本文件）可以被用來(lái)調(diào)用用戶(hù)定義的XSL文件，從而導(dǎo)致任意的、沒(méi)有簽名的代碼執(zhí)行。當(dāng)用戶(hù)向winrm.vbs提供'-format:pretty'或者'-format:text'參數(shù)時(shí)，winrm.vbs將從cscript.exe所在目錄讀取WsmPty.xsl或Wsmtxt.xsl文件。這意味著若將cscript.exe拷貝到攻擊者可以控制的目錄下，并將惡意的XSL文件也置于相同路徑中，攻擊者將可以繞過(guò)簽名保護(hù)而執(zhí)行任意代碼。這個(gè)攻擊手段和Casey    Smith的wmic.exe技術(shù)很相像。

繞過(guò)方法的POC

整個(gè)工作流程如下所示：

1.在攻擊者可以控制的目錄中放置惡意的WsmPty.xsl或者WsmTxt.xsl文件。

2.拷貝cscript.exe或者wscript.exe到相同的目錄中。

3.根據(jù)第一步中的惡意XSL文件(WsmPty.xsl或者WsmTxt.xsl)，執(zhí)行winrm.vbs并提供不同的參數(shù)('-format:pretty'或者'-format:text')。下面是一個(gè)惡意XSL文件的例子。該文件可以被放置到上述第一步中的路徑中（對(duì)于這個(gè)例子來(lái)說(shuō)，是C:\BypassDir\WsmPty.xsl）:

一個(gè)更加有攻擊意義的XSL文件可以執(zhí)行通過(guò)DotNetToJScript生成的Payload，導(dǎo)致攻擊者可以利用該手法執(zhí)行任意不具有簽名的代碼。在放置了惡意XSL文件后，以下的批處理文件可以被用來(lái)啟動(dòng)paylaod：

mkdir %SystemDrive%\BypassDir
copy %windir%\System32\cscript.exe %SystemDrive%\BypassDir
%SystemDrive%\BypassDir\cscript //nologo %windir%\System32\winrm.vbs get wmicimv2/Win32_Process?Handle=4 -format:pretty

我是如何發(fā)現(xiàn)該問(wèn)題的

我發(fā)現(xiàn)這個(gè)問(wèn)題完全是出于偶然。我曾和Casey一起研究利用wmic.exe的XSL繞過(guò)方法，不久之后，我又開(kāi)始檢查系統(tǒng)自帶的各種VBS和JScript文件，尋找更多的繞過(guò)方法。我之所以開(kāi)始檢查這些自帶的腳本是因?yàn)镸att Nelson的.vbs注入技術(shù)給了我啟發(fā)。當(dāng)我在查閱winrm.vbs源碼的時(shí)候，文件中的'WsmPty'以及'WsmTxt'馬上引起了我的注意，因?yàn)镃asey曾經(jīng)在他的博客中說(shuō)過(guò)，對(duì)于使用了XSL的文件，它們可以通過(guò)在XSL文件中嵌入WSH腳本內(nèi)容而擁有執(zhí)行任意代碼的潛力。毫無(wú)疑問(wèn)，winrm.vbs也不例外。我非常注重于尋找這些具備Windows簽名的，并可以導(dǎo)致任意代碼執(zhí)行的腳本或者二進(jìn)制文件。這是因?yàn)樗鼈儾粌H可以繞過(guò)應(yīng)用白名單的防御，同時(shí)它們也不容易被安全軟件檢查出來(lái)（至少當(dāng)它們還沒(méi)有被公布的時(shí)候）。我會(huì)一直都在尋找它們的路上！

檢測(cè)策略

若要對(duì)上述的方法做出有效的檢測(cè)和防護(hù)，尋找這類(lèi)攻擊手段所需要的最小組件集合是很重要的。

攻擊者控制的WsmPty.xsl或者WsmTxt.xsl文件一定會(huì)被創(chuàng)建

winrm.vbs硬編碼了這兩個(gè)文件的名字，并明確將這兩個(gè)文件同'pretty'或者'text'參數(shù)綁定到了一起。目前來(lái)看，這兩個(gè)文件只可能當(dāng)前工作目錄中被獲?。ǘ鄶?shù)情況下就是cscript.exe所在的目錄），而不太可能被重定向到其他位置。從防守的角度上來(lái)說(shuō)，若一個(gè)WsmPty.xsl或WsmTxt.xsl文件與它們?cè)赟ystem32目錄下的版本具有不同哈希值，則我們可以認(rèn)為這個(gè)XSL文件是可疑的。幸運(yùn)的是，合法的XSL文件很少會(huì)有變化。

一個(gè)具有有效簽名的winrm.vbs會(huì)被執(zhí)行。若要利用本文的繞過(guò)方法，攻擊者不能修改winrm.vbs的內(nèi)容

通過(guò)在命令行中尋找'winrm.vbs'字符串這種防御手段是不足的，因?yàn)楣粽呖梢匀我庑薷膚inrm.vbs的文件名。

調(diào)用winrm.vbs時(shí)的'format'參數(shù)必須指定為'pretty'或'text'，這樣winrm.vbs才會(huì)調(diào)用對(duì)應(yīng)xsl文件

攻擊者不僅僅可以采用'format'參數(shù)，下面的變種形式也是可以的(大小寫(xiě)敏感)：

-format:pretty

-format:"pretty"

/format:pretty

/format:"pretty"

-format:text

-format:"text"

/format:text

/format:"text"

若僅僅查找'format'字符串可以檢測(cè)到上述的所有變體，這種方法帶來(lái)的誤報(bào)會(huì)很多。'format:'后面所接內(nèi)容的合法與否將取決于具體的公司環(huán)境。不過(guò)，對(duì)xsl文件的合法引用更多的來(lái)源于system32目錄下的csript.exe和winrm.vbs文件，而不會(huì)來(lái)源于其他位置。

winrm.vbs應(yīng)該是被cscript.exe執(zhí)行的。winrm.vbs內(nèi)部的邏輯驗(yàn)證了這一點(diǎn)。

winrm.vbs通過(guò)驗(yàn)證WScript.FullName是否包含了字符串'cscript.exe'這一點(diǎn)來(lái)驗(yàn)證其自身是被cscript.exe執(zhí)行的。這個(gè)驗(yàn)證本身是不夠完善的，因?yàn)樗鼉H僅檢查可執(zhí)行文件的路徑中是否包含'cscript.exe'字符串。這將導(dǎo)致攻擊者可以從一個(gè)被重命名過(guò)的cscript.exe啟動(dòng)winrm.vbs，甚至可以用其他的腳本解釋器(例如wscript.exe)來(lái)啟動(dòng)winrm.vbs。下面的批處理程序的例子解釋了如何繞過(guò)winrm.vbs腳本中對(duì)'cscript.exe'的驗(yàn)證：

mkdir %SystemDrive%\BypassDir\cscript.exe
copy %windir%\System32\wscript.exe %SystemDrive%\BypassDir\cscript.exe\winword.exe
%SystemDrive%\BypassDir\cscript.exe\winword.exe //nologo %windir%\System32\winrm.vbs get wmicimv2/Win32_Process?Handle=4 -format:pretty

檢測(cè)方法的健壯性

POC例子中的get wmicimv2/Win32_Process?Handle=4僅僅是為了說(shuō)明實(shí)際的命令行參數(shù)將返回一些有意義的東西。這并不意味著這個(gè)方法需要WinRM服務(wù)被啟用。有很多的選項(xiàng)都可以支持'format'參數(shù)。

足夠健壯的檢測(cè)手段不應(yīng)該從命令行中檢測(cè)'cscript.exe'或者'wscript.exe'作為判斷依據(jù)。盡管如果攻擊者沒(méi)有刻意規(guī)避檢測(cè)，這種檢測(cè)方法可以檢測(cè)到上文所述的攻擊手段，但是攻擊者若是將script.exe拷貝并重命名，檢測(cè)手段就對(duì)此無(wú)能為力了。一個(gè)更加健壯的檢測(cè)方法應(yīng)該考慮檢測(cè)二進(jìn)制文件的簽名以及它的'原始文件名'。'原始文件名'這一屬性被嵌入到了二進(jìn)制文件之中，并被簽名所保護(hù)，而如果攻擊者想要修改這一屬性，二進(jìn)制文件的簽名將會(huì)失效。

緩解和阻止措施

本文提到的繞過(guò)方法可以通過(guò)啟用Windows Defender Application Control(WDAC)的User Mode Code Integrity(UMCI)選項(xiàng)來(lái)阻止。由于目前并沒(méi)有其他有效的方法阻止這些具有Windows簽名的腳本文件運(yùn)行，具有威脅的腳本文件將通過(guò)其哈希值被禁用。不過(guò)獲取各個(gè)版本的腳本文件的哈希值會(huì)是很困難的，考慮到Windows如此龐大的版本數(shù)量。這篇博客詳細(xì)說(shuō)明了為什么通過(guò)哈希值禁用文件是不高效的。至于緩解措施，微軟可以修改這個(gè)腳本文件的內(nèi)容并重新進(jìn)行簽名。如果這樣做的話(huà)，這將導(dǎo)致之前版本的腳本文件的簽名失效。所以如果我們通過(guò)WDAC啟用了腳本執(zhí)行的簽名保護(hù)，這些腳本的執(zhí)行將失敗。然而，這樣的場(chǎng)景只能阻止一個(gè)非管理員賬戶(hù)進(jìn)行攻擊，因?yàn)楣粽呖梢酝ㄟ^(guò)管理員權(quán)限安裝微軟之前版本的catalog簽名，從而恢復(fù)腳本文件的簽名信息。上述的阻止和緩解措施都依賴(lài)于WDAC的開(kāi)啟?？紤]到目前有大量企業(yè)并沒(méi)有開(kāi)啟WDAC，就算winrm.vbs被微軟修復(fù)，也沒(méi)有什么措施可以阻止攻擊將舊版本的winrm.vbs文件放在系統(tǒng)中并加以利用。因此，就算微軟修復(fù)了winrm.vbs的問(wèn)題，目前也沒(méi)有真正足夠健壯的方法可以防護(hù)此問(wèn)題。

WSH/XSL腳本檢測(cè)

這不是第一次WSH/XSL被攻擊者濫用，也不會(huì)是最后一次。攻擊者應(yīng)該需要了解它們的payload到底是從磁盤(pán)中的文件被執(zhí)行或者是完全在內(nèi)存中被執(zhí)行。通過(guò)ScriptLogging技術(shù),Powershell完全具有這種能力。然而對(duì)于WSH來(lái)說(shuō)，它們卻不具備類(lèi)似的能力。然而，只要你對(duì)于ETW熟悉，利用Antimalware Scan Interface(AMSI)捕獲WSH的內(nèi)容是完全可能的。AMSI通過(guò)Microsoft-Antimalware-Scan-Interface    ETW Provider被暴露出來(lái)。如果你想嘗試獲取ASMI事件，KrabsETW是你可以采用的最好的庫(kù)之一。不過(guò)，若僅僅出于實(shí)驗(yàn)?zāi)康模憧梢酝ㄟ^(guò)logman.exe獲取ETL記錄。下面的例子可以開(kāi)始和暫停ETL的記錄，并將ASMI相關(guān)的事件記錄到ASMITrace.etl:

logman start AMSITrace -p Microsoft-Antimalware-Scan-Interface Event1 -o AMSITrace.etl -ets

logman stop AMSITrace -ets

盡管本文章將不會(huì)討論ETW技術(shù)，你可能還是想知道我是怎么知道'Microsoft-Antimalware-Scan-Interface'這一EWT Provider，并且上文中的'Event1'又是從何而來(lái)。我是通過(guò)logman query providers這一命令查找已注冊(cè)providers的名稱(chēng)的。'Event1'這一關(guān)鍵字對(duì)應(yīng)著捕獲ASMI信息。為了找到這個(gè)關(guān)鍵字，我通過(guò)perfview.exe將ETW清單文件導(dǎo)出到XML。這個(gè)清單文件可以讓你很清楚地了解到通過(guò)這一provider到底可以查詢(xún)到哪些事件。

在捕獲到ETL記錄后，你就可以自己任意選擇工具來(lái)進(jìn)行分析。Get-WinEvent這一powershell命令就可以很好的解析ETL記錄。我寫(xiě)了一個(gè)簡(jiǎn)單的腳本來(lái)解析ASMI事件。需要注意的是，WSH無(wú)法提供'contentname'這一屬性，導(dǎo)致我們不得不手動(dòng)解析這一事件信息。這個(gè)腳本也會(huì)捕獲到powershell的內(nèi)容。

# Script author: Matt Graeber (@mattifestation)
# logman start AMSITrace -p Microsoft-Antimalware-Scan-Interface Event1 -o AMSITrace.etl -ets
# Do your malicious things here that would be logged by AMSI
# logman stop AMSITrace -ets

$OSArchProperty = Get-CimInstance -ClassName Win32_OperatingSystem -Property OSArchitecture
$OSArch = $OSArchProperty.OSArchitecture

$OSPointerSize = 32
if ($OSArch -eq '64-bit') { $OSPointerSize = 64 }

$AMSIScanEvents = Get-WinEvent -Path .\AMSITrace.etl -Oldest -FilterXPath '*[System[EventID=1101]]' | ForEach-Object {
    if (-not $_.Properties) {
        # The AMSI provider is not supplying the contentname property when WSH content is logged resulting
        # in Get-WinEvent or Event Viewer being unable to parse the data based on the schema.
        # If this bug were not present, retrieving WSH content would be trivial.

        $PayloadString = ([Xml] $_.ToXml()).Event.ProcessingErrorData.EventPayload
        [Byte[]] $PayloadBytes = ($PayloadString -split '([0-9A-F]{2})' | Where-Object {$_} | ForEach-Object {[Byte] "0x$_"})

        $MemoryStream = New-Object -TypeName IO.MemoryStream -ArgumentList @(,$PayloadBytes)
        $BinaryReader = New-Object -TypeName IO.BinaryReader -ArgumentList $MemoryStream, ([Text.Encoding]::Unicode)

        switch ($OSPointerSize) {
            32 { $Session = $BinaryReader.ReadUInt32() }
            64 { $Session = $BinaryReader.ReadUInt64() }
        }

        $ScanStatus = $BinaryReader.ReadByte()
        $ScanResult = $BinaryReader.ReadInt32()

        $StringBuilder = New-Object -TypeName Text.StringBuilder
        do { $CharVal = $BinaryReader.ReadInt16(); $null = $StringBuilder.Append([Char] $CharVal) } while ($CharVal -ne 0)
        $AppName = $StringBuilder.ToString()
        $null = $StringBuilder.Clear()

        $ContentSize = $BinaryReader.ReadInt32()
        $OriginalSize = $BinaryReader.ReadInt32()
        $ContentRaw = $BinaryReader.ReadBytes($ContentSize)
        $Content = [Text.Encoding]::Unicode.GetString($ContentRaw)
        $Hash = [BitConverter]::ToString($BinaryReader.ReadBytes(0x20)).Replace('-', '')
        [Bool] $ContentFiltered = $BinaryReader.ReadInt32()

        $BinaryReader.Close()

        [PSCustomObject] @{
            Session = $Session
            ScanStatus = $ScanStatus
            ScanResult = $ScanResult
            AppName = $AppName
            ContentName = $null
            Content = $Content
            Hash = $Hash
            ContentFiltered = $ContentFiltered
        }
    } else {
        $Session = $_.Properties[0].Value
        $ScanStatus = $_.Properties[1].Value
        $ScanResult = $_.Properties[2].Value
        $AppName = $_.Properties[3].Value
        $ContentName = $_.Properties[4].Value
        $Content = [Text.Encoding]::Unicode.GetString($_.Properties[7].Value)
        $Hash = [BitConverter]::ToString($_.Properties[8].Value).Replace('-', '')
        $ContentFiltered = $_.Properties[9].Value

        [PSCustomObject] @{
            Session = $Session
            ScanStatus = $ScanStatus
            ScanResult = $ScanResult
            AppName = $AppName
            ContentName = $ContentName
            Content = $Content
            Hash = $Hash
            ContentFiltered = $ContentFiltered
        }
    }
}

$AMSIScanEvents

在成功捕獲之后，你就可以看到這次執(zhí)行payload的內(nèi)容了。pic here利用ETW進(jìn)行相關(guān)檢測(cè)并不是這篇文章的主題，不過(guò)希望這篇文章能夠讓你產(chǎn)生足夠的興趣，讓你之后進(jìn)行深入研究。

披露時(shí)間線(xiàn)

為了避免我們披露此問(wèn)題后，攻擊者利用該漏洞造成不良影響，我們一般會(huì)先向廠商報(bào)告漏洞并提供足夠多的時(shí)間讓它們修復(fù)問(wèn)題。由于本文的漏洞涉及到Windows Defender Application Control，我們將這個(gè)問(wèn)題提供給了Windows。整個(gè)時(shí)間線(xiàn)如下所示。

April 24, 2018?—?向MSRC報(bào)告此問(wèn)題

April 24, 2018?—?MSRC知曉了問(wèn)題并提供了一個(gè)事件編號(hào)

April 30, 2018?— 收到郵件，告訴我們?cè)搯?wèn)題已被復(fù)現(xiàn)

May 24, 2018?—?向MSRC發(fā)送郵件，要求更新

May 28, 2018?— 回復(fù)稱(chēng)評(píng)估過(guò)程仍在繼續(xù)

June 10, 2018?—?向MSRC發(fā)送郵件，要求更新

June 11, 2018?—?MSRC回復(fù)稱(chēng)計(jì)劃在8月更新中修復(fù)問(wèn)題

July 12, 2018?—?MSRC回復(fù)稱(chēng)該問(wèn)題不能通過(guò)安全更新方式解決，可能會(huì)在下一個(gè)版本更新中修復(fù)此問(wèn)題。

以上是“如何利用Winrm.vbs繞過(guò)白名單限制執(zhí)行任意代碼”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對(duì)大家有所幫助，如果還想學(xué)習(xí)更多知識(shí)，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道！