Android Security AutoRepro

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

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

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

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

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

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

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

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

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

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

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

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

ה-PoC האיכותי צריך לעשות יותר מאשר להפעיל באג. הוא צריך לספק הוכחה שניתנת לאימות לכך שחצו גבול אבטחה. כדי להשיג את זה, ה-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 שלא נדרשות.

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

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

שליחת בדיקת AutoRepro

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

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

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