Одного устройства в сети Tailscale, которое уже контролирует атакующий, достаточно, чтобы получить root на других серверах, куда это устройство имеет право подключаться. Об этом говорится в отчёте Tailworm, который 25 октября опубликовала Эрика Виндиш (Erica Windisch) из Cyberdione Labs. Проблема касается Tailscale SSH в конфигурации с разрешённым пробросом портов.
Виндиш проверяла Tailscale версии 1.104.2 и headscale версии 0.29.5 — самостоятельно размещаемый сервер, которым некоторые сети заменяют облачный сервис компании. Тесты шли три дня в лаборатории. Речь именно о лабораторных испытаниях, а не об атаках на реальные сети. На момент публикации Tailscale не выпустила ни бюллетеня безопасности, ни идентификатора CVE, ни исправленной версии — та же ситуация, что была с двумя 0-day в Citrix NetScaler, эксплуатировавшимися до патча.
Почему Tailscale SSH не похож на обычный SSH
Tailscale SSH не проверяет пароль или ключ подключающегося пользователя. Он идентифицирует само устройство, и одно правило доступа решает, может ли это устройство открыть SSH-сессию к цели. Поэтому атакующему не нужны украденные пароли или ключи — нужна лишь точка опоры на одном устройстве. Отчёт перечисляет обычные пути её получения: уязвимое веб-приложение, отравленный программный пакет, фишинг или украденные учётные данные. Сама Tailscale эту первую точку опоры не создаёт.
Насколько администратор может ограничить последствия, зависит от того, где работает сеть. В облачном сервисе Tailscale проброс отключается на уровне правила. В headscale 0.29.5 отключить его нельзя вообще — отчёт советует считать любое SSH-разрешение там выдачей root на целевой машине.
Три способа добраться до root
В лаборатории Виндиш показала атаку по этапам. При стандартном пробросе портов SSH обычная сессия заставляла процесс Tailscale с правами root подключиться к системному сокету, доступ к которому должен быть только у root. Тест почти сразу получил root и прочитал системный файл с паролями — без прав администратора.
Второй метод подменял сокет, принадлежащий root, на сокет атакующего. Это давало прямое выполнение команд от root в отношении отдельных сервисов.
Третий метод обходил защитную проверку, ограничивающую файлы, доступные через проброс. Обход строился на гонке: система проверяет путь к файлу и использует его в разные моменты, и между ними путь подменяется. В лаборатории цепочка пошла дальше: она перехватила ключ, которым в сеть вводятся новые устройства, и с его помощью подключила машину атакующего как доверенный сервер.
Последний шаг целиком сработал только в сетях без включённой функции Tailnet Lock. Там, где она включена, нужные секреты перехватывались при передаче, но финальный шаг завершить не удалось.
«Червеобразность» — оценка, а не наблюдение
Виндиш называет общий результат «wormable» — способным распространяться как червь. В лаборатории одно скомпрометированное устройство переходило на каждое устройство, разрешённое правилами доступа, без паролей, без украденных ключей и без действий пользователя, менее чем за секунду на шаг. Формулировка из отчёта: «сеть превращает одну обычную точку опоры в привилегированный доступ ко всему парку на машинной скорости». Это измерение в лаборатории, в реальных сетях такого распространения не наблюдали.
Распространению мешали две вещи: правила доступа, записанные как отдельные пары «источник — назначение», которые сами по себе останавливали распространение, и ключи устройств, привязанные к аппаратуре вроде TPM или Secure Enclave. Часть исследователей, прочитавших отчёт, публично усомнилась в описании «wormable», другие назвали находку с получением root серьёзной.
Проблема SSH — лишь одна из 11 находок отчёта. Там же разобраны app connectors Tailscale, функция serve, ретранслятор DERP между устройствами и headscale. Виндиш сказала The Hacker News, что повышение привилегий через SSH «вызывает беспокойство», но находка про app connector «может оказаться более значимой для некоторых организаций». Речь об экспериментальной функции conn25: разрешённый пользователь может отправлять трафик на адреса, которые команда безопасности не одобряла, включая сервис метаданных облачного провайдера, а тот способен выдать учётные данные сервера.
Все находки опираются только на отчёт Виндиш. Другие исследователи публично их не воспроизводили, Tailscale конкретные технические утверждения не подтвердила. Код proof-of-concept не опубликован: по словам Виндиш, она передала его только контакту по безопасности Tailscale.
Что ответила Tailscale
Вице-президент по инженерии Майк Шейвер (Mike Shaver) написал в Reddit, что компания получила отчёт, уже изучала те же области вместе с внешними специалистами по безопасности и нашла проблемы, которые исправляет. Шейвер сказал, что компания ещё определяет, какие конфигурации затронуты, и что она «не рекомендует всем отключать Tailscale SSH».
Спор о раскрытии тоже есть. Виндиш описала его как «reported but not coordinated» — сообщено, но не согласовано, — написав об этом на Ycombinator HN; как минимум один комментатор там назвал публикацию без предварительного уведомления Tailscale безответственной. В ответ на вопросы The Hacker News Виндиш заявила, что до публичного поста действительно передала компании копию отчёта и код proof-of-concept — на контакт по безопасности в субботу перед публикацией. Она также сказала, что раньше поднимала вопросы к архитектуре Tailscale с главой компании и публично выложила хеш файла и совет отключить Tailscale SSH.
Это не первый случай в той же части продукта. Ранее в 2026 году компания исправила несколько уязвимостей Tailscale SSH и обработки серверных сокетов, включая ту, где проброс Unix-сокета SSH достигал привилегированного сокета, — в версии 1.98.9. Похожая история была у Gitea, где среди 27 закрытых уязвимостей тоже нашёлся обход SSH-аутентификации.
Что делать без патча
Пока исправления нет, остаются изменения в настройках Tailscale SSH и связанных функций. Рекомендации отчёта и самой Tailscale в основном совпадают.
- Пересмотрите правила доступа Tailscale SSH. Записывайте их отдельными парами «источник — назначение», где названы одно устройство и одна цель, и уберите широкие правила, выдающие доступ по идентичности или тегу. Отчёт называет попарные правила единственным средством, остановившим распространение в тестах.
- Отключите проброс портов SSH, где это возможно. В облачном сервисе Tailscale это настройка на уровне правила. В headscale 0.29.5 отключить нельзя — считайте любое SSH-разрешение там выдачей root на цели.
- Снимите разрешения app connector с устройств, которым они не нужны.
- Уберите любой проброс tailscale serve, указывающий на Unix-сокет.
- Включите истечение срока действия ключей узлов, чтобы украденный ключ устройства не оставался действительным навсегда.
- Если устройство скомпрометировано, удалите его на уровне control plane. Переустановка системы не отзывает ключи, которые атакующий мог уже скопировать.
Tailscale также предлагает включить режим проверки SSH (check mode), который добавляет шаг входа перед началом сессии, и автоматические обновления. Check mode не устраняет повышение привилегий — он лишь ставит ещё один барьер перед ним.
Если сеть уже взломана и нужно понять, как злоумышленник поднимает привилегии до root, полезно посмотреть на четыре уязвимости повышения привилегий в ядре Linux — механика там схожая, хотя конкретные пути и сокеты другие.
Частые вопросы
Кого касается эта проблема?
Сети, где Tailscale SSH разрешает проброс портов, и headscale версии 0.29.5, где проброс отключить нельзя. Обязательное условие — атакующий уже контролирует хотя бы одно устройство, которому правила доступа разрешают подключаться к цели.
Есть ли CVE или исправленная версия?
На момент публикации отчёта нет ни идентификатора CVE, ни бюллетеня безопасности, ни версии с исправлением. Tailscale подтвердила, что работает над проблемами, но конкретные технические утверждения не подтвердила.
Это уже атакуют в реальных сетях?
Нет данных об атаках на реальные сети. Все результаты получены в лаборатории Виндиш за три дня тестов на Tailscale 1.104.2 и headscale 0.29.5.
Нужны ли атакующему пароли или SSH-ключи?
Нет. Tailscale SSH идентифицирует устройство, а не пользователя, поэтому украденные пароли и ключи не требуются — достаточно точки опоры на одном устройстве.
Поможет ли отключение Tailscale SSH?
Это радикальная мера, и Tailscale её не рекомендует. Шейвер прямо сказал, что компания «не рекомендует всем отключать Tailscale SSH». Сначала стоит ограничить правила доступа и проброс портов.
Почему попарные правила называют главной защитой?
В тестах именно правила, записанные как отдельные пары «источник — назначение» с одним устройством и одной целью, останавливали распространение. Широкие правила по идентичности или тегу такой остановки не давали.
Защищает ли Tailnet Lock?
Частично. В сети с включённым Tailnet Lock нужные секреты перехватывались при передаче, но финальный шаг — подключение машины атакующего как доверенного сервера — завершить не удалось.
Достаточно ли переустановить скомпрометированную машину?
Нет. Отчёт советует удалять устройство на уровне control plane: переустановка системы не отзывает ключи, которые атакующий мог уже скопировать с устройства.
Что даёт режим проверки SSH?
Check mode добавляет шаг входа перед началом сессии. Повышение привилегий он не устраняет — это лишь дополнительный барьер, а не исправление.
Источник: thehackernews.com