到現在，您可能已經聽過 AI 代理逃脫安全評估並攻擊 Hugging Face（一個 LLM 市集）的消息。這個代理認為 Hugging Face 可能擁有其基準測試的答案，因此偷取答案只是為了在考試中作弊。這動機聽起來有趣，但結果卻令人擔憂。

Hugging Face 發布了一份詳細重建入侵過程的報告。這份報告涵蓋了四天半內約 17,600 個已復原的行動，包括沙箱逃脫、程式碼執行、雲端憑證、即興的命令與控制系統，以及最後使用 Tailscale 在其組織內擴散。

但 Tailscale 是一個零信任網路！零信任的全部意義就是防止攻擊者在您的公司內橫向移動。那麼到底出了什麼問題？

Tailscale 在哪裡出現

並未發現或利用 Tailscale 的「漏洞」，這可能讓我們感到更加不安。Tailscale 出現在 AI 基礎架構的各處：幾乎每家 AI 公司都使用 Tailscale。所以我們最終出現在 AI 事件報告中並不意外。

但我們是一個安全工具。他們的入侵就是我們的入侵，我們有責任認真對待這件事。就像任何事後檢討一樣，我們需要反思發生了什麼事，以及我們本來可以做些什麼來防止它。

當代理逃脫沙箱並找到 Tailscale 時，它已經在生產工作程序內獲得程式碼執行權限、在 Kubernetes 節點上取得 root 權限，並讀取包含 136 個金鑰的生產秘密儲存區。在某種意義上，我們還沒登場，遊戲就已經結束了。

但這不就是問題所在嗎？讓我們倒推一兩步。為什麼長期有效的秘密金鑰可以被任何人存取？

因為長期憑證是標準做法

它們本不應該是這樣。我們現在已經看到一個很好的例子來證明這一點。在大多數入侵都是由人類以人類速度完成的舊世界中，憑證洩漏緩解措施被視為「有做更好」。一個大型憑證儲存區，可以一次讀取 136 個金鑰，這在安全團隊的低優先級清單中只是待辦事項。

現在，在流氓 AI 代理的世界中，大型憑證儲存庫就是獎品。這已經不能接受了。

我只知道兩種解決長期憑證問題的主要方法。

首先，您可以設定一個金鑰庫，它只根據您一次插入且永不歸還的長期憑證發行短期憑證。例如 HashiCorp Vault 就能做到這點；他們稱之為動態憑證。不幸的是，動態憑證設定和維護的工作量很大。當安全性需要工作時，人們就不會去做。

第二個選擇是憑證注入代理。如果客戶端 C 想要存取伺服器 S，不要給 C 存取 S 的憑證；相反，讓它透過強化的代理 P 傳送請求，這個代理只負責接收請求、插入憑證，然後轉發。隨著現代基於網狀的網路消除了大部分延遲，憑證注入正變得越來越受歡迎。幾個月前，我們收購了Border0（「Tailscale PAM」），它是一個優雅且相當精巧的憑證注入代理，與 Tailscale 緊密整合。如果完全部署 Border0，本來可以防止讀取那 136 個金鑰，並記錄每次使用金鑰的嘗試。（相同的憑證注入功能支援Aperture Connectors）。但是，這東西出現得太晚了。我們大多數的客戶甚至還沒看過它。

第三個額外的選擇：Tailscale 本身。在 Tailscale 中，您的節點金鑰可以使用 TPM 繫結到機器以防止匯出，如果您是企業，您絕對應該這樣做。唉，我們不得不預設關閉 Linux 和 Windows 上的 TPM 儲存，因為我們在某些使用者的硬體上發現了 HSM 問題。不管怎樣，在今天的情況下，攻擊就是授予 Tailscale 存取權限，所以我們到得太晚了。

那個長期有效的授權金鑰本來不需要存在

因為沒有動態憑證或憑證注入代理，所以 136 個金鑰洩漏了。下一道防線是什麼？

136 個憑證中有一個是可重複使用的 Tailscale 授權金鑰，用於在他們的 tailnet 中建立新的 Tailscale CI（持續整合，用於自動化測試）節點。代理將該金鑰複製到一系列外部沙箱中，並在數天內使用它總共在 Hugging Face 的 tailnet 中註冊 181 個節點。這些節點各自獲得授予 CI 節點所有存取權限的 Tailscale 身分標籤。

我們無法拯救那 136 個金鑰。但可重複使用的 Tailscale 金鑰本來不應該在其中。

