Android Security AutoRepro

افزونه AutoRepro Gradle بر روی چارچوب تست فدراسیون تجارت اندروید (Android Trade Federation) ساخته شده است تا تمام دستگاه‌های اندروید را برای تست‌های وصله امنیتی در برابر آسیب‌پذیری‌های موجود در بولتن امنیتی اندروید آزمایش کند. این آزمایش‌ها منحصراً برای رفع اشکالاتی هستند که با یک آسیب‌پذیری و آسیب‌پذیری رایج (CVE) مرتبط هستند یا خواهند بود.

این افزونه امکان توسعه تست‌های Tradefed را خارج از درخت کد اندروید با استفاده از اندروید استودیو یا SDK استاندارد اندروید فراهم می‌کند. این افزونه شامل تمام ابزارهایی است که برای ساخت و اجرای یک تست Tradefed مورد نیاز است.

این در درجه اول برای ارسال خودکار اثبات مفاهیم قابل تکرار برای برنامه پاداش آسیب‌پذیری اندروید استفاده می‌شود.

دانلود مستقیم download نمونه AutoRepro

مرور مثال‌ها و قالب‌های AutoRepro open_in_new

پیش‌نیازها

دستورالعمل‌ها برای یک کامپیوتر لینوکس ۶۴ بیتی ارائه شده‌اند.

• اندروید استودیو لیدی‌باگ یا جدیدتر - همچنین می‌تواند از طریق مدیریت بسته توزیع شما نصب شود.
• ابزارهای پلتفرم SDK اندروید ( adb ، fastboot ) - باید نصب شوند و در $PATH شما باشند (یعنی باید بتوانید adb از خط فرمان اجرا کنید). ساده‌ترین راه برای نصب ابزارهای پلتفرم، استفاده از مدیر بسته توزیع شما است.
  • اگر به جای ابزارهای مستقل پلتفرم، از مدیریت SDK اندروید استودیو استفاده می‌کنید، به یاد داشته باشید که پوشه platform-tools مربوط به SDK را برای توسعه خط فرمان به $PATH خود اضافه کنید.
• AAPT2 - همچنین می‌تواند با استفاده از مدیر بسته توزیع شما نصب شود.
• جاوا JDK 21 یا جدیدتر - سازگار با Android SDK و Gradle.

شروع به استفاده از اندروید استودیو کنید

پس از استخراج مثال یا الگو، دایرکتوری را در اندروید استودیو به عنوان یک پروژه موجود باز کنید و منتظر بمانید تا همگام‌سازی Gradle کامل شود. چندین پیکربندی از پیش تنظیم شده برای اجرای اندروید استودیو وجود دارد.

وظایف گریدل:

• assembleSubmissionSources - فایل‌های منبع را برای فایل زیپ ارسال، اسمبل (جمع‌بندی) می‌کند.
• assembleSubmissionZip - فایل زیپ ارسالی را برای آپلود سرهم می‌کند.
• copyInvocationResultsToSubmission - نتایج حاصل از فراخوانی‌های قبلی Tradefed را در دایرکتوری منابع ارسال AutoRepro کپی می‌کند تا به فرآیند بررسی کمک کند. توجه داشته باشید که این شامل گزارش‌هایی از میزبان و دستگاه است؛ قبل یا بعد از اجرای این، محتویات را بررسی کنید.

تنظیمات اجرای فراخوانی AutoRepro در اندروید استودیو:

• autorepro_nonroot_arm64
• autorepro_nonroot_x86_64
• autorepro_root_arm64
• autorepro_root_x86_64

