Windows Container已成為第一個已知的以Windows Container為目標的惡意軟件的受害者。在這次攻擊活動中，惡意軟件團伙穿透Kubernetes集群以植入后門，使得攻擊者可以竊取數據和用戶憑據，甚至劫持集群中托管的整個數據庫。
該惡意軟件是由Unit 42安全研究員Daniel Prizmant發現的。他將其命名為“Siloscape”，發音為“Silo escape”。該惡意軟件會撬開Web服務器和數據庫中的已知漏洞，從而破壞Kubernetes節點和后門集群。
在周一發布的一篇文章中，Prizmant寫道，Siloscape是通過Windows Container攻擊Kubernetes集群的惡意軟件，其主要目的是打開“后門進入配置不當的Kubernetes集群以運行惡意container”。
在較受歡迎的容器的中脫穎而出
在另一篇文章中，Unit 42研究人員Ariel Zelivansky和Matthew Chiodi將容器與貨船上用于打包不同材料的集裝箱進行了比較。云容器具有類似的功能，因為它們可以將不同的材料打包在一起以提高效率，從而使開發團隊能夠快速移動并“以幾乎任何規模”運行。
以這種方式在容器中運行應用程序被稱為容器化，并且與其他遠程工作方式一樣，由于COVID-19的流行，它得到了大力發展。研究人員指出：“近年來，我們看到越來越多的組織在云中使用容器，尤其是因為COVID-19大流行導致許多組織在尋求一種更快地移動和更有效地部署云工作payload的方式。”
第一個針對Windows Container的惡意軟件
根據Zelivansky和Chiodi的說法，這是研究人員第一次看到針對Windows Container的惡意軟件。他們說，云環境中的Linux操作系統已經非常流行。
Unit 42研究人員已經確定了23名Siloscape受害者，并表示有證據表明該活動已于一年多前發起。
Prizmant通過收集服務器的創建日期來確定該活動的開始日期，大約在2020年1月12日。但他也指出，這并不一定意味著Siloscape是在那個日期創建的，相反，這很可能是惡意軟件活動開始的時候。
經過特別艱難的逆向工程，Prizmant能夠連接到Siloscape命令和控制（C2）服務器，他發現該服務器總共托管了313個用戶。他說，這意味著Siloscape是“更廣泛的活動的一小部分”。
Siloscape如何逃逸
該惡意軟件首先針對常見云應用程序（例如Web服務器）中的已知漏洞（“1-days”）進行攻擊。這種初始訪問可能是通過利用在野外發現的漏洞獲得的。去年，Prizmant記錄了一種打破Windows Container邊界的方法。在2020年發表的一份報告中，他描述了如果攻擊者從容器中逃離，他們會做什么。
他選擇將重點放在當前的場景上：從Kubernetes中的Windows集群節點逃脫，這將允許攻擊者獲得節點外的訪問權并擴散到集群中。
在入侵Web服務器后，Siloscape使用容器逃逸策略在Kubernetes節點上實現代碼執行。Prizmant說，Siloscape大量使用混淆使得逆向工程變得很麻煩。“整個二進制文件中幾乎沒有可讀的字符串。雖然混淆邏輯本身并不復雜，但它使得反轉這個二進制文件變得非常艱難，”他解釋說。
該惡意軟件會混淆函數和模塊名稱（包括簡單的API），并且僅在運行時對其進行反混淆。他說，Siloscape不是僅僅調用函數，而是“努力使用同一函數的原生API（NTAPI）版本”。“最終結果是惡意軟件很難用靜態分析工具檢測到，并且讓逆向工程也困難重重。”
“Siloscape使用一對唯一的密鑰為每一次新的攻擊進行編譯，”Prizmant繼續說道。“硬編碼的密鑰使每個二進制文件與其他二進制文件略有不同，這也就解釋了為什么我在任何地方都找不到它的哈希值，因此也就無法僅通過哈希來檢測Siloscape。”
Siloscape逃逸后會干什么
在Siloscape破壞節點后，惡意軟件會四處尋找使其能夠傳播到Kubernetes集群中其他節點的憑據。然后，它使用IRC（一種舊協議）通過Tor匿名通信網絡連接到其C2服務器，等待命令。
Prizmant采用了一個他認為在連接到C2服務器時看起來合法的用戶名。成功連接后，他發現它仍在工作，那里有23個“活躍受害者”，以及一個名為admin的頻道操作員。
不幸的是，大約2分鐘后，他被踢出了服務器。兩分鐘后，服務器關閉了——至少，它在onion他曾經連接的原始域中不再處于活動狀態。
但Siloscape惡意軟件只是整個活動的一小部分。C2服務器上的活躍用戶比他在#WindowsKubernetes頻道中看到的要多得多——確切地說，總共有313個用戶。然而，他無法識別、聯系或警告他們中的任何一個。
“可悲的是，當我連接到服務器時，頻道列表是空的，這表明服務器被配置為不顯示其頻道，”Prizmant寫道。“因此，我無法從頻道名稱中獲得更多信息。”
但研究人員確實設法收集到了一個重要的細節，即用于受害者姓名的約定。Unit 42研究人員使用“php_35”，它的Siloscape樣本通過易受攻擊的php實例執行。包含字符串“sqlinj”的其他名稱表明攻擊者可能設法通過SQL注入實現代碼執行。
加密劫持、供應鏈中毒等的危險
Prizmant在2020年7月的帖子中表示，他的研究表明“在[Windows Server Containers]中運行任何代碼，實際上都與在主機上運行admin一樣危險。這些容器不是為沙盒設計的，并且我發現逃離它們很容易。”
他在周一的帖子中警告說，這可能使攻擊者能夠竊取關鍵憑據、機密和內部文件，甚至是集群中托管的整個數據庫。如果攻擊者將組織的文件作為要挾，它甚至可能導致勒索軟件攻擊。他說，更糟糕的是組織大規模遷移到云端所帶來的威脅。他說，鑒于許多人正在使用Kubernetes集群來開發和測試代碼，漏洞“可能導致毀滅性的軟件供應鏈攻擊”。
在周一的帖子中，他解釋說，破壞整個集群比破壞單個容器要嚴重得多，因為“一個集群可以運行多個云應用程序，而單個容器通常運行單個云應用程序。”
他還指出，一方面，Siloscape與大多數云惡意軟件不同，后者通常側重于加密挖掘和DoS之類的資源劫持。另一方面，Siloscape“不會將自己局限在任何特定目標上，”Prizmant說。“相反，它為各種惡意活動打開了后門。”
最近的供應鏈與Kubernetes攻擊
與Prizmant警告的相類似，供應鏈攻擊已經與間諜軟件安裝、SignSight操作、Able Desktop的入侵、航空公司的漏洞以及其中最龐大的供應鏈：太陽風（SolarWinds）對美國政府的入侵密切相關。
最近的一些頭條新聞也報道了Kubernetes的其他一些網絡安全事故，包括2021年4月的安全漏洞， Kubernetes所使用的其中一個Go代碼庫中存在漏洞，該漏洞可能會導致CRI-O和Podman容器引擎的拒絕服務攻擊。CRI-O和Podman都是容器引擎，類似于Docker，主要用于在云端執行操作和管理容器。CRI-O和Podman使用“containers/storage”來處理容器鏡像的存儲和下載。四月份早些時候，一場有組織的、自我傳播的cryptomining活動被發現，其目標是配置錯誤的開放Docker Daemon API端口。
研究人員表示，同樣在4月份，微軟的云容器技術Azure Functions被發現存在一個漏洞，該漏洞允許攻擊者直接寫入文件。幾個月前，也就是2021年2月，一種新的惡意軟件正在劫持Kubernetes集群以對Monero進行加密。
云基礎設施需要更高的安全性，另一個可以佐證的例子是，在最近的實驗室測試中，一個簡單的Docker容器蜜罐在24小時內被用于四次不同的犯罪活動。
云原生戰略
企業數據安全公司Comforte AG的產品經理Trevor Morgan認為Siloscape是一種威脅，它會讓企業對采用云計算感到緊張。“企業采用云原生戰略是因為他們希望提高創新能力。不幸的是，大多數組織都在努力確保正確的數據安全級別，以避免損害云原生應用程序架構，”他周一通過電子郵件告訴Threatpost。
“像Siloscape這樣的惡意軟件通過攻擊容器化的核心使這項工作復雜化，并在云原生開發工作方面致使大家產生猶豫。”他指出，“惡意軟件威脅在靈活、謹慎以及安全處理敏感數據之間做出了錯誤的選擇。”
Morgan建議，專門為云原生應用程序構建的以數據為中心的安全性，例如專門為云本地應用程序構建的標記化，通過保護數據本身而不是“圍繞云本地應用程序環境的分層的、甚至是無定形的邊界”，可以“幫助在這兩者之間取得適當的平衡”。
“組織可以放心，數據安全不會妨礙速度和靈活性，因為即使在容器中的標記化敏感信息，如果落入犯罪分子之手也不會受到損害，”他說，“采用云原生策略的組織可以在實現效率的同時確保數據安全。”
應對策略
Prizmant建議用戶遵循Microsoft的建議，不要將Windows容器用作安全功能。微軟建議對依賴容器化作為安全邊界的任何事物嚴格使用Hyper-V容器，他指出：“應假定在Windows Server容器中運行的任何進程都與主機上的admin具有相同的權限，在本例中就是Kubernetes節點。如果您在需要保護的Windows Server容器中運行應用程序，我們建議將這些應用程序移至Hyper-V容器。”
“Siloscape向我們展示了容器安全的重要性，正式因為存在容器逃逸，惡意軟件才給我們造成了如此重大的損害，”他寫道。“組織保持配置良好且安全的云環境以抵御此類威脅至關重要。”
