کشف رخنه امنیتی خطرناک در سفت‌افزار UEFI سرورها؛ هشداری جدی برای دیتاسنترهای سراسر جهان

تیم‌های امنیت سایبری در سراسر جهان بار دیگر با چالش مهار یک آسیب‌پذیری خطرناک اجرای کد مواجه شده‌اند؛ نقصی که این بار در سفت‌افزارهای زمان راه‌اندازی رخنه کرده و اکثر دیتاسنترها و تولیدکنندگان سرور در جهان را تحت تأثیر قرار داده است.

این آسیب‌پذیری با امتیاز شدت ۹٫۵ از ۱۰، در پروژه EDK II متعلق به TianoCore ریشه دارد؛ پایگاه‌کد متن‌بازی که سازندگان سخت‌افزار و ارائه‌دهندگان خدمات ابری از آن برای توسعه سفت‌افزارهای UEFI در فرایند بوت سیستم استفاده می‌کنند. سال گذشته، نماینده انجمن UEFI در گزارشی، EDK2 را «برترین راه‌کار و پیاده‌سازی رسمی برای مشخصات UEFI» نامید. تقریباً تمام ارائه‌دهندگان مستقل بایوس (IBV) نظیر AMI، Insyde و Phoenix به‌طور گسترده از این کد مرجع بهره می‌برند. حتی پروژه Project Mu، نسخه امن‌سازی‌شده EDK2 توسط مایکروسافت، نیز حاوی این بخش آسیب‌پذیر بوده است.

این آسیب‌پذیری با شناسه CVE-2026-97631، یک نقص تخریب حافظه در مؤلفه پروتکل ICMP است که مهاجمان می‌توانند با سوءاستفاده از آن، کدهای مخرب خود را حتی پیش از فعال‌شدن تدابیر امنیتی سیستم‌عامل و سفت‌افزار اجرا کنند. از جمله این تدابیر دفاعی می‌توان به راه‌اندازی امن (Secure Boot) اشاره کرد که زنجیره اعتماد تمام کدهای بارگذاری‌شده، از جمله ماژول پلتفرم مورد اعتماد یا TPM، را تضمین می‌کند. اگرچه پی‌لودهای نهایی حاصل از این رخنه پایداری ندارند (به این معنی که فقط یک‌بار اجرا می‌شوند)، اما فرصت فوق‌العاده‌ای برای مهاجمان فراهم می‌کنند تا بدافزارهای دیگری نصب کنند که در مراحل ابتدایی بوت سیستم اجرا شوند.

افشای زودهنگام و آغاز دردسرها

کاشفان این رخنه امنیتی، یعنی الکس ماتراسف از شرکت Anthropic و دن هولمز از گوگل، توافق کرده بودند جزییات این آسیب‌پذیری تا زمان افشای هماهنگ در ماه ژانویه محرمانه بماند. با این حال، شرکت AMI که از سازندگان شناخته‌شده مادربرد و سخت‌افزار است، ماه گذشته درخواست پول‌ریکوئستی در گیت‌هاب ثبت کرد که جزییات آسیب‌پذیری و کد اصلاحی آن را در بر داشت. پس از جلب توجه کاشفان این نقص به موضوع، اعضای پروژه TianoCore هفته گذشته یک بیانیه امنیتی عمومی منتشر کردند.

با عمومی‌شدن کد وصله، برای هکرهای پیشرفته بسیار ساده خواهد بود که نحوه فعال‌سازی این باگ را درک کنند و اکسپلویت‌های عملیاتی بسازند. آنچه وضعیت را بحرانی‌تر می‌کند، دشواری و زمان‌بر بودن به‌روزرسانی کد UEFI در میلیون‌ها دستگاه سرور است که توسط هزاران سازنده سخت‌افزار و ارائه‌دهنده ابری عرضه شده‌اند و مورد استفاده قرار می‌گیرند. خبر این آسیب‌پذیری تنها شش روز پس از افشای زودهنگام یک رخنه خطرناک اجرای کد در زبان برنامه‌نویسی PHP منتشر می‌شود.

