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

تم إنشاء 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.
  • aapt، يمكن أيضًا تثبيته من خلال مدير الحِزم في التوزيع

بدء استخدام "استوديو Android"

بعد استخراج الأرشيف، افتح الدليل في "استوديو Android" كمشروع حالي. يمكنك تشغيل هدف الإصدار assembleSTSARM أو assembleSTSx86 لاختبار الهيكل العظمي، استنادًا إلى بنية جهاز Android المستهدف. شغِّل هدف الإصدار runSTS لإجراء اختبار الهيكل العظمي على الجهاز المتصل (يجب أن يكون Ads Data Hub مسموحًا به).

بدء استخدام 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 على الجهاز إلى النقر على الأزرار ومشاهدة التطبيق باستخدام IDE UIAutomator، أو الوصول إلى نظام Android بطرق تؤدي إلى كشف نقاط الضعف في الأمان.
    4. يتم عرض نجاح اختبارات JUnit على الجهاز أو تعذّرها في الاختبار على المضيف، والذي يمكن استخدامه لتحديد ما إذا كان الاختبار قد اجتاز أم لا.

ويمكن أيضًا الجمع بين النمطين (على سبيل المثال، تشغيل برنامج محلي بالتزامن مع الاختبارات من جهة الجهاز). وتتوفّر أيضًا بعض أُطر عمل الأدوات الأخرى، مثل frida-inject. لمعرفة التفاصيل، يُرجى الاطّلاع على المستندات المرجعية لـ "حزمة اختبار الأمان" والمستندات المرجعية التجريبية.

لا يحتاج هجوم إثبات مفهومي إلى تطبيق تجريبي أو تطبيق محلي قابل للتنفيذ.

لن تحتاج معظم الاختبارات إلى تطبيق من جهة الجهاز وتطبيق أصلي قابل للتنفيذ.

إذا لم يتضمّن الاختبار استخدام تطبيق أو خدمة على الجهاز، ما عليك سوى حذف الدليل الفرعي "test-app". وبالمثل، إذا كان الاختبار لا يستخدم ملفًا أصليًا قابلاً للتنفيذ، احذف الدليل الفرعي native-poc ثم أجرِ مزامنة للمشروع. تم إعداد المشروع لتخطي إنشاء تلك الوحدات تلقائيًا عندما لا توجد.

تشمل هجمات إثبات المفهوم التي أُجريتها تطبيقًا أو خدمة ثانية

أولاً، أضِف وحدة جديدة إلى مشروعك للتطبيق/الخدمة الثانية واكتب الملف كما تفعل مع أي حزمة APK أخرى.

بعد ذلك، عدِّل build.gradle في جذر هذا الدليل وأضِف وحدتك باتّباع التعليمات الواردة في copyArtifacts وassembleStsARM و assembleStsx86. سيضمن ذلك نسخ حزمة APK المجمّعة إلى ملف مخرجات أداة STS وتفعيل تثبيت/استدعاء التطبيق الجديد من الاختبار.

أخيرًا، يمكنك مزامنة المشروع باستخدام Gradle.

إرسال اختبار STS

شغِّل مهمة zipForSubmission (إما باستخدام "استوديو Android" أو باستخدام Gradle في سطر الأوامر). يجب إنشاء ملف جديد باسم codesubmission.zip في الدليل build في جذر المشروع. حمِّل هذا الملف مع العينة التي تم إرسالها إلى "برنامج المكافآت للمبلّغين عن الثغرات الأمنية في Android".