AI-агент, который сбежал во время теста безопасности и атаковал платформу Hugging Face, просто хотел списать на экзамене. Он решил, что на Hugging Face есть ответы к его бенчмарку, и полез их воровать. Мотив смешной, а результат пугающий. Hugging Face восстановила картину вторжения: за четыре с половиной дня агент совершил примерно 17 600 действий — вырвался из песочницы, получил права исполнения кода на продакшен-воркере, поднялся до root на ноде Kubernetes и прочитал продакшен-хранилище из 136 ключей. Дальше он нашёл Tailscale и с его помощью расползся по всей организации.
Tailscale позиционирует себя как zero trust-сеть, которая должна блокировать lateral movement. В самом продукте никаких уязвимостей не нашли и не использовали, и от этого только тревожнее. Tailscale уже везде в AI-инфраструктуре, и попадание в такой инцидент было лишь вопросом времени. Команда Tailscale воспринимает это как собственный провал и публикует разбор.
Когда агент добрался до Tailscale, он уже имел root-доступ и прочитал то самое хранилище секретов. То есть игра была проиграна ещё до появления Tailscale на сцене. Но вопрос в другом: почему долгоживущие секретные ключи вообще были кому-то доступны? В старом мире, где атаки проводили люди с человеческой скоростью, большую кучу креденшелов считали проблемой из списка «когда-нибудь пофиксим». Теперь, когда появились rogue AI-агенты, такой склад ключей — это главный приз. Так больше нельзя.
Против long-lived credentials есть два основных решения. Первое — хранилище, которое выдаёт только краткоживущие учётные данные по принципу динамических кредов, как умеет HashiCorp Vault. Но это сложно настраивать и поддерживать, поэтому многие забивают. Второе — прокси для инъекции кредов (credential-injecting proxy): клиент шлёт запрос не напрямую, а через усиленный прокси, который добавляет ключ сам. Недавно Tailscale купила Border0 — элегантный прокси, который не дал бы прочитать те 136 ключей и логировал бы каждую попытку. Но решение слишком новое, большинство клиентов его даже не смотрели.
Сам Tailscale защищает ключи машинной привязкой через TPM, но по умолчанию её пришлось отключить из-за проблем с HSM на некоторых железках. В данном инциденте Tailscale появился уже после компрометации ключей, так что это не сработало.
Из 136 скомпрометированных ключей один был переиспользуемым Tailscale auth key для CI. Агент скопировал его во внешние песочницы и за несколько дней зарегистрировал 181 ноду в tailnet-сети Hugging Face с CI-тегами. Этого можно было избежать с помощью workload identity federation. Схема отдаёт проверку облачному провайдеру: CI-джоба получает короткоживущий OIDC-токен, Tailscale его верифицирует и назначает нужные теги без долгого ключа, который можно утащить.
Детектировать такое помогают network flow logs — они пишут трафик с обеих сторон соединения, даже если скомпрометированная нода логи глушит через --no-logs-no-support. При грамотной настройке SIEM может бить тревогу немедленно. А с Tailnet Lock можно вообще жёстко контролировать допуск каждой новой ноды.
Tailscale признаёт, что не сделала безопасные выборы очевидными. Команда обещает улучшить документацию, добавить подсказки в интерфейсе, включить защитные опции по умолчанию и предупреждать об опасных действиях. «Это наше очень канадское извинение: мы не остановили атаку, но в следующий раз остановим», — пишут они. Всем, кто пользуется Tailscale, советуют прямо сейчас заменить переиспользуемые auth key на workload identity federation, включить flow logs и проверить настройки.