Jenkins CI / CD 解決方案為開發人員提供了一種創建自動化、可擴展和高度可配置的管道的方法，以確保代碼庫保持最新，并且可以毫不費力地推出。當開發人員向任何代碼推送新的提交時， Jenkins 都可以接受這些更改，并運行一系列測試和構建，然后通過一條無縫管道將其交付生產。
詹金斯在全球擁有超過 30 萬臺裝置，并在穩步增長。任何一家擁有軟件開發團隊的公司都可能有一個或多個 Jenkins 的實例與之交互。
由于這種普遍性， Jenkins 經常成為威脅行為者的目標，特別是暗示這些管道包含秘密和公司最密切的軟件來源。
GroovyWaiter 是一個簡單的 Python 腳本，它將獲取一個 URL 文件，對于每個 URL ，它將嘗試枚舉對 Jenkins 腳本控制臺的未經驗證的訪問（下面將進一步解釋）。如果它能夠訪問 Console ，如果 Jenkins 服務器運行的是 Linux ，它將執行id命令；如果服務器運行的 Windows ，則執行whoami.exe命令。
腳本將在掃描時顯示找到的主機（圖 1 ）。掃描完成后，它將顯示表中運行的命令的輸出（圖 2 ）。
您可以修改此腳本，使其運行比上面提到的命令更多的命令。您甚至可以將存儲在服務器上的所有秘密轉儲，以獲得一個包含密碼、密鑰和其他物品的表。
詹金斯的歷史和威脅景觀
Jenkins 允許將“秘密”注入到自動化 CI / CD 構建中。這意味著開發人員可以將密碼、 SSH 密鑰等安全地插入到構建中，而不是對它們進行硬編碼。然而，這些秘密存儲在 Jenkins 服務器本身上。
多年來，出于多種原因，威脅行為者一直以 Jenkins 服務器為目標。這些是勒索軟件以及供應鏈注入（針對更高級的參與者）的主要候選。更常見的情況是，這些服務器之所以成為目標，是因為它們可能保存數據。
Jenkins 服務器的開發
與任何產品一樣，每年都會有很多 Jenkins common vulnerabilities and exposures (CVEs) 報告。這些漏洞包含從反映的跨站點腳本漏洞到完整的遠程代碼執行漏洞。這篇文章關注的是紅色團隊如何通過使用 Jenkins 自身的功能來濫用 Jenkins 服務器。
Groovy 腳本和 Jenkins
Jenkins 的特點是能夠在通過 Jenkins 服務器訪問的控制臺內 任意執行 Groovy scripts 。腳本控制臺始終在 Jenkins 的/script端點上可用。
在大多數情況下，這是在 Jenkins 身份驗證（基本的服務器端身份驗證、 LDAP 或任何其他身份驗證解決方案）之后實現的。它只對在 Jenkins 服務器上具有“總體/讀取”權限的用戶安全。
Jenkins 腳本控制臺訪問（未經驗證）
在某些情況下， Jenkins 部署的訪問控制過于松懈。這導致能夠在不進行身份驗證的情況下訪問 Jenkins 服務器上的任何內容，包括腳本控制臺（圖 3 ）。
圖 3 顯示了/script端點被訪問并呈現腳本控制臺引擎，而無需詢問憑據。此時，攻擊者可以執行多個操作，包括：
- 使用 Groovy 轉儲所有機密
- 執行系統命令以降級、破壞或銷毀運行 Jenkins 的底層服務器上的數據
- 使用 Groovy 函數快速解密以前發現的秘密
顯然，在沒有身份驗證的情況下訪問 Jenkins 腳本控制臺具有重大意義。攻擊者可以在整個網絡中橫向移動和/或提升權限，中斷或注入服務器上運行的構建，等等。
上面提供的示例只是一個 Jenkins 服務器，它可能無法保存攻擊者所尋求的秘密。下一節探討攻擊者如何擴展這種類型的攻擊。
Jenkins 服務器的擴展利用
根據網絡或環境的不同，可能會為不同的團隊和辦公室部署數百個 Jenkins 服務器。攻擊者可以手動嘗試這種類型的攻擊，但這將花費大量時間，而眼尖的防御者可能會縮短時間。
看到這種擴展的機會，我開始研究如何獲取主機列表，枚舉對/script端點的訪問，并在規模上進行利用。因此， GroovyWaiter 腳本誕生了。
緩解措施
強烈建議遵循基本訪問控制的適當安全做法。你也應該 適當的保護Jenkins 服務器?。簡單地添加身份驗證和適當的訪問控制，就可以區別于完全網絡攻擊和阻止攻擊者。
?
