Комплект для разработки Android Security Test Suite (STS SDK)

Пакет тестов безопасности Trade Federation (sts-tradefed) создан на основе набора тестов Android Trade Federation для тестирования всех устройств Android на наличие исправлений безопасности, которые не попадают в набор тестов совместимости. Эти тесты предназначены исключительно для исправлений, которые связаны (или будут связаны) с общими уязвимостями и рисками (CVE).

SDK позволяет разрабатывать тесты STS за пределами исходного дерева Android с помощью Android Studio или стандартного Android SDK. Он включает в себя все утилиты, необходимые для создания и запуска теста STS.

Получить последнюю версию SDK STS

Предпосылки

  • 64-битный ПК с Linux.
  • Android Studio (также можно установить из диспетчера пакетов вашего дистрибутива.
  • Инструменты платформы Android ( adb , fastboot ) должны быть установлены и находиться в вашем $PATH (т.е. вы должны иметь возможность запускать adb из командной строки). Самый простой способ установить инструменты платформы — через менеджер пакетов вашего дистрибутива.
    • Если вы используете диспетчер SDK Android Studio вместо отдельных инструментов платформы, не забудьте добавить каталог platform-tools SDK в ваш $PATH.
  • aapt , который также можно установить через диспетчер пакетов вашего дистрибутива.

Начните использовать Android Studio

После распаковки архива откройте каталог в Android Studio как существующий проект. Запустите цель сборки 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 . Дополнительные сведения см. в справочной документации Security Test Suite и справочной документации Tradefed .

Моя демонстрационная атака не требует тестового приложения и/или собственного исполняемого файла.

Большинству тестов не потребуется ни приложение на стороне устройства, ни собственный исполняемый файл.

Если ваш тест не предполагает использования приложения/службы на устройстве, просто удалите подкаталог test-app . Точно так же, если в вашем тесте не используется собственный исполняемый файл, удалите подкаталог native-poc , а затем синхронизируйте проект с Gradle. Проект настроен на автоматический пропуск сборки этих модулей, когда они не существуют.

В моей экспериментальной атаке задействовано второе приложение/сервис.

Во-первых, добавьте в свой проект новый модуль для второго приложения/сервиса и напишите его так же, как и любой другой APK.

Затем отредактируйте build.gradle в корне этого каталога и добавьте свой модуль, следуя инструкциям в copyArtifacts , assembleStsARM и assembleStsx86 . Это обеспечит копирование скомпилированного APK в выходной каталог STS и позволит установить/вызвать новое приложение из теста.

Наконец, Gradle-синхронизируйте проект.

Отправка теста STS

Запустите задачу zipForSubmission (либо с помощью Android Studio, либо с помощью Gradle в командной строке). Новый файл codesubmission.zip должен быть создан в каталоге build в корне проекта. Загрузите этот файл вместе с отправкой в ​​программу вознаграждения за уязвимости Android.