Android Security AutoRepro

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

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

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

הורדת דוגמה ל-AutoRepro

דרישות מוקדמות

ההוראות הן למחשב Linux עם 64 סיביות.

  • Android Studio Ladybug ואילך – אפשר להתקין גם באמצעות מנהל החבילות של הפצת Linux.
  • Android SDK platform tools (adb, fastboot) – צריך להתקין אותם ולהיות ב-$PATH (כלומר, צריך להיות אפשר להריץ את adb משורת הפקודה). הדרך הקלה ביותר להתקין את כלי הפלטפורמה היא באמצעות מנהל החבילות של הפצה.
    • אם משתמשים במנהל ה-SDK של Android Studio במקום בכלים עצמאיים לפלטפורמה, חשוב לזכור להוסיף את הספרייה platform-tools של ה-SDK ל-$PATH לפיתוח בשורת הפקודה.
  • AAPT2. - אפשר להתקין אותו גם באמצעות מנהל החבילות של הפצת Linux.
  • Java JDK 21 ואילך – תואם ל-Android SDK ול-Gradle.

תחילת השימוש ב-Android Studio

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

משימות Gradle:

  • assembleSubmissionSources – איסוף קובצי המקור לקובץ ה-zip לשליחה.
  • assembleSubmissionZip – יצירת קובץ ה-zip לשליחה להעלאה.
  • copyInvocationResultsToSubmission – מעתיקים את התוצאות מהפעלות קודמות של Tradefed לספריית המקורות של שליחת AutoRepro כדי לעזור בתהליך הבדיקה. חשוב לדעת שהקובץ הזה מכיל יומנים גם מהמארח וגם מהמכשיר. כדאי לבדוק את התוכן לפני או אחרי ההרצה.

הגדרות ההרצה של AutoRepro ב-Android Studio:

  • autorepro_nonroot_arm64
  • autorepro_nonroot_x86_64
  • autorepro_root_arm64
  • autorepro_root_x86_64

הגדרות מרכז האפליקציות הן בפורמט autorepro_{device_root}_{device_arch}. באופן כללי, עדיף להשתמש בחשבון ללא הרשאת root כי נקודות החולשה שדורשות הרשאת root חמורות פחות. עם זאת, מותר להשתמש בחשבון root כדי לבצע הגדרה או ניקוי, כל עוד הדבר מתועד בבירור ומקובל בדרך כלל כמצב תקין שאינו root. לדוגמה, מותר להשתמש ב-root כדי לשלוח הודעות טקסט מזויפות למכשיר כדי להימנע מהצורך במכשיר נוסף ובכמה כרטיסי SIM.

הפקודות האלה יפעילו את Tradefed לבדיקה. המערכת של Tradefed ממתינה למכשיר תקין שיחובר, לכן חשוב לוודא שמכשיר מחובר והרשאה לניפוי באגים ב-ADB.

כתיבת בדיקת AutoRepro

בדיקת AutoRepro מורכבת משלושה חלקים ושלושה פלאגינים תואמים של Gradle:

  1. פלאגין Gradle id("com.android.security.autorepro.javahosttest") הבדיקה היחידה של Tradefed בצד המארח, שמקיימת אינטראקציה עם המכשיר דרך ADB. בדוגמה הוא מופיע בספרייה submission/hostTest/.
  2. הפלאגין של Gradle id("com.android.security.autorepro.apptest") אפליקציה או קובץ APK של שירות שמותקנים במכשיר דרך adb install ומופעל על ידי הבדיקה בצד המארח. האפליקציה או השירות יכולים גם להכיל קבוצה משלהם של טענות נכוֹנוּת (assertions) של JUnit, שמדווחות למפעיל בצד המארח. בדוגמה הוא מופיע ב-submission/appTest/ ובספרייה.
  3. הפלאגין של Gradle id("com.android.security.autorepro.ndktest") התקפת הוכחת קונספט אופציונלית שמבוססת על NDK, שמועברת למכשיר דרך adb push ומבוצעת על ידי הבדיקה בצד המארח. בדוגמה הזו הוא מופיע בספרייה submission/ndkTest/.

