AutoRepro de seguridad de Android

El complemento AutoRepro de Gradle 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 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 vulnerabilidades y exposiciones comunes (CVE).

El complemento permite el desarrollo de pruebas de Tradefed fuera del árbol de origen 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.

Descarga directa del ejemplo de AutoRepro

Explora el ejemplo y las plantillas 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). 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 usar el administrador de paquetes de tu distribución.
    • Si usas el administrador del SDK de Android Studio en lugar de las herramientas de la plataforma independientes, recuerda agregar el directorio platform-tools del SDK a tu $PATH para el desarrollo de la 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.

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. Hay varias configuraciones de ejecución de Android Studio preconfiguradas.

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 contiene registros del host y del dispositivo. Revisa el contenido antes o después de ejecutarlo.

Configuraciones de ejecución de Android Studio de 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 nonroot porque las vulnerabilidades que requieren root son menos graves. Sin embargo, usar root para realizar la configuración o la limpieza puede ser aceptable siempre que esté claramente documentado y se acepte como un estado nonroot válido. Por ejemplo, es aceptable usar root para simular el envío de mensajes de texto al dispositivo para evitar requerir un segundo dispositivo y varias tarjetas SIM.

Esto iniciará Tradefed para tu prueba. Tradefed espera a que se conecte un dispositivo válido, así que asegúrate de que esté conectado y que la depuración de ADB esté autorizada.

Integración con agentes de codificación

El ejemplo y las plantillas proporcionan un archivo de contexto AGENTS.md compatible con Gemini en Android Studio, Gemini CLI y otros agentes de codificación. Tiene contenido con opiniones sobre la estructuración del envío y las instrucciones para usar AutoRepro. Puedes usarlo para lo siguiente:

  • Ejecutar AutoRepro automáticamente para tu dispositivo
  • Revisar el código de un envío existente para detectar cambios que puedan ayudar a que se acepte tu informe más rápido
  • Ayudar a estructurar una nueva prueba de concepto con la información sobre la vulnerabilidad

Escribe 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"): Es la única prueba de Tradefed del host que interactúa con el dispositivo a través de ADB. El ejemplo lo 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 se inicia con la prueba 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. El ejemplo lo 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 NDK que se envía al dispositivo a través de adb push y se ejecuta con la prueba del host. El ejemplo lo usa en el directorio submission/ndkTest/.

Un flujo de prueba de AutoRepro típico suele seguir uno de los dos patrones siguientes:

  • 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 incluyen en el APK a través de runDeviceTest().
    3. Las pruebas de JUnit 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 fracaso de las pruebas de JUnit del dispositivo se devuelve a la prueba del host, que se puede usar para determinar si la prueba se aprobó o no. El mensaje de falla debe contener información detallada sobre por qué falló la aserción y cualquier objeto, valor, excepción, seguimiento de pila o artefacto específico como prueba de vulnerabilidad.

  • Prueba de concepto de NDK:

    1. La prueba del host envía e inicia 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, observa el seguimiento de pila de logcat o busca el código de salida específico para determinar si el ataque tuvo éxito. El mensaje de falla debe contener información detallada sobre por qué falló la aserción y cualquier estructura, valor, seguimiento 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 están disponibles algunos otros frameworks de instrumentación, como frida-inject. Para obtener más detalles, consulta los documentos de referencia de Security Test Suite y los documentos de referencia de Tradefed.

Estructuración de la probabilidad de la prueba de concepto

Una prueba de concepto de alta calidad debe hacer más que activar un error. Debe proporcionar una prueba verificable de que se cruzó un límite de seguridad. Para lograrlo, las pruebas de concepto pueden seguir un patrón específico de tres pasos de "falla y luego éxito":

  1. Configuración: Prepara el dispositivo instalando las apps necesarias, enviando archivos y asegurándote de que el dispositivo esté en el estado específico requerido inmediatamente antes del exploit. (Se permite el uso de root para la configuración si está justificado y representa un estado realista del usuario final).
  2. Prueba el límite: Antes de activar la vulnerabilidad, intenta la acción de destino y afirma que falla. Por ejemplo, si el exploit permite leer un archivo protegido, primero debes intentar leerlo y confirmar que recibes un error de "Permiso denegado".
  3. Activa y verifica: Activa la vulnerabilidad y, luego, repite inmediatamente la acción del paso 2. En un dispositivo vulnerable, esta acción ahora debería tener éxito. Para verificarlo, debes usar una aserción que falle en un dispositivo vulnerable con un mensaje que comience con el prefijo exacto AUTOREPRO_VULNERABILITY_PROVEN:. Este mensaje debe incluir una descripción concisa de la vulnerabilidad y cualquier artefacto capturado (como datos filtrados o estados inesperados) para demostrar de manera definitiva que el exploit tuvo éxito.

Ejemplo:

@Test
public void testPoc() throws Exception {
    // 1. Setup: Prepare the device.
    setup();

    // 2. Prove the Boundary: Assert the resource is protected BEFORE the exploit.
    // This passes on all devices (safe or vulnerable) before the trigger runs.
    assertDeviceIsSecure();

    // 3. Trigger & Verify: Execute the exploit logic, then immediately repeat
    // the action from Step 2. On a vulnerable device, this action should now
    // succeed, causing assertDeviceIsSecure() to fail with an
    // AUTOREPRO_VULNERABILITY_PROVEN message.
    triggerExploit();
    assertDeviceIsSecure();
}

private void assertDeviceIsSecure() {
    try {
        String content = readProtectedFile();

        // Where possible, put the content in the assertion message.
        // Start the assertion message with "AUTOREPRO_VULNERABILITY_PROVEN:".
        Assert.fail("AUTOREPRO_VULNERABILITY_PROVEN: Successfully read protected file. Content: '" + content + "'");
    } catch (ThisVulnSpecificException e) {
        Log.i(TAG, "protected against reading protected file", e);
    }
}

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 ni un ejecutable nativo.

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

Mi ataque de prueba de concepto incluye 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 la prueba de tu dispositivo como parte del envío, haz lo siguiente:

  • De manera opcional, ejecuta la tarea clean de Gradle para borrar cualquier ejecución de prueba anterior.
  • 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 que se suba con el informe inicial. Si subes los envíos tarde, se verá afectada nuestra capacidad de revisar tu informe de forma adecuada.