המגף המהימן של שרדינגר. Intel Boot Guard

אנו מציעים לרדת שוב לרמה הנמוכה ולדבר על האבטחה של פלטפורמות מחשב תואמות קושחה x86. הפעם, המרכיב העיקרי של המחקר הוא Intel Boot Guard (לא להתבלבל עם Intel BIOS Guard!) - טכנולוגיית אתחול מהימנה של BIOS הנתמכת בחומרה שספק מערכת מחשבים יכול להפעיל או לכבות לצמיתות בשלב הייצור. ובכן, אנחנו כבר מכירים את מתכון המחקר: חתכו דק את היישום של הטכנולוגיה הזו על ידי הנדסה לאחור, תארו את הארכיטקטורה שלה, ממלאים אותה בפרטים לא מתועדים, מתבלים אותה בוקטורי תקיפה לפי הטעם ומערבבים אותה. בואו נוסיף אש עם סיפור על איך באג משובט בייצור של מספר ספקים במשך שנים מאפשר לתוקף פוטנציאלי להשתמש בטכנולוגיה הזו כדי ליצור rootkit מוסתר שלא ניתן להסיר (אפילו על ידי מתכנת) במערכת.

אגב, הכתבה מבוססת על הדיווחים "On Guard for Rootkits: Intel BootGuard" מהכנס ZeroNights 2016 ומפגש 29 DefCon רוסיה (שתי המצגות כאן).

קושחה לפלטפורמת מחשב עם ארכיטקטורת Intel 64

ראשית, בואו נענה על השאלה: מהי הקושחה של פלטפורמת מחשב מודרנית עם ארכיטקטורת Intel 64? כמובן, UEFI BIOS. אבל תשובה זו לא תהיה מדויקת. בואו נסתכל על האיור, המציגה את גרסת שולחן העבודה (המחשב הנייד) של ארכיטקטורה זו.

הבסיס הוא הקישור:

• מעבד (CPU, Central Processing Unit), אשר בנוסף לליבות הראשיות, יש לו ליבה גרפית מובנית (לא בכל הדגמים) ובקר זיכרון (IMC, Integrated Memory Controller);
• ערכת שבבים (PCH, Platform Controller Hub), המכילה בקרים שונים לאינטראקציה עם התקנים היקפיים וניהול תתי מערכות. ביניהם ניתן למצוא את Intel Management Engine (ME) הידוע לשמצה, שיש לו גם קושחה (קושחה של Intel ME).

