🥇دانلود مورد اعتماد شرودینگر. اینتل بوت گارد

ما پیشنهاد می کنیم دوباره به سطح پایین برویم و در مورد امنیت سیستم عامل های رایانه ای سازگار با x86 صحبت کنیم. این بار، عنصر اصلی مطالعه اینتل Boot Guard است (نباید با Intel BIOS Guard اشتباه گرفته شود!) - یک فناوری بوت قابل اعتماد بایوس با پشتیبانی سخت افزاری که یک فروشنده سیستم کامپیوتری می تواند به طور دائم در مرحله تولید روشن یا خاموش کند. خب، ما از قبل دستور تحقیق را می‌دانیم: اجرای این فناوری را با مهندسی معکوس برش دهید، معماری آن را توصیف کنید، آن را با جزئیات غیرمستند پر کنید، آن را با بردارهای حمله مزه کنید و آن را مخلوط کنید. بیایید آتش را با داستانی اضافه کنیم که چگونه یک باگ شبیه‌سازی شده در تولید چندین فروشنده برای سال‌ها به مهاجم بالقوه اجازه می‌دهد از این فناوری برای ایجاد یک روت کیت مخفی استفاده کند که نمی‌تواند (حتی توسط یک برنامه‌نویس) در سیستم حذف شود.

به هر حال، مقاله بر اساس گزارش های "On Guard for Rootkits: Intel BootGuard" از کنفرانس است. ZeroNights 2016 و بیست و نهمین جلسه DefCon روسیه (هر دو ارائه اینجا).

سفت‌افزار برای پلتفرم رایانه‌ای با معماری Intel 64

برای شروع، اجازه دهید به این سوال پاسخ دهیم: سیستم عامل یک پلت فرم کامپیوتر مدرن با معماری Intel 64 چیست؟ البته بایوس UEFI. اما این پاسخ دقیق نخواهد بود. بیایید نگاهی به شکلی بیندازیم که نسخه دسکتاپ (لپ تاپ) این معماری را نشان می دهد.

اساس پیوند است:

پردازنده (CPU، واحد پردازش مرکزی)، که علاوه بر هسته های اصلی، دارای یک هسته گرافیکی داخلی (نه در همه مدل ها) و یک کنترلر حافظه (IMC، کنترلر حافظه یکپارچه) است.
چیپست (PCH، پلتفرم کنترلر هاب)، حاوی کنترلرهای مختلف برای تعامل با دستگاه های جانبی و مدیریت زیرسیستم ها. از جمله آنها می توان به موتور بدنام مدیریت اینتل (ME) اشاره کرد که دارای یک سیستم عامل (Intel ME firmware) نیز می باشد.

لپ‌تاپ‌ها علاوه بر موارد فوق، به یک کنترلر یکپارچه (ACPI EC، کنترل پیشرفته و کنترلر تعبیه شده رابط برق) نیاز دارند که وظیفه عملکرد زیرسیستم پاور، تاچ پد، صفحه‌کلید، کلیدهای Fn (روشنایی صفحه، حجم صدا، صفحه‌کلید) را بر عهده دارد. نور پس زمینه و غیره) و موارد دیگر. و همچنین فریمور مخصوص به خودش را دارد.

بنابراین، ترکیبی از فریمور فوق، سیستم عامل پلتفرم رایانه (سیستم فریمور) است که بر روی یک فلش مموری SPI مشترک ذخیره می شود. برای اینکه کاربران این حافظه در جایی که کسی دروغ می گوید گیج نشوند، محتویات این حافظه به مناطق زیر تقسیم می شود (همانطور که در شکل نشان داده شده است):

UEFI BIOS؛
سیستم عامل ACPI EC (یک ناحیه جداگانه با ریزمعماری پردازنده Skylake (2015) ظاهر شد، اما در طبیعت ما هنوز نمونه هایی از استفاده از آن را ندیده ایم، بنابراین سیستم عامل کنترل جاسازی شده هنوز بخشی از UEFI BIOS است).
سیستم عامل Intel ME؛
پیکربندی (آدرس MAC و غیره) آداپتور شبکه داخلی GbE (گیگابیت اترنت).
توصیفگرهای فلش - منطقه اصلی حافظه فلش، که شامل نشانگرهایی به مناطق دیگر و همچنین مجوزهای دسترسی به آنها است.

تمایز دسترسی به مناطق (مطابق با مجوزهای مشخص شده) توسط گذرگاه اصلی SPI - کنترلر SPI تعبیه شده در چیپست انجام می شود که از طریق آن به این حافظه دسترسی پیدا می شود. اگر مجوزها روی مقادیر توصیه شده (به دلایل امنیتی) توسط اینتل تنظیم شوند، هر کاربر فلش SPI فقط به منطقه خود دسترسی کامل (خواندن/نوشتن) دارد. بقیه یا فقط خواندنی هستند یا غیرقابل دسترسی هستند. واقعیت شناخته شده: در بسیاری از سیستم ها، CPU به UEFI BIOS و GbE دسترسی کامل دارد، فقط به توصیف کننده های فلش دسترسی دارد و اصلاً به منطقه ME اینتل دسترسی ندارد. چرا خیلی ها و نه همه؟ آنچه توصیه می شود اختیاری است. در ادامه مقاله بیشتر به شما خواهیم گفت.

مکانیسم هایی برای محافظت از سیستم عامل یک پلت فرم رایانه در برابر تغییر

بدیهی است که سفت‌افزار یک پلت‌فرم رایانه باید از خطرات احتمالی محافظت شود، که به مهاجم بالقوه اجازه می‌دهد تا در آن جای پای خود را به دست آورد (به‌روزرسانی‌ها / نصب مجدد سیستم عامل زنده بماند)، کد خود را در ممتازترین حالت‌ها و غیره اجرا کند. و البته محدود کردن دسترسی به مناطق حافظه فلش SPI کافی نیست. بنابراین، مکانیسم های مختلفی خاص برای هر محیط اجرا برای محافظت از سیستم عامل در برابر تغییرات استفاده می شود.

