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

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

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

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

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

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

מיון באגים

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

סוגי הקשר

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

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

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

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

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

כולל הצ'יפ Titan-M שמופיע במכשירי Android מסוימים.

מידת החומרה

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

Rating התוצאה של ניצול מוצלח
קריטי
  • ביצוע קוד שרירותי בסביבת TEE או SE
  • מעקף של מנגנוני תוכנה שנועדו למנוע תוכנה או חומרה הקשורות לבטיחות רכיבים בגלל תקלות (לדוגמה, אמצעי הגנה תרמיים)
  • גישה מרחוק לפרטי כניסה רגישים שמשמשים לאימות של שירות מרחוק (ל לדוגמה, סיסמאות לחשבונות או אסימונים למוכ"ז)
  • ביצוע קוד שרירותי מרחוק בהקשר של פס בסיס סלולרי ללא משתמש אינטראקציה (לדוגמה, ניצול באג בשירות הרדיו הסלולרי)
  • ביצוע קוד שרירותי מרחוק בהקשר מוגבל, בשרשרת תוכנת האתחול, ב-THB או הליבה של מערכת ההפעלה
  • מעקף מרחוק של דרישות האינטראקציה של המשתמש בהתקנת חבילה או שווה ערך התנהגות
  • מעקף מרחוק של דרישות האינטראקציה של המשתמשים עבור מפתח ליבה, אבטחה או הגדרות הפרטיות
  • התקפת מניעת שירות מתמשכת (DoS) מרחוק, שמחייבת רפליקציה של כל מערכת ההפעלה או איפוס להגדרות המקוריות)
  • מעקף להפעלה מאובטחת מרחוק
  • גישה לא מורשית לנתונים שאבטחו על ידי ה-SE, כולל גישה שהופעלה על ידי מפתחות חלשים ב- SE.
גבוהה
  • מעקף מלא של תכונת אבטחה ליבה (לדוגמה, SELinux, FBE או seccomp)
  • מעקף כללי להגנה לעומק או לטכנולוגיה לצמצום הבעיה שרשרת תוכנת אתחול, TEE או SE
  • מעקף כללי להגנות של מערכת ההפעלה שחושפים זיכרון או תוכן של קבצים מעבר לגבולות של אפליקציות, משתמשים או פרופילים
  • התקפות נגד SE שגורמות לשדרוג לאחור להטמעה פחות מאובטחת
  • מעבר מקושחה ממתכת חשופה שנפרצה, שניתן לגשת אליה מרחוק (למשל, פס בסיס, CP/מעבד תקשורת) בליבה (kernel) או מעקף של מעבד האפליקציות (AP) מנגנונים שנועדו לבודד קושחה של מתכת חשופה מהליבה של AP
  • מעקף של הגנת המכשיר/הגנה על איפוס להגדרות המקוריות או הגבלות על הספק
  • מעקף של דרישות האינטראקציה של המשתמשים, המאובטחות על ידי TEE
  • נקודת חולשה קריפטוגרפית שמאפשרת התקפות על פרוטוקולים מקצה לקצה כולל תקיפות של אבטחת שכבת התעבורה (TLS) ו-Bluetooth (BT).
  • גישה מקומית לפרטי כניסה רגישים שמשמשים לאימות של שירות מרחוק (ל לדוגמה, סיסמאות לחשבונות או אסימונים למוכ"ז)
  • ביצוע קוד שרירותי מקומי בהקשר מוגבל, בשרשרת תוכנת האתחול, ב-THB או הליבה של מערכת ההפעלה
  • מעקף להפעלה מאובטחת מקומית
  • מעקף למסך הנעילה
  • מעקף מקומי של דרישות האינטראקציה של המשתמשים עבור מפתחי ליבה, אבטחה או פרטיות ההגדרות
  • מעקף מקומי של דרישות אינטראקציה של משתמשים בהתקנת חבילה או שווה ערך התנהגות
  • התקפת מניעת שירות (DoS) קבועה, שמחייבת רפליקציה של כל מערכת ההפעלה או איפוס להגדרות המקוריות)
  • גישה מרחוק לנתונים מוגנים (כלומר, נתונים שמוגבלים לנתונים הקשר)
  • ביצוע קוד שרירותי מרחוק בהקשר ללא הרשאות
  • מניעת גישה מרחוק לשירות סלולרי או Wi-Fi ללא אינטראקציה של המשתמש (עבור לדוגמה, קריסת שירות הרדיו הסלולרי באמצעות חבילה לא תקינה)
  • מעקף מרחוק של דרישות האינטראקציה של המשתמשים (גישה לפונקציונליות או לנתונים נדרשות ביוזמת המשתמש או בהרשאת משתמש)
  • מניעת גישה ממוקדת לשירותי חירום
  • העברת מידע רגיש בפרוטוקול רשת לא מאובטח (לדוגמה, HTTP ו-Bluetooth לא מוצפן) כשהמגיש מצפה להעברה מאובטחת. הערה ההגדרה הזו לא חלה על הצפנת Wi-Fi (כמו WEP)
  • גישה לא מורשית לנתונים שאבטחו על ידי מכשיר ה-TEE, כולל גישה שהופעלה על ידי מפתחות חלשים בסביבת TEE
