語：Unit 42的研究人員一直在跟蹤一起大范圍的惡意JavaScript（JS）注入活動，該活動將受害者重定向到廣告軟件和欺騙頁面等惡意內容。這一威脅在2022年全年都很活躍，并在2023年繼續感染眾多網站。

Unit 42的研究人員一直在跟蹤一起大范圍的惡意JavaScript（JS）注入活動，該活動將受害者重定向到廣告軟件和欺騙頁面等惡意內容。這一威脅在2022年全年都很活躍，并在2023年繼續感染眾多網站。

我們在51000多個網站上檢測到了注入的JS代碼，包括躋身Tranco前100萬個網站排行榜的數百個網站。受影響的網站出現在Tranco中表明，這起活動可能影響了大量的人。

我們還發現，這起活動是多方面的，因為它在重定向到惡意網頁之前執行多步注入，并使用混淆和良性附加攻擊來繞過檢測機制。惡意軟件編寫者利用這些技術將惡意JS代碼樣本的多種變體注入到網站中。

我們新穎的對抗性深度學習技術無罪推定（IUPG）檢測到了注入的JS代碼的多種變體。該模型是我們下一代防火墻產品的高級URL過濾（AUF）訂閱服務的一部分。它可以檢測惡意JS樣本，并可以對來自內聯保護和我們離線爬蟲的內容進行分類，內聯保護可對防火墻上的流量進行實時分析。

具體活動和用戶影響

我們已經檢測到攻擊者將惡意JS代碼注入到網站的活動的多種形式。這種注入的代碼將受害者重定向到各種惡意內容，比如廣告軟件和騙局。

研究人員去年報道了一起類似的活動。我們在2020年觀察到了該活動的第一例。然而，我們將側重介紹在2022年1月至2023年期間跟蹤的這起活動的最新變體。

自2022年初以來，我們在來自51000個主機名的大約170000個URL上檢測到了這起活動。如圖1所示，該活動在過去一年保持活躍狀態，并在2023年繼續影響網站。這起活動在2022年5月至8月期間達到了頂峰，當時我們看到平均每天有4000個URL中招。

圖1. 該圖顯示了整個2022年和2023年初的活動，在2022年5月至8月之間達到頂峰

我們懷疑這起活動影響了大量的人，因為在撰寫本文時，數百個受感染的網站躋身Tranco的前100萬網站排行榜。在2023年1月期間，我們在14773個設備上攔截了來自這些網站的約240000次會話。

JS注入的例子

這起惡意JS注入活動使用各種技術來繞過檢測機制，比如混淆、向大型良性文件附加代碼和多步注入。我們將介紹惡意JS代碼的幾個例子，活動背后的不法分子對這些代碼進行混淆處理，并隱藏在更龐大的JS文件中。我們還將介紹一個例子，其中惡意軟件在最終加載惡意載荷之前執行一系列的JS注入。

混淆

圖2a、b和c顯示了活動中經常檢測到的JS片段例子。在所有這些例子中，注入的JS代碼都經過混淆處理，以隱藏惡意載荷從而繞過檢測。具體來說，這種經過混淆處理的代碼隱藏了用于加載惡意JS的外部URL。代碼還包括向文檔對象模型（DOM）動態添加惡意JS的行為。

比如說，下面的前兩個JS代碼片段（圖2a和圖b）使用String.fromCharCode隱藏了指向惡意JS的鏈接，這是一種常見的混淆技術。圖2c顯示了混淆的另一個例子。經過混淆處理的代碼顯示在左邊，經過去混淆處理的代碼顯示在右邊。通過使用variable _0xfcc4中的十六進制表示來混淆函數調用的名稱（比如fromCharCode）。

圖2 a. 使用String.fromCharCode隱藏惡意JS鏈接的例子

圖2 b. 使用String.fromCharCode隱藏惡意JS鏈接的例子