מחשבים ניידים, בנוסף לאמור לעיל, דורשים בקר משולב (ACPI EC, Advanced Control and Power Interface Embedded Controller), שאחראי על תפעול תת-מערכת החשמל, משטח המגע, המקלדת, מקשי Fn (בהירות המסך, עוצמת הקול, מקלדת תאורה אחורית וכו'). ) ועוד. ויש לו גם קושחה משלו.

אז, השילוב של הקושחה לעיל הוא הקושחה של פלטפורמת המחשב (קושחת המערכת), אשר מאוחסנת בזיכרון פלאש SPI נפוץ. כדי שמשתמשי הזיכרון הזה לא יתבלבלו איפה מישהו שוכב, התוכן של הזיכרון הזה מחולק לאזורים הבאים (כפי שמוצג באיור):

• UEFI BIOS;
• קושחת ACPI EC (אזור נפרד הופיע עם המיקרו-ארכיטקטורה של מעבד Skylake (2015), אבל בטבע עדיין לא ראינו דוגמאות לשימוש בה, ולכן קושחת הבקר המוטבע היא עדיין חלק מה-UEFI BIOS);
• קושחת Intel ME;
• תצורה (כתובת MAC וכו') של מתאם הרשת GbE (Gigabit Ethernet) המובנה;
• מתארי flash - האזור הראשי של זיכרון הפלאש, המכיל מצביעים לאזורים אחרים, כמו גם הרשאות גישה אליהם.

בידול הגישה לאזורים (בהתאם להרשאות שצוינו) מטופל על ידי מנהל האוטובוס SPI - בקר ה-SPI המובנה בערכת השבבים, שדרכו ניגשים לזיכרון זה. אם ההרשאות מוגדרות לערכים המומלצים (מסיבות אבטחה) על ידי אינטל, אז לכל משתמש בפלאש SPI יש גישה מלאה (קריאה/כתיבה) רק לאזור שלו. השאר הם לקריאה בלבד או בלתי נגישים. עובדה ידועה: במערכות רבות, ל-CPU יש גישה מלאה ל-UEFI BIOS ו-GbE, גישת קריאה רק לתיאורי פלאש, וללא גישה לאזור Intel ME כלל. למה רבים ולא כולם? מה שמומלץ הוא אופציונלי. נספר לכם יותר בהמשך המאמר.

מנגנונים להגנה על הקושחה של פלטפורמת מחשב מפני שינויים

מן הסתם, הקושחה של פלטפורמת מחשב צריכה להיות מוגנת מפני פשרה אפשרית, שתאפשר לתוקף פוטנציאלי להשיג בה דריסת רגל (לשרוד עדכוני מערכת הפעלה / התקנות מחדש), לבצע את הקוד שלו במצבים המועדפים ביותר וכו'. ותיחום גישה לאזורי זיכרון פלאש SPI, כמובן, אינו מספיק. לכן, נעשה שימוש במנגנונים שונים ספציפיים לכל סביבת ביצוע כדי להגן על הקושחה מפני שינויים.

לכן, הקושחה של Intel ME חתומה עבור בקרת שלמות ואותנטיות, ונבדקת על ידי בקר ME בכל פעם שהיא נטענת לזיכרון ME UMA. תהליך האימות הזה כבר נדון על ידינו באחד מה- מאמריםמוקדש לתת-מערכת Intel ME.

וקושחת ACPI EC, ככלל, נבדקת רק עבור תקינות. עם זאת, בשל העובדה שהבינארי הזה כלול ב-UEFI BIOS, הוא כפוף כמעט תמיד לאותם מנגנוני הגנה שבהם משתמש ה-UEFI BIOS. בואו נדבר עליהם.

ניתן לחלק מנגנונים אלו לשתי קטגוריות.

הגנת כתיבה לאזור UEFI BIOS

1. הגנה פיזית על התוכן של זיכרון הפלאש SPI עם מגשר להגנה על כתיבה;
2. הגנה על הקרנה של אזור ה-UEFI BIOS במרחב הכתובות של המעבד באמצעות אוגרי PRx של ערכת השבבים;
3. חסימת ניסיונות כתיבה לאזור UEFI BIOS על ידי יצירה ועיבוד של הפסקת SMI המתאימה על ידי הגדרת סיביות BIOS_WE / BLE ו-SMM_BWP באוגרי ערכת השבבים;
4. גרסה מתקדמת יותר של הגנה זו היא Intel BIOS Guard (PFAT).

בנוסף למנגנונים אלה, הספקים יכולים לפתח וליישם אמצעי אבטחה משלהם (לדוגמה, חתימה על קפסולות עם עדכוני UEFI BIOS).

חשוב לציין כי על מערכת ספציפית (תלוי בספק), ייתכן שלא כל מנגנוני ההגנה הנ"ל מיושמים, ייתכן שהם לא מיושמים כלל או שהם מיושמים בצורה פגיעה. תוכל לקרוא עוד על מנגנונים אלו ועל המצב עם יישומם ב מאמר זה. למעוניינים, אנו ממליצים לקרוא את כל סדרת המאמרים על אבטחת UEFI BIOS מ קוד.

אימות UEFI BIOS אימות

כשאנחנו מדברים על טכנולוגיות אתחול מהימנות, הדבר הראשון שעולה על הדעת הוא אתחול מאובטח. עם זאת, מבחינה ארכיטקטונית, הוא נועד לאמת רכיבים חיצוניים ל-UEFI BIOS (מנהלי התקנים, מעמיסים וכו'), ולא את הקושחה עצמה.

לכן, אינטל ב-SoCs עם מיקרו-ארכיטקטורת Bay Trail (2012) הטמיעה אתחול מאובטח שאינו ניתן להחלפה בחומרה (אתחול מאומת), שאין לו שום קשר לטכנולוגיית האתחול המאובטח הנ"ל. מאוחר יותר (2013), מנגנון זה שופר, ותחת השם Intel Boot Guard, שוחרר למחשבים שולחניים עם המיקרו-ארכיטקטורה של Haswell.

לפני שנתאר את Intel Boot Guard, בואו נסתכל על זמני ריצה בארכיטקטורת Intel 64, אשר, בשילוב, הם שורשי האמון של טכנולוגיית האתחול המהימנה הזו.

מעבד אינטל

Cap מציע שהמעבד הוא סביבת הביצוע העיקרית בארכיטקטורת Intel 64. מדוע הוא גם שורש האמון? מסתבר שהחזקת המרכיבים הבאים היא זו שגורמת לכך:

• Microcode ROM הוא זיכרון לא נדיף ולא ניתן לכתיבה לאחסון מיקרוקוד. הוא האמין כי מיקרוקוד הוא היישום של מערכת הוראות המעבד על ההוראות הפשוטות ביותר. קורה גם במיקרוקוד באגים. אז ב-BIOS אתה יכול למצוא קבצים בינאריים עם עדכוני מיקרוקוד (הם מונחים על גבי בזמן האתחול, כי לא ניתן להחליף את ה-ROM). התוכן של קבצים בינאריים אלו מוצפן, מה שמסבך מאוד את הניתוח (לכן, התוכן הספציפי של המיקרוקוד ידוע רק למי שמפתח אותו), ונחתם כדי לשלוט על השלמות והאותנטיות;
• מפתח AES לפענוח התוכן של עדכוני מיקרוקוד;
• hash של המפתח הציבורי RSA המאמת את החתימה של עדכוני מיקרוקוד;
• Hash מפתח ציבורי RSA, שבודק את החתימה של מודולי קוד ACM (Authenticated Code Module) שפותחו על ידי אינטל, שה-CPU יכול להריץ לפני הפעלת ה-BIOS (שלום מיקרוקוד) או במהלך פעולתו, כאשר מתרחשים אירועים מסוימים.

אינטל ME

תת-מערכת זו בבלוג שלנו הוקדשה две מאמרים. נזכיר כי סביבת הפעלה זו מבוססת על המיקרו-בקר המובנה בערכת השבבים והיא הנסתרת והמועדפת ביותר במערכת.

למרות ההתגנבות, Intel ME היא גם שורש האמון, מכיוון שיש לה:

• ME ROM - זיכרון לא נדיף ולא ניתן לכתיבה מחדש (לא מסופקת שיטת עדכון), המכיל את קוד ההתחלה, כמו גם את ה-hash SHA256 של המפתח הציבורי RSA, שבודק את החתימה של הקושחה של Intel ME;
• מפתח AES לאחסון מידע סודי;
• גישה לסט של נתיכים (FPFs, Field Programmable Fuses) המשולבים בערכת השבבים לאחסון קבוע של מידע מסוים, כולל מידע שצוין על ידי ספק מערכת המחשב.

Intel Boot Guard 1.x

כתב ויתור קטן. מספרי הגרסאות של טכנולוגיית Intel Boot Guard שבהן אנו משתמשים במאמר זה הם שרירותיים וייתכן שאין להם שום קשר למספור המשמש בתיעוד פנימי של Intel. בנוסף, המידע על הטמעת טכנולוגיה זו שניתן כאן התקבל במהלך הנדסה לאחור, ועשוי להכיל אי דיוקים בהשוואה למפרט עבור Intel Boot Guard, שספק אם יתפרסם אי פעם.

אז, Intel Boot Guard (BG) היא טכנולוגיית אימות UEFI BIOS הנתמכת בחומרה. אם לשפוט לפי התיאור הקטן שלו בספר [Platform Embedded Security Technology Revealed, Chapter Boot with Integrity, or Not Boot], הוא עובד כשרשרת אתחול מהימנה. והקישור הראשון בו הוא קוד האתחול (מיקרוקוד) בתוך ה-CPU, המופעל על ידי אירוע ה-RESET (לא להתבלבל עם וקטור ה-RESET ב-BIOS!). ה-CPU מוצא מודול קוד (Intel BG startup ACM) שפותח וחתום על ידי אינטל בזיכרון הפלאש SPI, טוען אותו למטמון שלו, מאמת אותו (כבר צוין למעלה של-CPU יש Hash מפתח ציבורי שמאמת את חתימת ACM ) ומתחיל.

מודול קוד זה אחראי לאימות חלק התחלתי קטן של UEFI BIOS - Initial Boot Block (IBB), אשר, בתורו, מכיל את הפונקציונליות לאימות החלק העיקרי של UEFI BIOS. לפיכך, Intel BG מאפשרת לך לאמת את האותנטיות של ה-BIOS לפני אתחול מערכת ההפעלה (שניתן לבצע תחת פיקוח של טכנולוגיית Secure Boot).

טכנולוגיית Intel BG מספקת שני מצבי פעולה (ואחד אינו מפריע לשני, כלומר ניתן להפעיל את שני המצבים במערכת, ואת שניהם ניתן להשבית).

אתחול מדוד

במצב אתחול מדוד (MB), כל רכיב אתחול (החל מ-CPU) "מודד" את הבא באמצעות היכולות של Trusted Platform Module (TPM). למי שלא יודע, אסביר.

ל-TPM יש PCRs (Platform Configuration Registers), המתעדים את התוצאה של פעולת הגיבוב לפי הנוסחה:

הָהֵן. ערך ה-PCR הנוכחי תלוי בקודם, והרגיסטרים הללו מאופסים רק כאשר המערכת מאופסת.

לפיכך, במצב MB, בנקודת זמן מסוימת, PCRs משקפים מזהה ייחודי (בתוך היכולות של פעולת ה-hash) של הקוד או הנתונים ש"נמדדו". ניתן להשתמש בערכי ה-PCR בהצפנה של פעולות מסוימות של נתונים (TPM_Seal). לאחר מכן, פענוחם (TPM_Unseal) יתאפשר רק אם ערכי ה-PCR לא השתנו כתוצאה מהטעינה (כלומר, אף רכיב "נמדד" לא שונה).

אתחול מאומת

הדבר המפחיד ביותר עבור אלה שאוהבים לשנות את UEFI BIOS הוא מצב האתחול המאומת (VB), שבו כל רכיב אתחול מאמת קריפטוגרפית את השלמות והאותנטיות של הבא. ובמקרה של שגיאת אימות, (אחת מהאפשרויות הבאות) מתרחשת:

• כיבוי על ידי פסק זמן מדקה עד 1 דקות (כדי שלמשתמש יהיה זמן להבין מדוע המחשב שלו לא מאתחל, ואם אפשר, ינסה לשחזר את ה-BIOS);
• כיבוי מיידי (כדי שלמשתמש אין זמן להבין ויותר מכך, לעשות);
• המשך עבודה עם פנים ישרות (במקרה שאין זמן לבטיחות, כי יש דברים יותר חשובים לעשות).

בחירת הפעולה תלויה בתצורת Intel BG שצוינה (כלומר, במה שנקרא מדיניות האכיפה), אשר מתועדת לצמיתות על ידי ספק פלטפורמת המחשב באחסון שתוכנן במיוחד - נתיכים של ערכת שבבים (FPF). על נקודה זו נתעכב ביתר פירוט בהמשך.

בנוסף לתצורה, הספק יוצר שני מפתחות RSA 2048 ויוצר שני מבני נתונים (מוצג באיור):

1. מניפסט מפתח השורש של הספק (KEYM, OEM Root Key Manifest), שמציב את ה-SVN (מספר גרסת אבטחה) של מניפסט זה, ה-hash SHA256 של המפתח הציבורי של המניפסט הבא, המפתח הציבורי RSA (כלומר החלק הציבורי של המניפסט מפתח שורש של ספק) כדי לאמת את החתימה של מניפסט זה ואת החתימה עצמה;
2. מניפסט IBB (IBBM, Initial Boot Block Manifest), שמציב את ה-SVN של מניפסט זה, את ה-hash SHA256 של ה-IBB, את המפתח הציבורי לאימות החתימה של מניפסט זה ואת החתימה עצמה.

ה-hash SHA256 של מפתח השורש של OEM נכתב לצמיתות לנתיכים של ערכות שבבים (FPFs), בדיוק כמו תצורת Intel BG. אם תצורת Intel BG מספקת הכללה של טכנולוגיה זו, אז מעתה ואילך מערכת זו רק הבעלים של החלק הפרטי של מפתח השורש של OEM יכול לעדכן את ה-BIOS (כלומר להיות מסוגל לחשב מחדש את המניפסטים הללו), כלומר. מוֹכֵר.

כשמסתכלים על התמונה, מיד מתעוררים ספקות לגבי הצורך בשרשרת אימות כל כך ארוכה - יכולת להשתמש במניפסט אחד. למה לסבך?

למעשה, אינטל מספקת לפיכך לספק את ההזדמנות להשתמש במפתחות IBB שונים עבור קווי מוצרים שונים ואחד בתור השורש. אם החלק הפרטי של מפתח IBB (שחותם על המניפסט השני) דלוף, התקרית תשפיע רק על קו מוצרים אחד ורק עד שהספק יפיק זוג חדש ויאפשר את המניפסטים המחושבים מחדש בעדכון ה-BIOS הבא.

אבל אם מפתח השורש נפגע (עמו נחתם המניפסט הראשון), לא ניתן יהיה להחליף אותו, הליך הביטול לא מסופק. ה-hash של החלק הציבורי של מפתח זה מתוכנת לתוך FPFs אחת ולתמיד.

תצורת Intel Boot Guard

כעת בואו נסתכל מקרוב על תצורת Intel BG ועל תהליך היצירה שלה. אם תסתכל על הכרטיסייה המתאימה ב-GUI של Flash Image Tool מ-Intel System Tool Kit (STK), תבחין שתצורת Intel BG כוללת hash של החלק הציבורי של מפתח השורש של הספק, כמה לא ברורים ערכים וכן הלאה. פרופיל Intel 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 כך שאם האימות נכשל, שוב, תתרחש הורדה לא מהימנה.

השאר דברים כאלה בידי הספקים...

ה-GUI של כלי השירות מספק את הפרופילים ה"מוכנים" הבאים:

מספר
משטר
תיאור

0
No_FVME
טכנולוגיית Intel BG מושבתת

1
VE
מצב VB מופעל, כיבוי לפי פסק זמן

2
VME
שני המצבים מופעלים (VB ו-MB), כיבוי לפי פסק זמן

3
VM
שני המצבים מופעלים, מבלי לכבות את המערכת

4
FVE
מצב VB מופעל, כיבוי מיידי

5
FVME
שני המצבים מופעלים, כיבוי מיידי

כפי שכבר הוזכר, תצורת Intel BG חייבת להיכתב אחת ולתמיד על ידי ספק המערכת לתוך נתיכים של ערכת שבבים (FPF) - אחסון מידע חומרה קטן (לפי מידע לא מאומת, 256 בתים בלבד) בתוך ערכת השבבים, שניתן לתכנת בחוץ. ממתקני הייצור של אינטל (אז זו הסיבה ניתן לתכנות בשטח נתיכים).

זה נהדר לאחסון תצורה מכיוון:

• בעל אזור אחסון נתונים שניתן לתכנות חד-פעמי (בדיוק היכן שנכתבה תצורת Intel BG);
• רק Intel ME יכולה לקרוא ולתכנת אותו.

לכן, על מנת להגדיר את התצורה עבור טכנולוגיית Intel BG על מערכת ספציפית, הספק עושה את הפעולות הבאות במהלך הייצור:

1. שימוש בכלי ה-Flash Image (מ-Intel STK), יוצר תמונת קושחה עם תצורת Intel BG נתונה כמשתנים בתוך אזור Intel ME (מה שנקרא מראה זמנית עבור FPFs);
2. באמצעות כלי תכנות הפלאש (מ-Intel STK), כותב תמונה זו לזיכרון הפלאש SPI של המערכת וסוגר את מה שנקרא. מצב ייצור (במקרה זה, הפקודה המתאימה נשלחת לאינטל ME).

כתוצאה מפעולות אלו, אינטל ME תתחייב בפני FPF את הערכים הנתונים מהמראה עבור FPFs באזור ME, תגדיר את ההרשאות במתארי הבזק של SPI לערכים המומלצים על ידי אינטל (מתוארים בתחילת כתבה) ולבצע איפוס מערכת.

ניתוח יישום של Intel Boot Guard

על מנת לנתח את היישום של טכנולוגיה זו על דוגמה ספציפית, בדקנו את המערכות הבאות עבור עקבות של טכנולוגיית Intel BG:

מערכת
שים לב

Gigabyte GA-H170-D3H
סקיילייק, יש תמיכה

Gigabyte GA-Q170-D3H
סקיילייק, יש תמיכה

Gigabyte GA-B150-HD3
סקיילייק, יש תמיכה

MSI H170A Gaming Pro
סקיילייק, אין תמיכה

Lenovo ThinkPad 460
Skylake, תמיכה זמינה, טכנולוגיה מופעלת

לינוקס יוגה 2 Pro
הסוול, אין תמיכה

לנובו U330p
הסוול, אין תמיכה

"תמיכה" פירושה הנוכחות של מודול ההפעלה Intel BG ACM, המניפסטים שהוזכרו לעיל והקוד המתאים ב-BIOS, כלומר. יישומים לניתוח.

כדוגמה, ניקח את זה שהורד מהמשרד. תמונת אתר של ספק של זיכרון פלאש SPI עבור Gigabyte GA-H170-D3H (גרסה F4).

ROM אתחול של אינטל CPU

קודם כל, בואו נדבר על הפעולות של המעבד אם טכנולוגיית Intel BG מופעלת.

לא ניתן היה למצוא דוגמאות של המיקרוקוד המפוענח, לכן, כיצד הפעולות המתוארות להלן מיושמות (במיקרוקוד או בחומרה) היא שאלה פתוחה. עם זאת, העובדה שמעבדי אינטל מודרניים "יכולים" לבצע את הפעולות הללו היא עובדה.

לאחר היציאה ממצב RESET, המעבד (שבמרחב הכתובות שלו תוכן זיכרון הפלאש כבר ממופה) מוצא את ה-FIT (Firmware Interface Table). למצוא אותו קל, המצביע אליו כתוב בכתובת 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. מבנה הכותרת של בינארי זה אופייני למודולי קוד שפותחו על ידי אינטל (ACMs, עדכוני מיקרוקוד, קטעי קוד 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];
};

המעבד טוען את הבינארי הזה לתוך המטמון שלו, מאמת ומפעיל.

אינטל BG אתחול ACM

כתוצאה מניתוח העבודה של ACM זה, התברר שהוא עושה את הפעולות הבאות:

• מקבל מ-Intel ME את תצורת Intel BG שנכתבה לנתיכים של ערכת השבבים (FPFs);
• מוצא מניפסטים של KEYM ו-IBBM, מאמת אותם.

כדי למצוא את המניפסטים הללו, ACM משתמשת גם בטבלת FIT, שיש לה שני סוגים של ערכים כדי להצביע על מבנים אלה (ראה FIT_ENTRY_TYPES למעלה).

בואו נסתכל מקרוב על המניפסטים. במבנה של המניפסט הראשון, אנו רואים מספר קבועים לא ברורים, hash של המפתח הציבורי מהמניפסט השני, ומפתח OEM Root ציבורי חתום כמבנה מקונן:

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, אנו נזכיר כי נעשה שימוש ב-hash 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
};

השני מכיל את ה-Hash SHA256 של ה-IBB ואת מספר המתארים המתארים את תוכן ה-IBB (כלומר ממה מחושב ה-hash):

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 (מאומת על ידי ה-hash 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 עצמאי) או ספק המערכת עצמו. כי רק מערכות Lenovo ו-Gigabyte התבררו כעומדות לרשותנו ובעלות תמיכה של Intel BG, בואו נבחן את הקוד שחולץ ממערכות אלו.

מודול UEFI BIOS LenovoVerifiedBootPei

במקרה של לנובו, התברר שמדובר במודול LenovoVerifiedBootPei {B9F2AC77-54C7-4075-B42E-C36325A9468D}, שפותח על ידי Lenovo.

תפקידו הוא לחפש (על ידי GUID) טבלת hash עבור ה-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

במקרה של Gigabyte, התברר שזהו מודול BootGuardPei {B41956E1-7CA2-42DB-9562-168389F0F066}, שפותח על ידי AMI, ולכן קיים בכל BIOS של AMI עם תמיכה של 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;
};

