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.

Ejemplo de AutoRepro de descarga directa

Explora ejemplos y plantillas 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 21 de Java o una versión posterior: Compatible con el SDK de Android y Gradle.

Nota: Consulta la guía de CTS para obtener más detalles sobre la configuración de ADB y AAPT2.

Precaución: AutoRepro solo admite oficialmente máquinas Linux de 64 bits. Si bien las pruebas escritas con AutoRepro pueden compilarse y ejecutarse en Windows o macOS, también deben ser compatibles con Linux para su envío.

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 archivo 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.

Nota: Ejecutar copyInvocationResultsToSubmission puede ayudar a que se revise tu envío más rápido, ya que proporciona directamente registros y resultados de tu dispositivo y host.

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, así que asegúrate de que haya uno conectado y que la depuración de ADB esté autorizada.

Integración con agentes de programación

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

• Ejecuta AutoRepro automáticamente en tu dispositivo
• Revisa el código de un envío existente para detectar cambios que puedan ayudar a que se acepte tu informe más rápido
• Ayuda a estructurar una nueva PoC a partir de la información sobre la vulnerabilidad

Cómo escribir una prueba de AutoRepro

Nota: Una prueba de AutoRepro falla cuando el dispositivo es vulnerable y se aprueba cuando el dispositivo tiene parches o no es vulnerable por otro motivo. Una de las principales ventajas de este enfoque es que el mensaje de error debe contener información detallada sobre la vulnerabilidad y los artefactos generados por la PoC. La prueba debe devolver un ASSUMPTION_FAILURE (por ejemplo, usando JUnit Assume en lugar de Assert) cuando no pueda determinar si el dispositivo es vulnerable o no.

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 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. 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 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 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 lado del dispositivo). También hay disponibles 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 demostrabilidad de la prueba de concepto

Una PoC de alta calidad debe hacer más que activar un error; debe proporcionar pruebas verificables de que se cruzó un límite de seguridad. Para lograrlo, las PoC pueden seguir un patrón específico de tres pasos de "primero fallar y luego tener éxito":

1. Configuración: Prepara el dispositivo instalando las apps necesarias, transfiriendo archivos y asegurándote de que el dispositivo se encuentre en el estado específico requerido inmediatamente antes del exploit. (Se permite el uso de raíz para la configuración si está justificado y es representativo de un estado realista del usuario final).
2. Demuestra el límite: Antes de activar la vulnerabilidad, intenta realizar la acción objetivo 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 de inmediato la acción del paso 2. En un dispositivo vulnerable, esta acción ahora debería completarse correctamente. Para verificar esto, 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 los artefactos capturados (como datos filtrados o estados inesperados) para demostrar de forma definitiva que el exploit se realizó con é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 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 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 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.