تصور کنید تمام ترافیک بهروزرسانیهای نرمافزاری سرور شما، بهجای مقصد اصلی، به سروری هدایت شود که توسط هکرها کنترل شده است. این کابوس برای کاربران Virtualizor به واقعیت تبدیل شد؛ جایی که زیرساختهای بنیادین اینترنت برای توزیع بدافزار به خدمت گرفته شدند.
طبق گزارشهای منتشر شده در ۲ سپتامبر ۲۰۲۶، مهاجمان کنترل آدرسهای IP شرکت Softaculous را به دست گرفتند و کانال بهروزرسانیهای مورد اعتماد این شرکت را به سیستمی برای توزیع بدافزار تبدیل کردند. این حادثه یک نقطه ضعف مرگبار در پروتکل دروازه مرزی (BGP) — همان سیستمی که ترافیک را در سراسر اینترنت جهانی هدایت میکند — را افشا کرد.
برای درک این موضوع، باید بدانیم که اینترنت برخلاف ظاهر یکپارچهاش، مجموعهای از شبکههای مستقل به نام «سیستمهای خودمختار» (Autonomous Systems یا ASes) است که با ASN شناخته میشوند. هر AS یک شبکه مستقل است که بخشی از ۳.۷ میلیارد آدرس عمومی موجود در پروتکل IPv4 به آن اختصاص یافته است. BGP در واقع مانند چسبی است که این سیستمها را به هم متصل میکند. اما مشکل اینجاست که BGP در ابتدا بر پایه «اعتماد» ساخته شده بود. همین ویژگی باعث میشود وقتی یک بازیگر مخرب بهطور 거짓انه ادعا میکند مالک مجموعهای از آدرسهای IP است، سیستم دچار «ربایش» (Hijacking) شود.
اینترنت را مثل یک سیستم پستی جهانی تصور کنید که در آن هر اداره پست محلی میتواند ناگهان ادعا کند که دفتر مرکزی یک شرکت بزرگ است. اگر سایر ادارات پست این ادعا را باور کنند، تمام نامههای آن شرکت به دست impostor یا همان جعلکننده میافتد. در این مورد، مهاجمان فقط دادهها را ندزدیدند، بلکه با جعل هویت فروشنده نرمافزار، «بهروزرسانیهایی» فرستادند که در واقع کدهای مخرب بودند.
همانطور که در تحلیلهای پیشین ما درباره امنیت زیرساختهای ابری اشاره کردیم، اعتماد بیش از حد به پروتکلهای قدیمی میتواند کل زنجیره تأمین را به خطر بیندازد. این آسیبپذیریهای زیرساختی در کنار رخنههای بحرانی در کنترلکنندههای مدیریت پایه (BMC)، لایههای امنیتی سرورهای سازمانی را به شدت تهدید میکنند.
مکانیسم ربایش ترافیک
این حمله روی محدوده IP خاصی (162.55.80.0/24) متمرکز بود که توسط Softaculous، شرکتی مستقر در امارات برای پلتفرم مدیریت Virtualizor استفاده میشد. Softaculous از این IPها برای میزبانی سایت مشتریان، سیستم صورتحساب و همچنین نقطه انتهایی (Endpoint) بهروزرسانی نرمافزار خود استفاده میکرد. مهاجمان از زنجیرهای از خطاها در چندین ارائهدهنده زیرساختی بهره بردند:
- Hetzner Online (AS24940): این ارائهدهنده میزبانی دارای پیکربندیهای امنیتی مسیریابی بسیار ضعیفی بود که اجازه داد ربایش رخ دهد و برای مدتی تداوم یابد.
- Nexon Host (AS62390): زیرساخت این ارائهدهنده احتمالاً تسهیلکننده اعلامات مخرب بوده است؛ احتمالاً به دلیل یک رخنه امنیتی یا شکاف در پیکربندی. داگ مدوری، متخصص BGP، اشاره کرد که اعلامات مخرب احتمالاً از اینجا منشأ گرفته است.
- Zet.net (AS6204): یک peer ترانزیت در پاییندست Hetzner که در نظارت بر سیستمهای خود شکست خورد و اجازه داد ربایش ساعتها بدون شناسایی باقی بماند.
به نقل از داگ مدوری (Doug Madory)، متخصص BGP در شرکت Infoblox، مهاجمان از یک مسیر «دقیقتر» (more-specific) استفاده کردند. در دنیای مسیریابی BGP، روترها همیشه دقیقترین محدوده آدرس را ترجیح میدهند. در حالی که مسیر قانونی یک بلوک بزرگ (162.55.0.0/16) بود، مهاجمان یک بلوک بسیار کوچک و دقیق (162.55.80.0/24) را اعلام کردند. به دلیل مکانیسمی به نام «تطبیق طولانیترین پیشوند» (longest-prefix-match)، اینترنت جهانی بهطور خودکار مسیر مهاجم را بر مسیر واقعی ترجیح داد.
درک بلوکهای IP و پیشوندها
برای درک دلیل موفقیت این حمله، باید بدانیم محدودههای IP چگونه اندازهگیری میشوند. بلوکها با یک اسلش (/) و یک عدد مشخص میشوند. برخلاف تصور، هرچه عدد بزرگتر باشد، بلوک کوچکتر است. این موضوع بر اساس ۳۲ بیت استاندارد IPv4 است:
- یک بلوک /16 شامل (32-16)^2 یا ۶۵,۰۳۶ آدرس IP است.
- یک بلوک /24 شامل (32-24)^2 یا ۲۵۶ آدرس است.
از آنجایی که هیچ مسیری برای محدوده خاص 162.55.80.0/24 وجود نداشت تا با آن رقابت کند، این مسیر تا جایی که مکانیسمهای فیلترینگ اجازه میدادند، منتشر شد. بن کارترایت-کاکس (Ben Cartwright-Cox)، سازنده BGP Tools، توضیح داد که Hetzner اجازه اعلام محدودههای دقیقتر (/24) را داد در حالی که باید روی /16 محدود میشد. این خطا باعث شد ربایشگر بهطور خودکار در تصمیمات مسیریابی پیروز شود.
شکست در برابر دفاعهای مدرن
شبکههای مدرن از زیرساخت کلید عمومی منبع (RPKI) و اعتبارسنجی منشأ مسیر (ROV) برای جلوگیری از این حملات استفاده میکنند. RPKI ROV از رکوردهای رمزنگاریشدهای به نام «مجوزهای منشأ مسیر» (ROAs) استفاده میکند تا منشأ صحیح و طول ماسک پیشوند مسیرها را تأیید کند. سیستمهای AS که RPKI ROV را مستقر کردهاند، مسیرهایی را که با ROA مطابقت ندارند، رد میکنند.
اما مهاجمان با جعل مسیر AS، این سیستم را دور زدند. آنها AS24940 را به عنوان آخرین ASN در مسیر اضافه کردند. این کار باعث شد مسیر به دو دلیل برای RPKI «معتبر» به نظر برسد:
۱. مجوز ROA ایجاب میکرد که منشأ مسیر AS24940 باشد.
۲. مجوز ROA اجازه میداد طول پیشوند هر عددی بین ۱۶ تا ۲۴ باشد.
بن کارترایت-کاکس این لغزشها را «اشتباهات احمقانه و قابل پیشگیری» نامید. شرکت Hetzner Online تنظیمات RPKI خود را بهگونهای پیکربندی کرده بود که زیر-پریفیکسهای بسیار کوچک (تا /24) را هم معتبر بداند. این خطای پیکربندی عملاً لایه دفاعی را خنثی کرد و اجازه داد مسیر جعلی بدون اینکه توسط ASهای سختگیر رد شود، در سطح جهانی منتشر شود.
سقوط آخرین خط دفاع: TLS و امضای کد
مهاجمان به مسیریابی اکتفا نکردند. آنها از فضای IP ربوده شده برای فریب دادن Let's Encrypt (یک مرجع صدور گواهینامه) استفاده کردند تا گواهینامههای TLS معتبر صادر کند. بهطور معمول، متقاضی باید کنترل دامنه را از طریق مجموعهای از نقاط انتهایی پراکنده جغرافیایی اثبات کند و Let's Encrypt برای صدور گواهینامه به یک حد نصاب (Quorum) از نتایج مثبت نیاز دارد.
با هدف قرار دادن محدوده کوچک /24، ربایش در سطح جهانی پخش شد و باعث شد درخواستهای اعتبارسنجی بهجای اپراتور قانونی، به سرور مهاجم برسد. Let's Encrypt اشاره کرد که اگر از «اتصال حساب مجوز مجوز مرجع صدور» (CAA account binding) استفاده میشد — که صادرکنندگان و روشهای اعتبارسنجی پذیرفته شده را محدود میکند — این کار بهمراتب دشوارتر میشد.
زمانی که مهاجمان گواهینامه معتبر و کنترل ترافیک را به دست آوردند، آخرین خط دفاع، اعتبارسنجی نرمافزار بود. Softaculous اعتراف کرد که کلاینتهای بهروزرسانی محصولاتش، بستههای بهروزرسانی را بهصورت رمزنگاریشده تأیید نمیکردند. به دلیل نبود امضای دیجیتال (Code Signing)، سرورهای Virtualizor بدافزارها را بهعنوان بهروزرسانیهای قانونی پذیرفتند. Softaculous هشدار داد هر نصبی که ترافیک آن منحرف شده باشد، احتمالاً بسته مخربی را از سرور مهاجم دریافت کرده است.
خط زمانی رخنه
این حمله در یک بازه ۳۳ ساعته که از عصر جمعه (به وقت UTC) شروع شد، رخ داد:
۱. شروع ربایش درست قبل از ساعت ۹ شب جمعه بود، زمانی که پیشوند 162.55.80.0/24 وارد جدول مسیریابی جهانی شد.
۲. شرکت Hetzner Online ۱۲ ساعت بعد با اعلام مسیر صحیح، فضای IP را بازپس گرفت.
۳. سپس Hetzner اعلام مسیر را متوقف کرد و مهاجمان برای بار دوم دقیقاً همان ربایش را اجرا کردند.
۴. واکنش نهایی و شناسایی ناهنجاری توسط سه شرکت درگیر پس از ۱۰ ساعت در موج دوم رخ داد.
در مجموع، این ربایش به مدت ۲۲ ساعت بهصورت متناوب (روشن و خاموش) ادامه یافت تا اینکه Softaculous، Hetzner و Zet.net متوجه ناهنجاری شدند.
پیامدهای حادثه
اگرچه Softaculous معتقد است تنها تعداد کمی از سرورها تحت تأثیر قرار گرفتهاند، اما نمیتواند لیست قطعی از آنها ارائه دهد. آنها از تمام مدیران سرور Virtualizor خواستهاند که سیستم خود را بهصورت احتمالی آلوده فرض کرده و بررسیهای امنیتی جامع انجام دهند.
این اتفاق یک نمونه نادر و خطرناک از استفاده از ربایش BGP برای توزیع فعال بدافزار است. در حالی که حملات مشابهی در سال ۲۰۱۵ (Hacking Team) و سال ۲۰۲۲ (جایی که مهاجمان IPهای آمازون را برای میزبانی یک قرارداد هوشمند ربودند و ۲۳۵,۰۰۰ دلار بیتکوین از کاربران Celer Bridge دزدیدند) رخ داده بود، مقیاس این تخریب در زنجیره تأمین برای مدیران زیرساخت بسیار نگرانکننده است. این رویکرد تهاجمی به توزیع بدافزار در مقیاس وسیع، یادآور نفوذ گسترده کرم Shai-Hulud است که توسط گروه TeamPCP برای آلوده کردن هزاران سازمان به کار گرفته شد.
برای یک مالک کسبوکار یا مدیر IT، این یک یادآوری تلخ است که امنیت شما تنها به اندازه ضعیفترین ارائهدهنده شماست. شما ممکن است امنیت داخلی بینقصی داشته باشید، اما اگر ارائهدهنده میزبانی شما یک مسیر BGP را اشتباه پیکربندی کند، کانال بهروزرسانی مورد اعتماد شما میتواند به سلاحی علیه خودتان تبدیل شود.
تغییر در الگوهای حمله نشان میدهد که هکرها از سرقت ساده دادهها فراتر رفته و به سمت دستکاری پروتکلهای اصلی مسیریابی اینترنت حرکت میکنند تا ابزارهای مدرن رمزنگاری و اعتبارسنجی را دور بزنند. برای محافظت از زیرساخت خود، باید مکانیزمهای بهروزرسانی نرمافزاری را بازبینی کنید تا مطمئن شوید حتماً به امضاهای رمزنگاریشده نیاز دارند و تأیید کنید که ارائهدهندگان میزبانی شما RPKI ROV را بهطور سختگیرانه و بدون طولهای پیشوند بیش از حد آزاد، اجرا میکنند.
گام بعدی شما
- اگر مدیر سرور هستید، تمام نصبهای Virtualizor را بهصورت احتمالی آلوده فرض کرده و بررسیهای امنیتی را آغاز کنید.
- از ارائهدهنده میزبانی خود بخواهید وضعیت اجرای سختگیرانه RPKI ROV را تأیید کند.
- مکانیزمهای بهروزرسانی نرمافزاری خود را بازبینی کنید تا مطمئن شوید هر بسته حتماً دارای امضای رمزنگاریشده است.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما درباره تراشههای Blackwell مراجعه کنید.
گفتگو