Intel Boot Guard 2.x

בואו נדבר בקצרה על יישום נוסף של Intel Boot Guard, שנמצא במערכת חדשה יותר המבוססת על Intel SoC עם מיקרו-ארכיטקטורת Apollo Lake - ASRock J4205-IT.

למרות שגרסה זו תשמש רק ב-SoCs (מערכות חדשות עם מיקרו-ארכיטקטורת מעבד Kaby Lake ממשיכות להשתמש ב-Intel Boot Guard 1.x), יש לה עניין רב בבחינת אפשרות ארכיטקטורה חדשה עבור פלטפורמות המבוססות על Intel SoCs, אשר נראתה מוחשית שינויים, למשל:

• אזורי BIOS ו-Intel ME (או ליתר דיוק Intel TXE, לפי המינוח של Intel SoC) הם כעת אזור IFWI אחד;
• למרות ש-Intel BG הופעלה בפלטפורמה, מבנים כגון FIT, KEYM, IBBM לא נמצאו בזיכרון הבזק;
• בנוסף לליבות TXE ו-ISH (x86), נוספה לערכת השבבים ליבה שלישית (שוב ARC, אגב) - PMC (Power Management Controller), הקשורה להבטחת התפעול של תת-מערכת החשמל ולניטור ביצועים.