پیکربندی‌های لانچر به شکل autorepro_{device_root}_{device_arch} هستند. معمولاً استفاده از حالت بدون روت ترجیح داده می‌شود زیرا آسیب‌پذیری‌هایی که نیاز به روت دارند، شدت کمتری دارند. با این حال، استفاده از روت برای انجام تنظیمات یا پاکسازی می‌تواند قابل قبول باشد، تا زمانی که به وضوح مستند شده باشد و به طور کلی به عنوان یک حالت بدون روت معتبر پذیرفته شده باشد. به عنوان مثال، استفاده از روت برای ارسال جعلی پیام‌های متنی به دستگاه برای جلوگیری از نیاز به دستگاه دوم و چندین سیم کارت قابل قبول است.

این‌ها Tradefed را برای آزمایش شما اجرا می‌کنند. Tradefed منتظر اتصال یک دستگاه معتبر می‌ماند، بنابراین مطمئن شوید که یکی متصل شده و اشکال‌زدایی ADB مجاز است.

ادغام با عوامل کدنویسی

این مثال و قالب‌ها یک فایل زمینه AGENTS.md ارائه می‌دهند که با Gemini در اندروید استودیو، Gemini CLI و سایر عوامل کدنویسی سازگار است. این فایل شامل نظراتی در مورد ساختار ارسال و دستورالعمل‌هایی در مورد استفاده از AutoRepro است. می‌توانید از این فایل برای موارد زیر استفاده کنید:

• اجرای خودکار AutoRepro برای دستگاه شما
• بررسی کد یک ارسال موجود برای تغییراتی که می‌تواند به پذیرش سریع‌تر گزارش شما کمک کند.
• با توجه به اطلاعات مربوط به آسیب‌پذیری، به ساختاردهی یک PoC جدید کمک کنید

یک تست AutoRepro بنویسید

سه بخش برای تست AutoRepro و سه افزونه Gradle مربوطه وجود دارد:

1. Gradle plugin id("com.android.security.autorepro.javahosttest") تست Tradefed سمت میزبان که از طریق ADB با دستگاه تعامل دارد. در این مثال از آن در دایرکتوری submission/hostTest/ استفاده شده است.
2. Gradle plugin id("com.android.security.autorepro.apptest") یک APK برنامه یا سرویس که از طریق adb install روی دستگاه نصب شده و توسط تست سمت میزبان اجرا می‌شود. این برنامه یا سرویس همچنین می‌تواند شامل مجموعه‌ای از دستورات JUnit مخصوص به خود باشد که به اجراکننده سمت میزبان گزارش می‌شود. در این مثال از آن در دایرکتوری submission/appTest/ و دایرکتوری appTest/ استفاده شده است.
3. id("com.android.security.autorepro.ndktest") یک حمله اثبات مفهومی مبتنی بر NDK اختیاری که از طریق adb push به دستگاه وارد شده و توسط تست سمت میزبان اجرا می‌شود. این مثال از آن در دایرکتوری submission/ndkTest/ استفاده می‌کند.

یک جریان تست AutoRepro معمولی معمولاً از یکی از دو الگو پیروی می‌کند:

• برنامه تست ابزار دقیق:

  1. تست سمت میزبان، یک APK شامل یک برنامه یا سرویسِ مجهز به ابزار را به دستگاه ارسال می‌کند.
  2. تست سمت میزبان، تست‌های JUnit سمت دستگاه را که از طریق runDeviceTest() با APK همراه است، آغاز می‌کند.
  3. JUnit سمت دستگاه، دکمه‌های ضربه‌ای را آزمایش می‌کند و با استفاده از UIAutomator برنامه را زیر نظر می‌گیرد، یا به روش‌های دیگری به APIهای اندروید دسترسی پیدا می‌کند که آسیب‌پذیری‌های امنیتی را آشکار می‌کند.
  4. موفقیت یا شکست تست‌های JUnit سمت دستگاه به تست سمت میزبان بازگردانده می‌شود، که می‌تواند برای تعیین موفقیت یا عدم موفقیت تست مورد استفاده قرار گیرد. پیام شکست باید حاوی اطلاعات دقیقی در مورد دلیل شکست ادعا و هرگونه شیء، مقدار، استثنا، stacktraces یا سایر مصنوعات خاص به عنوان اثبات آسیب‌پذیری باشد.

