控制源代碼:濫用源代碼管理系統
有關這項研究的完整詳細信息,請參閱 X-Force Red 白皮書“控制源代碼:濫用源代碼管理系統”。該材料也將在Black Hat USA 2022上展示。
源代碼管理 (SCM) 系統在組織中發揮著至關重要的作用,與 Active Directory 等其他關鍵企業系統相比,它在防御方面一直是事后考慮的。大多數組織都使用 SCM 系統來管理源代碼并與企業內的其他系統集成,作為 DevOps 管道的一部分,例如 Jenkins 等 CI/CD 系統。這些 SCM 系統為攻擊者提供了軟件供應鏈攻擊的機會,并且可以促進整個組織的橫向移動和權限升級。
這篇博文將回顧 SCM 系統的背景,并詳細介紹濫用一些最流行的 SCM 系統(包括 GitHub Enterprise、GitLab Enterprise 和 Bitbucket)來執行各種攻擊場景的方法。這些攻擊場景包括偵察、用戶角色操縱、存儲庫接管、轉向其他 DevOps 系統、用戶模擬和維護持久訪問。X-Force Red 的源代碼管理攻擊工具包 ( SCMKit ) 也將展示執行和促進這些攻擊。此外,還將概述保護這些 SCM 系統的防御性指南。
背景
有許多方法可以與源代碼以及已編譯的源代碼資產進行交互和跟蹤。此過程中使用的一些常用術語是源代碼控制、版本控制和源代碼管理。術語“源代碼控制”和“版本控制”通常可以互換使用。但是,這兩個術語之間存在差異。源代碼控制專門用于跟蹤源代碼的更改,而版本控制還包括跟蹤二進制文件和其他文件類型的更改。這方面的一個例子是版本控制跟蹤對已編譯可執行文件的更改,而源代碼控制將跟蹤對編譯到該可執行文件中的底層 C# 或 C++ 源文件的更改。Git 是流行的源代碼控制工具,Subversion 是流行的版本控制工具。
為了以實用的方式使用源代碼控制作為開發過程的一部分,使用了源代碼管理 (SCM) 系統。這些系統允許跟蹤對源代碼存儲庫的更改,并允許開發人員在同時合并來自多個人的代碼提交時解決沖突。其中一些 SCM 系統比其他系統更受歡迎,并已被企業采用,因為它們以更可靠的方式集成到開發過程中。一些流行的 SCM 系統包括GitHub Enterprise、GitLab Enterprise 和Bitbucket。由于這些 SCM 系統的作用和重要性,它們可能被濫用以促進軟件供應鏈攻擊和組織內的橫向移動。
SCM 系統和 DevOps 管道
SCM 系統在 DevOps 管道中項目的“構建”階段被大量使用,如下圖所示。所有其他階段都取決于在 SCM 系統中開發和維護的源代碼。一旦源代碼項目準備好編譯和構建,它將被推送到持續集成 (CI) 服務器。之后,將對其進行測試、掃描和部署以用于生產。
DevOps 流水線圖
軟件供應鏈攻擊
最近流行的一種攻擊是軟件供應鏈攻擊。在這種攻擊中,攻擊者在其中一個階段將自己注入到開發過程中,以將惡意代碼部署到生產中。這通常在“構建”階段執行。對于向其他組織提供軟件的組織,這可能會導致多個組織的妥協。最著名的軟件供應鏈攻擊之一是SolarWinds 漏洞,它影響了私營和公共部門的許多組織。
下圖顯示了攻擊者在開發過程中實施軟件供應鏈攻擊的機會。這項研究側重于“B”和“C”的突出領域,因為它與 SCM 系統的妥協有關。但是,這些 SCM 系統的入侵也可能導致其他情況,例如“D”,攻擊者可以使用 SCM 系統破壞構建平臺系統。
軟件供應鏈攻擊機會圖
橫向移動到其他 DevOps 系統
SCM 系統可用作其他 DevOps 系統的初始訪問點,這些系統在 DevOps 生命周期的不同階段使用。能夠轉向構建系統以破壞 CI/CD 平臺或轉向包存儲庫系統以破壞分發平臺是攻擊者可以執行軟件供應鏈攻擊的其他場景。白皮書中顯示了這方面的兩個詳細示例。
攻擊場景
以下攻擊場景對于攻擊者嘗試攻擊 GitHub Enterprise、GitLab Enterprise 和 Bitbucket 是值得注意的。這些作為 X-Force Red 對抗模擬活動的一部分非常有用。這并不是可在這些 SCM 系統上執行的每條攻擊路徑的詳盡列表。下表列出了白皮書中詳述的攻擊場景。其中一些場景將在后續章節中展示。


