ميزة AutoRepro لأمان Android

تم إنشاء المكوّن الإضافي AutoRepro Gradle استنادًا إلى Android Trade Federation، وهو إطار عمل لاختبار جميع أجهزة Android بحثًا عن ثغرات أمنية في نشرة أمان Android. تقتصر هذه الاختبارات على الإصلاحات المرتبطة أو التي سيتم ربطها بثغرات ومخاطر أمنية شائعة (CVE).

يسمح المكوّن الإضافي بتطوير اختبارات Tradefed خارج شجرة مصدر Android باستخدام "استوديو Android" أو حزمة تطوير البرامج (SDK) العادية لنظام التشغيل Android. وتتضمّن جميع الأدوات المساعدة اللازمة لإنشاء اختبار Tradefed وتشغيله.

ويُستخدَم بشكل أساسي لإرسال نماذج أولية يمكن إعادة إنتاجها تلقائيًا في إطار برنامج مكافآت الثغرات الأمنية في Android.

مثال على ميزة "إعادة الإنتاج التلقائي" للتنزيل المباشر

تصفُّح مثال ونماذج AutoRepro

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

يتم تقديم التعليمات لجهاز كمبيوتر Linux 64 بت.

  • الإصدار Ladybug من "استوديو Android" أو إصدار أحدث - يمكن أيضًا تثبيته من مدير الحِزم في توزيعتك.
  • أدوات منصة Android SDK (adb وfastboot): يجب تثبيتها وتضمينها في $PATH (أي يجب أن تتمكّن من تشغيل adb من سطر الأوامر). أسهل طريقة لتثبيت أدوات النظام الأساسي هي استخدام مدير الحِزم الخاص بتوزيعتك.
    • في حال استخدام أداة SDK Manager في "استوديو Android" بدلاً من أدوات النظام الأساسي المستقلة، تذكَّر إضافة دليل platform-tools الخاص بحزمة SDK إلى $PATH لتطوير سطر الأوامر.
  • ‫AAPT2 - يمكن أيضًا تثبيته باستخدام مدير الحِزم في توزيعتك.
  • الإصدار 21 أو إصدار أحدث من حزمة تطوير البرامج (JDK) للغة Java: متوافق مع حزمة تطوير البرامج (SDK) لنظام Android وGradle.

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

بعد استخراج المثال أو النموذج، افتح الدليل في "استوديو Android" كمشروع حالي وانتظِر إلى أن تكتمل عملية المزامنة مع Gradle. تتوفّر عدّة إعدادات تشغيل مُسبَقة الضبط في "استوديو Android".

مهام Gradle:

  • assembleSubmissionSources - تجميع ملفات المصدر لملف zip الخاص بعملية الإرسال
  • assembleSubmissionZip - تجميع ملف ZIP الخاص بطلب الإرسال لتحميله
  • copyInvocationResultsToSubmission - انسخ النتائج من عمليات استدعاء Tradefed السابقة إلى دليل مصادر إرسال AutoRepro للمساعدة في عملية المراجعة. يُرجى العِلم أنّ هذا الملف يحتوي على سجلّات من كلّ من المضيف والجهاز، لذا راجِع المحتوى قبل أو بعد تشغيل هذا الأمر.

استدعاء AutoRepro في إعدادات التشغيل في Android Studio:

  • autorepro_nonroot_arm64
  • autorepro_nonroot_x86_64
  • autorepro_root_arm64
  • autorepro_root_x86_64

تكون إعدادات مشغّل التطبيقات بالتنسيق autorepro_{device_root}_{device_arch}. ويُفضّل بشكل عام استخدام غير الجذر لأنّ الثغرات الأمنية التي تتطلّب الجذر تكون أقل خطورة. ومع ذلك، يمكن استخدام إذن الوصول إلى الجذر لتنفيذ عمليات الإعداد أو التنظيف، طالما تم توثيق ذلك بوضوح ويتم قبوله بشكل عام كحالة صالحة غير جذرية. على سبيل المثال، يمكن استخدام الوصول إلى الجذر لإرسال رسائل نصية مزيّفة إلى الجهاز لتجنُّب الحاجة إلى جهاز ثانٍ وشرائح SIM متعددة.

