آسیب‌پذیری‌های وصله‌نشده SSH در Tailscale به یک دستگاه آلوده اجازه می‌دهند دسترسی root را در کل شبکه گسترش دهد

یک محقق امنیتی ۱۱ آسیب‌پذیری در SSH تیلاسکیل فاش کرده که می‌توانند به یک مهاجم با دسترسی اولیه به یک دستگاه، اجازه دهند دسترسی root را بر روی تمام سرورهایی که قوانین شبکه اجازه دسترسی به آن‌ها را می‌دهد به دست آورد. این یافته‌ها که در ۲۵ اکتبر توسط اریکا ویندیش از آزمایشگاه‌های Cyberdione با نام Tailworm منتشر شد، هر سازمانی را که از Tailscale SSH با port forwarding فعال استفاده می‌کند تحت تأثیر قرار می‌دهد.

Tailscale یک ابزار VPN پوششی است که شبکه‌های خصوصی به نام «tailnet» بین دستگاه‌های ابری، مراکز داده و ایستگاه‌های کاری از راه دور ایجاد می‌کند. قابلیت SSH داخلی آن برای جایگزینی مدیریت کلیدهای SSH سنتی طراحی شده است.

توانایی‌های مهاجم

گزارش ویندیش سه مسیر حمله اصلی را نشان می‌دهد: دسترسی به socket های سیستمی محدود به root، جایگزین کردن socket های متعلق به root، و به دست آوردن کلید ثبت دستگاه از طریق یک race condition. در شبکه‌هایی که Tailnet Lock فعال نیست، مسیر سوم به مهاجم اجازه می‌دهد یک ماشین جدید را به عنوان سرور مورد اعتماد به شبکه اضافه کند.

همچنین یک آسیب‌پذیری در قابلیت آزمایشی app-connector وجود دارد که می‌تواند به مقاصد غیرمجاز از جمله سرویس‌های metadata ابری دسترسی پیدا کند — همان endpoint هایی که در حملات بزرگ سرقت اعتبارنامه ابری مورد سوءاستفاده قرار گرفته‌اند.

کاربران Headscale در معرض خطر بیشتری هستند

سازمان‌هایی که Headscale نسخه ۰.۲۹.۵ را اجرا می‌کنند — جایگزین متن‌باز سرور هماهنگ‌سازی Tailscale — در موقعیت آسیب‌پذیرتری هستند. برخلاف سرویس میزبانی‌شده، Headscale گزینه‌ای برای غیرفعال کردن port forwarding SSH ندارد. ویندیش توضیح می‌دهد که برای استقرارهای Headscale، هر دسترسی SSH باید در حال حاضر معادل دسترسی root به ماشین هدف تلقی شود.

بدون وصله، بدون CVE

تا زمان انتشار این گزارش، Tailscale هیچ وصله، CVE یا اعلامیه امنیتی منتشر نکرده است. معاون مهندسی شرکت تأیید کرد که گزارش ویندیش را دریافت کرده و اعلام کرد که Tailscale از قبل در حال بررسی همین حوزه‌ها بوده است.

اقدامات حفاظتی تا زمان انتشار وصله

تا زمانی که وصله رسمی منتشر شود، سازمان‌ها باید: قوانین دسترسی SSH را به صورت جفت‌های یک دستگاه به یک هدف بنویسند؛ port forwarding SSH را در صورت امکان غیرفعال کنند؛ مجوزهای app-connector را از دستگاه‌های غیرضروری حذف کنند؛ و انقضای کلید گره را فعال کنند. اگر دستگاهی مشکوک به آلودگی است، باید در سطح control plane حذف شود — نه صرفاً reimaging انجام شود، زیرا کلیدهای کپی‌شده همچنان معتبر خواهند بود.

تحقیق توسط اریکا ویندیش از Cyberdione Labs، اولین بار توسط The Hacker News گزارش شد.