單片機攻擊場景表
存儲庫接管
使用管理權限(特別是站點管理員角色),攻擊者可以授予自己對 GitHub Enterprise 內任何存儲庫的寫入權限。在下面的示例中,我們嘗試在 GitHub Enterprise 中查看我們的受感染管理用戶 ( adumbledore) 無權訪問的存儲庫。
查看鎖定的存儲庫
使用站點管理員角色,您可以選擇通過如下所示的“解鎖”按鈕解鎖存儲庫。默認情況下,這將為用戶解鎖存儲庫兩個小時。
查看屏幕以解鎖存儲庫
您必須提供解鎖存儲庫的原因,并且該原因與請求一起記錄。
添加解鎖存儲庫的原因
現在您可以看到我們已經成功解鎖了存儲庫,并且為adumbledore用戶帳戶解鎖了兩個小時。然后可以訪問或修改此存儲庫中的代碼。
顯示存儲庫已解鎖
用戶模擬
如果攻擊者擁有對 GitLab Enterprise 或 GitHub Enterprise 的管理訪問權限并且想要冒充另一個用戶,那么他們有兩種選擇。第一個選項是通過 Web 界面模擬用戶登錄,第二個選項是創建模擬令牌。這將在 GitLab Enterprise 中專門顯示。
模擬用戶登錄
通過 GitLab Enterprise 的管理區域查看用戶時,右上角有一個標記為“模擬”的按鈕。
在 hpotter 配置文件中模擬用戶按鈕
單擊“模擬”按鈕后,您將以要模擬的用戶身份登錄。在本例中,我們模擬了 hpotter 用戶帳戶。
顯示假冒 hpotter
模擬令牌
對 GitLab Enterprise 具有管理員訪問權限的攻擊者還可以通過創建模擬令牌來模擬另一個用戶。這可以通過 Web 界面或用戶 REST API執行。以管理員身份使用 Web 界面,您可以導航到要模擬的用戶帳戶的“模擬令牌”部分;添加令牌的詳細信息,包括名稱、到期日期和權限范圍。
創建模擬令牌
創建模擬令牌后,將列出令牌值以供使用。被模擬的用戶在以自己的身份訪問 GitLab Enterprise 時看不到此模擬令牌;它僅對其他管理員用戶可見。
顯示創建的模擬令牌
攻擊者還可以通過用戶 REST API 創建模擬令牌,如下面的 curl 命令示例所示。
curl -k --request POST --header "PRIVATE-TOKEN: apiToken" --data "name=someName-impersonate" --data "expires_at=" --data "scopes[]=api" --data "scopes[]=read_user" --data "scopes[]=read_repository" --data "scopes[]=write_repository" --data "scopes[]=sudo" "https://gitlabHost/api/v4/users/userIDNumberToImpersonate/impersonation_tokens"
通過 API 創建模擬令牌后的輸出
修改 CI/CD 管道
在 Bitbucket 中,有一個名為Bamboo的功能可以安裝和配置以促進 CI/CD 管道。如果存儲庫正在使用帶有 Bamboo 的 CI/CD 管道,它將在存儲庫的根目錄中包含一個名為“bamboo-specs”的目錄,以及一個 Bamboo 配置文件。此配置文件可以是YAML文件 (bamboo.yaml) 或Java規范文件 (pom.xml)。如果攻擊者想通過 Bamboo 發現任何配置了 CI/CD 管道的存儲庫,他們可以在 Web 界面或 REST API 中搜索“bamboo-specs”。
通過 Bamboo 發現具有 CI/CD 集成的存儲庫
如果您對存儲庫具有寫入權限或管理員權限,則可以修改 Bamboo 配置文件。在這種情況下,我們正在修改bamboo.yaml 文件以將我們的SSH 密鑰添加到運行Bamboo 代理的服務器。這也可以通過 Git 命令行工具執行,以將更改提交到 Bamboo 配置文件。
修改 Bamboo yaml 文件
這將立即觸發 CI/CD 管道運行,如下所示。
顯示成功的作業狀態
查看管道的輸出時,我們可以看到添加了 SSH 密鑰,并打印了添加 SSH 密鑰的服務器的主機名。此時,我們將能夠通過我們的 SSH 密鑰向該服務器執行橫向移動。
查看管道日志
保持持久訪問
在維護對 SCM 系統的持久訪問方面,攻擊者有三個主要選擇。這可以通過創建個人訪問令牌、模擬令牌或添加公共 SSH 密鑰來執行。白皮書中詳細介紹了所有這些選項。
將顯示的持久性選項是在 GitLab Enterprise 中創建個人訪問令牌。這可以作為普通用戶通過 Web 界面執行,也可以作為管理員通過用戶 REST API執行。下面的屏幕截圖顯示了創建一個名為“persistence-token”的個人訪問令牌。
為 hpotter 用戶創建個人訪問令牌
您可以在下面看到創建的個人訪問令牌和令牌值。
顯示創建的令牌值
攻擊者還可以通過用戶 REST API 創建個人訪問令牌,如下面的 curl 命令示例所示。在 GitLab Enterprise 中,這需要管理員權限。
curl -k --request POST --header "PRIVATE-TOKEN: apiToken" --data "name=hgranger-persistence-token" --data "expires_at=" --data "scopes[]=api" --data "scopes[]=read_repository" --data "scopes[]=write_repository" "https://gitlabHost/api/v4/users/UserIDNumber/personal_access_tokens"
通過 API 創建訪問令牌
單片機套件
背景
在 X-Force Red,我們希望利用參與期間最常見的 SCM 系統中可用的 REST API 功能,并在名為SCMKit的概念驗證工具中添加最有用的功能。該工具的目標是提供對 SCM 系統濫用的認識,并鼓勵檢測針對 SCM 系統的攻擊技術。SCMKit 將在Black Hat USA 2022 阿森納展出。
SCMKit 允許用戶指定要使用的 SCM 系統和攻擊模塊,以及指定相應 SCM 系統的有效憑據(用戶名/密碼或 API 密鑰)。目前,SCMKit 支持的 SCM 系統有 GitHub Enterprise、GitLab Enterprise 和 Bitbucket Server。支持的攻擊模塊包括偵察、權限提升和持久性。非公開版本的 SCMKit 中可用的其他功能未包含在防御者的考慮范圍內,例如用戶模擬和內置憑證搜索。SCMKit 采用模塊化方法構建,因此信息安全社區將來可以添加新的模塊和 SCM 系統。X-Force Red GitHub 上提供了該工具和完整文檔. 下一節將展示一些示例。
偵察
SCMKit 有多個模塊可用于執行特定于各種 SCM 系統(如GitLab Runners )的存儲庫、文件、代碼和其他資源的偵察。下面的例子展示了在 SCMKit 中使用“codesearch”模塊。在這種情況下,我們在 Bitbucket Server 中搜索包含“API_KEY”的任何代碼,以嘗試在源代碼中發現 API 密鑰。
使用 SCMKit 的 API 密鑰的代碼搜索示例
還有其他幾個僅適用于某些 SCM 系統的偵察模塊。例如,有一個偵察模塊可以發現您可以通過“runnerlist”模塊訪問的 GitLab Runners。
帶有 SCMKit 的 GitLab Runner 偵察示例
權限提升
SCMKit 中的另一個可用功能是將另一個普通用戶添加到管理員角色。下面的示例顯示了通過“addadmin”模塊將我們控制下的普通用戶(在本例中為 hgranter)添加到 GitHub Enterprise 中的站點管理員角色。
通過 SCMKit 添加站點管理示例
通過 SCMKit 執行站點管理員添加后,您可以看到在 GitHub Enterprise 中生效的更改,因為 hgranter 用戶現在是站點管理員組的成員。
顯示 hgranter 添加為站點管理員
持久性
SCMKit 中有兩個持久性模塊,包括使用個人訪問令牌或 SSH 密鑰。這對于保持對 SCM 系統的訪問很有用。下面的示例顯示了通過“createsshkey”模塊為 Bitbucket 中的 hgranter 用戶帳戶創建 SSH 密鑰。
使用 SCMKit 創建 SSH 密鑰示例
我們可以通過“listsshkey”模塊列出給定用戶的所有活動 SSH 密鑰,如下所示。您將看到我們為 hgranter 用戶添加的 SSH 密鑰。
使用 SCMKit 列出 SSH 密鑰示例
防御考慮
單片機套件
有多個靜態簽名可用于檢測 SCMKit 的使用情況。這些可以在 SCMKit 存儲庫的 Yara 規則中找到。
嘗試 SCMKit 中的每個模塊時使用靜態用戶代理字符串。用戶代理字符串是“SCMKIT-5dc493ada400c79dd318abbe770dac7c”。SCMKit 存儲庫中提供了 Snort 規則。
此外,使用 SCMKit 在 SCM 系統中創建的任何訪問令牌或 SSH 密鑰都將在名稱中添加“SCMKit-”。這可以在相應的 SCM 系統中進行過濾,以指示訪問令牌或 SSH 密鑰是使用 SCMKit 創建的。
單片機系統
確保將以下日志發送到您的 SIEM。這還列出了每個 SCM 系統在服務器上的日志位置。






各種攻擊類型的搜索查詢表 – Bitbucket Server
此外,在配置這些 SCM 系統時,應考慮以下事項:
- 禁用用戶模擬
- 不允許用戶創建沒有過期日期的個人訪問令牌或 SSH 密鑰
- 為創建/添加的所有個人訪問令牌和 SSH 密鑰設置自動到期日期
- 限制管理用戶的數量。至少應該有兩個,除非必要,否則不應更多
- 在訪問存儲庫方面執行最低權限策略
- 需要通過 GPG 密鑰或 S/MIME 證書進行簽名提交
- 啟用多因素身份驗證
- 確保及時刪除代碼分支
- 每個代碼提交至少需要一個批準者
- 在適用的情況下提高日志記錄級別以檢測偵察
結論
源代碼管理系統包含組織中一些最敏感的信息,并且是 DevOps 生命周期中的關鍵組件。根據組織的角色,這些系統的入侵可能會導致其他組織的入侵。這些系統對攻擊者來說具有很高的價值,并且需要信息安全社區的更多可見性,因為與 Active Directory 等其他系統相比,它們目前是事后才想到的。X-Force Red 的目標是,這項研究將引起更多關注并激發未來對保護這些關鍵企業系統的研究。