יישום אבטחה

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

דף זה מספק שיטות עבודה מומלצות לאבטחה המבוססות על החוויות שלנו, מרחיב את תיעוד ה- Designing for Security שסיפקנו למפתחים וכולל פרטים ייחודיים לבנייה או התקנה של תוכנות ברמת המערכת במכשירים.

כדי להקל על אימוץ שיטות העבודה המומלצות הללו, במידת האפשר צוות האבטחה של Android משלב בדיקות בחבילת בדיקת התאימות של Android (CTS) וב- Android Lint . אנו מעודדים מיישמי מכשירים לתרום בדיקות שיכולות לעזור למשתמשי אנדרואיד אחרים (הצג בדיקות הקשורות לאבטחה ב- root/cts/tests/tests/security/src/android/security/cts ).

תהליך פיתוח

השתמש בשיטות העבודה המומלצות הבאות בתהליכי הפיתוח ובסביבתך.

סקירת קוד המקור

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

• הפעל את Android Lint על כל קוד האפליקציה באמצעות Android SDK ותקן את כל הבעיות שזוהו.
• יש לנתח קוד מקורי באמצעות כלי אוטומטי שיכול לזהות בעיות בניהול זיכרון כגון הצפת מאגר ושגיאות מנותקות.
• למערכת ה-build של אנדרואיד יש תמיכה ברבים מחומרי החיטוי של LLVM, כגון AddressSanitizer ו-UndefinedBehaviorSanitizer שניתן להשתמש בהם למטרה זו.

שימוש בבדיקות אוטומטיות

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

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

חתימה על תמונות מערכת

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

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

יישומי חתימה (APK)

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

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

פרסום אפליקציות

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

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

תגובה לאירועים

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

• צור כתובת security@your-company.com או כתובת דומה ופרסם אותה.
• אם נודעת לבעיית אבטחה המשפיעה על מערכת ההפעלה אנדרואיד או מכשירי Android מיצרני מכשירים מרובים, עליך לפנות לצוות האבטחה של Android על ידי הגשת דוח באג באבטחה .

הטמעת המוצר

השתמש בשיטות המומלצות הבאות בעת יישום מוצר.

בידוד תהליכי שורש

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

• התקנים צריכים להפעיל את הקוד המינימלי הדרוש בתור שורש. היכן שניתן, השתמש בתהליך אנדרואיד רגיל ולא בתהליך שורש. ל-ICS Galaxy Nexus יש רק שישה תהליכי שורש: vold, inetd, zygote, tf_daemon, ueventd ו-init. אם תהליך חייב לפעול כ-root במכשיר, תיעד את התהליך בבקשת תכונה AOSP כדי שניתן יהיה לבדוק אותו באופן ציבורי.
• במידת האפשר, יש לבודד את קוד השורש מנתונים לא מהימנים ולגשת אליהם באמצעות IPC. לדוגמה, צמצם את פונקציונליות השורש לשירות קטן הנגיש באמצעות Binder וחשוף את השירות עם הרשאת חתימה לאפליקציה עם הרשאות נמוכות או ללא הרשאות לטפל בתעבורת רשת.
• אסור להאזין לתהליכי שורש בשקע רשת.
• אסור לתהליכי שורש לספק זמן ריצה למטרות כלליות עבור יישומים (לדוגמה, Java VM).

בידוד אפליקציות מערכת

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

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

תהליכי בידוד

ה-Android Application Sandbox מספק לאפליקציות ציפייה לבידוד מתהליכים אחרים במערכת, לרבות תהליכי שורש ו-debuggers. אלא אם איתור באגים מופעל במיוחד על ידי האפליקציה והמשתמש, אף אפליקציה לא אמורה להפר את הציפייה הזו. שיטות עבודה מומלצות:

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

אבטחת קבצי SUID

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

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

מאמת CTS כולל מבחן מידע המפרט קבצי SUID; חלק מקבצי setuid אינם מותרים לפי בדיקות CTS.

אבטחת שקעי האזנה

בדיקות CTS נכשלות כאשר מכשיר מאזין בכל יציאה, בכל ממשק. במקרה של כשל, אנדרואיד מאמת שהשיטות המומלצות הבאות נמצאות בשימוש:

• לא אמורות להיות יציאות האזנה במכשיר.
• יציאות האזנה חייבות להיות מושבתות ללא OTA. זה יכול להיות שינוי תצורה של שרת או מכשיר משתמש.
• אסור להאזין לתהליכי שורש בשום יציאה.
• אסור להאזין לתהליכים שבבעלות ה-UID של המערכת בשום יציאה.
• עבור IPC מקומי באמצעות שקעים, אפליקציות חייבות להשתמש ב-UNIX Domain Socket עם גישה מוגבלת לקבוצה. צור מתאר קובץ עבור ה-IPC והפוך אותו ל-+RW עבור קבוצת UNIX ספציפית. כל יישומי לקוח חייבים להיות בתוך קבוצת UNIX זו.
• מכשירים מסוימים עם מספר מעבדים (למשל רדיו/מודם נפרדים ממעבד היישומים) משתמשים בשקעי רשת כדי לתקשר בין מעבדים. במקרים כאלה, שקע הרשת המשמש לתקשורת בין-מעבדים חייב להשתמש בממשק רשת מבודד כדי למנוע גישה של יישומים לא מורשים במכשיר (כלומר, להשתמש iptables כדי למנוע גישה של יישומים אחרים במכשיר).
• דמונים שמטפלים ביציאות האזנה חייבים להיות חזקים מפני נתונים שגויים. Google עשויה לבצע בדיקות fuzz נגד הנמל באמצעות לקוח לא מורשה, ובמידת האפשר, לקוח מורשה. כל קריסות יתוייקו בתור באגים בדרגת חומרה מתאימה.

רישום נתונים

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

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

CTS כולל בדיקות הבודקות נוכחות של מידע שעלול להיות רגיש ביומני המערכת.

הגבלת גישה לספרייה

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

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

אבטחת קבצי תצורה

מנהלי התקנים ושירותים רבים מסתמכים על קבצי תצורה ונתונים המאוחסנים בספריות כגון /system/etc ו- /data . אם קבצים אלה מעובדים בתהליך מיוחס והם ניתנים לכתיבה בעולם, ייתכן שאפליקציה תנצל פגיעות בתהליך על ידי יצירת תוכן זדוני בקובץ הניתן לכתיבה בעולם. שיטות עבודה מומלצות:

• קבצי תצורה המשמשים תהליכים מורשים אינם צריכים להיות קריאים בעולם.
• אסור שקובצי תצורה המשמשים תהליכים מורשים יהיו ניתנים לכתיבה עולמית.

אחסון ספריות קוד מקוריות

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

הגבלת גישה למנהלי התקנים

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

השבתת ADB

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

• ADB חייב להיות מושבת כברירת מחדל.
• ADB חייב לדרוש מהמשתמש להפעיל אותו לפני קבלת חיבורים.

ביטול נעילה של עומסי אתחול

מכשירי אנדרואיד רבים תומכים בביטול נעילה, מה שמאפשר לבעל המכשיר לשנות את מחיצת המערכת ו/או להתקין מערכת הפעלה מותאמת אישית. מקרי שימוש נפוצים כוללים התקנת ROM של צד שלישי וביצוע פיתוח ברמת המערכות במכשיר. לדוגמה, בעל מכשיר Google Nexus יכול להפעיל את fastboot oem unlock כדי להתחיל בתהליך ביטול הנעילה, המציג את ההודעה הבאה למשתמש:

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

• כאשר פקודת ביטול הנעילה מאושרת על ידי המשתמש, על המכשיר להתחיל מחיקת נתונים מיידית. אסור להגדיר את הדגל לא unlocked עד לאחר השלמת המחיקה המאובטחת.
• אם לא ניתן להשלים מחיקה מאובטחת, המכשיר חייב להישאר במצב נעול.
• אם נתמך על ידי התקן הבלוק הבסיסי, יש להשתמש ioctl(BLKSECDISCARD) או שווה ערך. עבור התקני eMMC, המשמעות היא שימוש בפקודה Secure Erase או Secure Trim. עבור eMMC 4.5 ואילך, משמעות הדבר היא שימוש במחיקה או חיתוך רגילה ולאחריה פעולת חיטוי.
• אם BLKSECDISCARD אינו נתמך על ידי התקן הבלוק הבסיסי, יש להשתמש ioctl(BLKDISCARD) במקום זאת. בהתקני eMMC, זוהי פעולת Trim רגילה.
• אם BLKDISCARD אינו נתמך, החלפת התקני החסימה עם כל האפסים מקובלת.
• למשתמש קצה חייבת להיות אפשרות לדרוש כי נתוני המשתמש יימחקו לפני הבהוב של מחיצה. לדוגמה, במכשירי Nexus, זה נעשה באמצעות פקודת fastboot oem lock .
• מכשיר יכול להקליט, באמצעות זרמים או מנגנון דומה, אם מכשיר נעול ו/או ננעל מחדש.

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

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