بنابراین، سیستم عامل Intel ME برای کنترل یکپارچگی و اصالت امضا شده است و هر بار که در حافظه ME UMA بارگذاری می شود توسط کنترلر ME بررسی می شود. این فرآیند تأیید قبلاً توسط ما در یکی از موارد مورد بحث قرار گرفته است مقالاتاختصاص داده شده به زیرسیستم Intel ME.

و سیستم عامل ACPI EC، به عنوان یک قاعده، فقط از نظر یکپارچگی بررسی می شود. با این حال، با توجه به این واقعیت که این باینری در بایوس UEFI گنجانده شده است، تقریبا همیشه در معرض مکانیزم های حفاظتی مشابهی است که UEFI BIOS از آن استفاده می کند. بیایید در مورد آنها صحبت کنیم.

این مکانیسم ها را می توان به دو دسته تقسیم کرد.

حفاظت را در منطقه UEFI BIOS بنویسید

محافظت فیزیکی از محتویات فلش مموری SPI با جامپر محافظت از نوشتن؛
محافظت از طرح ریزی منطقه UEFI BIOS در فضای آدرس CPU با استفاده از رجیسترهای PRx چیپست.
مسدود کردن تلاش برای نوشتن در منطقه UEFI BIOS با تولید و پردازش وقفه SMI مربوطه با تنظیم بیت های BIOS_WE / BLE و SMM_BWP در ثبات های چیپست.
یک نسخه پیشرفته تر از این محافظ Intel BIOS Guard (PFAT) است.

علاوه بر این مکانیسم ها، فروشندگان می توانند اقدامات امنیتی خود را توسعه داده و اجرا کنند (به عنوان مثال، امضای کپسول با به روز رسانی UEFI BIOS).

توجه به این نکته حائز اهمیت است که در یک سیستم خاص (بسته به فروشنده)، ممکن است همه مکانیسم‌های حفاظتی بالا اعمال نشوند، ممکن است اصلاً اعمال نشوند یا به روشی آسیب‌پذیر پیاده‌سازی شوند. می توانید در مورد این مکانیسم ها و وضعیت اجرای آنها بیشتر بخوانید این مقاله. به علاقه مندان، توصیه می کنیم کل مجموعه مقالات مربوط به امنیت UEFI BIOS را مطالعه کنند CodeRush.

تأیید اعتبار UEFI BIOS

وقتی در مورد فن آوری های بوت قابل اعتماد صحبت می کنیم، اولین چیزی که به ذهن می رسد Secure Boot است. با این حال، از نظر معماری، برای احراز هویت اجزای خارجی بایوس UEFI (درایورها، لودرها و غیره) طراحی شده است و نه خود سیستم عامل.

بنابراین، اینتل در SoCها با ریزمعماری Bay Trail (2012) یک سیستم سخت افزاری غیر قابل تعویض Secure Boot (Verified Boot) را پیاده سازی کرد که هیچ ارتباطی با فناوری Secure Boot فوق الذکر ندارد. بعداً (2013) این مکانیسم بهبود یافت و با نام Intel Boot Guard برای دسکتاپ ها با ریزمعماری Haswell عرضه شد.

قبل از توضیح اینتل Boot Guard، اجازه دهید به محیط های اجرایی در معماری اینتل 64 نگاهی بیندازیم، که در ترکیب، ریشه های اعتماد برای این فناوری بوت قابل اعتماد هستند.

اینتل CPU

Cap نشان می دهد که پردازنده محیط اجرای اصلی در معماری اینتل 64 است. چرا این نیز ریشه اعتماد است؟ معلوم می شود که داشتن عناصر زیر است که آن را چنین می کند:

Microcode ROM یک حافظه غیر فرار و غیر قابل بازنویسی برای ذخیره میکروکد است. اعتقاد بر این است که میکروکد پیاده سازی سیستم دستورالعمل پردازنده بر روی ساده ترین دستورالعمل ها است. در میکروکد هم اتفاق می افتد اشکالات. بنابراین در بایوس می‌توانید باینری‌هایی را با به‌روزرسانی‌های میکروکد پیدا کنید (آنها در زمان راه‌اندازی روی هم قرار می‌گیرند، زیرا رام قابل بازنویسی نیست). محتوای این باینری ها رمزگذاری شده است، که تجزیه و تحلیل را بسیار پیچیده می کند (بنابراین، محتوای خاص میکروکد فقط برای کسانی که آن را توسعه می دهند شناخته شده است)، و برای کنترل یکپارچگی و اصالت امضا شده است.
کلید AES برای رمزگشایی محتویات به‌روزرسانی‌های میکروکد.
هش کلید عمومی RSA که امضای به‌روزرسانی‌های میکروکد را تأیید می‌کند.
هش کلید عمومی RSA، که امضای ماژول‌های کد ACM (ماژول کد احراز هویت شده) توسعه‌یافته توسط اینتل را بررسی می‌کند، که CPU می‌تواند قبل از شروع بایوس (سلام میکروکد) یا در حین کار، زمانی که برخی رویدادها اتفاق می‌افتد، اجرا کند.

Intel ME

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

با وجود پنهان کاری، Intel ME نیز ریشه اعتماد است، زیرا دارای:

ME ROM - حافظه غیر فرار و غیر قابل بازنویسی (بدون روش به روز رسانی ارائه شده)، حاوی کد شروع، و همچنین هش SHA256 کلید عمومی RSA، که امضای سیستم عامل Intel ME را بررسی می کند.
کلید AES برای ذخیره اطلاعات سری؛
دسترسی به مجموعه ای از فیوزها (FPF، فیوزهای قابل برنامه ریزی میدانی) که در چیپست برای ذخیره دائمی برخی از اطلاعات، از جمله اطلاعات مشخص شده توسط فروشنده سیستم رایانه، یکپارچه شده است.

اینتل بوت گارد 1.x

