Kit de desarrollo de paquetes de pruebas de seguridad de Android (SDK de STS)

Security Test Suite Trade Federation (sts-tradefed) se compila sobre el agente de prueba de Android Trade Federation para probar todos los dispositivos Android en busca de pruebas de parches de seguridad que no se incluyan en el conjunto de pruebas de compatibilidad. Estas pruebas son exclusivas para las correcciones que están asociadas (o se asociarán) con una vulnerabilidad y exposición comunes (CVE).

El SDK permite desarrollar pruebas de STS fuera del árbol de fuentes de Android con Android Studio o el SDK estándar de Android. Incluye todas las utilidades que se necesitan para compilar y ejecutar una prueba de STS.

Obtener el SDK de STS más reciente

Requisitos previos

  • PC con 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 de Android (adb, fastboot) deben estar instaladas y estar en tu $PATH (es decir, deberías 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 tu distribución.
    • Si usas SDK Manager de Android Studio en lugar de herramientas de plataforma independientes, recuerda agregar el directorio platform-tools del SDK a tu $PATH.
  • aapt, que también se puede instalar a través del administrador de paquetes de tu distribución.

Comienza a usar Android Studio

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

Cómo comenzar a usar Gradle

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

Escribe una prueba de STS

Una prueba de STS consta de las siguientes tres partes:

  1. Es una prueba de 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 envía al dispositivo a través de adb push y lo ejecuta la prueba del host en el subdirectorio native-poc.
  3. Una app o un APK de servicio opcional que se instala en el dispositivo a través de adb install y que también se inicia mediante la prueba del host. La app o el servicio también pueden contener su propio conjunto de aserciones JUnit que se informan al ejecutor del host. Se encuentra en el subdirectorio test-app.

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

  • Prueba de concepto nativa:

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

  • App de prueba de instrumentación:

    1. La prueba del host envía un APK que consta de una app o un servicio al dispositivo.
    2. La prueba del host inicia las pruebas JUnit del dispositivo que se empaquetan con el APK mediante runDeviceTest().
    3. Las pruebas JUnit del dispositivo presionan los botones y observan la app con UIAutomator, o bien acceden al sistema Android de maneras que revelan vulnerabilidades de seguridad.
    4. El éxito o el fracaso de las pruebas JUnit del dispositivo se devuelven a la prueba del host, que se puede usar para determinar si la prueba se aprobó o no.

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

Mi ataque de prueba de concepto no necesita una app de prueba ni un ejecutable nativo

La mayoría de las pruebas no necesitarán una app del dispositivo y un ejecutable nativo.

Si tu prueba no implica el uso de una app o servicio en el dispositivo, simplemente borra el subdirectorio test-app. Del mismo modo, si la prueba no usa un ejecutable nativo, borra el subdirectorio native-poc y, luego, sincroniza el proyecto con Gradle. El proyecto está configurado para omitir automáticamente la compilación de esos módulos cuando no existen.

Mi ataque de prueba de concepto involucra una segunda aplicación o servicio

Primero, agrega un módulo nuevo a tu proyecto para tu segundo servicio o app y escribe como lo harías con cualquier otro APK.

Luego, edita build.gradle en la raíz de este directorio y agrega tu módulo siguiendo las instrucciones de copyArtifacts, assembleStsARM y assembleStsx86. Esto garantizará que el APK compilado se copie en el directorio de salida de STS y permita instalar o llamar a la app nueva desde la prueba.

Por último, sincroniza el proyecto con Gradle.

Envía la prueba de STS

Ejecuta la tarea zipForSubmission (con Android Studio o con Gradle en la línea de comandos). Se debe crear un archivo nuevo, codesubmission.zip, en el directorio build, en la raíz del proyecto. Sube ese archivo junto con tu envío al Programa de recompensas por detección de vulnerabilidades de Android.