Эта страница переведена с помощью Cloud Translation API.

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

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

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

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

Предварительные условия

ПК с 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, затем запустите задачу Gradle assembleSTSARM , чтобы построить скелетный тест. После завершения сборки тест можно запустить, перейдя ( 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 состоит из трех частей:

Тест Tradefed на стороне хоста, который взаимодействует с устройством через adb, в подкаталоге sts-test .
Необязательная встроенная атака для проверки концепции, которая передается на устройство через adb push и выполняется тестом на стороне хоста в подкаталоге native-poc .
Дополнительное 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.