Tailworm: Один взломанный сервер — корневой доступ на следующем 11 незакрытых уязвимостей Tailscale и что нужно заблокировать уже сегодня Ваша частная сеть остается частной, пока одно устройство в ней не будет скомпрометировано. Новый отчет утверждает, что Tailscale SSH может превратить это одно устройство в корневой доступ на остальных. Патча нет. CVE нет. Пока что. ---------------------- 25 октября исследователь Эрика Виндисч (Cyberdione Labs) опубликовала отчет «Tailworm»: 11 уязвимостей, сгруппированных в 5 категорий, протестированных на Tailscale 1.104.2 и headscale 0.29.5 с 22 по 24 октября. Суть проблемы: Tailscale SSH работает внутри tailscaled, а tailscaled запущен от имени root. Когда сессия перенаправляет Unix-сокеты (ssh -L / -R), проверки путей и операции с файлами выполняются с правами root. В лабораторных условиях обычный сеанс прошел через Docker-сокет и прочитал /etc/shadow. Другая цепочка захватила ключ регистрации и подключилась к враждебной ноде, выглядящей как доверенный сервер. Распространение заняло менее секунды на каждый прыжок. Ни паролей, ни украденных ключей. 🔹Что подтверждено, а что — нет🔹 ▫️ Все результаты — воспроизведены в лаборатории, не являются реальными инцидентами ▫️ Последний бюллетень Tailscale — TS-2026-013. Ничего о Tailworm, никакой исправленной версии ▫️ Вице-президент по инженерии Майк Шевер говорит, что они рассматривают отчет и не рекомендуют всем отключать Tailscale SSH. Его совет: пересмотрите политики SSH и перенаправления, включите автоматическое обновление ▫️ Исследователь утверждает, что проблема была «сообщена, но не согласована». Критики на HN называют отчет нечитаемым ▫️ Атакующему всё ещё нужна первоначальная точка входа: уязвимое веб-приложение, заражённый пакет, фишинговый эксплойт или украденные учётные данные 🔹Почему это важно за пределами IT🔹 Не первый случай в этом году. Бюллетени TS-2026-006 и TS-2026-009 описывали пути через SSH к root, один из них — через имя пользователя "-i". Обе были исправлены в версии 1.98.9. В июле ИИ-агент использовал один украденный повторно используемый ключ Tailscale, чтобы зарегистрировать 181 ноду в сети Hugging Face. Ни одной уязвимости не потребовалось. Многие разработчики запускают ботов, RPC-ноды, валидаторы и ИИ-агенты на VPS, доступ к которому возможен только через Tailscale. Сеть — это периметр. Один скомпрометированный сервер становится проблемой для всех. 🔹Практические рекомендации для разработчиков🔹 📝 Проверьте, используете ли вы это вообще. Откройте файл политики и прочитайте раздел ssh. Не нужно на ноде? tailscale set --ssh=false. Сначала обеспечьте альтернативный способ доступа — иначе вы заблокируете себя. 📝 Обычный OpenSSH через tailnet по-прежнему работает и понижает привилегии до уровня пользователя до начала сессии. 📝 Перепишите правила SSH по парам: один источник, один пункт назначения. Нет правил по тегам или для всех участников. Только правила по парам остановили распространение в лаборатории. 📝 Запретите перенаправление в каждом правиле SSH, если оно не требуется. На headscale 0.29.5 это невозможно — поэтому рассматривайте каждое правило SSH как дающее права root. 📝 Удалите serve-перенаправления, указывающие на Unix-сокеты, и неиспользуемые разрешения подключений приложений. 📝 Включите истечение срока действия ключей нод и Tailnet Lock. Замените повторно используемые ключи аутентификации на одноразовые или эфемерные. 📝 Если устройство скомпрометировано — удалите его на уровне контрольной плоскости. Переустановка ОС не отменяет уже скопированные ключи. 📝 Включите автоматические обновления и следите за бюллетенями безопасности на tailscale.com/security-bulletins. Моя гипотеза укрепится, если официальный бюллетень подтвердит находки по перенаправлению и выпустит исправление с понижением привилегий. Она ослабнет, если большинство этих проблем будут ограничены headscale или нестандартными конфигурациями. Zero Trust — это файл политики. Не свойство программного обеспечения. Запускаете ли вы Tailscale SSH на чём-либо, что хранит ключи?
