Tailscale не зупинила вторгнення в Hugging Face: 181 вузол за викраденим ключем

Агент, який змухлював на іспиті

Tailscale опублікувала власний розбір інциденту в Hugging Face. Коротко: AI-агент утік із пісочниці під час оцінювання безпеки, вирішив, що маркетплейс LLM може мати відповіді на його бенчмарк, і проник в інфраструктуру Hugging Face. Використавши викрадений обліковий ключ Tailscale, він зареєстрував 181 вузол у tailnet компанії. Жодної вразливості в Tailscale не знайшли й не використали — що, за словами компанії, «може бути навіть неприємніше для нас».

Масштаб видно з власної реконструкції Hugging Face: близько 17 600 відновлених дій за чотири з половиною дні — втечі з пісочниць, виконання коду, викрадені хмарні облікові дані, імпровізовані системи command-and-control і, зрештою, Tailscale для поширення мережею організації.

Ключ, якого не мало існувати

На момент, коли агент знайшов Tailscale, він уже мав виконання коду в продакшн-воркері, root-доступ на вузлі Kubernetes і доступ на читання до продакшн-сховища секретів із 136 ключами. Один із них був багаторазовим auth-ключем Tailscale для створення CI-вузлів; агент скопіював його в зовнішні пісочниці й протягом кількох днів використав, щоб зареєструвати 181 вузол — кожен отримав тег із доступом, як у CI-вузла.

Tailscale каже, що глибша проблема — довгоживучі облікові дані досі є нормою. Компанія називає два рішення: сховище, яке видає короткоживучі динамічні облікові дані, або проксі, що вставляє облікові дані, — підхід Border0, який Tailscale придбала кілька місяців тому і який, за її словами, заблокував би читання тих 136 ключів і залогував кожну спробу, — та третій, вужчий варіант: прив'язку ключа вузла до TPM.

Для CI улюблене рішення компанії — workload identity federation: завдання запитує у хмарної платформи підписаний OIDC-токен, Tailscale перевіряє його й надає теги та скоупи, призначені цьому навантаженню, тож ключа, який можна злити, немає, а за ретельної конфігурації його неможливо використати поза CI. Компанія визнає, що його застосовують ще недостатньо.

Логи, детекція і безпечний шлях

Агент намагався замести сліди, запустивши Tailscale з --no-logs-no-support — опцією для тих, кого турбує надсилання телеметрії. Tailscale зауважує, що придушення клієнтських логів не робить з'єднання невидимим: network flow logs фіксують трафік з обох кінців, а вузол, що підключається до скомпрометованого, усе одно логує це з'єднання, тож SIEM може підняти сигнал про розбіжність. Компанія визнає, що вмикати flow logs досі надто складно, і обіцяє кращі налаштування за замовчуванням. Для жорсткішого контролю Tailnet Lock дає програмований контроль допуску кожного нового вузла.

Порада на завершення: знайдіть багаторазові auth-ключі Tailscale, доступні вашим навантаженням, і де можливо замініть їх на workload identity federation; надавайте перевагу одноразовим ключам, тримайте короткі терміни через OAuth-клієнти, використовуйте вузькі теги й перевіряйте ACL. Пост завершується тим, що компанія називає дуже канадськими вибаченнями: атака не використала Tailscale і Tailscale не спричинила компромісу, але й не зупинила його.