سقوط امنیت در لایه زیرساخت: وقتی وصله‌های مایکروسافت از بوت‌کیت‌ها عقب می‌مانند

شکاف عمیق میان وصله و امنیت؛ پارادوکس BlackX

در دنیای امنیت سایبری، تصور عمومی بر این است که با دریافت آخرین آپدیت‌های ویندوز، سیستم در برابر تهدیدات نفوذناپذیر می‌شود. اما ظهور بدافزار جدیدی به نام BlackX، این باور را به چالش کشیده است. این بوت‌کیت (Bootkit) که در لایه UEFI (Unified Extensible Firmware Interface) عمل می‌کند، توانسته است از سدهای امنیتی سیستم‌هایی عبور کند که تمامی وصله‌های رسمی مایکروسافت (Microsoft) را دریافت کرده‌اند. این یعنی حتی با وجود نصبِ به اصطلاح «کامل» به‌روزرسانی‌ها، زنجیره اعتماد (Chain of Trust) در سطح سخت‌افزار همچنان آسیب‌پذیر باقی مانده است.

مسئله اصلی به ضعف در درک مشترک از مکانیسم‌های امنیتی بازمی‌گردد. زمانی که حفره Baton Drop (شناسه CVE-2022-21894) در سال ۲۰۲۲ کشف شد، مایکروسافت به سرعت برای آن وصله‌ای ارائه کرد. با این حال، همان‌طور که در مورد BlackLotus دیدیم و اکنون در BlackX شاهد آن هستیم، صرفِ نصب وصله کافی نیست. ما با وضعیتی مواجهیم که در آن مایکروسافت برای جلوگیری از غیرقابل بوت شدن میلیون‌ها سیستم، از ابطال کامل گواهی‌های دیجیتالِ آسیب‌پذیر خودداری کرده و مسئولیت این اقدام حیاتی را بر دوش مدیران شبکه گذاشته است؛ مسئولیتی که بخش بزرگی از آن‌ها حتی از وجودش بی‌اطلاع هستند.

چرا Secure Boot در برابر BlackX شکست خورد؟

قابلیت Secure Boot برای تضمین یکپارچگی فرآیند بوت طراحی شده است. این مکانیسم با بررسی امضای دیجیتالِ هر قطعه از نرم‌افزار بوت، مانع از اجرای کدهای غیرمجاز پیش از بارگذاری سیستم‌عامل می‌شود. اما BlackX از همان منطقی استفاده می‌کند که پیش‌تر در BlackLotus دیده بودیم: بهره‌برداری از یک نقص منطقی در Boot Manager ویندوز که اجازه می‌دهد امضاهای دیجیتالِ قدیمی و آسیب‌پذیر همچنان معتبر تلقی شوند.

از دیدگاه معماری زیرساخت ابری، این یک فاجعه است. بدافزاری که در لایه UEFI اجرا می‌شود، پیش از آنکه آنتی‌ویروس‌ها یا سیستم‌های دفاعی ویندوز فعال شوند، کنترل کامل سخت‌افزار و هسته (Kernel) را به دست می‌گیرد. وقتی این بدافزار در لایه اولیه نفوذ می‌کند، عملاً هرگونه امنیت نرم‌افزاریِ پس از آن، بی‌اثر می‌شود. این یعنی مهاجم می‌تواند به سادگی کلیدهای رمزنگاری BitLocker را استخراج کرده و به داده‌های حساس دسترسی پیدا کند، بدون اینکه کاربر متوجه کوچک‌ترین تغییری در عملکرد سیستم شود.

معمای ابطال گواهی؛ وقتی احتیاط به قیمت ناامنی تمام می‌شود

مایکروسافت در سال ۲۰۲۳ گواهی جدیدی به نام Windows UEFI CA 2023 معرفی کرد تا جایگزین ساختارهای قدیمی شود. در سال ۲۰۲۴ نیز ابزاری برای افزودن گواهی‌های سال ۲۰۱۱ به لیست سیاه (Forbidden Signatures) فراهم شد. اما مشکل اینجاست: اجرای این تغییرات نیازمند مداخله دستی ادمین‌هاست. مایکروسافت به جای اعمال خودکار این ابطال‌ها، ترجیح داده است سیستم را در وضعیتی میان‌مدت و ناامن رها کند تا از خرابی احتمالی سیستم‌های قدیمی جلوگیری کند.

این سیاستِ «بقا»، عملاً به مهاجمان اجازه داده است تا با تحلیل دقیقِ نحوه عملکردِ وصله‌ها، نسخه‌های کپی‌برداری شده از بوت‌کیت‌ها را توسعه دهند. محققان کسپرسکی (Kaspersky) به درستی اشاره کرده‌اند که دستورالعمل‌های مایکروسافت برای فعال‌سازی این حفاظت‌های امنیتی، در لایه‌های عمیق مستندات وب‌سایت این شرکت دفن شده است. برای یک مدیر سیستم که با صدها سرور و ورک‌استیشن سروکار دارد، دنبال کردن این دستورالعمل‌های پیچیده و غیرمستقیم، در اولویت اجرایی قرار نمی‌گیرد.

شکافِ شفافیت در اکوسیستم مایکروسافت

نقد اصلی به نحوه مدیریت مایکروسافت وارد است. در آخرین مقالات پایگاه دانش (Knowledge Base) این شرکت، هیچ هشدار صریحی مبنی بر اینکه «نصب وصله‌های فعلی به تنهایی شما را در برابر حملات Baton Drop محافظت نمی‌کند» وجود ندارد. این عدم شفافیت، باعث ایجاد یک حس امنیت کاذب در سازمان‌ها شده است. در حالی که امنیت زیرساخت باید بر مبنای «امنیت به صورت پیش‌فرض» (Security by Default) باشد، مایکروسافت رویکرد «امنیت به صورت اختیاری و پیچیده» را در پیش گرفته است.

این رویداد، زنگ خطری برای تمامی مهندسان دواپس (DevOps) و مدیران زیرساخت است. در معماری‌های مدرن، ما به دنبال اتوماسیون و پایداری هستیم؛ اما وقتی لایه‌های زیرین (Firmware) با چنین آشفتگی در مدیریت گواهی‌ها مواجه باشند، کل لایه‌های اپلیکیشنی و ابریِ مستقر روی آن‌ها نیز در معرض خطر قرار می‌گیرند. زمان آن رسیده است که غول‌های تکنولوژی در قبال مسئولیت‌های زیرساختی خود، شفاف‌تر عمل کرده و به جای ترس از خرابی‌های احتمالی، راهکارهای اتوماتیک و استاندارد برای پاک‌سازیِ گواهی‌های تاریخ‌گذشته ارائه دهند.