حزمة تطوير "حزمة اختبار أمان 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 لإجراء اختبار الهيكل على الجهاز المتصل (يجب تفويض 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" أو باستخدام Gradle في سطر الأوامر). ويجب إنشاء ملف جديد، codesubmission.zip، في دليل build في جذر المشروع. حمِّل هذا الملف مع العينة التي تم إرسالها إلى "برنامج المكافآت للمبلّغين عن الثغرات الأمنية في Android".