حزمة تطوير "حزمة اختبار أمان 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" بدلاً من النظام الأساسي المستقل تذكّر أن تضيف دليل platform-tools لحزمة تطوير البرامج (SDK) إلى مسار $PATH.
• aapt، التي يمكن تثبيتها أيضًا من خلال أداة إدارة الحِزم في Distro

ملاحظة: يمكنك الاطّلاع على دليل CTS إذا كنت بحاجة إلى ذلك. المساعدة في إعداد ADB وAAPT

تنبيه: لا تتوافق آلية STS رسميًا إلا مع الأجهزة التي تعمل بنظام التشغيل Linux 64 بت. أثناء كتابة الاختبارات التي تعمل بحزمة تطوير البرامج STS مع "استوديو Android" على نظامَي التشغيل Windows أو MacOS، ما يتيح الوصول إلى الذي يتم تنفيذه على تلك المنصة ليس بسيطًا، أي أنّه خارج نطاق هذا المستند.

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

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

بدء استخدام 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 عندما لا يكون الجهاز عرضة للاختراق، وينقطع عند يكون الجهاز عرضة للاختراق، أو بعبارة أخرى، عندما ينجح الهجوم. يجب أن يكون الاختبار عرض ASSUMPTION_FAILURE (على سبيل المثال، باستخدام Assume بدلاً من Assert) عندما يتعذّر تحديد ما إذا كان الجهاز عرضة للاختراق أم لا.

هناك ثلاثة أجزاء لاختبار 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. للحصول على التفاصيل، يمكنك مراجعة المستندات المرجعية لـ "حزمة اختبار الأمان" المستندات المرجعية التي تم تحويلها

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

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

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

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

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

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

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

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

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