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 במקום בכלי פלטפורמה עצמאיים, צריך לזכור להוסיף את ספריית ה-SDK של platform-tools אל $PATH כדי לפתח באמצעות שורת הפקודה.
  • ‫AAPT2. – אפשר גם להתקין באמצעות מנהל החבילות של ההפצה.
  • ‫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}. בדרך כלל עדיף להשתמש ב-nonroot כי פגיעויות שמחייבות 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 plugin id("com.android.security.autorepro.apptest") קובץ APK של אפליקציה או שירות שמותקן במכשיר באמצעות adb install ומופעל על ידי הבדיקה בצד המארח. האפליקציה או השירות יכולים גם להכיל קבוצה משלהם של הצהרות JUnit, שמדווחות ל-runner בצד המארח. בדוגמה נעשה שימוש ב-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, או ניגשות ל-Android APIs בדרכים אחרות שחושפות נקודות חולשה באבטחה.
    4. התוצאה של בדיקות JUnit בצד המכשיר (הצלחה או כישלון) מוחזרת לבדיקה בצד המארח, ובעזרתה אפשר לקבוע אם הבדיקה עברה או לא. הודעת הכשל צריכה לכלול מידע מפורט על הסיבה לכשל בהצהרה, ועל אובייקטים, ערכים, חריגים, עקבות מחסנית או פריטים אחרים ספציפיים כהוכחה לפגיעות.

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

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

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

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

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

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

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

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

שליחת בדיקת AutoRepro

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

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

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