דליפת "מפתח הזהב" של מיקרוסופט מאפשרת השבתה של אתחול מאובטח

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

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

כפי שדווח על ידי Ars Technica ו הקופה עם החדשות שמקורן בא אתר שסביר שיעשה לך כאב ראש (לא צוחק), כמה מפתחים (@לעולם לא פורסם ו @TheWack0lian) גילו שדלת אחורית שמיקרוסופט אפתה בה למטרות ניפוי באגים פתחה אפשרויות של השבתת אתחול מאובטח במכשירי Windows.

אתחול מאובטח ומה זה?

כאשר אתה מאתחל לראשונה מכשיר Windows, הליך האתחול מתנהל בסדר הכללי הזה: UEFI (Unified Extensible Firmware Interface, שהוא תחליף ל-BIOS) -> מנהל האתחול -> טוען אתחול -> חלונות. UEFI הוא המקום שבו קיימת פונקציונליות האתחול המאובטח. כפי שהשם מרמז עם הפעלה בטוחה

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

אתחול מאובטח הוא תכונה אופציונלית, אך מיקרוסופט הפכה את הפעלתה לחובה לקבל אישור Windows מ-Windows 8 ואילך. הנימוק כאן היה שאתחול מאובטח יקשה על מחברי תוכנות זדוניות להכניס קוד להליך האתחול. עם זאת, תופעת הלוואי לאתחול מאובטח הייתה שזה עשה את זה קצת מסובך לאתחול כפול במחשבי Windows, כמו גם מערכת ההפעלה השנייה וכל הדרישות המוקדמות שלה צריכות להיות חתומות דיגיטלית, או שהאתחול המאובטח צריך להיות נָכֶה. יש הרבה בעיות אחרות בנושא הזה, ומשתמשים מנוסים ב-dual boots יידעו עליהם יותר ממה שיכולתי להסביר בפסקה.

כעת, ישנם כמה מכשירים שבהם אתחול מאובטח לא יכול להיות מושבת על ידי המשתמש גם אם הוא רצה בכך. זה התחום שבו הנושא שלנו מצטמצם באופן דרסטי מכל מכשירי Windows (כולל שולחנות עבודה) למכשירי Windows ספציפיים כמו מכשירי Windows Phone, מכשירי Windows RT, מכשירי Surface מסוימים ואפילו HoloLens. למכשירי משתמש קצה אלה יש אתחול מאובטח נעול, כלומר א משתמש קצה אינו יכול לשנות או להשבית היבטים הקשורים לאתחול מאובטח, ובהרחבה, הם לא יכולים לגעת במערכת ההפעלה בדרכים שאינן מאושרות על ידי Microsoft עבור משתמש הקצה.

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

אלמנט החתימה מסתמך גם על מה שנקרא DeviceID, המשמש בעת הגשת הבקשה. אני אתן לפוסט בבלוג לעשות את ההסבר כאן, מכיוון שיש כמה חלקים שאינם ברורים לי כל כך:

כמו כן, יש דבר כזה שנקרא DeviceID. זה 64 הסיביות הראשונות של Hash מלוח SHA-256, של פלט UEFI PRNG כלשהו. הוא משמש בעת החלת מדיניות ב-Windows Phone וב-Windows RT (מובייל-startup מגדיר אותו בטלפון, ו-SecureBootDebug.efi כאשר זה מושק בפעם הראשונה ב-RT). בטלפון, המדיניות חייבת להיות ממוקמת במקום ספציפי במחיצת EFIESP עם שם הקובץ כולל ה-hex-צורת ה-DeviceID. (עם Redstone, זה השתנה ל-UnlockID, המוגדר על ידי bootmgr, והוא רק הפלט הגולמי של UEFI PRNG).