התוכן של אזור IFWI החדש הוא קבוצה של המודולים הבאים:

קיזוז
שם
תיאור

0000 2000 שעות
SMIP
תצורת פלטפורמה כלשהי, חתומה על ידי הספק

0000 6000 שעות
RBEP
סעיף קוד קושחה של Intel TXE, x86, חתום על ידי Intel

0001 0000 שעות
PMCP
סעיף קוד קושחה Intel PMC, ARC, חתום על ידי Intel

0002 0000 שעות
FTPR
סעיף קוד קושחה של Intel TXE, x86, חתום על ידי Intel

0007B000h
UCOD
עדכוני מיקרוקוד של CPU חתומים על ידי אינטל

0008 0000 שעות
IBBP
UEFI BIOS, SEC/PEI phases, x86, ספק חתום

0021 8000 שעות
ISHC
קטע קוד של קושחת Intel ISH, x86, חתום על ידי הספק

0025 8000 שעות
NFTP
סעיף קוד קושחה של Intel TXE, x86, חתום על ידי Intel

0036 1000 שעות
IUNP
לא ידוע

0038 1000 שעות
OBBP
UEFI BIOS, DXE phase, x86, לא חתום

במהלך הניתוח של קושחת TXE, התברר כי לאחר RESET, TXE שומר על המעבד במצב זה עד שהוא מכין את התוכן הבסיסי של מרחב הכתובות עבור ה-CPU (FIT, ACM, RESET וקטור...). יתרה מכך, TXE מציב את הנתונים הללו ב-SRAM שלו, ולאחר מכן הוא מספק למעבד באופן זמני גישה לשם ו"משחרר" אותם מ-RESET.

