本文講的是<b>CVE-2017-0199利用：HTA處理程式漏洞</b>，
FireEye最近記錄了在Windows HTA處理程式中使用Office RTF文檔在野外使用的0-day漏洞的攻擊。 該漏洞随後被命名為CVE-2017-0199，并在2017年4月的Microsoft Update進行了修補。在任何樣本或相關資訊中都沒有出現如何重制此漏洞的資訊，但是ActiveBreach團隊卻做了一個非常有意思的研究，他們能夠利用這一漏洞繞過已知的緩解措施，如EMET。
這篇文章描述了如何在沒有使用者基于我們研究的互動這一情況下利用這個漏洞，其中所讨論的技術可能與攻擊者所使用的技術不同。 還要強調的一點是，這個問題不僅僅局限于RTF檔案，我們還使用了其他的Office文檔類型來成功地利用了這一點。
具體步驟
雖然FireEye所述的重制問題的技術步驟很少，但是文章還是有幾個提示的：
首先，是在使用OLE2嵌入式連結對象時發現這一問題的，其次是處理HTA檔案。
要将OLE2連結對象嵌入到文檔中，請打開Microsoft Word并單擊插入對象按鈕，如下面的螢幕截圖所示：
選擇從檔案建立，将URL插入到HTA檔案，并勾選連結到檔案和顯示為圖示。
将文檔另存為DOCX，DOC或RTF檔案，所有這些都可以處理OLE2連結對象。
在這一步，需要一些社交工程才能讓使用者運作有效載荷，因為它們必須輕按兩下OLE對象的圖示。 但是如果使用者這樣做了，就不會顯示警告或運作提示，如下所示：
然而在這裡需要注意，圖示和文字可能會使那些受過教育的使用者感到有些可疑; 是以，可以通過替換圖示和檔案名以及在Word中呈現的對象來進行改進，隻需要不勾選“顯示為圖示”的複選框并将文檔内容類型選擇為應用程式/ rtf或應用程式/文檔即可：
這會使HTA如下圖所示：
到這裡仍然需要使用者互動——使用者必須輕按兩下“hello”文本，或者儲存檔案以強制文檔執行連結，更新内容并進行顯示。
但是在FireEye的描述中沒有明确說明使用者互動是必需的以及提示打開文檔時有效載荷應該自動運作的。 ActiveBreach團隊的研究是如何實作的呢？當我們進一步了解RTF RFC時發現了“ objupdate”控件：
此控件的描述特别有趣——因為這意味着對象将在顯示之前更新：
是以，這裡其實可以建立一個包含 objupdate控件的文檔，并最終迫使它在啟動時進行更新。這一步可以通過使用以前建立的文檔并在文本編輯器中進行修改來實作：
原版的：
注入 objupdate控件的文檔：
打開RTF檔案就會發現現在導緻托管的HTA檔案可以在沒有使用者互動的情況下運作：
還需要注意的是，我們的研究表明，如果使用者沒有安裝Microsoft Office，那麼該問題仍然可以在WordPad中利用，但需要進行互動。
如何檢測并響應？
應急中心已經釋出了一些Yara規則來檢測這個問題。 但在許多情況下，檢測并不是非常準确，并且可能會産生誤報，因為它們主要依賴于對基于包含OLE2Link對象的RTF文檔的檢測。而這并不一定意味着惡意行為，也可能是一個合法嵌入的對象。
是以為了有效地檢測CVE-2017-0199，Yara規則應該添加一個條件來識别 objupdate控件。
原文釋出時間為：2017年4月17日
本文作者：Change
本文來自雲栖社群合作夥伴嘶吼，了解相關資訊可以關注嘶吼網站。
<a href="http://www.4hou.com/technology/4325.html" target="_blank">原文連結</a>