הטמעת אבטחה

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

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

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

תהליך הפיתוח

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

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

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

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

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

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

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

תמונות של מערכות שלטים

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

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

חתימה על אפליקציות (חבילות APK)

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

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

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

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

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

תגובה לתקריות

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

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

הטמעת מוצרים

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

בידוד תהליכים ברמה הבסיסית (root)

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

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

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

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

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

בידוד תהליכים

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

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

אבטחה של קבצים עם הרשאת SUID

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

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

כלי האימות של CTS כולל בדיקה מידע שמציגה רשימה של קובצי SUID. חלק מקובצי setuid אסורים לפי בדיקות CTS.

שקעי הקשבה מאובטחים

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

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

נתוני יומן

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

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

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

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

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

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

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

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

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

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

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

הגבלת הגישה של מנהל ההתקן של המכשיר

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

השבתת ADB

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

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

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

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

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

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

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

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