AutoRepro de seguridad de Android

El complemento de Gradle de AutoRepro se basa en el agente de prueba de Android Trade Federation para probar todos los dispositivos Android en relación con las pruebas de parches de seguridad contra vulnerabilidades en el Boletín de seguridad de Android. Estas pruebas son exclusivamente para correcciones que están asociadas o se asociarán con una vulnerabilidad y exposición común (CVE).

El complemento permite el desarrollo de pruebas de Tradefed fuera del árbol de fuentes de Android con Android Studio o el SDK de Android estándar. Incluye todas las utilidades necesarias para compilar y ejecutar una prueba de Tradefed.

Se usa principalmente para enviar pruebas de concepto reproducibles automáticamente para el Programa de recompensas por vulnerabilidades de Android.

Descargar ejemplo de AutoRepro

Requisitos previos

Se proporcionan instrucciones para una PC Linux de 64 bits.

  • Android Studio Ladybug o una versión posterior: También se puede instalar desde el administrador de paquetes de tu distribución.
  • Herramientas de la plataforma del SDK de Android (adb, fastboot): Deben estar instaladas y 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 con el administrador de paquetes de tu distribución.
    • Si usas el SDK Manager de Android Studio en lugar de las herramientas de plataforma independientes, recuerda agregar el directorio platform-tools del SDK a tu $PATH para el desarrollo desde la línea de comandos.
  • AAPT2. - También se puede instalar con el administrador de paquetes de tu distribución.
  • JDK de Java 21 o posterior: Compatible con el SDK de Android y Gradle.

Comienza a usar Android Studio

Después de extraer el ejemplo o la plantilla, abre el directorio en Android Studio como un proyecto existente y espera a que se complete la sincronización de Gradle. Existen varias configuraciones de ejecución preconfiguradas de Android Studio.

Tareas de Gradle:

  • assembleSubmissionSources: Ensambla los archivos fuente para el ZIP de envío.
  • assembleSubmissionZip: Ensambla el ZIP de envío para la carga.
  • copyInvocationResultsToSubmission: Copia los resultados de las invocaciones anteriores de Tradefed en el directorio de fuentes de envío de AutoRepro para ayudar con el proceso de revisión. Ten en cuenta que este archivo contiene registros del host y del dispositivo. Revisa el contenido antes o después de ejecutar este comando.

Configuraciones de ejecución de Android Studio para la invocación de AutoRepro:

  • autorepro_nonroot_arm64
  • autorepro_nonroot_x86_64
  • autorepro_root_arm64
  • autorepro_root_x86_64

Las configuraciones del selector tienen el formato autorepro_{device_root}_{device_arch}. En general, es preferible usar nonroot porque las vulnerabilidades que requieren acceso de administrador son menos graves. Sin embargo, usar root para realizar la configuración o la limpieza puede ser aceptable siempre y cuando esté claramente documentado y se acepte generalmente como un estado no root válido. Por ejemplo, es aceptable usar el acceso raíz para simular el envío de mensajes de texto al dispositivo y evitar la necesidad de un segundo dispositivo y varias tarjetas SIM.

Estos comandos iniciarán Tradefed para tu prueba. Tradefed espera a que se conecte un dispositivo válido, por lo que debes asegurarte de que haya uno conectado y que la depuración de ADB esté autorizada.

Cómo escribir una prueba de AutoRepro

Una prueba de AutoRepro consta de tres partes y tres complementos de Gradle correspondientes:

  1. Complemento de Gradle id("com.android.security.autorepro.javahosttest") La única prueba de Tradefed del host que interactúa con el dispositivo a través de ADB. En el ejemplo, se usa en el directorio submission/hostTest/.
  2. Complemento de Gradle id("com.android.security.autorepro.apptest") APK de una app o servicio que se instala en el dispositivo a través de adb install y que inicia la prueba del lado del host. La app o el servicio también pueden contener su propio conjunto de aserciones de JUnit que se informan al ejecutor del host. En el ejemplo, se usa en el directorio submission/appTest/.
  3. Complemento de Gradle id("com.android.security.autorepro.ndktest"): Es un ataque opcional de prueba de concepto basado en el NDK que se envía al dispositivo a través de adb push y que ejecuta la prueba del host. En el ejemplo, se usa en el directorio submission/ndkTest/.

Por lo general, un flujo de prueba de AutoRepro típico sigue uno de los siguientes dos patrones:

  • App de prueba instrumentada:

    1. La prueba del host envía un APK que consta de una app o un servicio instrumentado al dispositivo.
    2. La prueba del host inicia las pruebas JUnit del dispositivo que se incluyen en el APK a través de runDeviceTest().
    3. Las pruebas de JUnit del lado del dispositivo presionan botones y observan la app con UIAutomator, o bien acceden a las APIs de Android de maneras que revelan vulnerabilidades de seguridad.
    4. El éxito o el fracaso de las pruebas de JUnit del lado del dispositivo se devuelven a la prueba del lado del host, que se puede usar para determinar si la prueba se aprobó o no. El mensaje de error debe contener información detallada sobre por qué falló la aserción y cualquier objeto, valor, excepción, registro de pila o artefacto específico como prueba de vulnerabilidad.

  • Prueba de concepto del NDK:

    1. La prueba del host envía e inicia un ejecutable de Linux en el dispositivo.
    2. El programa nativo falla o devuelve un código de salida específico.
    3. La prueba del host verifica si hay fallas, analiza el registro de seguimiento de logcat o busca el código de salida específico para determinar si el ataque tuvo éxito. El mensaje de error debe contener información detallada sobre por qué falló la aserción y cualquier struct, valor, registro de pila o artefacto específico como prueba de vulnerabilidad.

También es posible una combinación de los dos patrones (por ejemplo, la ejecución de un programa nativo junto con pruebas del dispositivo). También hay disponibles otros frameworks de instrumentación, como frida-inject. Para obtener más detalles, consulta los documentos de referencia del conjunto 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 lado del dispositivo y un ejecutable nativo.

Si tu prueba no implica el uso de una función, borra los directorios innecesarios de subproyectos de Gradle.

Mi ataque de prueba de concepto involucra una segunda app o servicio

Agrega tantos subproyectos de Gradle con complementos de AutoRepro como quieras.

Envía la prueba de AutoRepro

Para incluir los resultados de las pruebas de tu dispositivo como parte del envío, haz lo siguiente:

  • De manera opcional, ejecuta la tarea clean de Gradle para borrar las ejecuciones de pruebas anteriores.
  • Ejecuta la configuración de ejecución de AutoRepro adecuada para invocar Tradefed para tu prueba y recopilar registros y resultados.
  • Ejecuta la tarea copyInvocationResultsToSubmission para copiar los registros y los resultados en el directorio de fuentes de envío.

Ejecuta assembleSubmissionZip para crear el archivo submission/build/autorepro-submission.zip. Sube ese archivo junto con tu envío al Programa de recompensas por detección de vulnerabilidades de Android. Asegúrate de que el adjunto coincida con el patrón *autorepro-submission*.zip y de que se haya subido con el informe inicial. Si subes las presentaciones tarde, se verá afectada nuestra capacidad para revisar correctamente tu informe.