圖2 c. 隱藏函數調用名稱的例子。圖像的左側顯示了如何使用variable _0xfcc4中的十六進制表示來混淆函數調用。圖像的右側顯示了去混淆后的函數調用fromCharCode

將JS代碼附加到大文件中

我們在一些網站上發現了這些經過混淆處理的JS片段被注入到常見實用程序JS文件（比如jQuery）中的例子。惡意軟件編寫者經常使用這一招將惡意代碼附加到大塊的良性代碼中，這又叫良性附加攻擊。這種技術可以幫助惡意軟件編寫者逃避安全爬蟲的檢測機制。

多步JS注入

在所有JS代碼片段中注入的JS代碼（如圖2a、b和c所示）通過操縱DOM附加外部惡意JS代碼。這使攻擊者能夠改變惡意載荷。

這起活動最近的一種變體是將惡意JS代碼注入到網站。然后它執行一系列中間JS注入，之后加載將受害者重定向到惡意網頁的惡意載荷。

在圖3顯示的例子中，每個注入的JS代碼在投放惡意載荷之前依次執行來自另一個網站的JS代碼。包含來自不同網站的JS注入的一個原因可能是，攻擊者想要不斷改變加載最終載荷的URL，以防加載JS的URL被安全爬蟲列入黑名單。

圖3. 這個例子表明網站上的腳本注入在最終加載重定向到惡意網頁的惡意載荷之前執行一系列中間腳本注入

重定向到惡意內容

最終的惡意載荷將用戶重定向到不同的網站，然后登錄到最終的網頁，這通常是廣告軟件或欺騙頁面。比如說，訪客可能被重定向到一個虛假的通知欺騙頁面，如圖4a所示。在這個頁面上，人們會看到欺騙性內容，引誘他們允許由攻擊者控制的網站發送瀏覽器通知。

圖4. 顯示虛假的驗證碼圖像，是為了引誘人們允許網站發送通知

在另一個例子中，如圖4b所示，最終的惡意網頁顯示了來自知名視頻共享平臺的模仿頁面的虛假警告這種形式的欺騙性內容。這些欺騙性內容會誘使人們下載虛假瀏覽器。

圖4 b. 顯示了知名視頻共享平臺的模仿頁面以及虛假警告，誘使人們下載虛假瀏覽器

JS如何被注入到網站上？

Unit 42的研究人員懷疑，由于一個或多個易受攻擊的內容管理系統（CMS）插件，大量網站可能會遭到攻擊。Sucuri公司的研究人員曾報告了一起類似的活動利用CMS插件（詳見https://blog.sucuri.net/2022/05/massive-wordpress-javascript-injection-campaign-redirects-to-ads.html）。我們還發現，檢測到的網站（共51000個）中估計四分之三使用流行的CMS。

在一半以上被檢測到的網站的主頁上都包含注入的惡意JS代碼。活動攻擊者采用的一種常見策略是向經常使用的JS文件名（比如jQuery）注入惡意JS代碼，它們可能被包含在中招網站的主頁上。這可能幫助攻擊者鎖定網站的合法用戶，因為他們更有可能訪問網站的主頁。

利用深度學習檢測惡意JS注入

惡意軟件編寫者為這起活動設計了惡意JS代碼的不同變體，將其注入到網站中。眾所周知，深度學習技術在檢測同一攻擊的不同變體方面功能很強大。因此，深度學習技術可以提高惡意JS注入的檢出率。

深度學習技術還可以抵抗來自惡意軟件的對抗性逃避活動。這些類型的對抗性逃避的一個具體例子是普遍存在的黑盒對抗性威脅，即良性附加攻擊。

結論

在2022年至2023年初期間，在51000多個網站上檢測到了一起廣泛的惡意JavaScript注入活動。我們發現惡意軟件編寫者對惡意JS進行混淆處理以繞過檢測機制，并在重定向到惡意網頁之前執行多步注入。

注入的JS代碼可能影響了大量互聯網用戶，因為數百個受感染的網站躋身Tranco前100萬網站排行榜。我們建議網站所有者和客戶及時更新第三方插件和軟件，以保護他們的網站免受這類注入。

這起活動中注入的惡意JS代碼是我們在外頭看到的附加攻擊的一個常見例子。正如我們在IEEE安全和隱私研討會（SPW）上發表的IUPG模型研究工作中所解釋的那樣，IUPG模型的訓練過程專門旨在識別和隔離良性內容背景中的惡意子模式。

我們的深度學習模型無罪推定（IUPG）檢測到了注入惡意JS代碼的多種變體。該模型是高級URL過濾云提供的安全服務（可檢測惡意JS樣本）的檢測功能之一。它還可以對來自離線爬蟲以及防火墻上流量的內聯實時分析的內容進行分類。

使用高級URL過濾和DNS安全訂閱的下一代防火墻讓客戶可以免受本文描述的惡意JS注入活動的已知URL和主機名。我們還提供了已知攻陷指鏈接（https://github.com/pan-unit42/iocs/blob/master/IOCs_MaliciousJS.txt），幫助對付本文中討論的威脅。

翻譯自：https://unit42.paloaltonetworks.com/malicious-javascript-injection/

from https://www.4hou.com/index.php/posts/GKy0

景說明

假設需要劫持http響應并在html頁面中注入一段js代碼后再傳回瀏覽器，實現在瀏覽器出現一個彈框消息提醒。

由于原始html頁面編碼格式存在UTF-8、GBK等多種編碼格式，如果注入的js包含中文消息的話，那么在UTF-8或GBK編碼的頁面就會有一個出現亂碼。有沒有辦法做到不管是針對GBK、UTF-8編碼的頁面都能做到正常顯示而不會出現亂碼哪？

產生亂碼的原因

首先來分析一下產生亂碼的原因，我們在瀏覽器看到的信息都是通過圖形學手段在顯示器上呈現出來的，而實際保存在計算機硬件上的都是0和1（因為計算機實現是基于二進制），那么計算機要顯示、傳遞信息就需要依靠一套規則把一串串的0和1識別為正確的字符，這就是編碼。

例如01000001在ASCII編碼規則下對應字母A。相同的0/1串，不同的編碼解析出的字符一般是不同的，因此如果html頁面按照UTF-8的編碼解析正常，那么按照GBK的編碼解析就會是亂碼了。根據上面的示意圖，假設注入的js代碼為utf-8編碼格式，而原始html編碼格式也為UTF-8編碼格式，那么最終注入這部分中的中文就能正常顯示，但是如果原始html為GBK編碼，那注入的這部分js代碼的中文就會顯示亂碼。

解決辦法

有一種unicode統一編碼字符集，目標是把所有文字、字符統一編碼，也就是一串0/1組合在unicode字符集下對應的字符是唯一的，不會存在歧義。而js是支持解析unicode字符的，那么就可以在注入js中把要顯示的消息統一轉換為unicode編碼，瀏覽器端去解析這個unicode編碼，這樣不管原始html是UTF-8還是GBK，都能正常顯示中文。

原始注入js代碼關于中文字符的部分

// utf-8編碼格式
let message="中文";

解決亂碼的注入js代碼關于中文字符的部分

// utf-8編碼格式
let message="\\u4e2d\\u6587";  // 這個編碼對應上面的message"中文"

注意：

1. 注入的js代碼仍然是utf-8編碼格式，只是消息內容轉換為unicode編碼的形式；
2. unicode中0x4e2d表示的0/1串對應漢字"中"，0x6587對應的0/1串對應漢字"文";
3. message其實也不是真正的unicode編碼，它只是普通的字符串，只是使用了unicode對應的碼點（也就是二進制對應的數值），因為可以利用這個碼點在瀏覽器中恢復出正確的字符，事實上unicode字符集并沒有規定具體的編碼格式。