על המשמר של rootkits

ובכן, עכשיו בואו נעבור ל"חם". גילינו פעם שבמערכות רבות, לתיאורי פלאש SPI יש הרשאות גישה לאזורים של זיכרון פלאש SPI כך שכל המשתמשים בזיכרון הזה יכולים גם לכתוב וגם לקרוא כל אזור. הָהֵן. אין סיכוי.

לאחר בדיקה עם כלי השירות MEinfo (מ-Intel STK), ראינו שמצב הייצור במערכות אלו לא נסגר, ולכן נתיכים של ערכת השבבים (FPFs) נותרו במצב בלתי מוגדר. כן, Intel BG לא מופעלת ולא מושבתת במקרים כאלה.

אנחנו מדברים על המערכות הבאות (לגבי Intel BG ומה שיתואר בהמשך המאמר, נדבר על מערכות עם מיקרו-ארכיטקטורת מעבד Haswell ומעלה):

• כל מוצרי Gigabyte;
• כל מוצרי MSI;
• 21 דגמי מחשב נייד של לנובו ו-4 דגמי שרת Lenovo.

כמובן, דיווחנו על הממצא לספקים אלה, כמו גם לאינטל.

תגובה נאותה הגיעה רק מ Lenovoשהכיר בבעיה ו שחרר תיקון.