בעיקרון, bootmgr בודק את המדיניות כשהיא נטענת, אם היא כוללת DeviceID, שאינה תואמת ל-DeviceID של המכשיר עליו פועל bootmgr, המדיניות לא תצליח להיטען. כל מדיניות המאפשרת לאפשר חתימת בדיקות (MS קוראת למדיניות Retail Device Unlock / RDU, וכדי התקן אותם הוא ביטול נעילת מכשיר), אמור להיות נעול ל-DeviceID (UnlockID ב-Redstone ו מֵעַל). ואכן, יש לי מספר מדיניות (חתומה על ידי אישור הייצור של Windows Phone) כמו זה, כאשר ההבדלים היחידים הם ה-DeviceID הכלול והחתימה. אם לא מותקנת מדיניות חוקית, bootmgr חוזר לשימוש במדיניות ברירת מחדל הממוקמת במשאבים שלה. מדיניות זו היא זו שחוסמת את הפעלת חתימת בדיקות וכו' באמצעות כללי BCD.

זה החלק שבו הדברים הופכים מעניינים. במהלך הפיתוח של Windows 10 v1607, מיקרוסופט יצרה סוג חדש של מדיניות אתחול מאובטח (המכונה SBP מעתה והלאה למען הקיצור) למטרות בדיקות פנימיות ואיתור באגים. המדיניות היא "משלימה" במהותה ללא DeviceID, והיא גורמת למיזוג ההגדרות שלה למדיניות אתחול קיימת. מנהל האתחול נטען בסוגים הישנים יותר של SBP, לאחר מכן מאמת את החתימה והאותנטיות שלו ולאחר מכן נטען במדיניות האתחול המשלימה הזו. הבעיה כאן היא שאין אימות נוסף על הפוליסה המשלימה עצמה. כמו כן, מנהלי אתחול לפני Windows 10 v1511 אינם יודעים על קיומו של האופי המשלים של מדיניות זו, ומכאן, להגיב כאילו הטעינו פוליסה תקפה וחתומה לחלוטין. שוב, התנהגות זו הייתה ככל הנראה לפיתוח פנימי, כך שהמפתחים לא היו צריכים לחתום על כל גרסת מערכת הפעלה ושינוי קטן שהם היו צריכים לעשות במכשיר.

SBP זה מכונה "מפתח זהב" מכיוון שהוא בעצם מבטל את מטרת בדיקות החתימה. SBP זה נשלח ללא כוונה במכשירים קמעונאיים, אם כי במצב מושבת. המפתחים מצאו את ה-SBP הזה ופרסמו את ממצאיהם. עכשיו, ה-SBP יכול להיות נמצא מרחף באינטרנט, כאשר ה-zip הספציפי הזה משמש להתקנת ה-SBP במכשירי Windows RT.

מה זה אומר?

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

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

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

אז מה התיקון?

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

מה הלאה?

יש עולם של אפשרויות, וחלקן מתפתחות בפורומי Windows שלנו. אתה יכול לבדוק את הפורומים שלנו ב פיתוח ופריצה של Windows Phone 8 והפורומים שלנו עבור Windows 8, Windows RT ו- Surface Development and Hacking. אתה יכול גם למצוא שרשורי הוראות עבור מכשירים מסוימים, כאשר משתמשים אחרים דנים בכך.

---

הנוכחות של דלת האחורית של ניפוי באגים והדליפה של ה-SBP חשובים לא רק עבור הצד השלישי פיתוח של מכשירי Windows נעולים, הם גם מראים לנו תזכורת קודרת על מה שיכול לקרות אם זה מכוון נותרו דלתות אחוריות. ההתמקדות האחרונה באבטחה פנתה לסוכנויות חקירה שדוחקות שהנוכחות של דלתות אחוריות כאלה ישמשו כדי לסייע במטרות החקירה המשפטיות שלהן. אבל במוקדם או במאוחר, שיטות אלה רָצוֹן ליפול לידיים הלא נכונות. מה שנועד לשמש ככלי למלחמה בפשיעה ולסיוע בצדק, יהפוך אז לכלי לפשע עצמו יום אחד.

מה דעתך על הדלפת ה-Debug SBP? האם אתה מרגיש ש"מפתחות זהב" כמו אלה צריכים להתקיים? ספר לנו בתגובות למטה!