اچ‌دی مور، خالق ابزار امنیتی Metasploit و مدیر ارشد تحقیقات در شرکت امنیتی Dragos، در این باره می‌گوید: «این رخنه در تحلیل‌گر ICMP پشته شبکه EDK2 از منظر تأثیری که بر زنجیره اعتماد و کل اکوسیستم می‌گذارد، بسیار حائز اهمیت است. مهاجمی که قصد نفوذ به یک کلاینت یا سرور مجاور را داشته باشد، می‌تواند از این آسیب‌پذیری برای تغییر مسیر اجرای برنامه در مقطعی استفاده کند که فرایند بوت هنوز به بخش‌های حساسی نظیر TPM دسترسی دارد. چنین نفوذی می‌تواند برای شکستن رمزنگاری دیسک در شرایطی که مهاجم دسترسی کوتاه‌مدت به شبکه دارد، به کار گرفته شود؛ امری که در سناریوهای سرقت فیزیکی حتی ساده‌تر هم خواهد بود.»

آسیب‌پذیری CVE-2026-97631 یک نقص سرریز بافر با قدمت ۱۶ سال در درایور PXE-Base Code با شناسه مسیر NetworkPkg/UefiPxeBcDxe است؛ درایوری که وظیفه دارد امکان بوت‌شدن سرورها، تجهیزات ذخیره‌سازی و سایر دستگاه‌ها را از طریق کدهای دریافتی از شبکه محلی فراهم کند. در جریان این فرایند (که با عنوان بوت محیط پیش از اجرا یا PXE شناخته می‌شود)، درایور با شنود ترافیک شبکه، خطاهای ICMP را رصد می‌کند. از آنجا که این درایور محدودیت کپی حافظه به اندازه ۵۰۴ بایت را اعمال نکرده و داده‌های مجاور را بازنویسی می‌کند، یک نفوذگر داخلی یا هکری که به شبکه محلی دسترسی سطح پایین پیدا کرده است، می‌تواند پیام خطایی ارسال کند که کدهای مخرب را فراتر از این محدوده بنویسد؛ در نتیجه ماژول UEFI در حال اجرا روی پردازنده دچار تخریب حافظه می‌شود.

متن بیانیه رسمی این نقص را این‌گونه تشریح می‌کند:

در طول بوت از طریق شبکه، درایور PXE Base Code (مسیر NetworkPkg/UefiPxeBcDxe) یک درخواست دریافت برای پیام‌های خطای ICMP را باز نگه می‌دارد و هر پیام دریافتی را در فیلد ثابت ۵۰۴ بایتی Mode.IcmpError در ساختار داخلی خود کپی می‌کند. مدیریت محدوده در حلقه کپی، هم در پردازنده‌های IPv4 و هم IPv6 (توابع PxeBcIcmpErrorDpcHandle و PxeBcIcmp6ErrorDpcHandle) نادرست است: برای پیام‌های طولانی‌تر از ۵۰۴ بایت، درایور همچنان بایت‌ها را در این فیلد کپی می‌کند و اشاره‌گر مقصد را بر اساس طول تجمعی و نه طول هر قطعه به جلو می‌برد؛ بنابراین یک پیام بیش‌ازحد بزرگ، بایت‌های تحت کنترل مهاجم را فراتر از مرز فیلد می‌نویسد. پیش از این مرحله نیز هیچ کنترلی در مسیر دریافت برای محدود کردن طول پیام وجود ندارد.

این پیام خطای مخرب را می‌توان از طریق یک بسته ساده یونیکست (Unicast) از هر فاصله شبکه‌ای به آدرس IP دستگاه هدف ارسال کرد، به شرط آنکه در طول توالی بوت PXE فرستاده شود. مهاجم با متوقف کردن فرایند بوت می‌تواند حمله محروم‌سازی از سرویس (DoS) ترتیب دهد. افزون بر این، در صورتی که مهاجم از بیلد و نسخه سفت‌افزار هدف آگاه باشد، می‌تواند یک «رویداد جعلی» ثبت کند که کد مخرب را مستقیماً در محیط سفت‌افزار UEFI روی پردازنده اجرا نماید. این کد در سطح Ring 0، یعنی بالاترین سطح دسترسی پردازنده، اجرا می‌شود. از آنجا که چنین اکسپلویت‌هایی فرایندهای گواهی امنیتی (Attestation) را که با محاسبات رمزنگاری امن‌بودن سخت‌افزار را به سرورهای راه دور اثبات می‌کنند دور می‌زنند، فرصت طلایی و کم‌نظیری برای ارتقای سطح دسترسی مهاجم به شمار می‌روند.

آسیب‌پذیری بی‌پایان؛ باگی که تا سال‌ها باقی خواهد ماند