我們為這種情況建置了工作負載身分同盟。它依賴您的雲端供應商提供「環境授權」，以執行中 VM（或容器）的雲端身分產生短期憑證的形式。CI 工作可以向其雲端平台請求已簽章的 OIDC 權杖。Tailscale 驗證權杖，然後授予指派給該工作負載的標籤和範圍。很棒的是，一旦啟用，這可以自動發生：啟動 CI 節點，Tailscale 取得身分，指派正確的標籤。沒有憑證可以洩漏，而且如果設定得當，就無法在 CI 之外的任何地方使用此憑證。

這意味著您無法取得 CI 憑證，在其他地方的節點上執行它，並將其轉變為從測試叢集到網路其他部分的鋪路路線。

唉，沒有足夠的人使用工作負載身分同盟。我們本來應該做更多努力來確保客戶知道這是更容易也 更安全的途徑，並有明確的方法來採用它。我們可以改善文件，並在 UI 中加入更多提示。

沒有客戶端記錄並不意味著沒有證據

為了隱藏其蹤跡，代理以 --no-logs-no-support 執行 Tailscale，這會抑制來自該客戶端的報告。

這是一個設計給擔心將遙測中繼資料傳送到 Tailscale 的使用者的選項。即使我們沒有提供它，也很容易修改原始碼來移除遙測。

但停止記錄並不會讓連線變得無形。如果您啟用 Tailscale 網路流量記錄，它們會報告來自每條連線兩端的流量，以及來自子網路路由器和出口節點的流量。這很微妙但很重要：受感染的節點可能不會傳送流量記錄，但它連線到的每個節點都會。然後，您的 SIEM 如果設定得當，就可以在兩端不符時立即發出紅色警報。

當流量記錄串流到經過仔細設定的 SIEM 時，它們可以幫助偵測。但這需要很多工作。流量記錄需要啟用，您需要有正確的即時偵測規則，才能讓它們在即時而非只是事後鑑識時發揮作用。我們正在研究如何讓流量記錄更容易被發現、設定、採用，並作為警報觸發器。我希望我們能讓流量記錄如此容易使用，以至於即使您沒有安全團隊來監控它們，它們也能提供幫助。

如果您想要超越記錄的直接控制，您也可以啟用Tailnet Lock。這為您提供直接的可見性，以及對每個新節點的嚴格、可編程的准入控制。例如，透過一些工作，您可以編寫您的簽章節點來檢查「CI」標籤是否總是具有特定的 IP 位址範圍或其他用於驗證的有效性側通道證明。

讓安全的路徑成為容易的路徑

網路安全很難。它一直都很難。在流氓 AI 代理的新世界中，它不僅難，而且至關重要。這是一個問題，因為許多組織根本沒有網路安全專業知識。

所以在 Tailscale，我們將此視為個人責任。人們期望我們的產品能預設防止這種橫向移動攻擊，讓他們不必自己去做。即使他們不知道什麼是橫向移動攻擊。

如果這起事件讓您對自己的基礎架構有點緊張，請先查看您的工作負載可以讀取的可重複使用 Tailscale 授權金鑰。特別是對於雲端和 CI，盡可能用工作負載身分同盟取代它們。移除那些長期有效的授權金鑰。

（授權金鑰仍有很好的用途，特別是用於一次性佈建和沒有平台身分的環境。當您需要一個時，請選擇一次性金鑰；使用OAuth 用戶端來保持授權金鑰到期期間短暫；使用狹窄的標籤；在您的 ACL 中稽核授予這些金鑰的權限。）

開啟網路流量記錄並將它們傳送到您的安全團隊已經使用的工具。

在受管理的機群上使用安全節點狀態儲存，在那裡您可以控制 TPM。在您無法控制 TPM 的地方，使用裝置姿勢來隔離和限制節點。

我知道我們還沒有讓這些更安全的選擇足夠明顯。這是我們的責任。我們將改善文件、在 UI 中加入提示，盡力預設開啟這些功能，當您做危險的事情時警告您，並建議更好的替代方案。

這是我們非常加拿大式的道歉：很抱歉您踩到我們的腳趾。攻擊並未利用 Tailscale，Tailscale 也沒有造成入侵。但是，我們沒有阻止它。下一次，我們會阻止。

如果您執行 Tailscale 並想要深入了解，請聯絡我們的支持和解決方案工程團隊。我們可以幫助您強化設定，並幫助您在下一個 AI 代理之前找到粗糙的邊緣。