اگر اوایلِ اکتبر از راهِ Tor به سرورتان وصل شده‌اید و پیامی دربارهٔ «تغییرِ کلیدِ میزبان» دیده‌اید، این خبر به شما مربوط است. از ۲ اکتبر ۲۰۲۶ تا حذف‌شان در ۵ اکتبر، ۳۳۳ گرهٔ خروجیِ Tor اتصال‌های SSH را به ۱۲ سرورِ رهگیر فرستادند. گرهٔ خروجی Tor آخرین ایستگاهِ ترافیکِ شما در این شبکه است، پیش از آن‌که داده به سایت یا سرورِ مقصد برسد. طبقِ گزارشها دامنهٔ خطر محدود بود و ورود با کلید با این روش دزدیده نمی‌شد.
در یک نگاه
از ۲ اکتبر ۲۰۲۶ تا حذف‌شان در ۵ اکتبر، ۳۳۳ گرهٔ خروجیِ Tor اتصال‌های SSH را به ۱۲ سرورِ رهگیر فرستادند. طبقِ گزارشها فقط ورود با رمزِ عبور به SSH از راهِ Tor، پس از پذیرفتنِ کلیدِ میزبانِ سرورِ رهگیر، در خطر بود. ورود با کلید با این روش دزدیده نمی‌شد.
- یک پژوهشگر در ۲ اکتبر ۲۰۲۶ حدود ۳۰۰۰ گرهٔ خروجیِ Tor را اسکن کرد و دید ۳۳۳ تا از آن‌ها اتصال‌های SSH را به ۱۲ سرورِ رهگیرِ یکسان می‌فرستند.
- در اوجِ حمله، یعنی ۴ اکتبر ۲۰۲۶، رله‌هایی که سیاستِ خروجِ مهاجم را داشتند ۷٫۴۶ درصد از ظرفیتِ خروجیِ Tor را در دست داشتند.
- به گفتهٔ گردانندهٔ رلههای Quetzalcoatl، ریشهٔ نفوذ به سرورهای خودش یک رمزِ تکراری بود که برای SSH، sudo و پشتیبان به کار می‌رفت و به‌صورتِ متنِ ساده ذخیره شده بود.
- طبقِ گزارشها، فقط ورود با رمزِ عبور به SSH از راهِ Tor بین ۱ تا ۵ اکتبر و پس از پذیرفتنِ کلیدِ میزبانِ سرورِ رهگیر در خطر بود و ورود با کلید با این روش دزدیده نمی‌شد.
- پروژهٔ Tor از ۴ اکتبر علامت‌گذاریِ رلههای مخرب را شروع کرد و تا ۵ اکتبر هیچ‌کدام در فهرستِ رسمیِ شبکه باقی نماند.
در حملهٔ گره‌های خروجی Tor دقیقاً چه اتفاقی افتاد؟
بنابر گزارشِ Ars Technica، مهاجمان سه روز صدها گرهٔ خروجی را در اختیار داشتند تا اطلاعاتِ حساس بدزدند. پژوهشگری با نامِ Kaba در ۲ اکتبر همهٔ گره‌های خروجی را اسکن کرد. این گره‌ها حدود ۳۰۰۰ تا بودند و ۳۳۳ تا از آن‌ها ترافیکِ SSH را به همان ۱۲ سرور می‌فرستادند. SSH راهِ رایجِ ورودِ از راهِ دور به سرورهاست.
به گفتهٔ Kaba، رهگیریِ هماهنگ جمعه ۲ اکتبر ساعت ۹:۳۵ صبح شروع شد و او یافته‌هایش را ۲۰ اکتبر منتشر کرد. در اوجِ حمله، یعنی ۴ اکتبر، رله‌هایی که سیاستِ خروجِ مهاجم را داشتند ۷٫۴۶ درصد از ظرفیتِ خروجیِ Tor را در دست داشتند. پروژهٔ Tor از ۴ اکتبر علامت‌گذاریِ رلهها را شروع کرد. تا ۵ اکتبر هیچ‌کدام در consensus، یعنی فهرستِ رسمیِ رلههای شبکه، نمانده بود.
سرورهای یکی از گردانندگانِ رلهها چطور هک شد؟
در موردِ یکی از گردانندگان، ریشهٔ نفوذ یک رمزِ تکراری بود. گردانندهٔ خانوادهٔ رلههای Quetzalcoatl گزارش داد که از یک رمز برای ورودِ SSH، دسترسیِ sudo و عبارتِ عبورِ پشتیبان استفاده کرده بود. این رمز روی دو سرور به‌صورتِ متنِ ساده ذخیره شده بود و ورود با رمز هم روی سرورِ مدیریتِ رو به اینترنت باز مانده بود. معلوم نیست مهاجم این رمز را از کجا آورده است.
مهاجم ۲۸ اوت در همان تلاشِ اول وارد سرورِ مدیریت شد. کمتر از ۵ دقیقه بعد به دسترسیِ root رسید، یعنی بالاترین سطحِ اختیار روی سرور، و Ebury را نصب کرد. Ebury یک درِ پشتیِ قدیمی برای لینوکس است که اعتبارنامه‌ها را می‌دزدد. کمی بیش از یک ساعت بعد، Ebury را روی سرورِ دوم به نامِ Switzerland2 هم نصب کرد.
این گزارش فقط دربارهٔ سرورهای همین گرداننده است؛ گزارش‌های دیگر هم فقط می‌گویند بعضی از سرورهای آسیب‌دیده به Ebury آلوده بودند. در سطحِ کلِ شبکه، مهاجمان فایل‌های پیکربندیِ torrc را بازنویسی کردند و سیاستِ خروج را تغییر دادند، یعنی قاعده‌ای که تعیین می‌کند ترافیکِ کدام پورت‌ها از رله بیرون برود. با این کار پورتِ SSH روی ۳۴۲ رله باز شد که پیش‌تر آن را بسته بودند. روی دو رلهٔ این گرداننده، تغییر ۲ اکتبر انجام شد، حدود ۵۲ ساعت فعال ماند و هیچ ورود یا فرمانی در لاگ‌ها ثبت نشد.
چه کسی واقعاً در خطر بود؟
خطر فقط متوجهِ یک گروهِ مشخص بود. طبقِ گزارشها، این گروه کسانی بودند که بین ۱ تا ۵ اکتبر از راهِ Tor و با رمزِ عبور به SSH وصل شدند و کلیدِ میزبانِ سرورِ رهگیر را پذیرفتند. کلیدِ میزبان مثلِ شناسنامهٔ سرور است و وقتی عوض شود، SSH هشدار می‌دهد. کاربرانی که به سرورِ رهگیر هدایت می‌شدند همین هشدار را می‌دیدند. ورود با کلید (key-based) با این روش دزدیده نمی‌شد.
مهاجمان ایمیل را هم هدف گرفتند. طبقِ گزارش، آن‌ها پورت‌های 25، 465، 587، 993 و 995 را که برای ایمیلِ رمزنگاری‌شده به کار می‌روند بستند و پورت‌های بیرمز را باز گذاشتند. البته پورتِ 25 به‌خودیِ‌خود رمزنگاری‌شده نیست و رمزنگاری‌اش معمولاً با STARTTLS برقرار می‌شود. امیدِ مهاجمان این بود که سرویسِ ایمیل به اتصالِ بیرمز برگردد تا متنِ ساده را بخوانند.
از این ماجرا چه درسی می‌شود گرفت؟
هشدارِ تغییرِ کلیدِ میزبان را هیچ‌وقت سرسری رد نکنید. در این ماجرا، کسانی که به سرورِ رهگیر هدایت می‌شدند همین هشدار را می‌دیدند. رمزِ تکراری هم، همان‌طور که در سرورهای یک گرداننده دیدید، می‌تواند راهِ نفوذ را باز کند. اگر سرور یا حسابی دارید که شاید در این بازه لو رفته باشد، بررسی و تغییرِ تنظیماتِ امنیتی را به متخصصِ امنیتِ دارای صلاحیت بسپارید.
پرسش‌های پرتکرار
من فقط با مرورگرِ Tor سایت میبینم؛ باید نگران باشم؟
طبقِ گزارشها، هدفِ اصلی ورودهای SSH با رمزِ عبور و ایمیلِ بیرمز بود. اگر در بازهٔ ۱ تا ۵ اکتبر چنین کاری نکردهاید، در این روشِ مشخص در خطر نبودید.
چرا ورود با کلید در امان ماند؟
به گفتهٔ گزارشها، روشِ رهگیریِ مهاجم فقط ورودهای مبتنی بر رمزِ عبور را میدزدید و ورودهای مبتنی بر کلید با این روش دزدیده نمیشدند. برای راهاندازیِ درستِ آن روی سرورتان با متخصص مشورت کنید.
آیا خودِ پروژهٔ Tor هک شده بود؟
نه. سرورِ مدیریتِ آلوده مالِ یکی از گردانندگانِ رلهها بود، نه پروژهٔ Tor. پروژهٔ Tor تا ۵ اکتبر رلههای مخرب را از شبکه حذف کرد.
جمع‌بندی
این حمله نشان داد که امنیتِ شبکه‌ای مثلِ Tor به امنیتِ سرورهای گردانندگانش هم بستگی دارد. در یک مورد، یک رمزِ تکراری راهِ نفوذ به سرورهای یک گرداننده را باز کرد. طبقِ گزارشها، اعتبارِ ورودِ مبتنی بر کلید با این روش سرقت نمی‌شد و کاربرانِ هدایت‌شده به سرورِ رهگیر هشدارِ تغییرِ کلیدِ میزبان را می‌دیدند. پس دفعهٔ بعد که چنین هشداری دیدید، پیش از زدنِ «yes» یک لحظه مکث کنید.
منابع
- Ars Technica (2026-10-22)
- The Hacker News (2026-10-02)
- KABA (وبلاگِ پژوهشگرِ کشف‌کننده) (2026-10-02 (انتشار: 2026-10-20))
- daily.dev (خلاصهٔ گزارشِ Ars Technica) (2026-10-22)
- فهرستِ پستیِ tor-relays (پروژهٔ Tor) (2026-10)
- CyberInsider (2026-10)
این مقاله با کمکِ ابزارهای هوش مصنوعی از روی منابعِ بالا تألیف و با بازبینیِ مستقلِ فنی و ویراستاری سنجیده شده است. قیمت‌ها، پلن‌ها و شرایطِ سرویس‌ها ممکن است تغییر کند؛ پیش از خرید، شرایطِ رسمیِ هر سرویس را ببینید.