בינונית
  • מעקף כללי להגנה לעומק או לטכנולוגיה לצמצום הבעיה הקשר מוגבל, THB או הליבה של מערכת ההפעלה
  • מעקף כללי להגנות על מערכת ההפעלה שחושפות את מצב התהליך או מטא-נתונים בגבולות של אפליקציות, משתמשים או פרופילים
  • עקיפה של הצפנת Wi-Fi או אימות
  • נקודת חולשה קריפטוגרפית בפרימיטיבים קריפטוגרפיים רגילים שמאפשרת דליפה של טקסט ללא הצפנה (בלי פרטים ראשוניים שמשתמשים בהם ב-TLS)
  • גישה מקומית לנתונים מוגנים (כלומר, נתונים שמוגבלים להקשר מסווג)
  • ביצוע קוד שרירותי מקומי בהקשר ללא הרשאות
  • מעקף מקומי של דרישות אינטראקציה של משתמשים (גישה לפונקציונליות או לנתונים בדרך כלל יידרשו ביוזמת משתמש או בהרשאת משתמש)
  • גישה מרחוק לנתונים לא מוגנים (כלומר, נתונים שבדרך כלל נגישים לכל משתמש מקומי אפליקציה מותקנת)
  • ביצוע קוד שרירותי מרחוק בהקשר מוגבל
  • התקפת מניעת שירות (DoS) זמנית של המכשיר (ניתוק או הפעלה מחדש מרחוק)
נמוכה
  • מעקף כללי להגנה ברמת המשתמש לעומק או לניצול של טכנולוגיה לצמצום הבעיה הקשר ללא הרשאות
  • מעקף של השגרה רמת הגנה הרשאה
  • נקודת חולשה קריפטוגרפית בשימוש לא סטנדרטי
  • מעקף כללי של תכונות ההתאמה האישית במכשיר, כמו Voice Match או Face Match
  • תיעוד שגוי שעלול להוביל לפגיעוּת באבטחה
  • ביצוע קוד שרירותי מקומי בהקשר מוגבל
  • טקסט בהגדרת המערכת שכולל תיאור מטעה שיוצר ציפיות האבטחה
Negligible Security Impact (NSI)
  • נקודת חולשה שההשפעה שלה צומצמה על ידי שינוי אחד או יותר של דירוג או שינויים בארכיטקטורה שספציפית לגרסה מסוימת, כך שרמת החומרה האפקטיבית נמוכה מ'נמוכה', למרות שהבעיה הבסיסית בקוד עשויה להישאר
  • כל נקודת חולשה שמחייבת מערכת קבצים שגויה, אם מערכת הקבצים הזו תמיד הוצפנו/הוצפנו לפני השימוש.
  • מניעת שירות (DoS) זמנית, למשל המקומות שבהם ניתן לפתור את המצב על ידי הפעלה מחדש של המכשיר או הסרה האפליקציה שמפעילה.

תכונות שינוי של דירוג

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

סיבה אפקט
נדרשת הפעלה בתור הקשר מורשה כדי לבצע את המתקפה (לא רלוונטי ל-TEE, SE, ו-hypervisors כמו pKVM) - רמת חומרה אחת
פרטים ספציפיים לנקודות חולשה מגבילים את השפעת הבעיה - רמת חומרה אחת
מעקף לאימות ביומטרי שדורש מידע ביומטרי ישירות בעלי המכשיר - רמת חומרה אחת
הגדרות של מהדר או פלטפורמה מצמצמות נקודת חולשה בקוד המקור רמת חומרה בינונית אם נקודת החולשה הבסיסית היא בינונית או גבוהה יותר
נדרשת גישה פיזית לחלק הפנימי של המכשיר והיא עדיין אפשרית אם המכשיר כבוי או הנעילה של המכשיר לא נפתחה מאז שהופעל - רמת חומרה אחת
נדרשת גישה פיזית לחלק הפנימי של המכשיר בזמן שהמכשיר פועל והייתה לו בעבר הנעילה בוטלה -רמת חוּמרה
מתקפה מקומית שמחייבת ביטול נעילה של שרשרת תוכנת האתחול לא גבוה מנמוך
מתקפה מקומית שמחייבת את מצב הפיתוח או ההגדרות הקבועות של מצב המפתח כדי להיות מופעלות כרגע במכשיר (וזה לא באג במצב פיתוח עצמו). לא גבוה מנמוך
אם אין דומיין 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: שיפורים במסך הנעילה ובאימות ב-Android 11). דירוגי החומרה האלה מבחינים בין שני סוגים של התקפות, והמטרה שלהם היא לשקף את הסיכון בפועל למשתמש הקצה.

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

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

SYSTEM_ALERT_WINDOW וחטיפת הקשות

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

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

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

הרכיב המושפע

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

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

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

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

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

שליחת הקוד ל-AOSP

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

קבלת עדכונים ל-Android

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

מתבצע עדכון של שירותי Google

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

משאבים אחרים

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

פרטי האבטחה קיימים ברחבי הקוד הפתוח של Android ובאתרים למפתחים. החוויה שלי חיובית מקומות שכדאי להתחיל:

דוחות

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