Android Security AutoRepro

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

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

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

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

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

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

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