سلب مسئولیت کوچک. شماره نسخه های فناوری Intel Boot Guard که در این مقاله استفاده می کنیم دلخواه هستند و ممکن است ربطی به شماره گذاری استفاده شده در اسناد داخلی اینتل نداشته باشند. علاوه بر این، اطلاعات مربوط به اجرای این فناوری که در اینجا ارائه شده است، در طول مهندسی معکوس به دست آمده است و ممکن است در مقایسه با مشخصات Intel Boot Guard، که بعید است هرگز منتشر شود، نادرستی داشته باشد.

بنابراین، Intel Boot Guard (BG) یک فناوری احراز هویت UEFI BIOS با پشتیبانی سخت افزاری است. با قضاوت بر اساس توضیحات کوچک آن در کتاب [پلتفرم Embedded Security Technology Revealed, Chapter Boot with Integrity, or Not Boot]، به عنوان یک زنجیره بوت قابل اعتماد کار می کند. و اولین لینک موجود در آن کد بوت (میکروکد) داخل CPU است که با رویداد RESET (با بردار RESET در بایوس اشتباه نشود!) راه اندازی می شود. CPU یک ماژول کد (Intel BG startup ACM) را پیدا می کند که توسط اینتل در حافظه فلش SPI توسعه یافته و امضا شده است، آن را در حافظه پنهان بارگذاری می کند، آن را تأیید می کند (قبلاً ذکر شد که CPU دارای یک هش کلید عمومی است که امضای ACM را تأیید می کند. ) و شروع می شود.

این ماژول کد مسئول تأیید قسمت شروع کوچک UEFI BIOS - Initial Boot Block (IBB) است که به نوبه خود دارای قابلیت تأیید بخش اصلی بایوس UEFI است. بنابراین، Intel BG به شما اجازه می دهد تا قبل از بوت کردن سیستم عامل، صحت BIOS را تأیید کنید (که می تواند تحت نظارت فناوری Secure Boot انجام شود).

فناوری Intel BG دو حالت کار را ارائه می دهد (و یکی با دیگری تداخل ندارد، یعنی هر دو حالت را می توان در سیستم فعال کرد و هر دو را می توان غیرفعال کرد).

چکمه اندازه گیری شده

در حالت Boot Measured (MB)، هر مؤلفه بوت (با ROM بوت CPU شروع می شود) مؤلفه بعدی را با استفاده از قابلیت های Trusted Platform Module (TPM) "اندازه گیری" می کند. برای اونایی که نمیدونن توضیح بدم

TPM دارای PCR (رجیسترهای پیکربندی پلت فرم) است که نتیجه عملیات هش را مطابق فرمول ثبت می کند:

آن ها مقدار فعلی PCR به مقدار قبلی بستگی دارد، و این رجیسترها تنها زمانی بازنشانی می شوند که سیستم RESET باشد.

بنابراین، در حالت MB، در نقطه‌ای از زمان، PCRها یک شناسه منحصربه‌فرد (در محدوده قابلیت‌های عملیات هش) از کد یا داده‌هایی را که «اندازه‌گیری شده‌اند» منعکس می‌کنند. مقادیر PCR را می توان در رمزگذاری برخی از عملیات داده ها (TPM_Seal) استفاده کرد. پس از آن، رمزگشایی آنها (TPM_Unseal) تنها در صورتی امکان پذیر خواهد بود که مقادیر PCR در نتیجه بارگذاری تغییر نکرده باشد (یعنی حتی یک جزء "اندازه گیری شده" اصلاح نشده باشد).

بوت تایید شده

ترسناک ترین چیز برای کسانی که دوست دارند بایوس UEFI را تغییر دهند حالت Verified Boot (VB) است که در آن هر جزء بوت به صورت رمزنگاری یکپارچگی و اصالت قسمت بعدی را تأیید می کند. و در صورت خطای تایید، (یکی از موارد زیر) رخ می دهد:

خاموش شدن با وقفه از 1 دقیقه تا 30 دقیقه (به طوری که کاربر وقت داشته باشد که بفهمد چرا رایانه او بوت نمی شود و در صورت امکان سعی کند بایوس را بازیابی کند).
خاموش شدن فوری (به طوری که کاربر وقت لازم برای درک و علاوه بر این، انجام را نداشته باشد)؛
ادامه کار با صورت مستقیم (موردی که زمانی برای ایمنی وجود ندارد، زیرا کارهای مهم تری وجود دارد).

انتخاب عمل بستگی به پیکربندی مشخص شده Intel BG (یعنی به اصطلاح سیاست اجرایی) دارد که به طور دائم توسط فروشنده پلت فرم رایانه در یک ذخیره سازی طراحی شده مخصوص - فیوزهای چیپست (FPF) ثبت می شود. بعداً به تفصیل بیشتر به این نکته خواهیم پرداخت.

علاوه بر پیکربندی، فروشنده دو کلید RSA 2048 ایجاد می کند و دو ساختار داده ایجاد می کند (در شکل نشان داده شده است):

مانیفست کلید ریشه فروشنده (KEYM، OEM Root Manifest)، که SVN (شماره نسخه امنیتی) این مانیفست، هش SHA256 کلید عمومی مانیفست بعدی، کلید عمومی RSA (یعنی بخش عمومی مانیفست) را قرار می دهد. کلید ریشه فروشنده) برای تأیید امضای این مانیفست و خود امضا؛
مانیفست IBB (IBBM، Initial Boot Block Manifest)، که SVN این مانیفست، هش SHA256 IBB، کلید عمومی برای تأیید امضای این مانیفست و خود امضا را قرار می دهد.

هش SHA256 کلید اصلی OEM به طور دائم روی فیوزهای چیپست (FPF) نوشته می شود، درست مانند پیکربندی Intel BG. اگر پیکربندی Intel BG گنجاندن این فناوری را فراهم می کند، از این پس این سیستم تنها صاحب بخش خصوصی کلید ریشه OEM می تواند BIOS را به روز کند (یعنی قادر به محاسبه مجدد این مانیفست ها باشد). فروشنده

