تم إنشاء Security Test Suite Trade Federation (sts-tradefed) استنادًا إلى اختبارات Android Trade Federation لاختبار جميع أجهزة Android من أجل اختبارات معالجة الأمن التي لا تندرج ضمن مجموعة أدوات اختبار التوافق. يقتصر استخدام هذه الاختبارات على الإصلاحات المرتبطة (أو التي سيتم ربطها) بالثغرات والمخاطر الأمنية الشائعة (CVE).
تسمح حزمة SDK بتطوير اختبارات STS خارج شجرة مصدر Android باستخدام "استوديو Android" أو حزمة تطوير البرامج (SDK) العادية لنظام التشغيل Android. يشمل ذلك جميع الأدوات المساعدة اللازمة لإنشاء اختبار STS وتنفيذه.
الحصول على أحدث إصدار من حزمة تطوير البرامج (SDK) لنظام STS
المتطلّبات الأساسية
- كمبيوتر يعمل بنظام التشغيل Linux 64 بت.
- Android Studio (يمكن أيضًا تثبيته من مدير الحِزم في التوزيع)
- يجب تثبيت أدوات نظام Android الأساسي
(
adb
وfastboot
) ويجب أن تكون متوفّرة في$PATH
(أي يجب أن يكون بإمكانك تشغيلadb
من سطر الأوامر). إنّ أسهل طريقة ل تثبيت أدوات المنصة هي من خلال مدير الحِزم في التوزيعة.- في حال استخدام أداة إدارة حِزم تطوير البرامج (SDK) في Android Studio بدلاً من منصّة مستقلة
أدوات، تذكَّر إضافة دليل
platform-tools
لحزمة SDK إلى $PATH.
- في حال استخدام أداة إدارة حِزم تطوير البرامج (SDK) في Android Studio بدلاً من منصّة مستقلة
أدوات، تذكَّر إضافة دليل
- aapt، يمكن أيضًا تثبيته من خلال مدير الحِزم في التوزيع
بدء استخدام "استوديو Android"
بعد استخراج الأرشيف، افتح الدليل في "استوديو Android" كأحد
المشاريع الحالية. يمكنك تشغيل هدف الإنشاء 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" أو باستخدام Gradle في سطر الأوامر). ويجب إنشاء ملف جديد، codesubmission.zip
، في دليل build
في جذر المشروع. حمِّل هذا الملف مع العينة التي تم إرسالها إلى "برنامج المكافآت للمبلّغين عن الثغرات الأمنية في Android".