سيؤدي ذلك إلى تشغيل Tradefed لاختبارك. ينتظر Tradefed توصيل جهاز صالح، لذا تأكَّد من توصيل جهاز ومنح إذن بتصحيح أخطاء ADB.

التكامل مع وكلاء الترميز

يوفّر المثال والنماذج ملف سياق AGENTS.md متوافقًا مع "Gemini في استوديو Android" وGemini CLI وغيرهما من أدوات الترميز. يتضمّن هذا المستند آراءً حول بنية نماذج الإرسال وتعليمات حول استخدام أداة AutoRepro. يمكنك استخدام هذه الميزة من أجل:

  • تشغيل AutoRepro تلقائيًا على جهازك
  • مراجعة رمز إرسال حالي بحثًا عن تغييرات يمكن أن تساعد في قبول تقريرك بشكل أسرع
  • ساعدني في تنظيم PoC جديد بناءً على معلومات حول الثغرة الأمنية

كتابة اختبار AutoRepro

يتضمّن اختبار AutoRepro ثلاثة أجزاء وثلاثة مكوّنات إضافية متوافقة في Gradle:

  1. مكوّن Gradle الإضافي id("com.android.security.autorepro.javahosttest") هو اختبار Tradefed واحد من جهة المضيف يتفاعل مع الجهاز من خلال ADB. يستخدم المثال هذا الدليل في submission/hostTest/.
  2. المكوّن الإضافي لنظام Gradle id("com.android.security.autorepro.apptest") حِزمة APK لتطبيق أو خدمة يتم تثبيتها على الجهاز من خلال adb install ويتم تشغيلها من خلال الاختبار الذي يتم إجراؤه على الجهاز المضيف. يمكن أن يحتوي التطبيق أو الخدمة أيضًا على مجموعة خاصة من تأكيدات JUnit يتم إرسالها إلى برنامج التشغيل على الجهاز المضيف. يستخدم المثال هذا التنسيق في submission/appTest/ والدليل.
  3. المكوّن الإضافي لنظام Gradle id("com.android.security.autorepro.ndktest") هو هجوم اختياري يعتمد على NDK ويتم إرساله إلى الجهاز من خلال adb push ويتم تنفيذه من خلال الاختبار على جانب المضيف. يستخدم المثال هذا الملف في الدليل submission/ndkTest/.

عادةً ما يتّبع مسار اختبار AutoRepro أحد النمطَين التاليَين:

  • تطبيق اختبار قياس حالة التطبيق:

    1. يدفع الاختبار من جهة المضيف حزمة APK تتألف من تطبيق أو خدمة مزوّدة بأدوات إلى الجهاز.
    2. يبدأ الاختبار الذي يتم إجراؤه على الجهاز المضيف اختبارات JUnit التي يتم إجراؤها على الجهاز والمضمّنة في حزمة APK من خلال runDeviceTest().
    3. تستفيد اختبارات JUnit على الجهاز من أداة UIAutomator للنقر على الأزرار ومشاهدة التطبيق، أو تستخدم واجهات برمجة تطبيقات Android بطرق تكشف عن الثغرات الأمنية.
    4. يتم عرض نتيجة نجاح أو فشل اختبارات JUnit على الجهاز في الاختبار على الجهاز المضيف، ويمكن استخدامها لتحديد ما إذا كان الاختبار قد اجتاز أم لا. يجب أن تتضمّن رسالة الخطأ معلومات تفصيلية حول سبب تعذُّر تأكيد صحة البيان وأي كائنات أو قيم أو استثناءات أو عمليات تتبُّع تسلسل استدعاء الدوال البرمجية أو أي عناصر أخرى محدّدة كدليل على الثغرة الأمنية.

  • إثبات صحة المفهوم في NDK:

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

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

بنية إثبات جدوى الفكرة

