Уязвимости Tailscale SSH могут позволить уже авторизованному пользователю получить root-права на целевом сервере. Команда сервиса разбирает 11 проблем безопасности в клиенте Tailscale и self-hosted-сервере управления Headscale; для компаний, использующих tailnet как привычный путь к инфраструктуре, это повод немедленно пересмотреть SSH-политики и отключить ненужный форвардинг.
Проблемы обнаружила Cyberdione Labs при аудите Tailscale 1.104.2 и Headscale 0.29.5. Все сценарии исследователи воспроизвели в лаборатории на неизменённых релизных сборках, сообщает BleepingComputer. По словам основательницы Cyberdione Labs Эрики Виндиш, найденные дефекты не требуют экзотических условий для обнаружения: часть из них исследователи выявили с небольшими усилиями.
Самый опасный сценарий связан со встроенным SSH-сервером tailscaled. Демон работает с привилегиями root, а обработка Unix-сокетов при удалённом и локальном SSH-форвардинге выполняет часть операций с путями и файлами от имени root. Исследователи описали гонки и отсутствие своевременного понижения привилегий: обычная SSH-сессия при определённых условиях может подменить, открыть или удалить ресурс, доступный root.
Для атаки недостаточно просто оказаться в сети: злоумышленнику нужны одобренное устройство и правило SSH-политики. Но это не делает риск академическим. В организациях доступ к серверам через Tailscale часто выдаётся администраторам, разработчикам, подрядчикам и автоматизации. При успешной эксплуатации атакующий может выполнить код с root-правами на сервере, перехватить ключи подключения новых устройств или удалить файлы, к которым локальный пользователь не должен иметь доступа.
В Tailscale признали серьёзность отчёта. Компания уточнила, что большинство найденных проблем вокруг SSH относятся к эскалации привилегий: пользователь, которому уже разрешено подключение, в некоторых конфигурациях способен выйти за рамки прав назначенной ему локальной учётной записи. Итог зависит от правил доступа, настроек хоста и других условий, поэтому разработчики продолжают проверять полный список затронутых сценариев.
При этом Tailscale не рекомендует массово выключать SSH. Вице-президент по инженерии Майк Шейвер предложил более точечную меру: отключить именно SSH-форвардинг там, где он не нужен. Для этого в окружение службы tailscaled следует добавить TS_SSH_DISABLE_FORWARDING=1 и перезапустить сервис. Такая настройка сохраняет Tailscale SSH, но закрывает несколько наиболее опасных путей из отчёта. Одновременно стоит сократить правила доступа до конкретных пользователей и устройств, особенно для production-серверов, CI/CD-узлов, bastion-хостов и машин с секретами.
Список Tailworm не ограничивается SSH. В экспериментальных app connectors обнаружен обход сетевых ACL: устройство с правом использовать коннектор может направить трафик к выбранному атакующим адресу, при этом правила сети для фактического назначения не проверяются. Потенциальные цели — облачные metadata-сервисы с учётными данными, внутренние сегменты сети и, в Kubernetes-среде, сервисы кластера. Иными словами, удобный механизм публикации маршрутов может превратиться в обход привычной сетевой сегментации.
Отдельно затронут Headscale, самостоятельная реализация control server для Tailscale. Доступный из интернета сервер может быть подвержен неаутентифицированному истощению ресурсов: рост потребления памяти и вытеснение кэша способны отправить control plane в цикл падений. Последствия здесь менее эффектны, чем root-доступ, но для компании болезненны: новые устройства не смогут подключаться к tailnet, а восстановление доступа в разгар инцидента быстро превращается в отдельную операционную задачу.
Ещё две группы проблем касаются DERP-клиента и команды tailscale serve. Агент Tailscale может исчерпать память, если клиент удастся направить на вредоносный relay с неограниченно длинным ответом. В tailscale serve TCP-перенаправление на Unix-сокет не получило защиту, которая есть в HTTP-пути; это может открыть удалённый доступ к административному API узла. Также исследователи описали гонку в авторизации на уровне точек монтирования, из-за которой небольшая доля запросов способна обойти проверку прав приложения.
Команда Tailscale заявила 27 октября, что готовит исправленный клиент и рассчитывает выпустить его до конца дня. Администраторам имеет смысл заранее подготовить окно обновления, проверить версии агентов на серверах и в облаке, а также убедиться, что правила SSH не выданы слишком широко. Эти уязвимости Tailscale SSH хорошо иллюстрируют неприятную закономерность: mesh VPN снижает трение при доступе к инфраструктуре, но ошибка в слое управления доступом или проксировании способна масштабировать компрометацию на весь парк машин.
Главный вопрос теперь не в том, выключать ли Tailscale целиком, а в том, насколько аккуратно команды отделяют удобный доступ от административных привилегий. Патч закроет конкретные дефекты, но аудит SSH-политик, ограничение форвардинга и минимальные права для устройств останутся необходимыми и после обновления.
