اعتماد دیجیتالی به سیستم Secure Boot مایکروسافت در یک دهه اخیر، تنها یک نمایش بود. پژوهشگران شرکت امنیتی ESET در ۱۴ ژوئیه ۲۰۲۶ فاش کردند که این استاندارد صنعتی برای مقابله با عفونت‌های فیرم‌ور، در ۱۳ سال از ۱۴ سال عمر خود، به‌سادگی قابل دور زدن بوده است.
سیستم Secure Boot در سال ۲۰۱۲ طراحی شد تا جلوی بوت‌کیت‌ها (Bootkits) — نرم‌افزارهای مخربی که پیش از بالا آمدن سیستم‌عامل اجرا می‌شوند — را بگیرد. این وضعیت شبیه درِ ورودیِ قفل‌شده‌ای است که صاحب‌خانه به‌اشتباه ۱۱ کلید اصلی را ۱۰ سال زیر پادری گذاشته باشد؛ هر هکر تازه‌کاری که این کلیدها را پیدا کند، می‌تواند مستقیماً وارد شود. این شکست، عملاً یکی از دفاع‌های اصلی در برابر حملات دولتی و عفونت‌های عمیق سیستمی را خنثی کرده است.
همان‌طور که در تحلیل قبلی ما درباره‌ی تحلیل تنظیمات عمیق PC توسط Microsoft Copilot اشاره کردیم، این کشف نشان‌دهنده یک شکنندگی ساختاری در مدیریت مرز سخت‌افزار و نرم‌افزار در ویندوز است. در حالی که هوش مصنوعی عمیق‌تر در سیستم‌عامل ادغام می‌شود، زیربنای فرآیند بوت به‌طرز خطرناکی متخلخل باقی مانده است.
شکست در مدیریت شیم‌ها
مرکز این رخنه، «شیم‌ها» (Shims) هستند؛ قطعات کوچکی از نرم‌افزار که برای گسترش Secure Boot به دستگاه‌های لینوکسی و ابزارهای کاربردی مختلف استفاده می‌شوند. ESET طبق گزارش خود، ۱۱ تصویر فیرم‌ور — که برخی از آن‌ها به سال ۲۰۱۳ بازمی‌گردند — را شناسایی کرد که معیوب بودند اما همچنان امضای دیجیتال مایکروسافت را داشتند.
با استفاده از تکنیکی که حتی برای هکرهای تازه‌کار ساده است، این شیم‌های فراموش‌شده به مهاجمان اجازه می‌دهند حفاظ‌های تعبیه شده در UEFI (رابط فیرم‌ور توسعه‌یافته یکپارچه) مادربرد دستگاه را کاملاً دور بزنند. از آنجا که این شیم‌ها هرگز ابطال نشدند، یک مهاجم برای نفوذ نیازی به استفاده از اکسپلویت‌های پیچیده «روز صفر» (Zero-day) ندارد.
مارتین اسمولار، پژوهشگر ESET، در این باره خاطرنشان می‌کند که مهاجم به هیچ ابزار یا متد پیچیده‌ای برای بهره‌برداری نیاز ندارد. او تنها به یک کپی از یک باینری قدیمی که هنوز مورد اعتماد است و درک اولیه‌ای از مکانیسم‌های کاری UEFI نیاز دارد تا یکی از حیاتی‌ترین ویژگی‌های امنیتی سیستم را از کار بیندازد.
گستره تهدید
بر اساس مستندات ESET، این تهدید هم کاربران ویندوز و هم کاربران لینوکس را به طور یکسان تحت تأثیر قرار می‌دهد، زیرا شیم می‌تواند روی دستگاه‌هایی که هر یک از این دو سیستم‌عامل را اجرا می‌کنند، نصب شود. وقتی یک شیم آسیب‌پذیر بارگذاری شود، مهاجم می‌تواند زنجیره اجباری از فیرم‌ورهای امضا شده دیجیتال را دور زده و کد مخرب خود را نصب کند.
این اتفاق اجازه می‌دهد فیرم‌ورهای مخربی نصب شوند که بسیار زود در ابتدای فرآیند بوت اجرا می‌شوند. چنین عفونت‌هایی بسیار خطرناک هستند زیرا حتی اگر کاربر سیستم‌عامل را دوباره نصب کند یا به طور کامل هارد دیسک را تعویض نماید، باز هم در سیستم باقی می‌مانند.
برخی از بوت‌کیت‌های تاریخی و بارهای مخربی که از این نبودِ حفاظت بهره‌برداری کرده‌اند — به‌ویژه در مواردی که مهاجمان دسترسی فیزیکی کوتاهی به دستگاه داشته‌اند — عبارت‌اند از:
- LoJax: که در سال ۲۰۱۸ توسط هکرهای دولتی روسیه مورد استفاده قرار گرفت.
- MosaicRegressor: که در سال ۲۰۲۰ شناسایی شد.
- CosmicStrand: که در سال ۲۰۲۲ کشف گردید.
- BlackLotus: که در سال ۲۰۲۳ شناسایی شد.
- موارد دیگر: بوت‌کیت‌های متعددی در محیط واقعی که تحت نام‌هایی چون ESpecter، FinSpy و MoonBounce ردیابی شده‌اند.
تله پیچیدگی
مایکروسافت نظارت بر امضای این شیم‌ها را بر عهده داشت اما در ابطال ۱۱ تصویر خاص شکست خورد؛ در برخی موارد این اهمال بیش از یک دهه ادامه داشت. این شرکت سرانجام در به‌روزرسانی ماه ژوئن ۲۰۲۶، پس از آنکه ESET موضوع را به اطلاع CERT و خود شرکت رساند، اصلاحیه لازم را منتشر کرد.
این شکست از پیچیدگی شدید محیط UEFI ناشی می‌شود. سیستم مذکور به دو پایگاه داده اصلی متکی است:
- db: فهرستی از تمام گواهینامه‌های امضا و هش‌های Authenticode که مجاز هستند.
- dbx: شامل گواهینامه‌ها و هش‌هایی که دیگر مورد اعتماد نیستند و باید مسدود شوند.
برای اینکه یک جزء بارگذاری شود، باید ابتدا از طریق db تأیید شود و نباید در dbx ابطال شده باشد. اما مشکل اینجاست که فضای اختصاص داده شده به dbx تنها ۳۲ کیلوبایت است. با توجه به تعداد بسیار بالای اجزای لینوکسی که در زمان بوت اجرا می‌شوند، فهرست کردن تک‌تک آن‌ها در این فضای محدود غیرممکن است.
برای مدیریت این محدودیت، مایکروسافت از روش‌های ابطال مبتنی بر نسخه استفاده می‌کند. در حالی که dbx باینری‌های تکی را ابطال می‌کند، SBAT (هدف‌گیری پیشرفته بوت امن) و شماره نسخه امنیتی (SVN) کل نسخه‌ها را ابطال می‌کنند. این رویکرد اجازه می‌دهد یک شماره نسخه واحد، تمام بیلدها (Builds) تا یک نسخه معیوب خاص را پوشش دهد، تا دیگر نیازی به نگهداری لیست‌های طولانی از هش‌ها نباشد.
مکانیسم ابطال نسخه
هر جزء در لودر UEFI حاوی متادیتایی است که با همان گواهینامه باینری امضا شده است. این متادیتا شامل یک شماره نسل (Generation Number) است که با هر اصلاح امنیتی جدید، افزایش می‌یابد.
- یک متغیر مخصوص بوت در UEFI، حداقل شماره نسل قابل قبول برای هر جزء را ذخیره و نگهداری می‌کند.
- در این ساختار، شیم است که شماره این متغیر را اعمال می‌کند، نه خودِ فیرم‌ور.
- شیم این سیاست را از طریق مکانیسمی به نام SbatLevel تعبیه می‌کند تا اجرای سیاست‌ها صرفاً به متغیر خارجی وابسته نباشد.
در هر بار بوت، شیم متادیتای SBAT خود را با سیاست‌های موجود بررسی می‌کند. یک شیم قدیمی می‌تواند به گونه‌ای تنظیم شود که پیش از اعمال همین تست بر روی هر باینری بعدی که بارگذاری می‌کند، ابتدا خودش را رد کند. با این حال، حتی انقضای گواهینامه مایکروسافت که شیم‌ها را امضا کرده بود در ماه گذشته، باز هم برای ابطال ۱۱ مورد شناسایی شده توسط ESET کافی نبود.
گالری کدهای معیوب
این ۱۱ شیم شناسایی شده توسط CERT، توزیع‌کنندگان و ابزارهای سازمان‌های مختلفی را شامل می‌شد:
- توزیع‌کنندگان لینوکس: شیم‌های مورد استفاده در Redhat، OpenSuse و Oracle.
- نرم‌افزارهای شخص ثالث: ابزارهایی مانند PC-Doctor و سیستم‌های مربوط به هیئت امتحانات رسمی فنلاند.
این شیم‌ها به دلایل متمایزی شکست خوردند:
- نبود پشتیبانی: بسیاری از آن‌ها پیش از آنکه حفاظ‌هایی مثل SBAT یا لیست‌های رد MOK (کلیدهای مالکیت) وجود داشته باشند، ساخته شده بودند.
- باگ‌های داخلی: برخی حاوی باگ‌های انباشته در کد خود یا در باینری‌های مرحله دوم بودند که توسط آن‌ها تأیید می‌شدند.
- اکسپلویت‌های شناخته شده: برای مثال، شیم Oracle باینری‌ای را امضا می‌کند که به آسیب‌پذیری CVE-2015-5381 حساس است؛ نقصی که ESET می‌گوید بهره‌برداری از آن نیاز به مهارت بسیار کمی دارد.
واکنش متخصصان
اچ. دی مور، مدیرعامل runZero و منتقد قدیمی این سیستم، این اتفاق را یک «توبیخ جدی» برای کل مدل Secure Boot می‌داند. او استدلال می‌کند که قرار دادن مایکروسافت به‌عنوان ریشه اعتماد (Root of Trust) پیش‌فرض برای کل پلتفرم UEFI، یک خطای معماری بنیادی است.
مور اشاره می‌کند که این سیستم نمی‌تواند به‌اندازه کافی مقیاس‌پذیر شود. او خاطرنشان می‌کند که نتیجه این وضعیت، ایجاد تعداد عظیمی از اجزای امضا شده است — که هیچ‌کس جز مایکروسافت از آن‌ها باخبر نیست — که Secure Boot را دور می‌زنند و به‌دلیل باگ‌های امنیتی معمولی، می‌توانند تقریباً هر چیزی را بوت کنند.
مور مدعی است که این اکوسیستم «تا حدی شکسته است و نیاز به بازنگری کلی (Reboot) دارد»، زیرا اجزا اغلب حتی پس از انقضای گواهینامه‌های سطح بالایشان نیز قادر به بوت شدن هستند.
برای اکثر کاربران، اگر به‌روزرسانی ژوئن را نصب کرده باشند، ریسک کاهش یافته است، هرچند PCهای Secured-core در ویندوز ۱۱ در حالت پیش‌فرض احتمالاً آسیب‌پذیر نبودند. به کاربران لینوکس توصیه می‌شود وضعیت ابطال خود را از طریق Linux Vendor Firmware Service یا اسکریپت uefi-dbx-audit بررسی کنند.
این شکست نشان می‌دهد که اتکای صنعت به یک شرکت واحد برای مدیریت اعتماد سخت‌افزاری جهانی، یک نقطه شکست بحرانی است. با محو شدن مرز بین فیرم‌ور و سیستم‌عامل، نیاز به یک سیستم ابطال شفاف و مقیاس‌پذیر فوری است.
گام بعدی شما
- اگر کاربر لینوکس هستید، فوراً از اسکریپت
uefi-dbx-auditبرای بررسی وضعیت ابطال شیم‌ها استفاده کنید. - مطمئن شوید تمام به‌روزرسانی‌های امنیتی ژوئن ۲۰۲۶ ویندوز را نصب کرده‌اید.
- برای سازمان‌ها: بررسی کنید آیا از ابزارهای قدیمی مدیریت سخت‌افزار استفاده می‌کنید که ممکن است شیم‌های معیوب را بارگذاری کنند.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو