עקיפת מסך נעילה מסוכן להחלפת SIM - עדכן את אנדרואיד עכשיו!

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

לדברי Schütz, הוא נתקל בבאג עקיפת מסך נעילה מוחלט של אנדרואיד בטעות ביוני 2022, בתנאי חיים אמיתיים שיכולים בקלות לקרות לכל אחד.

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

לרוע המזל, זה לא תוקן עד נובמבר 2022, וזו הסיבה שהוא חשף את זה רק עכשיו.

הפסקת סוללה חריפה

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

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

... כשהטלפון מת.

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

וכולנו נאבקנו עם סיסמאות ו-PIN כשאנחנו ממהרים, במיוחד אם הם קודים שאנחנו משתמשים בהם לעתים רחוקות ומעולם לא פיתחנו "זיכרון שרירים" להקלדה.

במקרה של Schütz, זה היה ה-PIN הצנוע בכרטיס ה-SIM שלו שהכשיל אותו, ומכיוון שקודי ה-SIM יכולים להיות קצרים עד ארבע ספרות, הם מוגנים על ידי נעילת חומרה שמגבילה אותך לשלושה ניחושים לכל היותר. (היינו שם, עשינו את זה, ננעלנו בחוץ.)

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

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

מה עשיתי עם האריזה הזו?

למרבה המזל, מכיוון שהוא לא היה מוצא את הבאג בלעדיו, שיץ איתר את אריזת ה-SIM המקורית שהוחבאה איפשהו בארון, גירד את רצועת המגן שמסתירה את ה-PUK והקלד אותה.

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

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

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

האם באמת יש "נעילה" במסך הנעילה שלך?

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

מסך נעילה נייד מודרני הוא קצת כמו דלת כניסה לבית עם מנעול בריח באיכות הגונה...

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

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

מפה של מעברים מפותלים

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

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

מה ששיץ נתקל, ברצף בלתי יוצא מן הכלל של פעולות, היה תקלה במה שמכונה בעגה "מסך הנעילה" מכונת מצבים.

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

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

...ולפעמים, מעברים סודיים אקזוטיים שאיש לא שם לב אליהם במהלך הבדיקה.

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

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

משחק את המערכת עם סים חדש

בהתחשב בעובדה שהתוקף יודע גם את ה-PIN וגם את ה-PUK של ה-SIM החדש, הם יכולים לטעות בכוונה את ה-PIN שלוש פעמים ואז מיד לקבל את ה-PUK נכון, ובכך לאלץ בכוונה את מכונת מצב מסך הנעילה למצב הלא מאובטח שגילה Schütz בטעות.

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

בטל נעילת מעקף!

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

כפי שניסח זאת שיץ עצמו:

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

עיכובים בגילוי

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

אבל, לדברי שיץ, גוגל לא הצליחה לנהל את זה במקרה הזה.

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

אבל גוגל החמיצה את המועד האחרון של אוקטובר.

התיקון לפגם, שנועד למספר באג CVE-2022-20465, הופיע סוף סוף בתיקוני האבטחה של אנדרואיד מנובמבר 2022, מתאריך 2022-11-05, עם Google מתאר את התיקון כמו: "אל תבטל את שמירת המקשים לאחר ביטול נעילה של SIM PUK."

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

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

והוא אכן הפסיק לחשוף את הבאג לאחר המועד האחרון של 15 באוקטובר 2022, מקבל ששיקול דעת הוא החלק הטוב שלעתים בגבורה, ואמר:

[פחדתי] מכדי לכבות את הבאג החי ומכיוון שהתיקון היה בעוד פחות מחודש, זה לא היה שווה את זה בכל מקרה. החלטתי לחכות לתיקון.

מה לעשות?

בדוק שהאנדרואיד שלך מעודכן: הגדרות > אבטחה > עדכון אבטחה > בדוק עדכונים.

שימו לב שכשביקרנו ב עדכון אבטחה מסך, לאחר שלא השתמש בטלפון Pixel שלנו במשך זמן מה, הכריז אנדרואיד באומץ המערכת שלך מעודכנת, מראה שהוא בדק אוטומטית דקה או משהו קודם לכן, אבל עדיין אומר לנו שאנחנו ב- October 5, 2022 עדכון אבטחה.

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

לאחר אתחול הגענו ל- November 5, 2022 רמת תיקון.

לאחר מכן חזרנו ועשינו עוד אחד בדוק עדכונים כדי לאשר שלא היו עדיין תיקונים.

---

השתמשנו הגדרות > אבטחה > עדכון אבטחה כדי להגיע לדף הכוח להורדה:

---

התאריך המדווח נראה שגוי אז הכרחנו את אנדרואיד לעשות זאת בדוק עדכונים בכל מקרה:

---

אכן היה עדכון להתקנה:

---

במקום לחכות השתמשנו קורות חיים להמשיך בבת אחת:

---

לאחר מכן התרחש תהליך עדכון ארוך:

---

עשינו עוד אחד בדוק עדכונים כדי לאשר שהיינו שם:

---