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

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

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

איך מקבלים את גרסת ה-SDK העדכנית של STS

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

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

תחילת השימוש ב-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 כוללת שלושה חלקים:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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