نقص‌های وصله‌نشده Tailscale SSH؛ یک دستگاه هک‌شده می‌تواند به دسترسی روت روی سرورهای دیگر برسد
اخبار داغ فناوری اطلاعات و امنیت شبکهگزارش «Tailworm» از ۱۱ یافته می‌گوید؛ اما همه ادعاها هنوز فقط بر پایه یک گزارش هستند
یک پژوهشگر امنیتی اعلام کرده در شبکه‌های Tailscale، یک دستگاه واحد که به خطر افتاده می‌تواند برای دستیابی به دسترسی روت (Root) روی سایر سرورهایی که به آن‌ها دسترسی دارد، به کار گرفته شود. این یافته‌ها در ۲۵ اکتبر در گزارشی با عنوان Tailworm منتشر شده است.
شرایط لازم برای این حمله
بر اساس این گزارش، حمله به دو شرط نیاز دارد:
- Tailscale SSH به‌گونه‌ای پیکربندی شده باشد که فوروارد پورت (Port Forwarding) را مجاز کند.
- مهاجم از قبل کنترل یک دستگاه را در دست داشته باشد که قوانین دسترسی شبکه به آن اجازه اتصال به هدف را می‌دهد.
پس این حمله، آغازگر نفوذ نیست؛ نیازمند یک «جای‌پا» اولیه است. گزارش می‌گوید مهاجم می‌تواند این جای‌پا را به روش‌های معمول به دست آورد: یک اپلیکیشن وب آسیب‌پذیر، یک بسته نرم‌افزاری مسموم، فیشینگ، یا اطلاعات ورود سرقت‌شده.
چه کسی، چه چیزی را آزمایش کرد؟
گزارش را اریکا ویندیش (Erica Windisch) از آزمایشگاه Cyberdione Labs نوشته است. او طی سه روز در محیط آزمایشگاهی، Tailscale نسخه ۱.۱۰۴.۲ و headscale نسخه ۰.۲۹.۵ را آزمایش کرد؛ headscale سرور خودمیزبانی‌شده‌ای است که برخی شبکه‌ها به‌جای سرویس میزبانی‌شده Tailscale از آن استفاده می‌کنند.
گزارش، آزمایش روی نرم‌افزار را توصیف می‌کند، نه حمله به شبکه‌های واقعی. تا زمان انتشار خبر، Tailscale نه بولتن امنیتی منتشر کرده، نه شناسه CVEای تخصیص یافته، و نه نسخه اصلاح‌شده‌ای عرضه شده است.
چرا Tailscale SSH با SSH معمولی فرق دارد؟
Tailscale SSH مانند یک سرور SSH معمولی عمل نمی‌کند. به‌جای بررسی رمز عبور یا کلید کاربر، هویت دستگاه را تشخیص می‌دهد و یک قانون دسترسی واحد تعیین می‌کند آن دستگاه اجازه دارد یک نشست SSH با هدف باز کند یا خیر.
به همین دلیل این حمله نیازی به رمز عبور یا کلید سرقت‌شده ندارد؛ تنها به یک جای‌پا روی یک دستگاه نیاز دارد.
سه روش نمایش‌داده‌شده در آزمایشگاه
ویندیش مشکل را در سه مرحله نشان داده است:
۱. فوروارد استاندارد SSH: با استفاده از فوروارد پورت معمول، یک نشست عادی باعث شد فرایند سطح‌روت Tailscale به یک سوکت سیستمی که فقط باید برای روت قابل‌دسترس باشد متصل شود؛ آزمایش تقریباً بلافاصله به دسترسی روت رسید و فایل رمزهای عبور سیستم را خواند، آن هم بدون حقوق مدیریتی.
۲. جایگزینی سوکت: یک سوکت متعلق به روت با سوکت مهاجم جایگزین شد و اجرای مستقیم دستور با دسترسی روت علیه برخی سرویس‌ها ممکن شد.
۳. شرایط مسابقه (Race Condition): یک کنترل ایمنی که قرار است فایل‌های قابل‌دسترس برای فوروارد را محدود کند، با رقابت میان زمان بررسی مسیر فایل و زمان استفاده از آن (TOCTOU) دور زده شد. در آزمایشگاه، این زنجیره پیش‌تر هم رفت: کلیدی را که برای ثبت دستگاه‌های جدید استفاده می‌شود ربود و با آن، دستگاه خود مهاجم را به‌عنوان یک سرور مورد اعتماد به شبکه افزود.
مرحله آخر، تنها روی شبکه‌هایی از ابتدا تا انتها اجرا شد که قابلیت Tailnet Lock در آن‌ها فعال نبود. روی شبکه‌های دارای این قابلیت، اسرار موردنیاز در حین انتقال برداشت شدند، اما گام پایانی تکمیل نشد.
ادعای «کرم‌گونه بودن» و واکنش‌ها
ویندیش نتیجه کلی را «Wormable» (قابل‌انتشار به‌صورت کرم) توصیف می‌کند: در آزمایشگاه، یک دستگاه به‌خطرافتاده می‌توانست به همه دستگاه‌هایی که قوانین دسترسی اجازه می‌دهند منتشر شود؛ بدون رمز عبور، بدون کلید سرقت‌شده و بدون هیچ اقدام کاربر، در کمتر از یک ثانیه برای هر مرحله. به گفته گزارش، شبکه مش، یک جای‌پای معمولی را با سرعت ماشین به دسترسی ممتاز در سطح کل ناوگان تبدیل می‌کند. این گسترش در آزمایشگاه سنجیده شده، نه روی شبکه‌های واقعی.
گزارش دو عامل بازدارنده را نام می‌برد:
- قوانین دسترسی به‌صورت جفت‌های منبع-مقصد منفرد که به‌تنهایی مانع گسترش شدند
- کلیدهای دستگاه مقید به سخت‌افزار مانند TPM یا Secure Enclave
برخی پژوهشگرانی که گزارش را خوانده‌اند، توصیف «کرم‌گونه» را علناً زیر سؤال برده‌اند؛ در مقابل، گروهی دیگر یافته دسترسی روت را جدی خوانده‌اند.
واکنش رسمی Tailscale
مایک شیور (Mike Shaver)، معاون مهندسی Tailscale، در ردیت نوشت شرکت گزارش را دریافت کرده، پیش‌تر نیز همراه متخصصان امنیتی بیرونی همین حوزه‌ها را بررسی می‌کرده و به مشکلاتی رسیده که روی رفع آن‌ها کار می‌کند. او گفت هنوز مشخص نیست دقیقاً کدام پیکربندی‌ها تحت تأثیرند و شرکت توصیه نمی‌کند همه، Tailscale SSH را غیرفعال کنند.
محدودیت‌های مدیریتی بسته به محل اجرا
- روی سرویس میزبانی‌شده Tailscale، فوروارد را می‌توان برای هر قانون جداگانه خاموش کرد.
- روی headscale نسخه ۰.۲۹.۵، فوروارد را اصلاً نمی‌توان خاموش کرد؛ بنابراین گزارش می‌گوید هر مجوز SSH در آنجا باید به‌منزله دسترسی روت روی هدف تلقی شود.
SSH فقط یکی از ۱۱ یافته است
مشکل SSH یکی از ۱۱ یافته در گزارش است که اپ کانکتورها (App Connectors)، قابلیت serve، رله DERP (مورد استفاده میان دستگاه‌ها) و headscale را نیز پوشش می‌دهد. ویندیش می‌گوید افزایش سطح دسترسی SSH «نگران‌کننده است»، اما یافته مربوط به اپ کانکتور ممکن است برای برخی سازمان‌ها تأثیرگذارتر باشد.
آن یافته، در یک قابلیت آزمایشی به نام conn25 است و به کاربر مجاز اجازه می‌دهد ترافیک را به مقاصدی ارسال کند که تیم امنیت هرگز تأیید نکرده است؛ از جمله سرویس متادیتای یک ارائه‌دهنده ابری که می‌تواند اعتبارنامه‌های سرور را بدهد.
چقدر می‌توان به این یافته‌ها اعتماد کرد؟
باید به چند نکته مهم توجه داشت:
- تمام یافته‌ها فقط بر گزارش خود ویندیش تکیه دارند؛ هیچ پژوهشگر دیگری آن‌ها را علناً بازتولید نکرده و Tailscale جزئیات فنی مشخص را تأیید نکرده است.
- کد اثبات مفهوم (PoC) عمومی نیست؛ ویندیش می‌گوید آن را فقط برای تماس امنیتی Tailscale فرستاده است.
- شیوه افشا محل مناقشه است. ویندیش آن را «گزارش‌شده اما هماهنگ‌نشده» توصیف کرده و دست‌کم یک نظردهنده انتشار بدون گزارش قبلی به Tailscale را غیرمسئولانه خوانده است.
- ویندیش در پاسخ می‌گوید گزارش و کد PoC را روز شنبه پیش از انتشار عمومی برای تماس امنیتی Tailscale فرستاده، پیش‌تر نگرانی‌های معماری را با مدیرعامل شرکت مطرح کرده و علناً هش یک فایل را منتشر و به کاربران توصیه کرده Tailscale SSH را غیرفعال کنند.
بخشی از یک روند تکرارشونده
این گزارش آخرین مورد در رشته‌ای از مشکلات در همین بخش Tailscale است. در اوایل ۲۰۲۶، شرکت چند نقص در SSH و مدیریت سوکت‌های سرور را برطرف کرد؛ از جمله موردی که در آن فوروارد سوکت یونیکس SSH می‌توانست به یک سوکت ممتاز برسد (در نسخه ۱.۹۸.۹).
اقدامات پیشنهادی تا زمان انتشار وصله
از آنجا که وصله‌ای وجود ندارد، تنها گزینه‌ها تغییر در نحوه پیکربندی Tailscale SSH و قابلیت‌های مرتبط است:
- قوانین دسترسی SSH را بازبینی کنید: آن‌ها را به‌صورت جفت‌های منبع-مقصد منفرد بنویسید (یک دستگاه به یک هدف) و قوانین گسترده بر پایه هویت یا برچسب را حذف کنید. گزارش این را تنها کنترلی می‌داند که در آزمایش مانع گسترش شد.
- فوروارد پورت SSH را تا حد ممکن خاموش کنید. روی سرویس میزبانی‌شده، این تنظیم برای هر قانون است. روی headscale نسخه ۰.۲۹.۵ ممکن نیست؛ پس هر مجوز SSH را معادل روت روی هدف بدانید.
- مجوزهای اپ کانکتور را از دستگاه‌هایی که به آن نیاز ندارند حذف کنید.
- هر فوروارد
tailscale serveکه به یک سوکت یونیکس اشاره می‌کند را بردارید. - انقضای کلید گره (Node-Key Expiry) را فعال کنید تا کلید دستگاه سرقت‌شده تا ابد معتبر نماند.
- در صورت به‌خطر افتادن یک دستگاه، آن را از صفحه کنترل (Control Plane) حذف کنید؛ نصب مجدد سیستم‌عامل، کلیدهایی را که مهاجم از قبل کپی کرده باطل نمی‌کند.
Tailscale همچنین پیشنهاد می‌کند حالت بررسی SSH (Check Mode) را فعال کنید که پیش از شروع نشست یک مرحله ورود اضافه می‌کند، و به‌روزرسانی خودکار را روشن کنید. حالت بررسی، افزایش سطح دسترسی را رفع نمی‌کند؛ فقط یک مانع دیگر پیش روی آن می‌گذارد.
چرا این گزارش اهمیت دارد؟
نخست، Tailscale و ابزارهای مشابه شبکه‌های مش، برای ساده‌سازی دسترسی ایمن به منابع داخلی طراحی شده‌اند و در بسیاری از سازمان‌ها به‌عنوان جایگزین VPN سنتی به کار می‌روند؛ بنابراین هر نقصی در مدل اعتماد آن‌ها پیامدهای گسترده دارد. دوم، مدل «اعتماد بر پایه هویت دستگاه» به‌جای رمز یا کلید، یعنی تصرف یک دستگاه می‌تواند به معنای ارث بردن همه دسترسی‌های آن باشد؛ نکته‌ای که گزارش آن را برجسته می‌کند.
با این حال، قضاوت متعادل ضروری است: یافته‌ها هنوز مستقل تأیید نشده‌اند، PoC عمومی نیست، شرکت جزئیات فنی را تأیید نکرده و دامنه آسیب واقعی نامشخص است. بنابراین بهتر است سازمان‌ها به‌جای هراس، با اقدامات محافظه‌کارانه‌ای که هزینه کمی دارند (مثل قوانین جفت‌به‌جفت و خاموش کردن فوروارد) ریسک را کاهش دهند و بولتن رسمی Tailscale را دنبال کنند.
برچسب ها: Tailworm, امنیت_اطلاعات, امنیت_سایبری, Cyberattack, cybersecurity, حمله سایبری, news