وقتی به تصویر نگاه می کنید، بلافاصله تردیدهایی در مورد نیاز به چنین زنجیره تأیید طولانی ایجاد می شود - می توانستید از یک مانیفست استفاده کنید. چرا پیچیده؟

در واقع، اینتل به فروشنده این فرصت را می دهد تا از کلیدهای مختلف IBB برای خطوط تولید مختلف و یکی به عنوان روت استفاده کند. اگر قسمت خصوصی کلید IBB (که علامت مانیفست دوم را نشان می‌دهد) فاش شود، این رویداد تنها روی یک خط محصول تأثیر می‌گذارد و تنها تا زمانی که فروشنده یک جفت جدید ایجاد کند و مانیفست‌های محاسبه‌شده مجدد را در به‌روزرسانی بعدی بایوس فعال کند.

اما اگر کلید ریشه به خطر بیفتد (که اولین مانیفست با آن امضا شده است)، جایگزینی آن امکان پذیر نخواهد بود، روش ابطال ارائه نمی شود. هش بخش عمومی این کلید یک بار برای همیشه در FPF برنامه ریزی می شود.

پیکربندی Intel Boot Guard

حال بیایید نگاهی دقیق تر به پیکربندی Intel BG و روند ایجاد آن بیندازیم. اگر به برگه مربوطه در رابط کاربری گرافیکی Flash Image Tool از Intel System Tool Kit (STK) نگاه کنید، متوجه خواهید شد که پیکربندی Intel BG شامل یک هش از بخش عمومی کلید اصلی فروشنده است که چند مورد مبهم است. ارزش ها و غیره پروفایل BG اینتل.

ساختار این پروفایل:

typedef struct BG_PROFILE
{
	unsigned long Force_Boot_Guard_ACM : 1;
	unsigned long Verified_Boot : 1;
	unsigned long Measured_Boot : 1;
	unsigned long Protect_BIOS_Environment : 1;
	unsigned long Enforcement_Policy : 2; // 00b – do nothing
                                              // 01b – shutdown with timeout
                                              // 11b – immediate shutdown
	unsigned long : 26;
};

به طور کلی، پیکربندی Intel BG یک نهاد بسیار منعطف است. برای مثال پرچم Force_Boot_Guard_ACM را در نظر بگیرید. هنگامی که پاک شد، اگر ماژول ACM راه اندازی BG در فلش SPI پیدا نشد، هیچ راه اندازی قابل اعتمادی رخ نخواهد داد. غیر قابل اعتماد خواهد بود.

قبلاً در بالا نوشتیم که سیاست اجرایی برای حالت VB را می توان به گونه ای پیکربندی کرد که اگر تأیید نشد، دوباره یک بارگیری غیرقابل اعتماد رخ می دهد.

این قبیل کارها را به دست فروشندگان بسپارید...

رابط کاربری گرافیکی ابزار، نمایه های "آماده" زیر را ارائه می دهد:

شماره
حالت
شرح

0
No_FVME
فناوری Intel BG غیرفعال شده است

1
VE
حالت VB فعال است، با مهلت زمانی خاموش می شود

2
VME
هر دو حالت فعال هستند (VB و MB)، خاموش شدن با تایم اوت

3
VM
هر دو حالت بدون خاموش کردن سیستم فعال هستند

4
پنج
حالت VB فعال است، خاموش شدن فوری

5
FVME
هر دو حالت فعال است، خاموش شدن فوری

همانطور که قبلاً ذکر شد، پیکربندی Intel BG باید یکبار برای همیشه توسط فروشنده سیستم در فیوزهای چیپست (FPF) نوشته شود - یک ذخیره سازی اطلاعات سخت افزاری کوچک (طبق اطلاعات تأیید نشده، فقط 256 بایت) در داخل چیپست، که می تواند در خارج برنامه ریزی شود. از امکانات تولید اینتل (پس به همین دلیل است فیلد قابل برنامه ریزی فیوزها).

برای ذخیره تنظیمات عالی است زیرا:

دارای یک منطقه ذخیره سازی داده قابل برنامه ریزی یک بار (درست در جایی که پیکربندی Intel BG نوشته شده است).
فقط Intel ME می تواند آن را بخواند و برنامه ریزی کند.

بنابراین، به منظور تنظیم پیکربندی فناوری Intel BG بر روی یک سیستم خاص، فروشنده در حین تولید موارد زیر را انجام می دهد:

با استفاده از ابزار Flash Image Tool (از Intel STK)، یک تصویر میان‌افزار با پیکربندی Intel BG داده شده به عنوان متغیرهای داخل منطقه ME اینتل (به اصطلاح آینه موقت برای FPF) ایجاد می‌کند.
با استفاده از ابزار برنامه نویسی فلش (از Intel STK) این تصویر را روی فلش مموری SPI سیستم می نویسد و به اصطلاح بسته می شود. حالت ساخت (در این حالت دستور مربوطه به Intel ME ارسال می شود).

در نتیجه این عملیات، Intel ME مقادیر مشخص شده را از آینه برای FPF در منطقه ME به FPF ها متعهد می کند، مجوزها را در توصیفگرهای فلش SPI روی مقادیر توصیه شده توسط اینتل تنظیم می کند (توضیح داده شده در ابتدای مقاله) و بازنشانی سیستم را انجام دهید.

تجزیه و تحلیل پیاده سازی اینتل بوت گارد

به منظور تجزیه و تحلیل اجرای این فناوری بر روی یک مثال خاص، سیستم های زیر را برای ردپای فناوری Intel BG بررسی کردیم:

سیستم
یادداشت

گیگابایت GA-H170-D3H
Skylake، پشتیبانی وجود دارد

گیگابایت GA-Q170-D3H
Skylake، پشتیبانی وجود دارد

گیگابایت GA-B150-HD3
Skylake، پشتیبانی وجود دارد