آسیب‌پذیری CVE-2026-97631 به فهرست بلندبالایی از رخنه‌های امنیتی پیشین در UEFI و کدهای وابسته به آن می‌پیوندد. شدیدترین مورد در این میان، باگ مشهور LogoFail بود که از تصاویر لوگوی بارگذاری‌شده در UEFI تقریباً تمامی سازندگان سخت‌افزار ناشی می‌شد؛ باگ‌های رندرینگ تصویر به مهاجمان اجازه می‌دادند زنجیره اعتماد UEFI را بشکنند و پیش از بارگذاری سیستم‌عامل یا راه‌اندازی Secure Boot، اجزای مخرب خود را مستقر کنند. آسیب‌پذیری PixieFail نیز شباهت زیادی به باگ اخیر داشت و آن هم از نقص‌های بوت PXE در EDK2 نشأت می‌گرفت. به دنبال کشف آن آسیب‌پذیری، پژوهشگران چندین پروژه فازینگ و تحقیقاتی را در چارچوب پروژه‌های آزمون خودکار به راه انداختند تا سایر رخنه‌های بحرانی این کتابخانه متن‌باز را شناسایی کنند؛ اما به نظر می‌رسد این تلاش‌ها موفق به شناسایی باگ جدید نشده بودند.

از دیگر رخنه‌های امنیتی مهمی که در سال‌های اخیر در سفت‌افزارهای UEFI کشف شده‌اند، می‌توان به موارد زیر اشاره کرد:

• رخنه PKFail: نقص در زنجیره تأمین ناشی از کلیدهای آزمایشی غیرتولیدی که بیش از یک دهه پیش از افشا به‌صورت عمومی در دسترس بودند و در صدها مدل دستگاه به کار رفتند
• آسیب‌پذیری BootHole
• بدافزارهای بوت‌کیت (Bootkit)
• بدافزار معروف BlackLotus

مشابه CVE-2026-97631، بهره‌برداری از این نوع پی‌لودها جذابیت بالایی برای هکرها دارد؛ زیرا به آنها اجازه می‌دهد سیستم‌ها را در همان مراحل نخستین بوت و پیش از فعال شدن TPM و سایر تدابیر امنیتی آلوده کنند و بیشترین خسارت ممکن را به بار آورند. اچ‌دی مور با توجه به گستردگی چشمگیر این آسیب‌پذیری تأکید می‌کند که با یک باگ ماندگار مواجه هستیم؛ مشکلی که احتمالاً تا پایان عمر سیستم‌هایی که دیگر پشتیبانی دریافت نمی‌کنند، باقی خواهد ماند.

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

جسی مایکل، پژوهشگر ارشد در شرکت امنیت سفت‌افزار Eclypsium، درباره پیچیدگی‌های این حمله می‌گوید: «برای سوءاستفاده از این آسیب‌پذیری، مهاجم باید آدرس‌های حافظه خاصی را در سیستم هدف حدس بزند؛ بنابراین این‌گونه نیست که بتوان با یک اکسپلویت آماده و سراسری، روی طیف گسترده‌ای از دستگاه‌ها اجرای کد از راه دور (RCE) به دست آورد، بلکه کد حمله باید برای مدل، نسخه و پیکربندی دقیق هر سیستم هدف بهینه‌سازی شود؛ زیرا ساختار آدرس‌ها با تغییر هر یک از این موارد دگرگون می‌شود. با این حال بر خلاف رخنه‌های پر سر و صدای پیشین نظیر BootHole، BlackLotus یا Baton Drop، این آسیب‌پذیری با یک اصلاحیه کد ساده رفع می‌شود که البته نیازمند نصب به‌روزرسانی BIOS یا UEFI است، اما خوشبختانه نیازی به درگیر شدن با ابطال کلیدها، مدیریت کلیدهای امنیتی یا بازسازی رسانه‌های نصب سیستم‌عامل نخواهد بود.»

این آسیب‌پذیری کاربران خانگی و دفاتر کاری کوچک یا کاربرانی را که دستگاه‌های خود را صرفاً از روی دیسک‌درایوهای محلی بوت می‌کنند، تحت تأثیر قرار نمی‌دهد. در عوض، خطر اصلی متوجه سازمان‌ها و مراکزی است که سرورها و ماشین‌های آنها از طریق شبکه محلی یا منابع تحت شبکه راه‌اندازی می‌شوند. حتی در این حالت نیز سفت‌افزار سیستم باید حتماً مبتنی بر پروژه EDK2 بوده و قابلیت PXE در آن فعال باشد؛ قابلیتی که البته در بسیاری از سرورها به‌صورت پیش‌فرض روشن است.

