盡管木馬源攻擊的通用漏洞評分高達 9.8，但企業(yè)完全沒必要驚慌失措。

劍橋大學研究人員發(fā)現(xiàn)的木馬源（Trojan Source）攻擊會誘使編譯器讀取隱藏的 Unicode 字符，并生成帶有開發(fā)人員或安全分析師不知道的額外指令和后門的二進制文件。由于默認情況下特殊字符不可見，因此在代碼審查期間難以發(fā)現(xiàn)惡意代碼。

利用 Unicode 顯示文本方式的攻擊并不新鮮，但 “木馬源” 更具威脅的原因是從公共站點（例如 StackOverflow、GitHub 和其他社區(qū)論壇）復制和粘貼的大量代碼會直接進入源代碼文件。如果有問題的 Unicode 字符隱藏在文件中，這些字符也會被復制進來。

nVisium 高級應(yīng)用程序顧問 Jon Gaines 表示：“這對源代碼審查的能力是一次考驗，當下建議暫時不要復制和粘貼代碼，最好是自己重寫一遍?！?/p>方法一：“顯影” Unicode 字符

開發(fā)人員可以通過啟用他們正在使用的 IDE 或文本編輯器來顯示 Unicode 字符，從而檢測潛在的惡意 Unicode 字符?；蛘呖梢允褂妹钚惺M制編輯器，例如 HexEd.It，在文件中搜索特定的 Unicode 字符。

一些主要的源代碼控制平臺已經(jīng)做出回應(yīng)：GitHub、GitLab 和 Atlassian（用于 BitBucket）已經(jīng)發(fā)布了針對 Unicode BiDi 字符的警報 (CVE-2021-42574)。

對于容易遭受木馬源攻擊的文本編輯器 Visual Studio Code ，一種可行的方法是將編碼轉(zhuǎn)換為非 unicode。JFrog 安全研究高級主管 Shachar Menashe 表示，這會將惡意的 Unicode 字符（對于 BiDi 字符）標記為損壞字符，在手動代碼審查期間可以發(fā)現(xiàn)這些損壞的字符。

這是在 Visual Studio Code 中進行轉(zhuǎn)換后 Unicode BiDi 的樣子：

有些同形文字很難與合法字符區(qū)分開來。這是在 Visual Studio Code 中進行轉(zhuǎn)換后這些字符的顯示方式：

Visual Studio、Notepad 和 Sublime Text 實際上不受 BiDi 字符的影響，因為該行要么被破壞，要么整行顯示為注釋：

方法二：過濾字符

Menashe 認為木馬源攻擊方法的威脅 “在現(xiàn)實世界中影響有限”，因為常規(guī)源代碼通常不包含研究人員列舉的特殊 Unicode 字符（BiDi 和同形文字）。它們 “很容易被檢測到、發(fā)出警報，甚至可能會自動過濾掉”。

下面的 Linux 命令可以警告或刪除單個源代碼文件中的所有 Unicode 字符：

Alert:iconv-f utf-8 -t ascii input.cppStrip:iconv-c -f utf-8-t ascii input.cpp-o filtered_output.cpp

或者，此 Linux 命令將檢查文件列表并標記找到特殊字符的實例：

for file in filelist;do hexdump-C “$file”|grep RTLcharacters;done

以下命令不僅可以發(fā)出警報，還可以僅從單個代碼文件中刪除木馬源攻擊針對的特定字符。

例如以下這兩個 Linux 命令去除了 Unicode BiDi 字符 CVE-2021-42574)：

CHARS=$(python-c'print u"\u202A\u202B\u202D\u202E\u2066\u2067\u2068\u202C\u2069".encode("utf8")')sed's/['"$CHARS"']//g'filtered_output.cpp

對于 Unicode Homoglyph 字符 (CVE-2021-42694)，這兩個命令生成了僅用于剝離西里爾字母同形文字的部分列表：

CHARS=$(python-c'print u"\u0405\u0406\u0408\u0410\u0412\u0415\u0417\u041D\u0420\u0421\u0422\u0425\u0430\u0440\u0441\u0443\u0445\u0455\u04AE\u04BB\u04C0".encode("utf8")')lsed 's/['"$CHARS"']//g'< /tmp/utf8_input.txt>/tmp/ascii_output.txt方法三：更新工具

為編譯器安裝更新，這樣可阻止木馬源攻擊。在應(yīng)用得到更新前，自動檢測和清理文件的命令也可以緩解這些問題。雖然可以在更改文本編輯器設(shè)置后執(zhí)行手動源代碼審核以查找這些特殊字符，但這將是 “處理此問題的最糟糕方法”，Menashe 指出，因為某些字符在某些情況下來自合法的拉丁字符。

“最好的解決方案是運行自動化工具來標記和 / 或刪除這些字符，”Menashe 說道。

在擁有大型代碼庫的組織中，對文件的單獨審計很難大面積開展。Red Hat 發(fā)布了一個簡單的 Python 腳本（ https://access.redhat.com/sec...）來識別整個代碼庫中的潛在問題。該腳本可以集成到持續(xù)集成 / 持續(xù)交付工作流中，或者作為預提交檢查添加，以確保惡意代碼不會進入生產(chǎn)環(huán)境。

Rapid7 的首席安全數(shù)據(jù)科學家 Bob Rudis 還推薦了一個簡單的緩解措施：“如果你只用英語或只用阿拉伯語編寫代碼，則可禁止在代碼庫中使用 BiDi 指令”。

盡管木馬源攻擊的通用漏洞評分高達 9.8，但企業(yè)沒必要驚慌失措。Rudis 認為 9.8 分顯然是 “夸大了”，因為實施木馬源攻擊需要攻擊者直接訪問開發(fā)人員的工作站、源代碼管理系統(tǒng)或持續(xù)集成管道。

“如果攻擊者可以直接訪問你的源代碼管理系統(tǒng)，坦率地說，你可能會遇到比這次攻擊更大的問題?！盧udis 說：“我們建議在擔心需要本地或物理訪問的源代碼級攻擊之前，優(yōu)先考慮真正關(guān)鍵的補丁并防止服務(wù)和系統(tǒng)暴露。”