ערכת פיתוח של Android Security Test Suite (STS SDK)

איחוד שירותי בדיקת האבטחה של (sts-tradefed) בנוי על איחוד שירותי הסחר של Android מסגרת בדיקה לבדיקת האבטחה בכל מכשירי Android בדיקות תיקון שלא נכללות בחבילה לבדיקת התאימות. הבדיקות האלה אך ורק לתיקונים שמשויכים (או שישויכו) עם נקודות חולשה נפוצות וחשיפות נפוצות (CVE).

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

קבלת STS SDK העדכני ביותר

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

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

הערה: אם צריך, אפשר לעיין במדריך בנושא CTS. עזרה בהגדרת ADB ו-AAPT.

זהירות: STS באופן רשמי תומך רק במכונות Linux של 64 ביט. בזמן שהבדיקות נכתבו עם STS SDK עשוי להיפתח באמצעות Android Studio ב-Windows או MacOS, להריץ בפלטפורמות האלה לא קריטי ומחוץ להיקף המסמך הזה.

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

לאחר חילוץ הארכיון, פותחים את הספרייה ב-Android Studio בתור פרויקט קיים. מריצים את יעד ה-build assembleSTSARM או assembleSTSx86 כדי את בדיקת השלד, בהתאם לארכיטקטורה של מערכת ההפעלה Android במכשיר. מריצים את היעד של גרסת ה-build של runSTS כדי להריץ בדיקת שלד המכשיר (חייבת להיות הרשאה ל-ADB).

תחילת העבודה עם Gradle

לאחר חילוץ הארכיון, מגדירים את המאפיין sdk.dir בקובץ הקובץ local.properties ברמה הבסיסית (root) של הפרויקט Gradle, ואז מריצים את assembleSTSARM משימה של Gradle לבניית מבחן השלד. אחרי שה-build הסתיים, אפשר להריץ את הבדיקה על ידי ניווט (cd) אל build/android-sts/tools וביצוע ה-wrapper של sts-tradefed.

$ echo 'sdk.dir=/home/<myusername>/Android/Sdk' > local.properties
$ ./gradlew assembleSTSARM
$ cd build/android-sts/tools
$ ./sts-tradefed run sts-dynamic-develop -m hostsidetest

כתיבת בדיקת STS

הערה: בדיקת STS עוברת את הבדיקה כשהמכשיר לא פגיע, ונכשלה כאשר המכשיר חשוף, או במילים אחרות, כשהמתקפה פועלת. הבדיקה צריכה הפונקציה מחזירה ערך של ASSUMPTION_FAILURE (לדוגמה, באמצעות הפונקציה Assume במקום Assert) כשלא ניתן לקבוע אם המכשיר פגיע או לא.

בדיקת STS כוללת שלושה חלקים:

1. בדיקת סוחר בצד המארח, שמבצעת אינטראקציה עם המכשיר באמצעות adb, ספריית משנה אחת (sts-test).
2. מתקפה מובנית של הוכחת היתכנות, אשר מועברת אל של המכשיר דרך adb push ובוצעה על ידי הבדיקה בצד המארח ספריית משנה native-poc.
3. חבילת APK אופציונלית של אפליקציה או שירות שמותקנת במכשיר באמצעות adb install וגם הופעל על ידי הבדיקה בצד המארח. האפליקציה או השירות יכול גם להכיל קבוצה של טענות נכוֹנוּת (assertion) משלו של JUnit שמדווחות הפעלה בצד המארח. הפריט נמצא בספריית המשנה test-app.

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

• הוכחת היתכנות מקורית:

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

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

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

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

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

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

אם הבדיקה לא כוללת שימוש באפליקציה או בשירות ששמורים במכשיר, פשוט מוחקים ספריית המשנה test-app. באופן דומה, אם הבדיקה שלך לא משתמשת קובץ ההפעלה, מוחקים את ספריית המשנה native-poc ואז גוררים את הפרויקט באמצעות Gradle. הפרויקט מוגדר כך שידלג באופן אוטומטי על פיתוח המודולים האלה לא קיימים.

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

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

בשלב הבא, עורכים את build.gradle ברמה הבסיסית (root) של הספרייה הזו ומוסיפים את המודול לפי ההוראות ב-copyArtifacts, ב-assembleStsARM assembleStsx86 כך תבטיחו שה-APK שעבר הידור יועתק לפלט של STS ומאפשר להתקין/לקרוא לאפליקציה החדשה במהלך הבדיקה.

בסוף, Gradle מסנכרנים את הפרויקט.

שליחה של בדיקת ה-STS

מריצים את המשימה zipForSubmission (באמצעות Android Studio או באמצעות Gradle בשורת הפקודה). יש ליצור קובץ חדש, codesubmission.zip, ב-build בתיקיית השורש של הפרויקט. מעלים את הקובץ הזה יחד עם שליחה לתוכנית התגמול של Android לגבי פרצות אבטחה.