Несколько уязвимостей в Tailscale и Headscale дают возможность получить полные права на подключённых серверах, обойти сетевые политики и перехватить учётные данные. Речь идёт о встроенном SSH-сервере Tailscale SSH и о пробросе сокетов в служебном процессе tailscaled, который работает с правами root. Находку описали исследователи из Cyberdione Labs в отчёте Tailworm. Затронуты сети, построенные на Tailscale и на совместимом сервере Headscale.
Проброс сокетов и гонка при проверке пути
Причина кроется в том, как Tailscale SSH обращается с привилегиями. Классический сервер OpenSSH разделяет их: часть работы выполняет непривилегированный процесс. Встроенный сервер Tailscale отдельные операции проброса выполняет от имени root, то есть с полными правами администратора Linux. Сокет Unix - локальная точка обмена данными между процессами на одной машине; доступ к части таких сокетов обычно закрыт для обычных пользователей.
Одна из проблем связана с локальным пробросом сокета. Участник сети, прошедший аутентификацию, получает доступ к сокетам, которые зарезервированы за root. В испытаниях исследователи подключились к привилегированному сокету Docker (среда запуска контейнеров) и выполнили команды с правами root. Тем же способом они прочитали файл с хешами паролей Linux.
Другая проблема - обратный проброс, при котором соединение инициируется с удалённой стороны. Привилегированный процесс заменяет сокет, принадлежащий root, на прослушиватель атакующего. Это открывает путь к выполнению команд, подмене служб и перехвату учётных данных реестра Docker. Ещё один сценарий опирается на состояние гонки между проверкой пути к файлу и обращением к нему (TOCTOU). Такая рассинхронизация позволяет обойти ограничения на доступ к системным файлам.
Оценку CVSS ни исследователи, ни вендор не приводят; в отчёте уровень опасности обозначен как высокий. Атака идёт по сети. Атакующему достаточно контроля над одним устройством внутри сети Tailscale и уже выданных прав SSH. Дополнительные пароли, ключи и права администратора не нужны, участие пользователя не требуется.
Боковое перемещение и экспериментальный коннектор
Доверенные идентификаторы устройств и слишком широкие правила доступа по SSH позволяют автоматизировать боковое перемещение - переход с одной доступной машины на другую. В лабораторных условиях один такой переход занимал меньше секунды. Пользователь в этом не участвует.
Отдельно исследователи разобрали экспериментальный коннектор приложений conn25, который публикует внутренние сервисы для устройств сети. При избыточных правах он открывает доступ к службам, не предназначенным для публикации, к служебным адресам облачных метаданных и к ресурсам Kubernetes (платформа оркестрации контейнеров).
Переполнение памяти в Headscale и Tailscale
Ещё одна группа проблем - переполнение памяти в компонентах Headscale и Tailscale. Исчерпание памяти нарушает регистрацию устройств и доступность сети. Условия атаки по этим проблемам исследователи не расписали.
Исправлений и идентификаторов пока нет
На 25 октября, дату отчёта, ни CVE-идентификаторов, ни исправленных версий не объявлено. Tailscale подтвердила получение отчёта и ведёт проверку. Сведений об эксплуатации в реальных атаках нет: уязвимости воспроизводили в лаборатории на Tailscale 1.104.2 и headscale 0.29.5. Публикация отчёта раскрывает технические детали, но не означает, что проблемы уже используют.
Официальных обходных мер вендор не публиковал. Ограничения, которые предложили исследователи, сводятся к сужению доступа. Проверьте права Tailscale SSH и разрешите соединения только между конкретными устройствами-источниками и получателями. Отключите проброс портов, если он не нужен. В Headscale 0.29.5 отдельно отключить проброс SSH нельзя, поэтому ограничения задают правилами доступа. Права коннектора приложений ограничьте списками разрешённых назначений. Отслеживайте регистрацию новых устройств и защищайте учётные данные устройств аппаратными средствами.
Номер исправленной версии появится в уведомлении Tailscale и в описании релизов Headscale. Проброс сокетов с правами root превращает одну скомпрометированную машину в точку входа для остальных узлов. Сети на принципах нулевого доверия (zero trust, когда каждое соединение проверяется отдельно) не закрывают эту брешь, если права SSH выданы широко. До выпуска исправления основная работа ложится на настройку доступа.
Ссылки
