Tailworm: Один взламаний пристрій, кореневий доступ на наступному 11 незапatchених вразливостей 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-forward, що вказують на Unix-сокети, та невикористовувані дозволи app connector. 📝 Увімкніть термін дії node-key та Tailnet Lock. Замініть повторно використовувані ключи автентифікації на одноразові або ефемерні. 📝 Якщо пристрій скомпрометовано — видалить його через контрольну площину. Переустановка ОС не скасовує ключи, які вже були скопійовані. 📝 Увімкніть автобновлення та стежте за tailscale.com/security-bulletins. Моя гіпотеза підтверджується, якщо офіційний бюлетень підтвердить виявлення щодо пересилання та випустить фікс з пониженням прав. Вона слабшає, якщо багато з цього буде обмежено headscale або незвичайними конфігураціями. Zero Trust — це файл політики. Не властивість програмного забезпечення. Чи запускаєте ви Tailscale SSH на чомусь, що містить ключі?
