تم إنشاء Security Test Suite Trade Union (sts-tradefed) على رأس مجموعة اختبار Android Trade Union لاختبار جميع أجهزة Android لاختبارات تصحيح الأمان التي لا تندرج ضمن مجموعة اختبار التوافق. هذه الاختبارات مخصصة حصريًا للإصلاحات المرتبطة (أو التي سيتم ربطها) بالثغرات الأمنية والتعرضات الشائعة (CVE).
يسمح SDK بتطوير اختبارات STS خارج شجرة مصدر Android باستخدام Android Studio أو Android SDK القياسي. ويتضمن جميع الأدوات المساعدة اللازمة لإنشاء اختبار STS وتشغيله.
المتطلبات الأساسية
- كمبيوتر لينكس 64 بت.
- Android Studio (يمكن أيضًا تثبيته من مدير حزم التوزيعة الخاصة بك.
- يجب تثبيت أدوات نظام التشغيل Android (
adb
وfastboot
) وأن تكون في$PATH
(أي يجب أن تكون قادرًا على تشغيلadb
من سطر الأوامر). أسهل طريقة لتثبيت أدوات النظام الأساسي هي عبر مدير الحزم الخاص بالتوزيعة.- إذا كنت تستخدم مدير SDK الخاص بـ Android Studio بدلاً من أدوات النظام الأساسي المستقلة، فتذكر إضافة دليل
platform-tools
الخاص بـ SDK إلى $PATH الخاص بك.
- إذا كنت تستخدم مدير SDK الخاص بـ Android Studio بدلاً من أدوات النظام الأساسي المستقلة، فتذكر إضافة دليل
- aapt ، والذي يمكن تثبيته أيضًا عبر مدير الحزم الخاص بالتوزيعة.
ابدأ باستخدام Android Studio
بعد استخراج الأرشيف، افتح الدليل في Android Studio كمشروع موجود. قم بتشغيل هدف البناء assembleSTSARM
أو assembleSTSx86
لإنشاء اختبار الهيكل العظمي، اعتمادًا على بنية جهاز Android المستهدف. قم بتشغيل هدف بناء runSTS
لتشغيل اختبار الهيكل العظمي على الجهاز المتصل (يجب أن يكون ADB معتمدًا).
ابدأ باستخدام Gradle
بعد استخراج الأرشيف، قم بتعيين خاصية sdk.dir
في ملف local.properties
في جذر مشروع Gradle، ثم قم بتشغيل مهمة assembleSTSARM
Gradle لإنشاء اختبار الهيكل العظمي. بعد الانتهاء من الإنشاء، يمكن إجراء الاختبار عن طريق التنقل ( cd
) إلى build/android-sts/tools
وتنفيذ غلاف 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:
- اختبار Tradefed من جانب المضيف الذي يتفاعل مع الجهاز من خلال adb، في الدليل الفرعي
sts-test
. - هجوم أصلي اختياري لإثبات المفهوم يتم دفعه إلى الجهاز من خلال
adb push
ويتم تنفيذه بواسطة اختبار الجانب المضيف في الدليلnative-poc
. - تطبيق اختياري أو APK خدمة يتم تثبيته على الجهاز من خلال
adb install
ويتم تشغيله أيضًا بواسطة اختبار الجانب المضيف. يمكن أن يحتوي التطبيق أو الخدمة أيضًا على مجموعته الخاصة من تأكيدات JUnit التي يتم الإبلاغ عنها إلى المشغل من جانب المضيف. هذا موجود في الدليل الفرعيtest-app
.
عادةً ما يتبع تدفق اختبار STS النموذجي أحد النمطين:
إثبات المفهوم الأصلي:
- يقوم اختبار الجانب المضيف بدفع وتشغيل ملف أصلي قابل للتنفيذ على الجهاز.
- يتعطل البرنامج الأصلي أو يُرجع رمز خروج محددًا.
- يقوم الاختبار من جانب المضيف بالتحقق من الأعطال، أو النظر في التتبع الخلفي لـ logcat، أو البحث عن رمز الخروج المحدد لتحديد ما إذا كان الهجوم ناجحًا.
تطبيق الاختبار الآلي:
- يقوم اختبار الجانب المضيف بدفع APK الذي يتكون من تطبيق أو خدمة إلى الجهاز.
- يبدأ اختبار جانب المضيف اختبارات JUnit على جانب الجهاز المرفقة مع APK من خلال
runDeviceTest()
- تختبر JUnit الموجودة على جانب الجهاز الأزرار وتشاهد التطبيق باستخدام UIAutomator، أو تصل بطريقة أخرى إلى نظام Android بطرق تكشف عن الثغرات الأمنية.
- يتم إرجاع نجاح أو فشل اختبارات JUnit من جانب الجهاز إلى اختبار جانب المضيف، والذي يمكن استخدامه لتحديد ما إذا كان الاختبار قد نجح أم لا.
من الممكن أيضًا الجمع بين النموذجين (على سبيل المثال، تشغيل برنامج أصلي بالتزامن مع اختبارات جانب الجهاز). تتوفر أيضًا بعض أطر عمل الأجهزة الأخرى، مثل frida-inject
. للحصول على التفاصيل، راجع المستندات المرجعية لمجموعة اختبار الأمان والمستندات المرجعية لـ Tradefed .
لا يحتاج هجوم إثبات المفهوم الخاص بي إلى تطبيق اختباري و/أو برنامج أصلي قابل للتنفيذ
لن تحتاج معظم الاختبارات إلى تطبيق على جانب الجهاز وبرنامج أصلي قابل للتنفيذ.
إذا كان اختبارك لا يتضمن استخدام تطبيق/خدمة على الجهاز، فما عليك سوى حذف الدليل الفرعي test-app
. وبالمثل، إذا كان الاختبار الخاص بك لا يستخدم ملفًا أصليًا قابلاً للتنفيذ، فاحذف الدليل native-poc
ثم قم بمزامنة المشروع بواسطة Gradle. تم إعداد المشروع لتخطي بناء تلك الوحدات تلقائيًا في حالة عدم وجودها.
يشتمل هجوم إثبات المفهوم الخاص بي على تطبيق/خدمة ثانية
أولاً، أضف وحدة نمطية جديدة إلى مشروعك لتطبيقك/خدمتك الثانية واكتبها كما تفعل مع أي ملف APK آخر.
بعد ذلك، قم بتحرير build.gradle
في جذر هذا الدليل وأضف الوحدة النمطية الخاصة بك باتباع الإرشادات الموجودة في copyArtifacts
و assembleStsARM
و assembleStsx86
. سيضمن ذلك نسخ ملف APK المترجم إلى دليل إخراج STS وتمكين تثبيت/استدعاء التطبيق الجديد من الاختبار.
وأخيرًا، يقوم Gradle بمزامنة المشروع.
تقديم اختبار STS
قم بتشغيل مهمة zipForSubmission
(إما باستخدام Android Studio أو باستخدام Gradle في سطر الأوامر). يجب إنشاء ملف جديد، codesubmission.zip
، في دليل build
في جذر المشروع. قم بتحميل هذا الملف مع إرسالك إلى برنامج مكافآت Android Vulnerability Reward.