עדכוני אבטחה ומשאבים

צוות האבטחה של Android אחראי על ניהול נקודות חולשה באבטחה שמתגלות בפלטפורמת Android ובהרבה מאפליקציות הליבה של Android שמצורפות למכשירי Android.

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

דיווח על בעיות אבטחה

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

באגים שמסומנים כבעיות אבטחה לא גלויים חיצונית, אבל יכול להיות שהם יהפכו לגלויים אחרי שהבעיה תיבדק או תיפתר. אם אתם מתכננים לשלוח תיקון או בדיקה של Compatibility Test Suite ‏ (CTS) כדי לפתור בעיה אבטחתית, עליכם לצרף אותם לדוח הבאגים ולהמתין לתשובה לפני העלאת הקוד ל-AOSP.

מיון באגים

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

סוגי הקשר

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

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

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

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

לדוגמה, אפליקציה ל-Android עם יכולות שאסורות על ידי דומיין SELinux untrusted_app או עם גישה להרשאות privileged|signature.
ליבת מערכת ההפעלה פונקציונליות ש:
  • הוא חלק מהליבה
  • פועל באותו הקשר של ה-CPU כמו הליבה (לדוגמה, מנהלי התקנים של מכשירים)
  • יש לו גישה ישירה לזיכרון הליבה (לדוגמה, רכיבי חומרה במכשיר)
  • יש לו יכולת לטעון סקריפטים לרכיב ליבה (לדוגמה, eBPF)
  • היא אחת מתוך מספר מצומצם של שירותי משתמש שנחשבים לשווי ערך לליבת מערכת ההפעלה (כמו apexd,‏ bpfloader,‏ init,‏ ueventd ו-vold).
בסיס חומרה מהימן (THB) רכיבי חומרה נפרדים, בדרך כלל ב-SoC, שמספקים פונקציונליות חיונית לתרחישי השימוש העיקריים של המכשיר (כמו פס בסיס סלולרי, DSP,‏ GPU ומעבדי ML).
שרשרת תוכנת האתחול רכיב שמגדיר את המכשיר בזמן האתחול ואז מעביר את השליטה למערכת ההפעלה Android.
סביבת מחשוב אמינה (TEE) רכיב שנועד להיות מוגן גם מפני ליבת מערכת הפעלה עוינת (לדוגמה, TrustZone והיפר-ויזורים, כמו pKVM, שמגנים על מכונות וירטואליות מפני ליבת מערכת ההפעלה).
Secure Enclave / רכיב מאובטח (SE) רכיב חומרה אופציונלי שנועד להיות מוגן מכל הרכיבים האחרים במכשיר וממתקפה פיזית, כפי שמוגדר במאמר מבוא לרכיבי אבטחה.

כולל שבב Titan-M שקיים בחלק ממכשירי Android.

מידת החומרה

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

דירוג ההשלכות של ניצול מוצלח
קריטי
  • הרצת קוד שרירותי בסביבת מחשוב אמינה (TEE) או ברכיב מאובטח (SE)
  • עקיפה של מנגנוני תוכנה שנועדו למנוע מתקלות ברכיבי תוכנה או חומרה שקשורים לבטיחות (לדוגמה, אמצעי הגנה מפני התחממות יתר)
  • גישה מרחוק לפרטי כניסה רגישים שמשמשים לאימות שירותים מרחוק (לדוגמה, סיסמאות לחשבון או אסימוני Bearer)
  • הרצת קוד שרירותי מרחוק בהקשר של פס בסיס סלולרי ללא אינטראקציית משתמש (לדוגמה, ניצול באג בשירות רדיו סלולרי)
  • הרצת קוד שרירותי מרחוק בהקשר של הרשאות, בשרשרת של טוען האתחול, ב-THB או בקרנל של מערכת ההפעלה
  • עקיפה מרחוק של הדרישות לאינטראקציית משתמש בהתקנת חבילה או התנהגות שוות ערך
  • עקיפה מרחוק של דרישות אינטראקציה עם המשתמש בהגדרות ליבה למפתחים, אבטחה או פרטיות
  • מניעת שירות מתמשכת מרחוק (קבועה, מחייבת צריבה מחדש של כל מערכת ההפעלה או איפוס להגדרות המקוריות)
  • עקיפה של הפעלה מאובטחת מרחוק
  • גישה לא מורשית לנתונים שמאובטחים על ידי ה-SE, כולל גישה שמופעלת על ידי מפתחות חלשים ב-SE.