يجب أن يقدّم PoC عالي الجودة أكثر من مجرد تشغيل خطأ، بل يجب أن يقدّم دليلاً يمكن التحقّق منه على أنّه تم تجاوز حدود الأمان. لتحقيق ذلك، يمكن أن تتبع PoC نمطًا محدّدًا من ثلاث خطوات "الفشل ثم النجاح":

  1. الإعداد: جهِّز الجهاز من خلال تثبيت التطبيقات اللازمة ونقل الملفات والتأكّد من أنّ الجهاز في الحالة المحدّدة المطلوبة قبل استغلال الثغرة مباشرةً. (يُسمح باستخدام الجذر في عملية الإعداد إذا كان ذلك مبرّرًا ويمثّل حالة واقعية للمستخدم النهائي).
  2. إثبات وجود ثغرة أمنية: قبل بدء استغلال الثغرة الأمنية، حاوِل تنفيذ الإجراء المستهدَف وأكِّد أنّه يتعذّر تنفيذه. على سبيل المثال، إذا كان الثغرة الأمنية تسمح بقراءة ملف محمي، عليك أولاً محاولة قراءته والتأكّد من ظهور رسالة الخطأ "تم رفض الإذن".
  3. التشغيل والتحقّق: شغِّل الثغرة الأمنية، ثم كرِّر الإجراء من الخطوة 2 على الفور. من المفترض أن ينجح هذا الإجراء الآن على جهاز معرَّض للخطر. للتحقّق من ذلك، يجب استخدام تأكيد يتعذّر تنفيذه على جهاز معرَّض للخطر ويتضمّن رسالة تبدأ بالبادئة AUTOREPRO_VULNERABILITY_PROVEN:. يجب أن تتضمّن هذه الرسالة وصفًا موجزًا للثغرة الأمنية وأي عناصر تم رصدها (مثل البيانات المسروقة أو الحالات غير المتوقعة) لإثبات نجاح عملية الاستغلال بشكل قاطع.

مثال:

@Test
public void testPoc() throws Exception {
    // 1. Setup: Prepare the device.
    setup();

    // 2. Prove the Boundary: Assert the resource is protected BEFORE the exploit.
    // This passes on all devices (safe or vulnerable) before the trigger runs.
    assertDeviceIsSecure();

    // 3. Trigger & Verify: Execute the exploit logic, then immediately repeat
    // the action from Step 2. On a vulnerable device, this action should now
    // succeed, causing assertDeviceIsSecure() to fail with an
    // AUTOREPRO_VULNERABILITY_PROVEN message.
    triggerExploit();
    assertDeviceIsSecure();
}

private void assertDeviceIsSecure() {
    try {
        String content = readProtectedFile();

        // Where possible, put the content in the assertion message.
        // Start the assertion message with "AUTOREPRO_VULNERABILITY_PROVEN:".
        Assert.fail("AUTOREPRO_VULNERABILITY_PROVEN: Successfully read protected file. Content: '" + content + "'");
    } catch (ThisVulnSpecificException e) {
        Log.i(TAG, "protected against reading protected file", e);
    }
}

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

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

إذا لم يتضمّن الاختبار استخدام إحدى الميزات، احذف أدلة المشاريع الفرعية غير الضرورية في Gradle.

يتضمّن الهجوم الذي أثبتُ فيه صحة الفكرة تطبيقًا أو خدمة ثانية

أضِف أي عدد تريده من المشاريع الفرعية في Gradle التي تتضمّن مكوّنات AutoRepro الإضافية.

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

لتضمين نتائج الاختبار من جهازك كجزء من الطلب:

  • يمكنك اختياريًا تنفيذ مهمة Gradle clean لحذف أي عمليات تشغيل اختبار قديمة.
  • نفِّذ إعداد تشغيل AutoRepro المناسب لاستدعاء Tradefed لاختبارك وجمع السجلات والنتائج.
  • نفِّذ المهمة copyInvocationResultsToSubmission لنسخ السجلّات والنتائج إلى دليل مصادر الإرسال.

نفِّذ الأمر assembleSubmissionZip لإنشاء الملف submission/build/autorepro-submission.zip. حمِّل هذا الملف مع نموذج الإبلاغ الذي ترسله إلى "برنامج مكافآت Android للمبلّغين عن الثغرات الأمنية". تأكَّد من أنّ المرفق يطابق النمط *autorepro-submission*.zip وأنّه تم تحميله مع التقرير الأوّلي. سيؤثر تحميل الطلبات في وقت متأخر في قدرتنا على مراجعة تقريرك بشكل صحيح.