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

La Federación de Comercio de paquetes de pruebas de seguridad (sts-tradefed) se basa en Federación de Comercio de Android agente de prueba para probar la seguridad de todos los dispositivos Android pruebas de parches que no están incluidas en el Conjunto de pruebas de compatibilidad. Estas pruebas son exclusivamente para correcciones que están asociadas (o se asociarán) con un Vulnerabilidades y exposiciones 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 necesarios para compilar y ejecutar una prueba de STS.

Obtén el SDK de STS más reciente

Requisitos previos

  • PC con Linux de 64 bits.
  • Android Studio (también se puede instalar) del administrador de paquetes de tu distribución.
  • Herramientas de la plataforma de Android (adb, fastboot) deben estar instalados en tu $PATH (es decir, debería poder ejecutar adb desde la línea de comandos). La forma más fácil de instales las herramientas de la plataforma es mediante el administrador de paquetes de tu distribución.
    • Si se usa SDK Manager de Android Studio en lugar de la plataforma independiente 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 proyecto existente. Ejecuta el destino de compilación assembleSTSARM o assembleSTSx86 para compilar la prueba de estructura, según la arquitectura del dispositivo Android de destino dispositivo. Ejecuta el destino de compilación runSTS para ejecutar la prueba de esqueleto en el servidor (ADB debe estar autorizado).

Cómo comenzar a usar Gradle

Después de extraer el archivo, configura la propiedad sdk.dir en local.properties en la raíz del proyecto de Gradle y, luego, ejecuta el assembleSTSARM Tarea de Gradle para compilar la prueba de estructura. Una vez que la compilación finalizado, la prueba se puede ejecutar navegando (cd) hacia build/android-sts/tools y ejecución del 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. 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 envía al mediante adb push, y lo ejecuta la prueba del host en la Subdirectorio native-poc.
  3. Una app o un APK de servicio opcional que se instala en el dispositivo mediante adb install y que también se inicia mediante la prueba del host. La app o servicio también puede contener su propio conjunto de aserciones JUnit que se informa al ejecutador del lado 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 lado del host envía e inicia un ejecutable nativo en el dispositivo.
    2. El programa nativo falla o devuelve un código de salida específico.
    3. La prueba del host comprueba si hay fallas, observa el backtrace de logcat o busca el código de salida específico para determinar si el ataque sin errores.

  • App de prueba de instrumentación:

    1. La prueba del lado del host envía un APK compuesto por una app o un servicio al el dispositivo.
    2. La prueba del host inicia las pruebas JUnit del dispositivo que se incluyen con el APK hasta el runDeviceTest()
    3. Las pruebas JUnit del dispositivo presionan los botones y observan la app con UIAutomator o acceder de otra manera al sistema Android de formas que revelar las vulnerabilidades de seguridad.
    4. El éxito o fracaso de las pruebas JUnit del dispositivo se devuelve a la prueba del lado del host, que puede usarse para determinar si la prueba fue exitosa o no.

Una combinación de los dos patrones (por ejemplo, ejecución de un programa nativo en en conjunto con pruebas del lado del dispositivo). Otra instrumentación de seguridad, como frida-inject, también están disponibles. Para obtener más información, consulta la Documentos de referencia del paquete de pruebas de seguridad y la 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 tu prueba no usa ejecutable, borra el subdirectorio native-poc y, luego, sincroniza Gradle el proyecto. El proyecto está configurado para omitir automáticamente la compilación de esos módulos cuando 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 segunda app o servicio y escribe del mismo modo que lo harías con cualquier otro APK.

A continuación, 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 resultado. de STS y habilita la instalación o la llamada de la app nueva desde la prueba.

Por último, sincroniza el proyecto con Gradle.

Envía la prueba de STS

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