MSI H170A Gaming Pro
Skylake، بدون پشتیبانی

لنوو ThinkPad 460
Skylake، پشتیبانی در دسترس، فناوری فعال است

لنوو یوگا 2 پرو
هاسول، بدون پشتیبانی

لنوو U330p
هاسول، بدون پشتیبانی

"پشتیبانی" به معنای وجود ماژول ACM راه اندازی Intel BG، مانیفست های ذکر شده در بالا و کد مربوطه در BIOS است، یعنی. پیاده سازی برای تجزیه و تحلیل

به عنوان مثال، بیایید دانلود شده از آفیس را در نظر بگیریم. تصویر سایت فروشنده از حافظه فلش SPI برای گیگابایت GA-H170-D3H (نسخه F4).

رام بوت سی پی یو اینتل

اول از همه، بیایید در مورد عملکرد پردازنده در صورت فعال بودن فناوری Intel BG صحبت کنیم.

یافتن نمونه‌هایی از میکروکد رمزگشایی شده ممکن نبود، بنابراین، نحوه اجرای اقدامات شرح داده شده در زیر (در میکروکد یا سخت‌افزار) یک سوال باز است. با این وجود، این واقعیت که پردازنده های مدرن اینتل "می توانند" این اقدامات را انجام دهند یک واقعیت است.

پس از خروج از حالت RESET، پردازنده (که محتویات فلش مموری قبلاً در فضای آدرس آن نقشه برداری شده است) FIT (جدول رابط میان افزار) را پیدا می کند. پیدا کردن آن آسان است، اشاره گر به آن در آدرس FFFF FFC0h نوشته شده است.

در این مثال، این آدرس حاوی مقدار FFD6 9500h است. با مراجعه به این آدرس، پردازنده جدول FIT را می بیند که محتویات آن به رکوردها تقسیم می شود. اولین ورودی سرفصل ساختار زیر است:

typedef struct FIT_HEADER
{
	char           Tag[8];     // ‘_FIT_   ’
	unsigned long  NumEntries; // including FIT header entry
	unsigned short Version;    // 1.0
	unsigned char  EntryType;  // 0
	unsigned char  Checksum;
};

به دلایلی نامعلوم، جمع چک همیشه در این جداول محاسبه نمی شود (فیلد خالی باقی می ماند).

ورودی‌های باقی‌مانده به باینری‌های مختلفی اشاره می‌کنند که باید قبل از اجرای BIOS تجزیه/اجرا شوند، یعنی. قبل از تغییر به بردار RESET قدیمی (FFFF FFF0h). ساختار هر یک از این ورودی ها به شرح زیر است:

typedef struct FIT_ENTRY
{
	unsigned long  BaseAddress;
	unsigned long  : 32;
	unsigned long  Size;
	unsigned short Version;     // 1.0
	unsigned char  EntryType;
	unsigned char  Checksum;
};

فیلد EntryType نوع بلوکی که این ورودی به آن اشاره دارد را نشان می دهد. ما چندین نوع را می شناسیم:

enum FIT_ENTRY_TYPES
{
	FIT_HEADER = 0,
	MICROCODE_UPDATE,
	BG_ACM,
	BIOS_INIT = 7,
	TPM_POLICY,
	BIOS_POLICY,
	TXT_POLICY,
	BG_KEYM,
	BG_IBBM
};

اکنون واضح است که یکی از ورودی ها به محل باینری ACM راه اندازی Intel BG اشاره می کند. ساختار هدر این باینری برای ماژول‌های کد توسعه‌یافته توسط اینتل (ACM، به‌روزرسانی‌های میکروکد، بخش‌های کد Intel ME، ...) معمولی است.

typedef struct BG_ACM_HEADER
{
	unsigned short ModuleType;     // 2
	unsigned short ModuleSubType;  // 3
	unsigned long  HeaderLength;   // in dwords
	unsigned long  : 32;
	unsigned long  : 32;
	unsigned long  ModuleVendor;   // 8086h
	unsigned long  Date;           // in BCD format
	unsigned long  TotalSize;      // in dwords
	unsigned long  unknown1[6];
	unsigned long  EntryPoint;
	unsigned long  unknown2[16];
	unsigned long  RsaKeySize;     // in dwords
	unsigned long  ScratchSize;    // in dwords
	unsigned char  RsaPubMod[256];
	unsigned long  RsaPubExp;
	unsigned char  RsaSig[256];
};

پردازنده این باینری را در حافظه پنهان خود بارگذاری می کند، تأیید می کند و راه اندازی می کند.

راه اندازی ACM اینتل BG

در نتیجه تجزیه و تحلیل کار این ACM مشخص شد که موارد زیر را انجام می دهد:

از Intel ME پیکربندی Intel BG نوشته شده روی فیوزهای چیپست (FPF) را دریافت می کند.
مانیفست های KEYM و IBBM را پیدا می کند، آنها را تأیید می کند.

برای یافتن این مانیفست‌ها، ACM از جدول FIT نیز استفاده می‌کند که دارای دو نوع ورودی برای اشاره به این ساختارها است (به FIT_ENTRY_TYPES بالا مراجعه کنید).

بیایید نگاهی دقیق تر به مانیفست ها بیندازیم. در ساختار مانیفست اول، چندین ثابت مبهم، یک هش از کلید عمومی از مانیفست دوم و یک کلید ریشه عمومی OEM که به عنوان یک ساختار تودرتو امضا شده است را می بینیم:

typedef struct KEY_MANIFEST
{
	char           Tag[8];          // ‘__KEYM__’
	unsigned char  : 8;             // 10h
	unsigned char  : 8;             // 10h
	unsigned char  : 8;             // 0
	unsigned char  : 8;             // 1
	unsigned short : 16;            // 0Bh
	unsigned short : 16;            // 20h == hash size?
	unsigned char  IbbmKeyHash[32]; // SHA256 of an IBBM public key
	BG_RSA_ENTRY   OemRootKey;
};