شرکت اینتل اعلام کرده است تا جایی که مشخص شده، هیچ‌یک از «محصولات تجاری تحت پشتیبانی امنیتی» این شرکت تحت تأثیر این آسیب‌پذیری قرار ندارند. اینتل در توضیحات خود افزود: «اینتل قابلیت آسیب‌پذیر EDK2 را در کدهای مرجع خود قرار نمی‌دهد، اگرچه ممکن است توسط سازندگان مادربرد یا تولیدکنندگان سیستم‌ها یکپارچه‌سازی شده باشد.» این شرکت به مشتریان توصیه کرده است برای دریافت راهنمایی دقیق به سازنده سیستم‌های خود مراجعه کنند. با این حال، کد مرجع عمومی اینتل به EDK2 ارجاع دارد. افزون بر این، پروژه TianoCore نیز تصریح کرده است که بسته‌های توسعه UEFI ارائه‌شده توسط اینتل پیاده‌سازی کاملاً اعتبارسنجی‌شده‌ای از نگارش‌های مشخص کدهای منبع EDK II هستند و مستندات پرشمار دیگری نیز این وابستگی را تأیید می‌کنند.

در همین حال، شرکت Arm نیز اعلام کرده است که آسیب‌پذیری CVE-2026-97631 مستقیماً سبد محصولات این شرکت را تحت تأثیر قرار نمی‌دهد. با این وجود، مشابه اینتل، سفت‌افزارهای ارائه‌شده توسط این شرکت نیز به‌شدت به پایگاه‌کد EDK2 وابسته هستند و پروژه TianoCore نیز وابستگی مستقیم پلتفرم‌های Arm به EDK2 را در مستندات رسمی خود ثبت کرده است.

اگرچه ممکن است برخی از پلتفرم‌ها از کدهای EDK2 استفاده نکرده باشند، اما رویکرد محتاطانه و هوشمندانه برای تمامی مدیران سرور این است که احتمال تأثیرپذیری سیستم‌های خود از این آسیب‌پذیری را به‌دقت مورد ارزیابی قرار دهند.

شرکت‌های AMD، Phoenix Technologies، AMI و همچنین غول‌های فناوری مانند مایکروسافت و آمازون که احتمالاً از بزرگ‌ترین مجموعه‌های متأثر از این مشکل هستند، تا زمان انتشار این گزارش پاسخی به پرسش‌های مطرح‌شده نداده‌اند. بدون شفاف‌سازی شفاف این غول‌های فناوری پیرامون نحوه استفاده از EDK2 در دیتاسنترهای خود، نمی‌توان با قطعیت دامنه دقیق سرورهای آسیب‌پذیر و تدابیر در حال اجرا را تعیین کرد. نمایندگان پروژه TianoCore نیز هنوز توضیحی در این زمینه ارائه نکرده‌اند.

شاید کمبود جزییات فنی در روزهای نخست افشا برای برخی متخصصان رضایت‌بخش نباشد؛ اما در رخدادهایی که به افشای زودهنگام و شکسته شدن مهلت‌های محرمانگی پیش از موعد مقرر منجر می‌شوند، محدود بودن اطلاعات عملیاتی و تکمیلی در گزارش‌های اولیه امری اجتناب‌ناپذیر است.

به مدیران زیرساخت و سازمان‌های متأثر توصیه می‌شود فوراً با سازندگان سفت‌افزارهای سرورهای خود ارتباط برقرار کرده و دستورالعمل‌های اختصاصی را دریافت کنند. علاوه بر این، در صورت امکان، غیرفعال‌سازی موقت قابلیت بوت از طریق شبکه (PXE Boot) می‌تواند اقدام پیشگیرانه مؤثری باشد. پیکربندی سفت‌افزارها همواره باید ویژگی‌های امنیتی نظیر TPM و Secure Boot را در حالت فعال نگه دارد، هرچند این لایه‌ها به‌تنهایی قادر به مهار این تهدید ویژه نیستند. در نهایت، پایش مستمر گزارش‌ها و لاگ‌های شبکه برای شناسایی هرگونه تلاش احتمالی جهت نفوذ، نقشی حیاتی در حفظ امنیت زیرساخت‌ها خواهد داشت.