AutoRepro de seguridad de Android

El complemento AutoRepro de Gradle se compila sobre el agente de prueba Android Trade Federation para probar todos los dispositivos Android en busca de parches de seguridad contra vulnerabilidades en el Boletín de seguridad de Android. Estas pruebas son exclusivas para las correcciones que están asociadas o se asociarán con vulnerabilidades y exposiciones comunes (CVE).

El complemento permite desarrollar pruebas de Tradefed fuera del árbol de fuentes de Android con Android Studio o el SDK de Android estándar. Incluye todas las utilidades que se necesitan 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 con 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): Se deben instalar y estar en tu $PATH (es decir, debes poder ejecutar adb desde la línea de comandos). La forma más sencilla de instalar las herramientas de la plataforma es usar el administrador de paquetes de tu distribución.
    • Si usas el administrador de SDK de Android Studio en lugar de herramientas de plataforma independientes, recuerda agregar el directorio platform-tools del SDK a tu $PATH para el desarrollo de línea de comandos.
  • AAPT2. - También se puede instalar con el administrador de paquetes de tu distribución.
  • Java JDK 21 o una versión posterior (compatible con el SDK de Android y Gradle)

Cómo comenzar 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 de origen para el archivo ZIP de envío.
  • assembleSubmissionZip: Ensambla el archivo ZIP de envío para subirlo.
  • copyInvocationResultsToSubmission: Copia los resultados de 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 contiene registros del host y del dispositivo. Revisa el contenido antes o después de ejecutarlo.

Parámetros de configuración 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}. Por lo general, es preferible usar una cuenta no root, ya que las vulnerabilidades que requieren permisos de administrador son menos graves. Sin embargo, el uso de root para realizar la configuración o la limpieza puede ser aceptable, siempre y cuando esté documentado de forma clara y se acepte generalmente como un estado válido que no sea de root. Por ejemplo, es aceptable usar el acceso raíz para enviar mensajes de texto falsos al dispositivo para evitar que se requiera un segundo dispositivo y varias tarjetas SIM.

Se iniciará Tradefed para tu prueba. Tradefed espera a que se conecte un dispositivo válido, así que asegúrate 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 tiene 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"): Es un APK de app o servicio que se instala en el dispositivo a través de adb install y que inicia la prueba del host. La app o el servicio también pueden contener su propio conjunto de aserciones de JUnit que se informa al ejecutor del host. En el ejemplo, se usa en el directorio submission/appTest/.
  3. Complemento de Gradle id("com.android.security.autorepro.ndktest"): Un ataque de prueba de concepto opcional basado en 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/.

Un flujo de prueba de AutoRepro típico suele seguir uno de estos 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 de JUnit del dispositivo que se agrupan con 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 formas que revelan vulnerabilidades de seguridad.
    4. El éxito o el error de las pruebas de JUnit del lado del dispositivo se muestra a la prueba 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 afirmación y cualquier objeto, valor, excepción, seguimiento de pila o cualquier otro artefacto específico como prueba de vulnerabilidad.
  • Prueba de concepto del NDK:

    1. La prueba del host envía y lanza un ejecutable de Linux en el dispositivo.
    2. El programa nativo falla o muestra un código de salida específico.
    3. La prueba del host verifica si hay 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. El mensaje de error debe contener información detallada sobre por qué falló la aserción y cualquier estructura, valor, seguimiento de pila o cualquier otro artefacto específico como prueba de vulnerabilidad.

También es posible combinar 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 frameworks de instrumentación, como frida-inject. Para obtener más información, consulta los documentos de referencia de Security Test Suite 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 para el dispositivo ni un ejecutable nativo.

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

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

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

Envía la prueba de AutoRepro

Para incluir los resultados de las pruebas de tu dispositivo como parte del envío, sigue estos pasos:

  • De manera opcional, ejecuta la tarea clean de Gradle para borrar las ejecuciones de prueba 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 archivo adjunto coincida con el patrón *autorepro-submission*.zip y de que se suba con el informe inicial. Si subes los envíos tarde, afectará nuestra capacidad para revisar tu informe de forma adecuada.