איחוד שירותי בדיקת האבטחה של (sts-tradefed) בנוי על איחוד שירותי הסחר של Android מסגרת בדיקה לבדיקת האבטחה בכל מכשירי Android בדיקות תיקון שלא נכללות בחבילה לבדיקת התאימות. הבדיקות האלה אך ורק לתיקונים שמשויכים (או שישויכו) עם נקודות חולשה נפוצות וחשיפות נפוצות (CVE).
ה-SDK מאפשר לפתח בדיקות STS מחוץ לעץ המקור של Android באמצעות Android Studio או באמצעות ה-SDK הרגיל של Android. הוא כולל את כל כלי השירות שנדרשים ליצירה ולהרצה של בדיקת STS.
דרישות מוקדמות
- מחשב Linux בגרסת 64 ביט.
- את Android Studio (אפשר גם להתקין אותו ממנהל החבילות של ההפצה.
- כלים בפלטפורמת Android
(
adb
,fastboot
) צריך להתקין את האפליקציה ולהיות ב-$PATH
(כלומר, צריך להיות מסוגל להריץ אתadb
משורת הפקודה). הדרך הקלה ביותר להתקין את כלי הפלטפורמה דרך מנהל החבילות של ההפצה.- אם אתם משתמשים במנהל ה-SDK של Android Studio במקום בפלטפורמה נפרדת
כלים, חשוב לזכור להוסיף את הספרייה
platform-tools
של ה-SDK ל-$PATH.
- אם אתם משתמשים במנהל ה-SDK של Android Studio במקום בפלטפורמה נפרדת
כלים, חשוב לזכור להוסיף את הספרייה
- 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 כוללת שלושה חלקים:
- בדיקת סוחר בצד המארח, שמבצעת אינטראקציה עם המכשיר באמצעות adb,
ספריית משנה אחת (
sts-test
). - מתקפה מובנית של הוכחת היתכנות, אשר מועברת אל
של המכשיר דרך
adb push
ובוצעה על ידי הבדיקה בצד המארח ספריית משנהnative-poc
. - חבילת APK אופציונלית של אפליקציה או שירות שמותקנת במכשיר באמצעות
adb install
וגם הופעל על ידי הבדיקה בצד המארח. האפליקציה או השירות יכול גם להכיל קבוצה של טענות נכוֹנוּת (assertion) משלו של JUnit שמדווחות הפעלה בצד המארח. הפריט נמצא בספריית המשנהtest-app
.
תהליך אופייני של בדיקת STS מתבצע בדרך כלל לפי אחד משני הדפוסים הבאים:
הוכחת היתכנות מקורית:
- הבדיקה בצד המארח דוחפת ומפעילים קובץ הפעלה מקורי במכשיר.
- התוכנה המקורית קורסת או מחזירה קוד יציאה ספציפי.
- הבדיקה בצד המארח מחפשת קריסות, בוחנת את מעקב ה-Logcat. או מחפש את קוד היציאה הספציפי כדי לקבוע אם המתקפה הצליחה.
אפליקציית בדיקה אינסטרומנטלית:
- הבדיקה בצד המארח דוחפת חבילת APK שמכילה אפליקציה או שירות אל במכשיר.
- הבדיקה בצד המארח מתחילה את בדיקות ה-JUnit של הצד המכשיר בחבילה
עם APK עד
runDeviceTest()
- JUnit בצד המכשיר בודק לחצנים וצופה באפליקציה באמצעות UIAutomator, או ניגש בצורה אחרת למערכת Android בדרכים לחשוף נקודות חולשה באבטחה.
- ההצלחה או הכשל של בדיקות ה-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 לגבי פרצות אבטחה.