Gigabyte נראה שהם קיבלו מידע על הפגיעות, אך לא הגיבו בשום צורה.

תקשורת עם MSI נתקע לחלוטין לבקשתנו לשלוח את מפתח ה-PGP הציבורי שלנו (על מנת לשלוח להם ייעוץ אבטחה מוצפן). הם הצהירו שהם "יצרן חומרה ואינם מייצרים מפתחות PGP".

אבל יותר לעניין. מכיוון שהנתיכים נותרים במצב לא מוגדר, המשתמש (או התוקף) יכול לתכנת אותם בעצמו (הקשה ביותר הוא מצא את Intel STK). זה דורש את השלבים הבאים.

1. אתחול לתוך מערכת ההפעלה של Windows (באופן כללי, ניתן לבצע את השלבים המתוארים להלן גם תחת לינוקס, אם אתה מפתח אנלוגי של Intel STK עבור מערכת ההפעלה הרצויה). באמצעות כלי השירות MEinfo, ודא שהנתיכים במערכת זו אינם מתוכנתים.

2. קרא את התוכן של זיכרון הבזק באמצעות כלי התכנות הפלאש.

3. פתח את תמונת הקריאה באמצעות כל כלי עריכת UEFI BIOS, בצע את השינויים הדרושים (הטמיע Rootkit, למשל), צור / ערוך את מבני KEYM ו-IBBM הקיימים באזור ME.