typedef struct BG_RSA_ENTRY
{
	unsigned char  : 8;             // 10h
	unsigned short : 16;            // 1
	unsigned char  : 8;             // 10h
	unsigned short RsaPubKeySize;   // 800h
	unsigned long  RsaPubExp;
	unsigned char  RsaPubKey[256];
	unsigned short : 16;            // 14
	unsigned char  : 8;             // 10h
	unsigned short RsaSigSize;      // 800h
	unsigned short : 16;            // 0Bh
	unsigned char  RsaSig[256];
};

برای تأیید کلید عمومی کلید اصلی OEM، یادآوری می کنیم که از هش SHA256 از فیوزها استفاده می شود که در حال حاضر قبلاً از Intel ME دریافت شده است.

بریم سراغ مانیفست دوم. از سه ساختار تشکیل شده است:

typedef struct IBB_MANIFEST
{
	ACBP Acbp;         // Boot policies
	IBBS Ibbs;         // IBB description
	IBB_DESCRIPTORS[];
	PMSG Pmsg;         // IBBM signature
};

مورد اول شامل چند ثابت است:

typedef struct ACBP
{
	char           Tag[8];          // ‘__ACBP__’
	unsigned char  : 8;             // 10h
	unsigned char  : 8;             // 1
	unsigned char  : 8;             // 10h
	unsigned char  : 8;             // 0
	unsigned short : 16;            // x & F0h = 0
	unsigned short : 16;            // 0 < x <= 400h
};

دومی شامل هش SHA256 IBB و تعداد توصیف‌گرهایی است که محتویات IBB را توصیف می‌کنند (یعنی هش از چه چیزی محاسبه می‌شود):

typedef struct IBBS
{
	char           Tag[8];            // ‘__IBBS__’
	unsigned char  : 8;               // 10h
	unsigned char  : 8;               // 0
	unsigned char  : 8;               // 0
	unsigned char  : 8;               // x <= 0Fh
	unsigned long  : 32;              // x & FFFFFFF8h = 0
	unsigned long  Unknown[20];
	unsigned short : 16;              // 0Bh
	unsigned short : 16;              // 20h == hash size ?
	unsigned char  IbbHash[32];       // SHA256 of an IBB
	unsigned char  NumIbbDescriptors;
};

توصیفگرهای IBB این ساختار را یکی پس از دیگری دنبال می کنند. محتوای آنها دارای قالب زیر است:

typedef struct IBB_DESCRIPTOR
{
	unsigned long  : 32;
	unsigned long  BaseAddress;
	unsigned long  Size;
};

ساده است: هر توصیفگر حاوی آدرس/اندازه یک قطعه IBB است. بنابراین، الحاق بلوک های اشاره شده توسط این توصیفگرها (به ترتیب خود توصیفگرها) IBB است. و به عنوان یک قاعده، IBB ترکیبی از تمام ماژول های فازهای SEC و PEI است.

مانیفست دوم با ساختاری حاوی کلید عمومی IBB (تأیید شده توسط هش SHA256 از اولین مانیفست) و امضای این مانیفست به پایان می رسد:

typedef struct PMSG
{
	char           Tag[8];            // ‘__PMSG__’
	unsigned char  : 8;               // 10h
	BG_RSA_ENTRY   IbbKey;
};

بنابراین، حتی قبل از شروع اجرای UEFI BIOS، پردازنده ACM را راه اندازی می کند، که صحت محتویات بخش ها را با کد فاز SEC و PEI تأیید می کند. در مرحله بعد، پردازنده از ACM خارج می شود، در امتداد بردار RESET حرکت می کند و شروع به اجرای BIOS می کند.

پارتیشن تایید شده PEI باید دارای ماژولی باشد که بقیه BIOS (کد DXE) را بررسی کند. این ماژول در حال حاضر توسط IBV (فروشنده مستقل BIOS) یا خود فروشنده سیستم در حال توسعه است. زیرا فقط سیستم‌های لنوو و گیگابایت در اختیار ما هستند و با پشتیبانی Intel BG، کد استخراج شده از این سیستم‌ها را در نظر می‌گیریم.

ماژول UEFI BIOS LenovoVerifiedBootPei

در مورد Lenovo، مشخص شد که این ماژول LenovoVerifiedBootPei {B9F2AC77-54C7-4075-B42E-C36325A9468D} است که توسط Lenovo توسعه یافته است.

وظیفه آن جستجو (توسط GUID) یک جدول هش برای DXE و تأیید DXE است.

if (EFI_PEI_SERVICES->GetBootMode() != BOOT_ON_S3_RESUME)
{
	if (!FindHashTable())
		return EFI_NOT_FOUND;
	if (!VerifyDxe())
		return EFI_SECURITY_VIOLATION;
}

Хеш таблица {389CC6F2-1EA8-467B-AB8A-78E769AE2A15} имеет следующий формат:

typedef struct HASH_TABLE
{
	char          Tag[8];            // ‘$HASHTBL’
	unsigned long NumDxeDescriptors;
	DXE_DESCRIPTORS[];
};

typedef struct DXE_DESCRIPTOR
{
	unsigned char BlockHash[32];     // SHA256
	unsigned long Offset;
	unsigned long Size;
};

ماژول UEFI BIOS BootGuardPei

در مورد گیگابایت، مشخص شد که این ماژول BootGuardPei {B41956E1-7CA2-42DB-9562-168389F0F066} است که توسط AMI توسعه یافته است، و بنابراین در هر AMI BIOS با پشتیبانی Intel BG وجود دارد.

الگوریتم عملکرد آن تا حدودی متفاوت است، با این حال، به همان شکل خلاصه می شود:

int bootMode = EFI_PEI_SERVICES->GetBootMode();

if (bootMode != BOOT_ON_S3_RESUME &&
    bootMode != BOOT_ON_FLASH_UPDATE &&
    bootMode != BOOT_IN_RECOVERY_MODE)
{
	HOB* h = CreateHob();
	if (!FindHashTable())
		return EFI_NOT_FOUND;
	WriteHob(&h, VerifyDxe());
	return h;
}