• اثبات مفهوم NDK:

  1. تست سمت میزبان، یک فایل اجرایی لینوکس را روی دستگاه اجرا و اجرا می‌کند.
  2. برنامه‌ی اصلی از کار می‌افتد یا یک کد خروج خاص را برمی‌گرداند.
  3. تست سمت میزبان، خرابی‌ها را بررسی می‌کند، به backtrace لاگ‌کت نگاه می‌کند، یا به دنبال کد خروج خاص می‌گردد تا مشخص کند که آیا حمله موفقیت‌آمیز بوده است یا خیر. پیام شکست باید حاوی اطلاعات دقیقی در مورد دلیل شکست ادعا و هرگونه ساختار، مقدار، stacktraces یا سایر مصنوعات خاص به عنوان اثبات آسیب‌پذیری باشد.

ترکیبی از این دو الگو (برای مثال، اجرای یک برنامه بومی همراه با تست‌های سمت دستگاه) نیز امکان‌پذیر است. برخی چارچوب‌های ابزار دقیق دیگر، مانند frida-inject ، نیز موجود هستند. برای جزئیات بیشتر، به اسناد مرجع Security Test Suite و اسناد مرجع Tradefed مراجعه کنید.

ساختار اثبات‌پذیری اثبات مفهوم

یک PoC با کیفیت بالا باید کاری بیش از ایجاد یک اشکال انجام دهد؛ باید مدرک قابل اثباتی ارائه دهد که نشان دهد از مرز امنیتی عبور شده است. برای دستیابی به این هدف، PoCها می‌توانند از یک الگوی سه مرحله‌ای خاص "شکست-سپس-موفقیت" پیروی کنند:

1. راه‌اندازی: دستگاه را با نصب برنامه‌های لازم، بارگذاری فایل‌ها و اطمینان از اینکه دستگاه در وضعیت خاص مورد نیاز بلافاصله قبل از بهره‌برداری قرار دارد، آماده کنید. (استفاده از روت برای پیکربندی در صورت توجیه و نشان دادن وضعیت واقعی کاربر نهایی مجاز است).
2. اثبات مرز: قبل از فعال کردن آسیب‌پذیری، اقدام مورد نظر را امتحان کنید و تأیید کنید که با شکست مواجه می‌شود . برای مثال، اگر اکسپلویت اجازه خواندن یک فایل محافظت‌شده را می‌دهد، ابتدا باید سعی کنید آن را بخوانید و تأیید کنید که خطای "اجازه رد شد" را دریافت می‌کنید.
3. فعال‌سازی و تأیید: آسیب‌پذیری را فعال کنید، سپس بلافاصله اقدام مرحله ۲ را تکرار کنید. در یک دستگاه آسیب‌پذیر، این اقدام اکنون باید موفقیت‌آمیز باشد. برای تأیید این موضوع، باید از یک ادعا که در یک دستگاه آسیب‌پذیر با پیامی که با پیشوند دقیق 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 run را اجرا کنید تا Tradefed را برای تست خود فراخوانی کرده و گزارش‌ها و نتایج را جمع‌آوری کنید.
• وظیفه copyInvocationResultsToSubmission را اجرا کنید تا گزارش‌ها و نتایج را در دایرکتوری منابع ارسال کپی کنید.

برای ایجاد فایل submission/build/autorepro-submission.zip ، فایل assembleSubmissionZip اجرا کنید. آن فایل را به همراه فایل ارسالی خود در برنامه پاداش آسیب‌پذیری اندروید آپلود کنید. مطمئن شوید که پیوست با الگوی *autorepro-submission*.zip مطابقت دارد و همراه با گزارش اولیه آپلود شده است. آپلود دیرهنگام فایل‌های ارسالی، بر توانایی ما در بررسی صحیح گزارش شما تأثیر خواهد گذاشت.