Android Security AutoRepro

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

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

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

דוגמה להורדה ישירה של דוח אוטומטי download

עיון בדוגמאות ובתבניות של AutoRepro open_in_new

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

ההוראות מתייחסות למחשב Linux בגרסת 64 סיביות.

• ‫Android Studio Ladybug או גרסה חדשה יותר – אפשר גם להתקין דרך מנהל החבילות של הפצת ה-Linux.
• Android SDK platform tools (adb, fastboot) – צריך להתקין אותם ולהוסיף אותם ל-$PATH (כלומר, צריכה להיות לך אפשרות להריץ את adb משורת הפקודה). הדרך הקלה ביותר להתקין את כלי הפלטפורמה היא באמצעות מנהל החבילות של הפצת הלינוקס.
  • אם משתמשים במנהל ה-SDK של Android Studio במקום בכלי פלטפורמה עצמאיים, צריך לזכור להוסיף את ספריית platform-tools של ה-SDK אל $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 מורשה.

שילוב עם סוכני תכנות

הדוגמה והתבניות מספקות AGENTS.md קובץ הקשר שתואם ל-Gemini ב-Android Studio, ל-Gemini CLI ולסוכני תכנות אחרים. יש בו תוכן עם דעות על מבנה ההגשה והוראות לשימוש ב-AutoRepro. אפשר להשתמש בזה כדי:

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

כתיבת בדיקת 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 plugin 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 בצד המכשיר (הצלחה או כישלון) מוחזרת לבדיקה בצד המארח, ובעזרתה אפשר לקבוע אם הבדיקה עברה או לא. הודעת הכשל צריכה לכלול מידע מפורט על הסיבה לכשל בטענת הנכוֹנוּת (assertion), ועל אובייקטים, ערכים, חריגים, עקבות מחסנית או פריטי מידע שנוצרו בתהליך פיתוח (Artifact) ספציפיים כהוכחה לנקודת חולשה.

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

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

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

מבנה של הוכחת היתכנות

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

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

לדוגמה:

@Test
public void testPoc() throws Exception {
    // 1. Setup: Prepare the device.
    setup();

    // 2. Prove the Boundary: Assert the resource is protected BEFORE the exploit.
    // This passes on all devices (safe or vulnerable) before the trigger runs.
    assertDeviceIsSecure();

    // 3. Trigger & Verify: Execute the exploit logic, then immediately repeat
    // the action from Step 2. On a vulnerable device, this action should now
    // succeed, causing assertDeviceIsSecure() to fail with an
    // AUTOREPRO_VULNERABILITY_PROVEN message.
    triggerExploit();
    assertDeviceIsSecure();
}

private void assertDeviceIsSecure() {
    try {
        String content = readProtectedFile();

        // Where possible, put the content in the assertion message.
        // Start the assertion message with "AUTOREPRO_VULNERABILITY_PROVEN:".
        Assert.fail("AUTOREPRO_VULNERABILITY_PROVEN: Successfully read protected file. Content: '" + content + "'");
    } catch (ThisVulnSpecificException e) {
        Log.i(TAG, "protected against reading protected file", e);
    }
}

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

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

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

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

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

שליחת בדיקת AutoRepro

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

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

מריצים את הפקודה assembleSubmissionZip כדי ליצור את הקובץ submission/build/autorepro-submission.zip. מעלים את הקובץ הזה יחד עם השליחה ל-Android Vulnerability Reward Program (תוכנית התגמולים על זיהוי נקודות חולשה באבטחה, VRP). מוודאים שהקובץ המצורף תואם לתבנית *autorepro-submission*.zip ושהוא מועלה עם הדוח הראשוני. העלאת חומרים באיחור תשפיע על היכולת שלנו לבדוק את הדיווח כמו שצריך.