גבוהה
  • עקיפה מלאה של תכונת אבטחה מרכזית (לדוגמה, SELinux,‏ FBE או seccomp)
  • עקיפה כללית של הגנה לעומק או טכנולוגיה לצמצום ניצול לרעה בשרשרת של תוכנת אתחול, TEE או SE
  • עקיפה כללית של אמצעי ההגנה של מערכת ההפעלה שחושפת את הזיכרון או את תוכן הקובץ בגבולות של אפליקציה, משתמש או פרופיל
  • התקפות נגד SE שגורמות לשדרוג לאחור להטמעה פחות מאובטחת
  • להשתמש בפריצה של קושחת מתכת חשופה (bare-metal) שאפשר לגשת אליה מרחוק (לדוגמה, פס בסיס, מעבד תקשורת (CP)) כדי להגיע לליבת מעבד האפליקציות (AP) או לעקוף מנגנונים שנועדו לבודד את קושחת המתכת החשופה מליבת מעבד האפליקציות
  • עקיפה של הגנת המכשיר, ההגנה למכשיר אחרי איפוס (ב-Android 15 ואילך) או הגבלות של ספק הסלולר
  • עקיפה של דרישות לאינטראקציה עם המשתמש שמאובטחות על ידי TEE
  • פגיעות קריפטוגרפית שמאפשרת מתקפות נגד פרוטוקולים מקצה לקצה, כולל מתקפות נגד אבטחת שכבת התעבורה (TLS) ו-Bluetooth ‏ (BT).
  • גישה מקומית לפרטי כניסה רגישים שמשמשים לאימות שירותים מרוחקים (לדוגמה, סיסמאות לחשבונות או אסימוני גישה)
  • הרצת קוד שרירותי מקומי בהקשר של הרשאות, שרשרת טוען האתחול, THB או ליבת מערכת ההפעלה
  • עקיפה של הפעלה מאובטחת במכשיר מקומי
  • עקיפת מסך הנעילה
  • עקיפה מקומית של דרישות לאינטראקציה עם המשתמש בהגדרות ליבה של מפתחים, אבטחה או פרטיות
  • עקיפה מקומית של הדרישות לאינטראקציה של המשתמשים בהתקנת חבילה או בהתנהגות מקבילה
  • התקפת מניעת שירות (DoS) מקומית מתמשכת (קבועה, מחייבת הפעלה מחדש של כל מערכת ההפעלה או איפוס להגדרות המקוריות)
  • גישה מרחוק לנתונים מוגנים (כלומר, נתונים שמוגבלים להקשר בעל הרשאות)
  • הרצת קוד מרחוק בהקשר לא מורשה
  • התקפת מניעת שירות מרחוק לשירות סלולרי או לשירות Wi-Fi שנמשכת עד להתערבות של המשתמש, ומופעלת ללא אינטראקציית משתמש (לדוגמה, קריסה של שירות הרדיו הסלולרי עם מנה לא תקינה שלא משוחזרת באופן אוטומטי ודורשת הפעלה מחדש ידנית או הפעלה מחדש של המכשיר).
  • עקיפה מרחוק של הדרישות לאינטראקציה עם המשתמש (גישה לפונקציונליות או לנתונים שצריכים לדרוש הפעלה על ידי המשתמש או הרשאת משתמש)
  • מניעת גישה ממוקדת לשירותי חירום
  • העברת מידע רגיש באמצעות פרוטוקול רשת לא מאובטח (לדוגמה, HTTP ו-Bluetooth לא מוצפן) כשהשולח מצפה להעברה מאובטחת. הערה הכלל הזה לא חל על הצפנת Wi-Fi (למשל, WEP)
  • גישה לא מורשית לנתונים שמאובטחים על ידי TEE, כולל גישה שמופעלת על ידי מפתחות חלשים ב-TEE
