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

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

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

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

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

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

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

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

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

    1. يقوم اختبار الجانب المضيف بدفع وتشغيل ملف أصلي قابل للتنفيذ على الجهاز.
    2. يتعطل البرنامج الأصلي أو يُرجع رمز خروج محددًا.
    3. يقوم الاختبار من جانب المضيف بالتحقق من الأعطال، أو النظر في التتبع الخلفي لـ logcat، أو البحث عن رمز الخروج المحدد لتحديد ما إذا كان الهجوم ناجحًا.
  • تطبيق الاختبار الآلي:

    1. يقوم اختبار الجانب المضيف بدفع APK الذي يتكون من تطبيق أو خدمة إلى الجهاز.
    2. يبدأ اختبار جانب المضيف اختبارات JUnit على جانب الجهاز المرفقة مع APK من خلال runDeviceTest()
    3. تختبر JUnit الموجودة على جانب الجهاز الأزرار وتشاهد التطبيق باستخدام UIAutomator، أو تصل بطريقة أخرى إلى نظام Android بطرق تكشف عن الثغرات الأمنية.
    4. يتم إرجاع نجاح أو فشل اختبارات 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.