החלק הציבורי של מפתח RSA מודגש בתמונה, שה-hash שלו יתכנת בנתיכים של ערכת השבבים יחד עם שאר תצורת Intel BG.

4. באמצעות כלי ה-Flash Image Tool, בנה תמונת קושחה חדשה (על ידי הגדרת תצורת Intel BG).

5. כתוב תמונה חדשה להבהב באמצעות כלי התכנות Flash, ודא באמצעות MEinfo שאזור ה-ME מכיל כעת את תצורת Intel BG.

6. השתמש בכלי תכנות פלאש כדי לסגור את מצב הייצור.

7. המערכת תאתחל, ולאחר מכן, באמצעות MEinfo, תוכל לוודא שה-FPFs מתוכנתים כעת.

הפעולות הללו לנצח הפעל את Intel BG במערכת זו. זה יהיה בלתי אפשרי לבטל את הפעולה, כלומר:

• רק הבעלים של החלק הפרטי של מפתח השורש (כלומר זה שהפעיל את Intel BG) יוכל לעדכן את UEFI BIOS במערכת זו;
• אם תחזיר את הקושחה המקורית למערכת זו, למשל, באמצעות מתכנת, היא אפילו לא תידלק (תוצאה של מדיניות אכיפה במקרה של שגיאת אימות);
• כדי להיפטר מ-UEFI BIOS כזה, אתה צריך להחליף את ערכת השבבים עם FPFs מתוכנתים עם "נקי" (כלומר, להלחם מחדש את ערכת השבבים אם יש לך גישה לתחנת הלחמה אינפרא אדום במחיר של מכונית, או פשוט להחליף את לוח האם ).