בינונית
  • עקיפה כללית של הגנה לעומק או של טכנולוגיה לצמצום ניצול לרעה בהקשר של הרשאות, THB או ליבת מערכת ההפעלה
  • עקיפה כללית של אמצעי ההגנה של מערכת ההפעלה, שחושפת את מצב התהליך או את המטא-נתונים מעבר לגבולות של האפליקציה, המשתמש או הפרופיל
  • עקיפת ההצפנה או האימות של Wi-Fi
  • פגיעות קריפטוגרפית בפרימיטיבים קריפטוגרפיים סטנדרטיים שמאפשרת דליפה של טקסט רגיל (לא פרימיטיבים שמשמשים ב-TLS)
  • גישה מקומית לנתונים מוגנים (כלומר, נתונים שמוגבלים להקשר עם הרשאות מיוחדות)
  • הרצת קוד שרירותי מקומי בהקשר ללא הרשאות
  • עקיפה מקומית של דרישות אינטראקציה עם המשתמש (גישה לפונקציונליות או לנתונים שבדרך כלל דורשים הפעלה על ידי המשתמש או הרשאה מהמשתמש)
  • גישה מרחוק לנתונים לא מוגנים (כלומר, נתונים שבדרך כלל נגישים לכל אפליקציה שמותקנת באופן מקומי)
  • הרצת קוד שרירותי מרחוק בהקשר מוגבל
  • מניעת שירות זמנית במכשיר מרחוק (הקפאה או הפעלה מחדש מרחוק)
נמוכה
  • עקיפה כללית של הגנה לעומק ברמת המשתמש או של טכנולוגיה לצמצום ניצול בהקשר לא מורשה
  • עקיפה של הרשאה ברמת הגנה רגילה
  • פגיעות קריפטוגרפית בשימוש לא סטנדרטי
  • עקיפה כללית של תכונות התאמה אישית במכשיר, כמו Voice Match או Face Match
  • תיעוד שגוי שעלול להוביל לפרצת אבטחה
  • הרצת קוד שרירותי מקומי בהקשר מוגבל
  • טקסט שמוגדר על ידי המערכת וכולל תיאור מטעה שיוצר ציפייה שגויה לאבטחה
השפעה זניחה על האבטחה (NSI)
  • פגיעות שההשפעה שלה צומצמה על ידי אחד או יותר מהשינויים בארכיטקטורה שספציפיים לגרסה, כך שהחומרה האפקטיבית נמוכה מנמוכה, למרות שבעיית הקוד הבסיסית עשויה להישאר
  • כל פגיעות שמצריכה מערכת קבצים פגומה, אם מערכת הקבצים הזו תמיד מאומצת/מוצפנת לפני השימוש.
  • מניעת שירות זמנית מקומית, למשל במקרים שבהם אפשר לפתור את הבעיה על ידי הפעלה מחדש של המכשיר או הסרה של האפליקציה שגרמה לבעיה.

גורמי שינוי של רמת החומרה

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

סיבה אפקט
נדרשת הרצה כהקשר עם הרשאות מיוחדות כדי לבצע את המתקפה (לא רלוונטי ל-TEE, ל-SE ולמפקחי מכונות וירטואליות כמו pKVM) רמת חומרה 1-
פרטים ספציפיים לגבי הפגיעות מגבילים את ההשפעה של הבעיה רמת חומרה 1-
עקיפה של אימות ביומטרי שדורשת מידע ביומטרי ישירות מבעלי המכשיר רמת חומרה 1-
הגדרות של קומפיילר או פלטפורמה מצמצמות את הפגיעות בקוד המקור רמת חומרה בינונית אם הפגיעות הבסיסית היא בינונית או גבוהה יותר
הפעולה הזו דורשת גישה פיזית לחלקים הפנימיים של המכשיר, ואפשר לבצע אותה גם אם המכשיר כבוי או אם לא בוצעה בו פתיחת נעילה מאז ההפעלה שלו רמת חומרה 1-
נדרשת גישה פיזית לחלקים הפנימיים של המכשיר כשהוא מופעל וכבר בוצעה בו פתיחת נעילה ‫2- מידת חומרה
מתקפה מקומית שדורשת ביטול נעילה של שרשרת תוכנת האתחול לא גבוהה מנמוכה
מתקפה מקומית שדורשת שמצב פיתוח או הגדרות קבועות של מצב פיתוח יהיו מופעלים במכשיר (ולא מדובר בבאג במצב פיתוח עצמו). לא גבוהה מנמוכה
אם אף דומיין SELinux לא יכול לבצע את הפעולה במסגרת SEPolicy שסופקה על ידי Google השפעה זניחה על האבטחה

מקומי לעומת קרוב לעומת רחוק

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

