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

Security Test Suite Trade Federation (sts-tradefed) se basa en 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 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 de fuentes 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 SDK de STS más reciente

requisitos previos

  • PC Linux de 64 bits.
  • Android Studio (también se puede instalar desde el administrador de paquetes de su distribución.
  • Las herramientas de la plataforma Android ( adb , fastboot ) deben instalarse y estar en su $PATH (es decir, debería poder ejecutar adb desde la línea de comandos). La forma más fácil de instalar las herramientas de la plataforma es a través del administrador de paquetes de su distribución.
    • Si usa el administrador de SDK de Android Studio en lugar de las herramientas de la plataforma independiente, 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.

Empezar 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 de esqueleto, según la arquitectura del dispositivo Android de destino. Ejecute el destino de compilación runSTS para ejecutar la prueba de esqueleto en el dispositivo conectado (ADB debe estar autorizado).

Comienza a usar Gradle

Después de extraer el archivo, establezca la propiedad sdk.dir en el archivo local.properties en la raíz del proyecto de Gradle y, a continuación, ejecute la tarea de Gradle para assembleSTSARM para crear la prueba básica. Una vez finalizada la compilación, se puede ejecutar la prueba navegando ( cd ) en 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

Escribir una prueba STS

Hay tres partes en una prueba STS:

  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 lo ejecuta la prueba del lado del host en el subdirectorio native-poc .
  3. Una aplicación o servicio APK opcional que se instala en el dispositivo a través de adb install y también se inicia mediante la prueba del lado del host. La aplicación o el servicio también puede contener su propio conjunto de aserciones JUnit que se informan al ejecutor del lado del host. Está en el subdirectorio test-app .

Un flujo de prueba típico de STS generalmente sigue uno de dos patrones:

  • Prueba de concepto nativa:

    1. La prueba del lado del host empuja 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 verifica si hay fallas, mira el rastreo 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 envía un APK que consta de una aplicación o un servicio al 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 otra 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 usar para determinar si la prueba pasó o no.

También es posible una combinación de los dos patrones (por ejemplo, la ejecución de 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 lado del dispositivo y un ejecutable nativo.

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

Mi ataque de prueba de concepto involucra 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 asegurará que el APK compilado se copie en el directorio de salida de STS y permita la instalación/llamada de la nueva aplicación desde la prueba.

Finalmente, Gradle sincroniza el proyecto.

Envío de 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 recompensas por vulnerabilidad de Android.