جدول هش {389CC6F2-1EA8-467B-AB8A-78E769AE2A15} که ظاهر می شود دارای قالب زیر است:

typedef HASH_TABLE DXE_DESCRIPTORS[];

typedef struct DXE_DESCRIPTOR
{
	unsigned char BlockHash[32];     // SHA256
	unsigned long BaseAddress;
	unsigned long Size;
};

اینتل بوت گارد 2.x

بیایید به طور خلاصه در مورد اجرای دیگری از Intel Boot Guard صحبت کنیم که در یک سیستم جدیدتر مبتنی بر Intel SoC با ریزمعماری Apollo Lake - ASRock J4205-IT یافت شد.

اگرچه این نسخه فقط در SoC ها استفاده خواهد شد (سیستم های جدید با ریزمعماری پردازنده Kaby Lake همچنان از Intel Boot Guard 1.x استفاده می کنند)، اما علاقه زیادی به کاوش در یک گزینه معماری جدید برای پلتفرم های مبتنی بر SoC های اینتل دارد که ملموس بوده است. تغییرات، به عنوان مثال:

مناطق BIOS و Intel ME (یا به عبارت بهتر Intel TXE، طبق اصطلاحات Intel SoC) اکنون یک منطقه IFWI هستند.
اگرچه Intel BG روی پلتفرم فعال بود، ساختارهایی مانند FIT، KEYM، IBBM در حافظه فلش یافت نشد.
علاوه بر هسته های TXE و ISH (x86)، یک هسته سوم (به هر حال، دوباره ARC) به چیپست اضافه شد - PMC (کنترل کننده مدیریت انرژی)، که با اطمینان از عملکرد زیرسیستم قدرت و نظارت بر عملکرد مرتبط است.

محتوای منطقه جدید IFWI مجموعه ای از ماژول های زیر است:

جانبداری
نام
شرح

0000 2000 ساعت
SMIP
برخی از پیکربندی پلت فرم، امضا شده توسط فروشنده

0000 6000 ساعت
RBEP
بخش کد میان‌افزار Intel TXE، x86، با امضای اینتل

0001 0000 ساعت
PMCP
بخش کد سیستم عامل Intel PMC، ARC، امضا شده توسط اینتل

0002 0000 ساعت
FTPR
بخش کد میان‌افزار Intel TXE، x86، با امضای اینتل

0007B000h
UCOD
به روز رسانی میکروکد CPU با امضای اینتل

0008 0000 ساعت
IBBP
UEFI BIOS، فازهای SEC/PEI، x86، فروشنده امضا شده است

0021 8000 ساعت
ISHC
بخش کد سیستم عامل Intel ISH، x86، امضا شده توسط فروشنده

0025 8000 ساعت
NFTP
بخش کد میان‌افزار Intel TXE، x86، با امضای اینتل

0036 1000 ساعت
IUNP
ناشناخته است

0038 1000 ساعت
OBBP
UEFI BIOS، فاز DXE، x86، بدون امضا

در طول تجزیه و تحلیل سیستم عامل TXE، مشخص شد که پس از RESET، TXE پردازنده را در این حالت نگه می دارد تا زمانی که محتویات اصلی فضای آدرس را برای CPU آماده کند (FIT، ACM، بردار RESET ...). علاوه بر این، TXE این داده ها را در SRAM خود قرار می دهد، پس از آن به طور موقت به پردازنده دسترسی به آنجا را فراهم می کند و آن را از RESET "آزاد می کند".

در مراقبت از روت کیت ها

خوب، حالا بیایید به "داغ" برویم. زمانی متوجه شدیم که در بسیاری از سیستم ها، توصیفگرهای فلش SPI مجوز دسترسی به مناطق حافظه فلش SPI را دارند تا همه کاربران این حافظه بتوانند هر منطقه را بنویسند و بخوانند. آن ها به هیچ وجه.

پس از بررسی با ابزار MEinfo (از Intel STK)، دیدیم که حالت ساخت در این سیستم ها بسته نشده است، بنابراین فیوزهای چیپست (FPF) در حالت نامشخص باقی مانده اند. بله، Intel BG در چنین مواردی نه فعال و نه غیرفعال است.

ما در مورد سیستم های زیر صحبت می کنیم (در مورد Intel BG و آنچه در ادامه مقاله توضیح داده خواهد شد، در مورد سیستم هایی با ریزمعماری پردازنده Haswell و بالاتر صحبت خواهیم کرد):

تمامی محصولات گیگابایت؛
تمام محصولات MSI;
21 مدل لپ تاپ لنوو و 4 مدل سرور لنوو.

البته ما این یافته را به این فروشندگان و همچنین به اینتل گزارش کردیم.

پاسخ کافی فقط از طرف خیرکه مشکل را تصدیق کرد و یک پچ منتشر کرد.

گیگابایت به نظر می رسد آنها اطلاعات مربوط به آسیب پذیری را پذیرفته اند، اما به هیچ وجه اظهار نظر نکرده اند.

ارتباط با MSI به درخواست ما برای ارسال کلید عمومی PGP ما (به منظور ارسال یک توصیه امنیتی رمزگذاری شده) به طور کامل متوقف شد. آنها اظهار داشتند که آنها "یک تولید کننده سخت افزار هستند و کلیدهای PGP را تولید نمی کنند."

اما بیشتر به این نکته. از آنجایی که فیوزها در حالت نامشخص باقی می مانند، کاربر (یا مهاجم) می تواند خودش آنها را برنامه ریزی کند (سخت ترین آنها Intel STK را پیدا کنید). این به مراحل زیر نیاز دارد.

