کیت توسعه مجموعه تست امنیت Android (STS SDK)

فدراسیون تجارت مجموعه تست امنیتی (sts-tradefed) بر روی مهار تست فدراسیون تجارت اندروید ساخته شده است تا تمام دستگاه‌های اندرویدی را برای تست‌های وصله امنیتی که در مجموعه تست سازگاری قرار نمی‌گیرند، آزمایش کند. این آزمایش‌ها منحصراً برای اصلاحاتی هستند که با آسیب‌پذیری‌ها و مواجهه‌های مشترک (CVE) مرتبط هستند (یا مرتبط خواهند بود).

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

آخرین STS SDK را دریافت کنید

پیش نیازها

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

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

پس از استخراج آرشیو، دایرکتوری را در Android Studio به عنوان یک پروژه موجود باز کنید. بسته به معماری دستگاه اندرویدی مورد نظر، assembleSTSARM یا assembleSTSx86 build target را برای ساخت تست اسکلت اجرا کنید. برای اجرای تست اسکلت روی دستگاه متصل، runSTS build target را اجرا کنید (ADB باید مجاز باشد).

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

پس از استخراج آرشیو، ویژگی sdk.dir در فایل local.properties در ریشه پروژه Gradle تنظیم کنید، سپس برای ساخت تست اسکلت، وظیفه assembleSTSARM Gradle را اجرا کنید. پس از اتمام ساخت، تست را می توان با پیمایش ( cd ) به build/android-sts/tools و اجرای wrapper 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 تماشا می‌کند، یا به روش‌هایی به سیستم اندروید دسترسی پیدا می‌کند که آسیب‌پذیری‌های امنیتی را آشکار می‌کند.
    4. موفقیت یا عدم موفقیت تست‌های JUnit سمت دستگاه به تست سمت میزبان بازگردانده می‌شود، که می‌توان از آن برای تعیین اینکه آیا آزمون موفق شد یا خیر، استفاده کرد.

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

حمله اثبات مفهوم من به برنامه آزمایشی یا فایل اجرایی بومی نیاز ندارد

اکثر تست ها هم به برنامه سمت دستگاه و هم به یک فایل اجرایی بومی نیاز ندارند.

اگر آزمایش شما شامل استفاده از برنامه/سرویس روی دستگاه نیست، به سادگی فهرست فرعی test-app را حذف کنید. به طور مشابه، اگر آزمایش شما از یک فایل اجرایی بومی استفاده نمی کند، زیر شاخه native-poc را حذف کنید و سپس پروژه را Gradle-sync کنید. این پروژه به گونه ای تنظیم شده است که به طور خودکار از ساخت آن ماژول ها در صورت عدم وجود آنها صرف نظر کند.

حمله اثبات مفهوم من شامل یک برنامه/سرویس دوم است

ابتدا یک ماژول جدید برای برنامه/سرویس دوم خود به پروژه خود اضافه کنید و مانند هر APK دیگری بنویسید.

سپس، build.gradle در ریشه این دایرکتوری ویرایش کنید و ماژول خود را طبق دستورالعمل‌های copyArtifacts ، assembleStsARM و assembleStsx86 اضافه کنید. این اطمینان حاصل می کند که APK کامپایل شده در دایرکتوری خروجی STS کپی شده است و نصب / فراخوانی برنامه جدید را از آزمایش امکان پذیر می کند.

در نهایت، پروژه را Gradle همگام سازی کنید.

آزمون STS را ارسال کنید

وظیفه zipForSubmission (با Android Studio یا Gradle در خط فرمان) را اجرا کنید. یک فایل جدید codesubmission.zip باید در دایرکتوری build در ریشه پروژه ایجاد شود. آن فایل را همراه با ارسال خود در برنامه پاداش آسیب پذیری Android آپلود کنید.

،

فدراسیون تجارت مجموعه تست امنیتی (sts-tradefed) بر روی مهار تست فدراسیون تجارت اندروید ساخته شده است تا تمام دستگاه‌های اندرویدی را برای تست‌های وصله امنیتی که در مجموعه تست سازگاری قرار نمی‌گیرند، آزمایش کند. این آزمایش‌ها منحصراً برای اصلاحاتی هستند که با آسیب‌پذیری‌ها و مواجهه‌های مشترک (CVE) مرتبط هستند (یا مرتبط خواهند بود).

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

آخرین STS SDK را دریافت کنید

پیش نیازها

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

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

پس از استخراج آرشیو، دایرکتوری را در Android Studio به عنوان یک پروژه موجود باز کنید. بسته به معماری دستگاه اندرویدی مورد نظر، assembleSTSARM یا assembleSTSx86 build target را برای ساخت تست اسکلت اجرا کنید. برای اجرای تست اسکلت روی دستگاه متصل، runSTS build target را اجرا کنید (ADB باید مجاز باشد).

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

پس از استخراج آرشیو، ویژگی sdk.dir در فایل local.properties در ریشه پروژه Gradle تنظیم کنید، سپس برای ساخت تست اسکلت، وظیفه assembleSTSARM Gradle را اجرا کنید. پس از اتمام ساخت، تست را می توان با پیمایش ( cd ) به build/android-sts/tools و اجرای wrapper 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 تماشا می‌کند، یا به روش‌هایی به سیستم اندروید دسترسی پیدا می‌کند که آسیب‌پذیری‌های امنیتی را آشکار می‌کند.
    4. موفقیت یا عدم موفقیت تست‌های JUnit سمت دستگاه به تست سمت میزبان بازگردانده می‌شود، که می‌توان از آن برای تعیین اینکه آیا آزمون موفق شد یا خیر، استفاده کرد.

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

حمله اثبات مفهوم من به برنامه آزمایشی یا فایل اجرایی بومی نیاز ندارد

اکثر تست ها هم به برنامه سمت دستگاه و هم به یک فایل اجرایی بومی نیاز ندارند.

اگر آزمایش شما شامل استفاده از برنامه/سرویس روی دستگاه نیست، به سادگی فهرست فرعی test-app را حذف کنید. به طور مشابه، اگر آزمایش شما از یک فایل اجرایی بومی استفاده نمی کند، زیر شاخه native-poc را حذف کنید و سپس پروژه را Gradle-sync کنید. این پروژه به گونه ای تنظیم شده است که به طور خودکار از ساخت آن ماژول ها در صورت عدم وجود آنها صرف نظر کند.

حمله اثبات مفهوم من شامل یک برنامه/سرویس دوم است

ابتدا یک ماژول جدید برای برنامه/سرویس دوم خود به پروژه خود اضافه کنید و مانند هر APK دیگری بنویسید.

سپس، build.gradle در ریشه این دایرکتوری ویرایش کنید و ماژول خود را طبق دستورالعمل‌های copyArtifacts ، assembleStsARM و assembleStsx86 اضافه کنید. این اطمینان حاصل می کند که APK کامپایل شده در دایرکتوری خروجی STS کپی شده است و نصب / فراخوانی برنامه جدید را از آزمایش امکان پذیر می کند.

در نهایت، پروژه را Gradle همگام سازی کنید.

آزمون STS را ارسال کنید

وظیفه zipForSubmission (با Android Studio یا Gradle در خط فرمان) را اجرا کنید. یک فایل جدید codesubmission.zip باید در دایرکتوری build در ریشه پروژه ایجاد شود. آن فایل را همراه با ارسال خود در برنامه پاداش آسیب پذیری Android آپلود کنید.