مجموعة أدوات تطوير حزمة اختبار أمان Android (STS SDK)

تم إنشاء Security Test Suite Trade Federation (sts-tradefed) على رأس اختبار Android Trade Federation لاختبار جميع أجهزة Android لاختبارات تصحيح الأمان التي لا تندرج في مجموعة اختبار التوافق. هذه الاختبارات مخصصة حصريًا للإصلاحات المرتبطة (أو التي ستترافق) مع نقاط الضعف والتعرض الشائعة (CVE).

يسمح SDK بتطوير اختبارات STS خارج شجرة مصدر Android باستخدام Android Studio أو Android SDK القياسي. يتضمن جميع الأدوات المساعدة اللازمة لإنشاء اختبار STS وتشغيله.

احصل على أحدث STS SDK

المتطلبات الأساسية

  • كمبيوتر Linux 64 بت.
  • Android Studio (يمكن تثبيته أيضًا من مدير الحزم في التوزيعة الخاصة بك.
  • يجب تثبيت أدوات نظام Android ( adb ، fastboot ) وأن تكون في $PATH (أي يجب أن تكون قادرًا على تشغيل adb من سطر الأوامر). أسهل طريقة لتثبيت أدوات النظام الأساسي هي عبر مدير الحزم في التوزيعة الخاصة بك.
    • إذا كنت تستخدم مدير SDK في Android Studio بدلاً من أدوات النظام الأساسي المستقلة ، فتذكر إضافة دليل platform-tools لـ SDK إلى $ PATH.
  • aapt ، والذي يمكن تثبيته أيضًا عبر مدير الحزم في التوزيعة.

ابدأ باستخدام Android Studio

بعد استخراج الأرشيف ، افتح الدليل في Android Studio كمشروع موجود. قم بتشغيل assembleSTSARM أو تجميع هدف بناء assembleSTSx86 لبناء اختبار الهيكل العظمي ، اعتمادًا على بنية جهاز Android المستهدف. قم بتشغيل runSTS build target لتشغيل اختبار الهيكل العظمي على الجهاز المتصل (يجب أن يكون 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:

  1. اختبار Tradefed من جانب المضيف يتفاعل مع الجهاز من خلال adb ، في الدليل الفرعي sts-test .
  2. هجوم اختياري محلي لإثبات المفهوم يتم دفعه إلى الجهاز من خلال adb push ويتم تنفيذه بواسطة اختبار جانب المضيف في الدليل native-poc .
  3. تطبيق اختياري أو حزمة APK للخدمة يتم تثبيتها على الجهاز من خلال adb install وتم إطلاقها أيضًا من خلال اختبار جانب المضيف. يمكن أن يحتوي التطبيق أو الخدمة أيضًا على مجموعته الخاصة من تأكيدات JUnit التي يتم الإبلاغ عنها إلى عداء جانب المضيف. يوجد هذا في الدليل الفرعي test-app .

عادةً ما يتبع تدفق اختبار STS النموذجي أحد نمطين:

  • إثبات المفهوم الأصلي:

    1. يدفع اختبار جانب المضيف ويطلق ملفًا قابلاً للتنفيذ أصليًا على الجهاز.
    2. يتعطل البرنامج الأصلي أو يقوم بإرجاع رمز إنهاء محدد.
    3. يتحقق الاختبار من جانب المضيف من الأعطال ، أو يفحص التتبع الخلفي لوجكات ، أو يبحث عن رمز الخروج المحدد لتحديد ما إذا كان الهجوم قد نجح أم لا.

  • تطبيق الاختبار الآلي:

    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 Vulnerability Reward.