כדי להבין מה Rootkit כזה יכול לעשות, אתה צריך להעריך מה מאפשר לבצע את הקוד שלך בסביבת UEFI BIOS. נגיד, במצב הפריבילגי ביותר של המעבד - SMM. ערכת שורש כזו עשויה להיות בעלת המאפיינים הבאים:

• להתבצע במקביל למערכת ההפעלה (תוכל להגדיר עיבוד על ידי יצירת פסיקת SMI, שתופעל על ידי טיימר);
• יש את כל היתרונות של להיות במצב SMM (גישה מלאה לתוכן של משאבי RAM וחומרה, סודיות ממערכת ההפעלה);
• ניתן להצפין ולפענח את קוד ה-rootkit כאשר הוא מופעל במצב SMM. כל הנתונים הזמינים רק במצב SMM יכולים לשמש כמפתח הצפנה. לדוגמה, hash מקבוצת כתובות ב-SMRAM. כדי לקבל מפתח זה, תצטרך לטפס ל-SMM. וזה יכול להיעשות בשתי דרכים. מצא את ה-RCE בקוד SMM ונצל אותו, או הוסף מודול SMM משלך ל-BIOS, וזה בלתי אפשרי, מכיוון שהפעלנו את Boot Guard.

לפיכך, פגיעות זו מאפשרת לתוקף:

• צור rootkit מוסתר, בלתי ניתן להסרה של מטרה לא ידועה במערכת;
• בצע את הקוד שלך על אחת מליבות ערכת השבבים בתוך ה-Intel SoC, כלומר על ה-Intel ISH (תסתכל מקרוב על התמונה).

למרות שהיכולות של תת-המערכת של Intel ISH עדיין לא נחקרו, נראה שזהו וקטור התקפה מעניין נגד Intel ME.

ממצאים

1. המחקר סיפק תיאור טכני של אופן הפעולה של טכנולוגיית ה-Intel Boot Guard. מינוס כמה סודות באבטחה של אינטל באמצעות מודל ערפול.
2. מוצג תרחיש תקיפה המאפשר יצירת rootkit בלתי ניתן להסרה במערכת.
3. ראינו שמעבדי אינטל מודרניים מסוגלים להפעיל הרבה קוד קנייני עוד לפני שה-BIOS מתחיל.
4. פלטפורמות עם ארכיטקטורת Intel 64 הופכות פחות ופחות מתאימות להפעלת תוכנה חופשית: אימות חומרה, מספר הולך וגדל של טכנולוגיות קנייניות ותתי מערכות (שלוש ליבות בערכת השבבים SoC: x86 ME, x86 ISH ו-ARC PMC).

מקלות

ספקים שמשאירים בכוונה את מצב הייצור פתוח צריכים בהחלט לסגור אותו. עד כה, הם רק עוצמים עיניים ומערכות Kaby Lake החדשות מראות זאת.

משתמשים יכולים להשבית את Intel BG במערכות שלהם (המושפעות מהפגיעות המתוארת) על ידי הפעלת כלי התכנות Flash עם האפשרות -closemnf. ראשית, עליך לוודא (באמצעות MEinfo) שהתצורה של Intel BG באזור ME מספקת לכיבוי מדויק של טכנולוגיה זו לאחר תכנות ב-FPFs.

מקור: www.habr.com