.png.c9b8f3e9eda461da3c0e9ca5ff8c6888.png)
最近，趨勢科技的研究人員分析了幾種可被濫用來攻擊供應鏈的攻擊載體的概念證明，其中一種便是針對開發者的供應鏈攻擊，該證明重點關注了本地集成開發環境（IDE），考慮當項目或生成被錯誤地“信任”時，通過注入命令執行惡意生成腳本的情況。
在本文中，我們將關注供應鏈的一個特定部分——開發者本身。要找到針對開發者的合適攻擊模型，我們必須首先了解誰是開發者、他們的工作流程和日常工具。我們還將重點放在開發者和他們各自的工具如何被濫用來破壞供應鏈。
誰是“開發者”?按照字面理解，將開發者定義為開發計算機軟件的人。在安全研究人員的理解中，則是寫代碼的人。這包括流行的編程或腳本語言，如Java、JavaScript、TypeScript、Go、Python、C/c++和許多其他語言，包括基礎設施或容器部署定義，如Dockerfile、Kubernetes、Terraform HCL等。僅從這個描述來看，該定義就涵蓋了IT行業的各個部分，包括編寫代碼的每個人、安全研究人員等等。
儘管工作流本身可能因開發者和公司的不同而有所不同，但根據開發者如何使用集成開發者環境(IDE)，它很可能屬於以下類別之一：
1.本地IDE：開發者在自己的設備上本地安裝了IDE。在這種情況下，開發者有兩個選擇：
1.1將代碼拉入或推送到遠程存儲庫，並在本地執行生成和調試；
1.2將更改提交到遠程存儲庫，觸發持續集成/持續交付（CI/CD）事件，並導致質量保證（QA）評估，甚至部署到生產環境中。
2.雲IDE：開發者使用雲服務託管的IDE，如AWS Cloud9、Visual Studio Online、GitHub代碼空間和許多其他當今可用的平台。在這種情況下，開發者設備就像網關一樣工作，通常通過瀏覽器訪問IDE，主要的代碼執行是在雲服務提供者內部的雲IDE的遠程主機中執行的。
由於開發者涵蓋多個職業，一些工作流可能會從列表中排除一些項目。例如，本文的概念證明很可能不會建立一個完整的CI/CD管道。然而，大多數工作流將包括使用IDE進行開發。在這篇文章中，我們將重點放在本地IDE上。
本地IDE的示例當使用本地IDE時，其中一個示例是開發者將代碼拉到本地計算機上。該代碼被進一步編譯為二進制格式，以便執行。對以前的貢獻者編寫的代碼有一種隱含的信任，因為大多數開發者認為代碼庫可能不會被污染，因為它可以按預期工作。這種信任不僅存在於源代碼本身中，還存在於生成腳本、庫、依賴項和其他項目文件中。這就引出了第一個攻擊場景：將惡意操作注入到項目文件或生成腳本中。
作為開發者，在執行遠程代碼之前，是否有必要在拉入遠程代碼之後閱讀生成腳本？
研究人員通過向生成腳本或項目文件注入惡意生成命令(如果適用的話)來測試各種流行的IDE和編程語言。以下是測試的IDE版本的結果：
Eclipse2022-09ApacheNetBeans16PyCharm2022.2.4IntelliJIDEA2022.03VisualStudio2022VisualStudioCode1.73.1當我們考慮通用攻擊模型時，還必須包括每個非受控輸入。這包括源代碼及其文件，並包括生成前和生成後腳本和IDE擴展(如果適用的話)。我們之前在2020年的一篇文章中寫過可能存在惡意IDE擴展的危險。
IDE攻擊模型
我們為每個IDE定義了以下場景，以驗證可能的攻擊模型：
開發者在線從不受信任的存儲庫中拉入代碼；
開發者在IDE中打開一個項目；
開發者試圖編譯或生成項目；
使用Visual Studio代碼從Visual Studio Code 1.57版(2021年5月發布)開始，代碼編輯器引入了Workspace Trust的概念。此功能通過防止代碼從不受信任的文件和存儲庫執行，幫助開發者安全地瀏覽和編輯代碼，而不考慮源代碼或作者。這可能是由於當時第三方擴展漏洞的數量不斷增加，當被濫用時，在打開不受信任的文件時，可能會允許遠程代碼執行（RCE）。這個概念很簡單：除非工作區是可信的，否則它不允許任何（生成/調試）任務或某些擴展功能運行。這就可以將責任轉移到開發者身上，並提示他們是否要信任下載的代碼。
這裡要強調的是，不要盲目地信任每一個工作區。
Visual Studio代碼工作區信任對話框
開發者應該尋找和考慮哪些代碼不應該被信任的可疑跡象？在其他示例中，應該引起開發者警惕的跡象包括：
較低的下載量；
論壇上共享的項目；
灰色區域；
一般未經證實的來源；
未知的人；
在執行IDE任務之前，應通過審計項目目錄中的文件以查找可疑或惡意命令來驗證.vscode/tasks.json文件，尤其是從未知源下載時。
惡意生成任務的示例
惡意命令可以隱藏在tasks.json文件下並偽裝成生成命令。當開發者試圖生成之前盲目信任的項目時，開發者設備將執行遠程代碼，這可能是惡意的。攻擊者還可以通過在常規生成命令之間隱藏惡意命令，使有效負載更為隱蔽，這將減少開發者的懷疑。
在模擬中，我們通過Pastebin在遠程服務器上放置了一個腳本。這是一種被一些攻擊者濫用的方法，將其惡意有效載荷發送到受感染的設備中。這項技術對攻擊者的好處是可以遠程更改有效載荷。例如，在成功感染後，可以將有效負載更改為無害的內容。
使用Visual StudioVisual Studio是Microsoft用於.NET和C++開發的專有IDE，它沒有工作區信任功能。因此，開發者在加載不受信任的項目文件和執行生成時應該格外小心。惡意的生成前或生成後任務可能會被注入到文件中，從而導致從生成開始就執行不必要的執行。
Visual Studio項目文件預生成任務命令示例
嵌入預生成PowerShell執行的概念驗證示例
使用其他IDE在Eclipse IDE中，仍然可以注入生成命令。因此，文件是不同的。首先，ExternalToolBuilder的生成命令必須在.project文件中指定，參考在. externaltoolbuilders文件夾中定義實際執行命令的另一個文件。通過將多個生成命令鏈接在一起，我們可以實現與Visual Studio Code中相同的多個命令執行。
.project文件節鏈接生成執行規範的示例
生成事件外部命令規範
由於使用外部生成工具的項目文件注入適用於基本IDE的範圍，因此它僅適用於實際代碼編譯為二進製文件的語言。這包括Java和C/c++，但不包括像PHP這樣的語言，因為不執行生成。
NetBeans IDE主要用於Java開發，儘管它還通過第三方擴展支持PHP、HTML5、JavaScript或C/C++開發。 Java開發項目可以利用Maven、Gradle或Ant作為其依賴關係管理和生成自動化工具。因此，項目和生成定義可能不同。然而，所有這些工具都支持將第三方流程作為生成前或生成後操作來執行。在這種情況下，攻擊者可以注入惡意代碼，並希望開發者不會注意到並不情願地執行。
對於Ant，注入可以在nbproject/build-impl.xml文件中完成，方法是將以下代碼片段添加到一個合適的目標標記中：
Ant的注入點和触發生成時的命令執行示例
當開發者使用Maven作為生成工具時，可以通過更改項目文件夾中的pom.xml來實現相同的目標。這一次，在生成標記中使用了org.codehaus.mojo插件。所使用的語法類似於Ant所使用的語法。
Maven第三方執行示例
對於Gradle，Groovy語言腳本用於位於app/build.gradle內部的生成定義，並且對所選任務內的字符串調用execute()函數將觸發代碼執行。
Gradle第三方執行示例
儘管“打開項目”對話框有一個“信任項目生成腳本”選項，但其功能僅對Gradle項目有效。如果未選中，它將阻止Gradle腳本啟動，因此，當加載項目作為CVE-2020-11986修復時，代碼執行是可能的。儘管如此，當用戶決定手動執行生成時，不會顯示進一步的對話框，並且生成被認為是可信的。
NetBeans中的“信任項目生成腳本”複選框
IntelliJ IDEA是另一個用於Java、Kotlin、Groovy和其他基於Java虛擬機(JVM)的語言開發的IDE。它還支持Ant生成腳本。加載包含Ant生成腳本的項目會觸發一個對話框警告，提示它可能會執行潛在的惡意代碼，如果它不是來自可信的源，建議使用安全模式。當開發者試圖在安全模式下執行生成時，IDE會警告用戶該操作只能在可信模式下完成。
IntelliJ IDEA顯示潛在惡意生成腳本的警告
IntelliJ IDEA生成安全模式生成警告
PyCharm是用於Python開發的IDE。 Python腳本通常不會在執行之前編譯。然而，開發者仍然可以指定自定義運行/調試配置，允許在實際腳本執行之前執行第三方二進製文件。這可能用於腳本數據輸入準備。
運行執行前的外部工具
該操作在項目內部被參考。但是，實際的可執行規範存儲在不同的位置，更具體地說，存儲在~/.config/JetBrains/PyCharmXXXX/tools/External Tools.xml。正如我們所看到的，該文件存儲在用戶主目錄中，保護它不受攻擊模型場景的影響，因為它需要修改本地文件系統。
運行前任務參考
運行前任務定義
總結研究人員使用執行惡意生成腳本的攻擊場景評估了所有已識別的IDE，向這些生成腳本中註入惡意命令是可能的。如上所述，一些IDE明確警告開發者惡意操作的可能性，除非項目配置將其標記為明確可信，否則不允許執行任務。另一方面，一些IDE使用這樣的假設，即當開發者打開一個項目或將其複製到他的工作區時，它會自動被信任，並且不需要任何進一步的操作。
無論我們使用什麼IDE，總會權衡安全性和可用性。開發者不應該盲目地相信互聯網上的每一個開源項目。在執行任何生成操作之前，開發者至少應該知道他們有可能成為目標並審查生成腳本。
我們還想強調，上述攻擊場景不僅限於本地IDE，而且安全重要性在於所使用的工作流和工作區信任本身，無論開發者在容器或支持在線IDE的VM中執行實際生成/編譯的情況如何。一旦工作區被標記為可信，並且生成腳本被修改，它可能會在環境中觸發不需要的代碼執行，並導致IDE具有訪問權限。以下是開發者可以記住的一些最佳安全實踐：
使用安全配置的CI/CD平台，在具有適當的基於角色的訪問控制（RBAC）的外部設備或服務上執行生成，只有授權人員才能更改生成腳本；
在集成到項目之前，檢查外部源代碼和生成腳本；
避免在審計之前盲目使用開箱即用的解決方案，特別是當這些解決方案在社區中沒有廣泛使用或來自未經核實的來源時；
定期跟踪變更並進行審查。