網(wǎng)絡(luò)安全領(lǐng)域近日發(fā)現(xiàn)了一種新型的Magecart網(wǎng)絡(luò)攻擊，這次攻擊采用了一種極具隱蔽性的手法，利用了網(wǎng)站的默認(rèn)404錯誤頁面來隱藏惡意代碼。你可能對404錯誤頁面并不陌生，它通常出現(xiàn)在你訪問一個不存在的頁面時。然而，攻擊者卻利用這個看似普通的錯誤頁面來進(jìn)行惡意活動。他們巧妙地將惡意代碼注入到404頁面中，使得攻擊更加難以察覺。當(dāng)你無意中進(jìn)入受感染的網(wǎng)站并看到404錯誤頁面時，你可能完全不知道自己已經(jīng)成為攻擊的目標(biāo)。這種新型攻擊方式給安全防御帶來了更大的挑戰(zhàn)，我們需要保持警惕，并采取措施來保護(hù)自己免受這種隱蔽攻擊的威脅。
內(nèi)容提要
• Akamai安全情報組發(fā)現(xiàn)了一個Magecart網(wǎng)站盜取活動，該活動針對的是大量網(wǎng)站，其中包括食品和零售行業(yè)的大型組織。
• 這一活動之所以引人注目，是因為它采用了三種先進(jìn)的隱藏技術(shù)，其中一種技術(shù)是我們以前從未見過的，特別是操縱網(wǎng)站的默認(rèn) 404 錯誤頁面來隱藏惡意代碼，這給檢測和緩解帶來了獨特的挑戰(zhàn)。
• 另外兩種混淆技術(shù)展示了攻擊者為躲避檢測和延長攻擊鏈而不斷演變的戰(zhàn)術(shù)。
• 隨著網(wǎng)絡(luò)盜刷攻擊變得越來越復(fù)雜，企業(yè)必須保持警惕，并探索先進(jìn)的方法來防范這些不斷演變的威脅。
引言
一種新的、復(fù)雜的、隱蔽的 Magecart 網(wǎng)絡(luò)盜版活動一直以 Magento 和 WooCommerce 網(wǎng)站為目標(biāo)。其中一些受害者與食品和零售行業(yè)的大型組織有關(guān)。
根據(jù)我們發(fā)現(xiàn)的證據(jù)，該活動已經(jīng)活躍了幾個星期，在某些情況下甚至更長。這次活動采用了一種我們以前從未遇到過的高級隱藏技術(shù)，讓我們大吃一驚。
新運動
Magecart 攻擊通常從利用目標(biāo)網(wǎng)站的漏洞或感染這些網(wǎng)站使用的第三方服務(wù)開始。在這次活動中，我們檢測到的所有受害網(wǎng)站都被直接利用了，因為惡意代碼片段被注入到了它們的第一方資源中。
在某些情況下，惡意代碼被插入 HTML 頁面；在其他情況下，惡意代碼被隱藏在作為網(wǎng)站一部分加載的第一方腳本中。
與許多其他 Magecart 活動一樣，該活動的攻擊基礎(chǔ)架構(gòu)由三個主要部分組成：加載器、惡意攻擊代碼和數(shù)據(jù)外滲（圖 1）。
1. 加載器 - 簡短、晦澀的 JavaScript 代碼片段，負(fù)責(zé)加載攻擊的全部惡意代碼
2. 惡意攻擊代碼 - 執(zhí)行攻擊的主要 JavaScript 代碼；它會檢測敏感輸入、讀取數(shù)據(jù)、擾亂結(jié)賬流程并注入虛假表單
3. 數(shù)據(jù)外滲 - 將竊取的數(shù)據(jù)傳輸?shù)焦粽叩闹笓]和控制 (C2) 服務(wù)器的方法
圖 1：Magecart 攻擊基礎(chǔ)結(jié)構(gòu)
將攻擊分為三部分的目的是為了隱藏攻擊，使其更難被發(fā)現(xiàn)。這樣只有在特定目標(biāo)頁面上才能啟動完整的攻擊流程；也就是說，由于攻擊者使用了混淆措施，只有在攻擊者打算執(zhí)行攻擊的地方才能啟動完整的攻擊流程。這使得攻擊更加隱蔽，更難被目標(biāo)網(wǎng)站上可能存在的安全服務(wù)和外部掃描工具檢測到。
雖然大多數(shù) Magecart 攻擊活動在流程和階段上都有相似之處，但攻擊者采用的各種隱藏技術(shù)卻使活動與眾不同。這些技術(shù)用于掩蓋攻擊的基礎(chǔ)設(shè)施、隱藏痕跡、使檢測和逆向工程復(fù)雜化，并最終延長攻擊時間。
三種不同的變體
我們發(fā)現(xiàn)了這一活動的三種不同變體，表明了攻擊的演變過程以及攻擊者為防止檢測和緩解這一活動所做的改進(jìn)：
• 前兩種變體非常相似，只是在裝載機(jī)部分略有不同。
• 第三個版本很特別，因為攻擊者使用了網(wǎng)站默認(rèn)的404錯誤頁面來隱藏惡意代碼；這是一種創(chuàng)造性的隱藏技術(shù)，我們以前從未見過。
讓我們來詳細(xì)了解一下這項新穎活動的三個變體的技術(shù)細(xì)節(jié)。
變體一
我們的研究始于我們在一家大型公司網(wǎng)站上發(fā)現(xiàn)的一些可疑代碼片段，這些代碼片段被我們的威脅情報監(jiān)控工具檢測到。在對這些代碼段進(jìn)行分析后，我們發(fā)現(xiàn)它們是惡意編碼的JavaScript加載器，在網(wǎng)站上仍然存在并處于活動狀態(tài)。這一發(fā)現(xiàn)促使我們進(jìn)一步調(diào)查，揭露了整個活動的變體及其對眾多網(wǎng)站的影響。
變體一號裝載機(jī)： 冰山一角
取樣器成功地在被利用的網(wǎng)站上注入了一個帶有onerror屬性的畸形HTML 圖像標(biāo)記（圖 2）。該屬性包含一個經(jīng)過混淆的Base64編碼惡意加載程序代碼片段。圖片標(biāo)簽的src屬性故意為空，目的是防止網(wǎng)絡(luò)請求，并觸發(fā)內(nèi)聯(lián)onerror回調(diào)的執(zhí)行，該回調(diào)包含經(jīng)過混淆的惡意 JavaScript 代碼片段。
使用圖片標(biāo)簽來執(zhí)行 JavaScript 代碼是一種不太常見但更復(fù)雜的技術(shù)。它可以幫助盜號者繞過安全措施，例如通常會分析網(wǎng)絡(luò)流量的外部掃描儀，但在這種特定情況下不會觸發(fā)這些掃描儀。混淆代碼將在頁面上下文中執(zhí)行，運行時就像由頁面本身啟動的本地第一方腳本一樣。
圖 2：變體一加載器--格式不當(dāng)?shù)?HTML 圖像標(biāo)記，帶有包含惡意加載器代碼的 onerror 屬性
解碼加載程序代碼 - 運行時
經(jīng)過混淆的 Base64 編碼代碼一旦在運行時被執(zhí)行，就會轉(zhuǎn)換成純 JavaScript，并負(fù)責(zé)啟動 WebSocket 通道（圖 3）。該通道是瀏覽器與攻擊者 C2 服務(wù)器之間的雙向通信鏈路。
在最近的幾次活動中，我們發(fā)現(xiàn)了在 Magecart 攻擊中使用 WebSockets 的情況。WebSocket 被認(rèn)為是一種更安靜、更靈活的通信方法，允許攻擊者利用單一網(wǎng)絡(luò)通道實現(xiàn)各種目的。這包括將攻擊的不同部分從 C2 服務(wù)器發(fā)送到瀏覽器（反之亦然），以及在某些情況下促進(jìn)數(shù)據(jù)外滲活動。
代碼的另一個值得注意的方面是僵尸檢測，它會檢查用戶代理是否受自動化控制。如果是，代碼就會終止執(zhí)行。這是一種巧妙的反僵尸技術(shù)，旨在躲避可能檢測到攻擊的外部安全掃描儀和沙箱。
圖 3：變體一加載器的運行時解碼 JavaScript 代碼
Websocket 通信流
一旦 WebSocket 通道建立，第一條信息就會從攻擊者的 C2 服務(wù)器發(fā)送到瀏覽器。該信息以 Base64 編碼字符串的形式傳輸，其中包含一條單行 JavaScript 命令，指示瀏覽器發(fā)回頁面的當(dāng)前 URL。
這一步的目的是讓 C2 服務(wù)器能夠確定當(dāng)前頁面是結(jié)賬（敏感）頁面還是其他非結(jié)賬頁面。這樣，攻擊者就可以相應(yīng)地調(diào)整下一步。
這種直接的服務(wù)器端驗證使攻擊者能夠只在相關(guān)的目標(biāo)網(wǎng)頁上啟動攻擊，從而避免了在非敏感網(wǎng)頁上的潛在暴露。這是另一個例子，突出說明了盜號者為逃避安全服務(wù)和外部掃描儀的檢測所做的努力。
當(dāng) C2 服務(wù)器識別出結(jié)賬頁面 URL 后，流程進(jìn)入下一階段。在這個步驟中，會向瀏覽器發(fā)送另一條信息。這是一個 Base64 編碼的長字符串，其中包含整個攻擊代碼。解碼后，一段冗長的混淆 JavaScript 代碼就會顯現(xiàn)出來（圖 4）。
這些代碼負(fù)責(zé)在目標(biāo)敏感頁面上執(zhí)行各種惡意活動，目的是讀取用戶的敏感個人數(shù)據(jù)和信用卡數(shù)據(jù)，并將其傳輸回盜取者的 C2 服務(wù)器。
隨后，包含惡意代碼收集的敏感被盜數(shù)據(jù)的混淆數(shù)據(jù)外泄信息會從瀏覽器發(fā)送到 C2 服務(wù)器。如前所述，與 XHR、獲取或 HTML 資源請求等傳統(tǒng)通信方法相比，使用相同的 WebSocket 通道加載完整的惡意代碼和外泄竊取的數(shù)據(jù)會使整個過程更安靜，涉及的網(wǎng)絡(luò)請求也更少。
圖 4：結(jié)賬頁面上的 WebSocket 流程
變體二
變體二號裝載機(jī):同位女士，新的著裝
變體一和變體二的主要區(qū)別在于加載器組件。在變體二中，取樣器插入了一個內(nèi)聯(lián)腳本，其中的代碼片段與著名的 Facebook 訪客活動跟蹤服務(wù) Meta Pixel 代碼片段非常相似，只是里面多了幾行代碼（圖 5）。
這些添加的行是真正的加載器部分，而周圍的 Meta Pixel 代碼則是一個誤導(dǎo)性的偽裝，使其看起來像是一個合法而不可疑的代碼片段。
這種隱藏技術(shù)會讓惡意代碼片段看起來像是 Google Tag Manager 或 Facebook 等知名服務(wù)，在最近的 Magecart 活動中很受歡迎。它允許篡改者逃避外部掃描儀和研究人員的靜態(tài)分析。
圖 5：變體二加載程序--偽裝成 Meta PIxel 代碼段的內(nèi)聯(lián)腳本，內(nèi)含惡意加載程序
索取圖片
當(dāng)我們仔細(xì)檢查偽造的 Meta Pixel 代碼段中的可疑行時，發(fā)現(xiàn)它似乎是從網(wǎng)站自己的目錄中獲取一張 PNG 圖像。該網(wǎng)絡(luò)請求似乎是對網(wǎng)站上托管的無辜圖像的典型請求。然而，當(dāng)我們檢查這張圖片的實際內(nèi)容時，發(fā)現(xiàn)它并不像看上去那么無害（圖 6）。
圖6：對已經(jīng)被攻擊者篡改并包含惡意代碼的圖像的網(wǎng)絡(luò)圖像請求
二進(jìn)制圖像中的惡意 JavaScript 代碼片段
PNG 圖像的二進(jìn)制數(shù)據(jù)包含一個添加到圖像二進(jìn)制文件末尾的 Base64 編碼字符串（圖 7）。加載程序代碼片段提取、解碼并執(zhí)行該字符串（圖 8）。解碼后的字符串代表一個 JavaScript 代碼段，與變體一中加載器的 onerror 屬性中的代碼段完全相同。
流程的后續(xù)步驟保持不變。該代碼片段在運行時會轉(zhuǎn)換為純 JavaScript 代碼，代碼會啟動 WebSocket 通道連接到攻擊者的 C2 服務(wù)器，其余步驟如前所述。
圖 7：包含隱藏惡意代碼的圖像二進(jìn)制數(shù)據(jù)
圖 8：最初以 Base64 編碼并隱藏在圖像中的惡意代碼在解碼后變得清晰可見
變體三
現(xiàn)在，讓我們來談?wù)勛罹实牟糠帧ｋm然我們已經(jīng)看到過類似的攻擊，但這次的攻擊卻獨一無二，著實讓我們大吃一驚。
變體三裝載機(jī)： 一樣，一樣，但又完全不同
乍一看，這個加載器與變體二中的加載器很相似，但你會發(fā)現(xiàn)（就像我們一樣）這是一個完全不同的場景。在某些情況下，這個加載程序會偽裝成 Meta Pixel 代碼段，如變體二所示（圖 9）。但在其他情況下，它會被注入頁面上的隨機(jī)內(nèi)聯(lián)腳本中（圖 10）。
該加載器的第一個顯著特征是向名為 "圖標(biāo) "的相對路徑發(fā)出獲取請求。
圖 9：變體三加載器--隱藏在代碼段中的惡意代碼段，模仿 Meta Pixel 的外觀
圖 10：變體三加載器 -- 隱藏在任意內(nèi)聯(lián)腳本中的惡意代碼片段
一次404 錯誤？確定嗎？
加載程序執(zhí)行后，攻擊會向 /icons 發(fā)送獲取請求，這是一個實際上并不存在的相對路徑。該請求導(dǎo)致 "404 Not Found "錯誤（圖 11）。對響應(yīng)中返回的 HTML 進(jìn)行分析后發(fā)現(xiàn)，這似乎是網(wǎng)站的默認(rèn) 404 頁面（圖 12）。這種情況令人困惑，讓我們懷疑盜號者是否不再活躍于我們發(fā)現(xiàn)的受害網(wǎng)站。
圖 11：加載程序向不存在的路徑發(fā)起請求，返回 404 錯誤
圖 12: 默認(rèn)錯誤頁面 HTML
永遠(yuǎn)不要低估裝載機(jī)
我們往后退一步，重新分析了加載器，發(fā)現(xiàn)了拼圖中缺失的部分。加載器中包含一個與字符串 "COOKIE_ANNOT "匹配的 regex，它應(yīng)該在作為圖標(biāo)請求的一部分返回的 404 錯誤頁面上執(zhí)行。
于是，我們在返回的 404 HTML 中搜索這個字符串，結(jié)果發(fā)現(xiàn)了一個隱藏在末尾的注釋！我們發(fā)現(xiàn)了隱藏在頁面末尾的注釋，其中包含 "COOKIE_ANNOT "字符串（圖 14）。在這個字符串旁邊，還連接了一個 Base64 編碼的長字符串。這個編碼字符串代表了整個混淆 JavaScript 攻擊代碼。加載器從注釋中提取這個字符串，解碼后執(zhí)行攻擊，目的是竊取用戶輸入的個人信息。
我們模擬了對不存在的路徑的其他請求，所有請求都返回了相同的 404 錯誤頁面，其中包含帶有惡意代碼編碼的注釋。這些檢查證實，攻擊者成功更改了整個網(wǎng)站的默認(rèn)錯誤頁面，并在其中隱藏了惡意代碼！
圖 13：加載器變體 3--"COOKIE_ANNOT ".字符串的 regex 匹配
圖 14：隱藏在錯誤頁面 HTML 中的惡意編碼注釋
數(shù)據(jù)外泄
虛假表單
與變體一和變體二不同，攻擊者在變體三中使用了另一種常見的數(shù)據(jù)外滲技術(shù)--注入虛假表單（圖 15）。這種技術(shù)通常在取款機(jī)無法訪問敏感輸入時使用。
當(dāng)網(wǎng)站使用的第三方支付服務(wù)在第三方 iframe 或外部頁面中實現(xiàn)支付表單時，就會出現(xiàn)這種情況。為了繞過這種情況，攻擊者會創(chuàng)建一個與原始支付表單非常相似的假表單，并將其覆蓋--這是一種越來越流行的技術(shù)。這正是變體三中被盜數(shù)據(jù)的外流方式。
圖 15：惡意代碼注入的虛假表單
當(dāng)用戶向攻擊者的虛假表單提交數(shù)據(jù)時，系統(tǒng)會顯示錯誤，隱藏虛假表單，顯示原始付款表單，并提示用戶重新輸入付款信息（圖 16）。
圖 16：隱藏虛假表單，提示用戶重新輸入信息
盜取數(shù)據(jù)的圖像請求
提交虛假表單后，就會向攻擊者的 C2 服務(wù)器發(fā)起圖像網(wǎng)絡(luò)請求，在查詢參數(shù)中以 Base64 編碼字符串的形式攜帶所有被竊取的個人信息和信用卡信息（圖 17）。解碼后，該字符串將揭示請求的真實意圖，整個攻擊流程也就一目了然了。
圖 17：將被盜數(shù)據(jù)作為 Base64-編碼字符串查詢參數(shù)包含的圖像網(wǎng)絡(luò)請求
從變體三中汲取的經(jīng)驗教訓(xùn)： 404 案例
這種隱藏技術(shù)極具創(chuàng)新性，是我們在以前的 Magecart 活動中從未見過的。操縱目標(biāo)網(wǎng)站的默認(rèn) 404 錯誤頁面的想法可以為 Magecart 攻擊者提供各種創(chuàng)造性的選擇，從而提高隱藏和逃避能力。
在我們發(fā)現(xiàn)的一些案例中，惡意加載程序在撰寫本文時已經(jīng)從受影響網(wǎng)站的頁面中刪除。然而，默認(rèn) 404 頁面中的惡意注釋卻依然存在，這可能會讓盜號者輕易地重新啟動攻擊。這凸顯了檢測這種方法的復(fù)雜性和減輕其影響的重要性。
另一種規(guī)避技術(shù)是向通往 404 頁面的第一方路徑發(fā)出請求，這種技術(shù)可以繞過內(nèi)容安全策略標(biāo)題和其他可能會主動分析頁面上網(wǎng)絡(luò)請求的安全措施。這無疑是我們最近遇到的最復(fù)雜的 Magecart 策略之一。
Akamai客戶端保護(hù)&合規(guī)性與取樣器的比較
作為對這一活動研究的一部分，我們針對Akamai客戶端保護(hù)與合規(guī)性進(jìn)行了模擬，我們的解決方案可以分析運行時的JavaScript執(zhí)行行為，從而抵御JavaScript威脅并減輕客戶端攻擊。
該解決方案成功檢測到了這個復(fù)雜的盜號軟件，并觸發(fā)了一個高嚴(yán)重性事件，以便立即采取緩解措施。在一個實際場景中，如果在特定網(wǎng)頁上啟用了客戶端保護(hù)與合規(guī)性，圖 18 顯示了網(wǎng)站所有者將收到的警報，這樣他們就可以迅速調(diào)查威脅，并實時響應(yīng)各種緩解方案。
圖 18：檢測到盜碼器后的客戶端保護(hù)與合規(guī)模擬警報
結(jié)論
這一活動進(jìn)一步說明，網(wǎng)絡(luò)盜版技術(shù)在不斷發(fā)展。它們變得越來越復(fù)雜，這使得通過靜態(tài)分析和外部掃描進(jìn)行檢測和緩解變得越來越具有挑戰(zhàn)性。該領(lǐng)域的威脅行為者不斷找到更好的方法，將其攻擊隱藏在受害者網(wǎng)站中，并規(guī)避可能暴露其攻擊的各種安全措施。
本研究強調(diào)的復(fù)雜程度應(yīng)提醒各組織保持警惕，關(guān)注網(wǎng)頁盜用攻擊載體，并積極尋求新的先進(jìn)方法來應(yīng)對此類攻擊。
