Kit de desarrollo del conjunto de pruebas de seguridad de Android (STS SDK)

Security Test Suite Trade Federation (sts-tradefed) está construido sobre el arnés de prueba de Android Trade Federation para probar todos los dispositivos Android en busca de pruebas de parches de seguridad que no se incluyen en el Compatibility Test Suite. Estas pruebas son exclusivamente para correcciones que están asociadas (o estarán asociadas) con vulnerabilidades y exposiciones comunes (CVE).

El SDK permite el desarrollo de pruebas STS fuera del árbol fuente de Android utilizando Android Studio o el SDK estándar de Android. Incluye todas las utilidades necesarias para crear y ejecutar una prueba STS.

Obtenga el último SDK de STS

Requisitos previos

  • Computadora Linux de 64 bits.
  • Android Studio (también se puede instalar desde el administrador de paquetes de tu distribución).
  • Las herramientas de la plataforma Android ( adb , fastboot ) deben estar instaladas y en su $PATH (es decir, debería poder ejecutar adb desde la línea de comandos). La forma más sencilla de instalar las herramientas de la plataforma es a través del administrador de paquetes de su distribución.
    • Si utiliza el administrador de SDK de Android Studio en lugar de herramientas de plataforma independientes, recuerde agregar el directorio platform-tools del SDK a su $PATH.
  • aapt , que también se puede instalar a través del administrador de paquetes de su distribución.

Comience a usar Android Studio

Después de extraer el archivo, abra el directorio en Android Studio como un proyecto existente. Ejecute el objetivo de compilación assembleSTSARM o assembleSTSx86 para compilar la prueba del esqueleto, según la arquitectura del dispositivo Android de destino. Ejecute el objetivo de compilación runSTS para ejecutar la prueba de esqueleto en el dispositivo conectado (ADB debe estar autorizado).

Comience a usar Gradle

Después de extraer el archivo, configure la propiedad sdk.dir en el archivo local.properties en la raíz del proyecto Gradle y luego ejecute la tarea assembleSTSARM Gradle para compilar la prueba del esqueleto. Una vez finalizada la compilación, la prueba se puede ejecutar navegando ( cd ) a build/android-sts/tools y ejecutando el contenedor 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

Escribe una prueba STS

Una prueba STS consta de tres partes:

  1. Una prueba Tradefed del lado del host que interactúa con el dispositivo a través de adb, en el subdirectorio sts-test .
  2. Un ataque de prueba de concepto nativo opcional que se inserta en el dispositivo a través de adb push y se ejecuta mediante la prueba del lado del host en el subdirectorio native-poc .
  3. Un APK de aplicación o servicio opcional que se instala en el dispositivo mediante adb install y también se inicia mediante la prueba del lado del host. La aplicación o servicio también puede contener su propio conjunto de aserciones JUnit que se informa al ejecutor del lado del host. Esto está en el subdirectorio test-app .

Un flujo de prueba STS típico suele seguir uno de dos patrones:

  • Prueba de concepto nativa:

    1. La prueba del lado del host envía y lanza un ejecutable nativo en el dispositivo.
    2. El programa nativo falla o devuelve un código de salida específico.
    3. La prueba del lado del host busca fallas, analiza el seguimiento de logcat o busca el código de salida específico para determinar si el ataque tuvo éxito.

  • Aplicación de prueba instrumentada:

    1. La prueba del lado del host inserta un APK que consta de una aplicación o servicio en el dispositivo.
    2. La prueba del lado del host inicia las pruebas JUnit del lado del dispositivo que se incluyen con el APK a través de runDeviceTest()
    3. El JUnit del lado del dispositivo prueba los botones y observa la aplicación usando UIAutomator, o accede al sistema Android de manera que revela vulnerabilidades de seguridad.
    4. El éxito o el fracaso de las pruebas JUnit del lado del dispositivo se devuelve a la prueba del lado del host, que se puede utilizar para determinar si la prueba pasó o no.

También es posible una combinación de los dos patrones (por ejemplo, ejecutar un programa nativo junto con pruebas del lado del dispositivo). También están disponibles algunos otros marcos de instrumentación, como frida-inject . Para obtener más información, consulte los documentos de referencia de Security Test Suite y los documentos de referencia de Tradefed .

Mi ataque de prueba de concepto no necesita una aplicación de prueba ni un ejecutable nativo

La mayoría de las pruebas no necesitarán una aplicación del dispositivo ni un ejecutable nativo.

Si su prueba no implica el uso de una aplicación/servicio en el dispositivo, simplemente elimine el subdirectorio test-app . De manera similar, si su prueba no utiliza un ejecutable nativo, elimine el subdirectorio native-poc y luego sincronice Gradle el proyecto. El proyecto está configurado para omitir automáticamente la creación de esos módulos cuando no existen.

Mi ataque de prueba de concepto implica una segunda aplicación/servicio

Primero, agregue un nuevo módulo a su proyecto para su segunda aplicación/servicio y escríbalo como lo haría con cualquier otro APK.

A continuación, edite build.gradle en la raíz de este directorio y agregue su módulo siguiendo las instrucciones en copyArtifacts , assembleStsARM y assembleStsx86 . Esto garantizará que el APK compilado se copie en el directorio de salida de STS y permitirá instalar/llamar la nueva aplicación desde la prueba.

Finalmente, Gradle sincroniza el proyecto.

Presentar la prueba STS

Ejecute la tarea zipForSubmission (ya sea con Android Studio o con Gradle en la línea de comando). Se debe crear un nuevo archivo, codesubmission.zip , en el directorio build en la raíz del proyecto. Cargue ese archivo junto con su envío al Programa de recompensa por vulnerabilidad de Android.