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

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

אגב, המאמר מבוסס על הדוחות "על המשמר מפני רוטקיטים: 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 (ME), שיש לה גם קושחה (firmware של Intel ME).

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

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

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

בקר SPI bus master, בקר SPI המובנה בתוך ערכת השבבים, אחראי על בקרת גישה לאזורים (בהתאם להרשאות שצוינו), ודרך בקר זה מתבצעת הגישה לזיכרון זה. אם ההרשאות מוגדרות לערכים המומלצים (מסיבות אבטחה) על ידי אינטל, אז לכל משתמש זיכרון פלאש SPI יש גישה מלאה (קריאה/כתיבה) רק לאזור שלו. האחרים הם לקריאה בלבד או בלתי נגישים. עובדה ידועה היא שבמערכות רבות, למעבד יש גישה מלאה ל-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. חסימת ניסיונות כתיבה לאזור ה-BIOS של UEFI על ידי יצירה ועיבוד של פסיקת SMI המתאימה על ידי הגדרת הביטים BIOS_WE/BLE ו-SMM_BWP באוגרי ערכת השבבים;
4. גרסה מתקדמת יותר של הגנה זו היא Intel BIOS Guard ‏(PFAT).

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

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

אימות האותנטיות של UEFI BIOS

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

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

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

מעבד אינטל

קאפ מציע שהמעבד הוא סביבת הביצוע העיקרית בארכיטקטורת אינטל 64. מדוע הוא שורש האמון? מסתבר שיש לו את האלמנטים הבאים:

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

אינטל ME

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

למרות סודיותה, Intel ME היא גם מקור לאמון משום שיש לה:

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

Intel Boot Guard 1.x

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

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

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

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

אתחול מדוד

במצב אתחול מדוד (MB), כל רכיב אתחול (החל מ-ROM אתחול המעבד) "מודד" את הבא אחריו באמצעות יכולות ה-TPM (מודול פלטפורמה מהימנה). למי שלא יודע, הבה נסביר.

ל-TPM יש PCRs (אוגרי תצורת פלטפורמה) שבהם תוצאת פעולת הגיבוב כתובה לפי הנוסחה:

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

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

אתחול מאומת

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

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

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

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

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

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

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

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

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

תצורת Intel Boot Guard

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

משאירים דברים כאלה לשיקול דעתם של הספקים...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מערכת
שים לב

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

ג'יגה-בייט GA-Q170-D3H
סקיילייק, יש תמיכה

ג'יגה-בייט GA-B150-HD3
סקיילייק, יש תמיכה

MSI H170A גיימינג פרו
סקיילייק, אין תמיכה

Lenovo ThinkPad 460
סקיילייק, יש תמיכה, הטכנולוגיה מופעלת

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

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

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

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

ROM אתחול מעבד אינטל

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

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

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

בואו נבחן מקרוב את המניפסטים. במבנה המניפסט הראשון, אנו רואים מספר קבועים לא ברורים, גיבוב של המפתח הציבורי מהמניפסט השני, ומפתח ציבורי של מפתח השורש של 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 hash מהפיוזים, אשר בשלב זה כבר התקבל מ-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}, שפותח על ידי לנובו.

תפקידו הוא לחפש (לפי 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

במקרה של ג'יגה-בייט, התברר שמדובר במודול 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;
}

טבלת ה-hash {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), יש עניין רב בחקר גרסת הארכיטקטורה החדשה עבור פלטפורמות על SoCs של אינטל, אשר עברה שינויים משמעותיים, כגון:

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

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

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

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

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

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

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

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

0008 0000 שעות
IBBP
BIOS UEFI, שלבי SEC/PEI, x86, חתום על ידי הספק

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

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

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

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

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

על המשמר מפני רוטקיטים

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

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

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

• כל מוצרי ג'יגהבייט;
• כל מוצרי MSI;
• 21 דגמי מחשבים ניידים של לנובו ו-4 דגמי שרתים של לנובו.

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

תגובה הולמת באה רק מ Lenovo, שזיהה את הבעיה ו פרסם תיקון.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ממצאים

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

מקלות

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

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

מקור: www.habr.com