1. بوت شدن در سیستم عامل ویندوز (به طور کلی، اگر یک آنالوگ Intel STK را برای سیستم عامل مورد نظر ایجاد کنید، مراحل توضیح داده شده در زیر را می توان از زیر لینوکس نیز انجام داد). با استفاده از ابزار MEinfo، مطمئن شوید که فیوزهای این سیستم برنامه ریزی نشده اند.

2. محتویات فلش مموری را با استفاده از ابزار برنامه نویسی فلش بخوانید.

3. تصویر خوانده شده را با استفاده از هر ابزار ویرایش UEFI BIOS باز کنید، تغییرات لازم را انجام دهید (مثلاً یک روت کیت را اجرا کنید)، ساختارهای KEYM و IBBM موجود در منطقه ME را ایجاد / ویرایش کنید.

بخش عمومی کلید RSA در تصویر مشخص شده است که هش آن به همراه بقیه پیکربندی Intel BG در فیوزهای چیپست برنامه ریزی می شود.

4. با استفاده از Flash Image Tool، یک تصویر سیستم عامل جدید بسازید (با تنظیم تنظیمات Intel BG).

5. یک تصویر جدید بنویسید تا با استفاده از ابزار برنامه نویسی فلش فلش شود، با استفاده از MEinfo تأیید کنید که منطقه ME اکنون دارای پیکربندی Intel BG است.

6. از ابزار برنامه نویسی Flash برای بستن حالت ساخت استفاده کنید.

7. سیستم راه اندازی مجدد می شود، پس از آن، با استفاده از MEinfo، می توانید تأیید کنید که FPF ها اکنون برنامه ریزی شده اند.

این اقدامات برای همیشه Intel BG را در این سیستم فعال کنید. لغو عمل غیرممکن خواهد بود، به این معنی:

فقط صاحب بخش خصوصی کلید ریشه (یعنی کسی که Intel BG را فعال کرده است) می تواند بایوس UEFI را در این سیستم به روز کند.
اگر سیستم عامل اصلی را به این سیستم برگردانید، به عنوان مثال، با استفاده از یک برنامه نویس، حتی روشن نمی شود (پیامد سیاست اجرایی در صورت خطای تأیید).
برای خلاص شدن از شر چنین بایوس UEFI، باید چیپست را با FPF های برنامه ریزی شده با یک "تمیز" جایگزین کنید (یعنی اگر به یک ایستگاه لحیم کاری مادون قرمز به قیمت یک ماشین دسترسی دارید، چیپست را دوباره لحیم کنید، یا فقط مادربرد را جایگزین کنید. ).

برای درک اینکه چنین روت کیتی چه کاری می تواند انجام دهد، باید ارزیابی کنید که چه چیزی اجرای کد شما را در محیط UEFI BIOS ممکن می کند. بگویید، در ممتازترین حالت پردازنده - SMM. چنین روت کیت ممکن است دارای ویژگی های زیر باشد:

به موازات سیستم عامل اجرا شود (می توانید پردازش را با ایجاد یک وقفه SMI پیکربندی کنید، که توسط یک تایمر فعال می شود).
دارای تمام مزایای قرار گرفتن در حالت SMM (دسترسی کامل به محتویات RAM و منابع سخت افزاری، مخفی بودن از سیستم عامل)؛
کد روت کیت در حالت SMM قابل رمزگذاری و رمزگشایی است. هر داده ای که فقط در حالت SMM موجود است می تواند به عنوان کلید رمزگذاری استفاده شود. به عنوان مثال، هش از مجموعه ای از آدرس ها در SMRAM. برای دریافت این کلید، باید به SMM بروید. و این کار به دو صورت قابل انجام است. RCE را در کد SMM پیدا کنید و از آن بهره برداری کنید، یا ماژول SMM خود را به بایوس اضافه کنید، که غیرممکن است، زیرا ما Boot Guard را فعال کرده ایم.

بنابراین، این آسیب‌پذیری به مهاجم اجازه می‌دهد:

یک روت کیت پنهان و غیرقابل حذف با هدف نامعلوم در سیستم ایجاد کنید.
کد خود را روی یکی از هسته‌های چیپست داخل SoC اینتل، یعنی روی Intel ISH اجرا کنید (به تصویر دقیق‌تر نگاه کنید).

اگرچه هنوز قابلیت‌های زیرسیستم Intel ISH بررسی نشده است، اما به نظر می‌رسد که یک حمله جالب بر علیه Intel ME باشد.

یافته ها

این مطالعه توصیفی فنی از نحوه عملکرد فناوری Intel Boot Guard ارائه کرد. منهای چند راز در امنیت اینتل از طریق مدل مبهم.
یک سناریوی حمله ارائه شده است که امکان ایجاد یک روت کیت غیرقابل حذف در سیستم را فراهم می کند.
ما دیده‌ایم که پردازنده‌های مدرن اینتل حتی قبل از شروع بایوس قادر به اجرای بسیاری از کدهای اختصاصی هستند.
پلتفرم‌های با معماری Intel 64 برای اجرای نرم‌افزار رایگان مناسب‌تر می‌شوند: تأیید سخت‌افزار، تعداد فزاینده‌ای از فناوری‌های اختصاصی و زیرسیستم‌ها (سه هسته در چیپست SoC: x86 ME، x86 ISH و ARC PMC).

تخفیف

فروشندگانی که عمداً حالت تولید را باز می گذارند، قطعاً باید آن را ببندند. تا کنون آنها فقط چشمان خود را بسته اند و سیستم های جدید Kaby Lake این را نشان می دهند.

کاربران می توانند با اجرای ابزار برنامه نویسی Flash با گزینه -closemnf، Intel BG را در سیستم های خود (که تحت تأثیر آسیب پذیری توصیف شده قرار دارند) غیرفعال کنند. ابتدا باید مطمئن شوید (با استفاده از MEinfo) که پیکربندی Intel BG در ناحیه ME دقیقاً خاموش کردن این فناوری را پس از برنامه‌نویسی در FPF فراهم می‌کند.

منبع: www.habr.com

چکمه مورد اعتماد شرودینگر اینتل بوت گارد