תהליך בדיקה אופייני של AutoRepro בדרך כלל עוקב אחרי אחד משני דפוסים:

  • אפליקציית בדיקה עם אינסטרומנטציה:

    1. הבדיקה בצד המארח דוחפת למכשיר קובץ APK שמכיל אפליקציה או שירות עם כלי למדידת ביצועים.
    2. הבדיקה בצד המארח מפעילה את בדיקות JUnit בצד המכשיר שמצורפות לחבילת ה-APK דרך runDeviceTest().
    3. בדיקות JUnit בצד המכשיר מקישות על לחצנים ומתבוננות באפליקציה באמצעות UIAutomator, או ניגשות לממשקי ה-API של Android בדרכים אחרות שמגלות נקודות חולשה באבטחה.
    4. התוצאה של בדיקות JUnit בצד המכשיר (הצלחה או כישלון) מוחזרת לבדיקה בצד המארח, וניתן להשתמש בה כדי לקבוע אם הבדיקה עברה או לא. הודעת הכשל צריכה להכיל מידע מפורט על הסיבה לכך שהטענה נכשלה, וכן אובייקטים, ערכים, חריגות, מעקב סטאק או ארטיפקטים ספציפיים אחרים כהוכחה לנקודת החולשה.

  • הוכחת היתכנות של NDK:

    1. הבדיקה בצד המארח דוחפת קובץ הפעלה של Linux ומפעילה אותו במכשיר.
    2. התוכנה המקורית קורסת או מחזירה קוד יציאה ספציפי.
    3. הבדיקה בצד המארח מחפשת קריסות, בודקת את ה-backtrace של logcat או מחפשת את קוד היציאה הספציפי כדי לקבוע אם ההתקפה הצליחה. הודעת הכשל צריכה לכלול מידע מפורט על הסיבה לכישלון טענת הנכוֹנוּת, וכן כל מבנה נתונים ספציפי, ערך, נתיב סטאק או ארטיפקט אחר כהוכחה לנקודת החולשה.

אפשר גם לשלב בין שני התבניות (לדוגמה, הפעלת תוכנית מקומית בשילוב עם בדיקות בצד המכשיר). יש גם מסגרות אחרות למדידה, כמו frida-inject. פרטים נוספים זמינים במסמכי העזרה של Security Test Suite ובמסמכי העזרה של Tradefed.

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

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

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

ההתקפה שלי להוכחת היתכנות כוללת אפליקציה/שירות שני

אפשר להוסיף כמה פרויקטים משניים של Gradle עם פלאגינים של AutoRepro שרוצים.

שליחת הבדיקה של AutoRepro

כדי לכלול את תוצאות הבדיקות מהמכשיר כחלק מההגשה:

  • אפשר גם להריץ את המשימה clean של Gradle כדי למחוק את כל הפעלות הבדיקה הישנות.
  • מריצים את הגדרת ההרצה המתאימה של AutoRepro כדי להפעיל את Tradefed לבדיקה ולאסוף יומנים ותוצאות.
  • מריצים את המשימה copyInvocationResultsToSubmission כדי להעתיק את היומנים והתוצאות לתיקיית מקורות השליחה.

מריצים את הפקודה assembleSubmissionZip כדי ליצור את הקובץ submission/build/autorepro-submission.zip. מעלים את הקובץ הזה יחד עם הדיווח לתוכנית התמריצים לזיהוי נקודות חולשה ב-Android. חשוב לוודא שהקובץ המצורף תואם לדפוס *autorepro-submission*.zip ושעליו להעלות אותו עם הדוח הראשוני. אם תשלחו את הדוחות באיחור, יכול להיות שלא נוכל לבדוק אותם כראוי.