וקטורים של התקפות קרובות נחשבים מרוחקים. הבאגים האלה כוללים באגים שאפשר לנצל רק אם התוקף נמצא בקרבת מכשיר היעד, למשל באג שדורש שליחה של חבילות Wi-Fi או Bluetooth פגומות. אנחנו מחשיבים מתקפות שמבוססות על Ultra-wideband‏ (UWB) ועל NFC כמתקפות שמתבצעות בקרבה, ולכן מרחוק.

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

מכשירים שהותאמו בהצלחה (כמו מכשירי Bluetooth נלווים) נחשבים למקומיים. אנחנו מבחינים בין מכשיר מותאם לבין מכשיר שמשתתף בתהליך התאמה.

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

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

אבטחת רשת

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

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

אימות ביומטרי

אימות ביומטרי הוא תחום מורכב, ואפילו את המערכות הכי טובות אפשר להטעות באמצעות התאמה כמעט מלאה (ראו Android Developers Blog: Lockscreen and authentication improvements in Android 11). דירוגי החומרה האלה מבחינים בין שני סוגים של התקפות, והם נועדו לשקף את הסיכון בפועל למשתמש הקצה.

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

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

SYSTEM_ALERT_WINDOW ו-tapjacking

מידע על המדיניות שלנו בנושא SYSTEM_ALERT_WINDOW ו-tapjacking זמין בקטע Tapjacking/overlay SYSTEM_ALERT_WINDOW vulnerability on a non-security-critical screen בדף Bugs with no security impact ב-BugHunter University.

אבטחה של משתמשים מרובים ב-Android Automotive OS

Android Automotive OS משתמש במודל אבטחה מרובה משתמשים, ששונה מזה של גורמי הצורה האחרים. כל משתמש ב-Android מיועד לשימוש של אדם פיזי אחר. לדוגמה, אפשר להקצות משתמש אורח זמני לחבר ששאל את הרכב מבעל הרכב. כדי לתת מענה לתרחישי שימוש כאלה, למשתמשים יש גישה כברירת מחדל לרכיבים הדרושים לשימוש ברכב, כמו הגדרות של Wi-Fi ורשת סלולרית.

רכיב מושפע

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

צוות ההנדסה של Android מתקן באגים בקוד AOSP במאגרים הפנימיים שלנו.

הרכיב משפיע גם על האופן שבו המשתמשים מקבלים עדכונים. באג במסגרת או בקרנל שדורש עדכון קושחה דרך האוויר (OTA) שכל יצרן ציוד מקורי (OEM) צריך לדחוף. באג באפליקציה או בספרייה שפורסמו ב-Google Play (לדוגמה, Gmail,‏ Google Play Services או WebView) יכול להישלח למשתמשי Android כעדכון מ-Google Play.

שליחת הודעה לשותפים

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

שחרור קוד ל-AOSP

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

קבלת עדכוני Android

עדכונים למערכת Android מועברים בדרך כלל למכשירים דרך חבילות עדכון OTA. העדכונים האלה עשויים להגיע מהיצרן המקורי של המכשיר או מהספק שמספק שירות למכשיר. עדכונים למכשירי Google Pixel מגיעים מצוות Google Pixel אחרי שעברו הליך בדיקה של אישור טכני (TA) של ספק הסלולר. ‫Google גם מפרסמת קובצי אימג' של Pixel להגדרות המקוריות שאפשר להעביר למכשירים.

עדכון שירותי Google

בנוסף לתיקון באגים שקשורים לאבטחה, צוות האבטחה של Android בודק באגים שקשורים לאבטחה כדי לקבוע אם יש דרכים אחרות להגן על המשתמשים. לדוגמה, מערכת Google Play סורקת את כל האפליקציות ומסירה כל אפליקציה שמנסה לנצל באג אבטחה. במכשירים עם Google Play Services, אפשר להשתמש גם בתכונה אימות אפליקציות כדי להזהיר משתמשים מפני אפליקציות שעלולות להזיק, אם האפליקציות האלה הותקנו ממקורות אחרים ולא מ-Google Play.

מקורות מידע נוספים

מידע למפתחי אפליקציות ל-Android: https://developer.android.com

מידע בנושא אבטחה זמין באתרים של Android Open Source ו-Google Developers. כדאי להתחיל עם:

דוחות

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