Analyse de l'application React Native

Reading time: 11 minutes

Pour confirmer si l'application a été construite sur le framework React Native, suivez ces étapes :

1. Renommez le fichier APK avec une extension zip et extrayez-le dans un nouveau dossier en utilisant la commande cp com.example.apk example-apk.zip et unzip -qq example-apk.zip -d ReactNative.

2. Naviguez vers le dossier ReactNative nouvellement créé et localisez le dossier assets. À l'intérieur de ce dossier, vous devriez trouver le fichier index.android.bundle, qui contient le JavaScript React dans un format minifié.

3. Utilisez la commande find . -print | grep -i ".bundle$" pour rechercher le fichier JavaScript.

Note : Si vous recevez un Android App Bundle (.aab) au lieu d'un APK, générez d'abord un APK universel, puis extrayez le bundle :

# Get bundletool.jar and generate a universal APK set
java -jar bundletool.jar build-apks \
--bundle=app-release.aab \
--output=app.apks \
--mode=universal \
--overwrite

# Extract the APK and then unzip it to find assets/index.android.bundle
unzip -p app.apks universal.apk > universal.apk
unzip -qq universal.apk -d ReactNative
ls ReactNative/assets/

Javascript Code

Si vous vérifiez le contenu du index.android.bundle, vous trouverez le code JavaScript de l'application (même s'il est minifié), vous pouvez l'analyser pour trouver des informations sensibles et des vulnérabilités.

Comme le bundle contient en réalité tout le code JS de l'application, il est possible de le diviser en différents fichiers (ce qui facilite potentiellement son ingénierie inverse) en utilisant l'outil react-native-decompiler.

Webpack

Pour analyser davantage le code JavaScript, vous pouvez télécharger le fichier sur https://spaceraccoon.github.io/webpack-exploder/ ou suivre ces étapes :

1. Créez un fichier nommé index.html dans le même répertoire avec le code suivant :

<script src="./index.android.bundle"></script>

2. Ouvrez le fichier index.html dans Google Chrome.

3. Ouvrez la barre d'outils de développement en appuyant sur Command+Option+J pour OS X ou Control+Shift+J pour Windows.

4. Cliquez sur "Sources" dans la barre d'outils de développement. Vous devriez voir un fichier JavaScript qui est divisé en dossiers et fichiers, constituant le bundle principal.

Si vous trouvez un fichier appelé index.android.bundle.map, vous pourrez analyser le code source dans un format non minifié. Les fichiers de carte contiennent un mappage source, ce qui vous permet de mapper des identifiants minifiés.

Pour rechercher des informations d'identification sensibles et des points de terminaison, suivez ces étapes :

1. Identifiez des mots-clés sensibles pour analyser le code JavaScript. Les applications React Native utilisent souvent des services tiers comme Firebase, des points de terminaison de service AWS S3, des clés privées, etc.

2. Dans ce cas spécifique, l'application a été observée en train d'utiliser le service Dialogflow. Recherchez un motif lié à sa configuration.

3. Il a été chanceux que des informations d'identification sensibles codées en dur aient été trouvées dans le code JavaScript lors du processus de reconnaissance.

Chasse rapide aux secrets/points de terminaison dans les bundles

Ces simples greps font souvent ressortir des indicateurs intéressants même dans le JS minifié :

# Common backends and crash reporters
strings -n 6 index.android.bundle | grep -Ei "(api\.|graphql|/v1/|/v2/|socket|wss://|sentry\.io|bugsnag|appcenter|codepush|firebaseio\.com|amplify|aws)"

# Firebase / Google keys (heuristics)
strings -n 6 index.android.bundle | grep -Ei "(AIza[0-9A-Za-z_-]{35}|AIzaSy[0-9A-Za-z_-]{33})"

# AWS access key id heuristic
strings -n 6 index.android.bundle | grep -E "AKIA[0-9A-Z]{16}"

# Expo/CodePush deployment keys
strings -n 6 index.android.bundle | grep -Ei "(CodePush|codepush:\\/\\/|DeploymentKey)"

# Sentry DSN
strings -n 6 index.android.bundle | grep -Ei "(Sentry\.init|dsn\s*:)"

Si vous soupçonnez des frameworks de mise à jour Over-The-Air, recherchez également :

• Microsoft App Center / clés de déploiement CodePush
• Configuration des mises à jour Expo EAS (expo-updates, expo\.io, certificats de signature)

Modifier le code JS et reconstruire

Dans ce cas, modifier le code est facile. Il vous suffit de renommer l'application pour utiliser l'extension .zip et de l'extraire. Ensuite, vous pouvez modifier le code JS à l'intérieur de ce bundle et reconstruire l'application. Cela devrait suffire pour vous permettre de injecter du code dans l'application à des fins de test.

Bytecode Hermes

Si le bundle contient du bytecode Hermes, vous ne pourrez pas accéder au code Javascript de l'application (même pas à la version minifiée).

Vous pouvez vérifier si le bundle contient du bytecode Hermes en exécutant la commande suivante :

file index.android.bundle
index.android.bundle: Hermes JavaScript bytecode, version 96

Cependant, vous pouvez utiliser les outils hbctool, des forks mis à jour de hbctool qui prennent en charge les versions de bytecode plus récentes, hasmer, hermes_rs (bibliothèque/APIs Rust), ou hermes-dec pour désassembler le bytecode et aussi pour le décompiler en un certain code JS pseudo. Par exemple :

# Disassemble and re-assemble with hbctool (works only for supported HBC versions)
hbctool disasm ./index.android.bundle ./hasm_out
# ...edit ./hasm_out/**/*.hasm (e.g., change comparisons, constants, feature flags)...
hbctool asm   ./hasm_out ./index.android.bundle

# Using hasmer (focus on disassembly; assembler/decompiler are WIP)
hasmer disasm ./index.android.bundle -o hasm_out

# Using hermes-dec to produce pseudo-JS
hbc-disassembler ./index.android.bundle /tmp/my_output_file.hasm
hbc-decompiler   ./index.android.bundle /tmp/my_output_file.js

Astuce : Le projet open-source Hermes propose également des outils de développement tels que hbcdump dans des versions spécifiques de Hermes. Si vous construisez la version correspondante de Hermes utilisée pour produire le bundle, hbcdump peut extraire des fonctions, des tables de chaînes et du bytecode pour une analyse plus approfondie.

Modifier le code et reconstruire (Hermes)

Idéalement, vous devriez être en mesure de modifier le code désassemblé (changer une comparaison, ou une valeur ou tout ce que vous devez modifier) puis reconstruire le bytecode et reconstruire l'application.

• L'original hbctool prend en charge le désassemblage du bundle et sa reconstruction après modifications, mais a historiquement pris en charge uniquement les anciennes versions de bytecode. Des forks maintenus par la communauté étendent le support aux nouvelles versions de Hermes (y compris les versions intermédiaires 80–96) et sont souvent l'option la plus pratique pour patcher les applications RN modernes.
• L'outil hermes-dec ne prend pas en charge la reconstruction du bytecode (décompilateur/désassembleur uniquement), mais il est très utile pour naviguer dans la logique et extraire des chaînes.
• L'outil hasmer vise à prendre en charge à la fois le désassemblage et l'assemblage pour plusieurs versions de Hermes ; l'assemblage est encore en maturation mais vaut la peine d'être essayé sur du bytecode récent.

Un flux de travail minimal avec des assembleurs similaires à hbctool :

# 1) Disassemble to HASM directories
hbctool disasm assets/index.android.bundle ./hasm

# 2) Edit a guard or feature flag (example: force boolean true)
#    In the relevant .hasm, replace a LoadConstUInt8 0 with 1
#    or change a conditional jump target to bypass a check.

# 3) Reassemble into a new bundle
hbctool asm ./hasm assets/index.android.bundle

# 4) Repack the APK and resign
zip -r ../patched.apk *
# Align/sign as usual (see Android signing section in HackTricks)

Notez que le format de bytecode Hermes est versionné et l'assembleur doit correspondre exactement au format sur disque. Si vous obtenez des erreurs de format, passez à un fork/alternative mis à jour ou reconstruisez les outils Hermes correspondants.

Analyse Dynamique

Vous pourriez essayer d'analyser dynamiquement l'application en utilisant Frida pour activer le mode développeur de l'application React et utiliser react-native-debugger pour s'y attacher. Cependant, pour cela, vous avez apparemment besoin du code source de l'application. Vous pouvez trouver plus d'informations à ce sujet dans https://newsroom.bedefended.com/hooking-react-native-applications-with-frida/.

Activation du Support Dev en version release avec Frida (précautions)

Certaines applications expédient accidentellement des classes qui rendent le Support Dev activable. Si présent, vous pouvez essayer de forcer getUseDeveloperSupport() à retourner true :

// frida -U -f com.target.app -l enable-dev.js
Java.perform(function(){
try {
var Host = Java.use('com.facebook.react.ReactNativeHost');
Host.getUseDeveloperSupport.implementation = function(){
return true; // force dev support
};
console.log('[+] Patched ReactNativeHost.getUseDeveloperSupport');
} catch (e) {
console.log('[-] Could not patch: ' + e);
}
});

Avertissement : Dans les versions de production correctement construites, DevSupportManagerImpl et les classes de débogage associées sont supprimées et activer ce drapeau peut faire planter l'application ou n'avoir aucun effet. Lorsque cela fonctionne, vous pouvez généralement exposer le menu de développement et attacher des débogueurs/inspecteurs.

Interception réseau dans les applications RN

React Native Android s'appuie généralement sur OkHttp en arrière-plan (via le module natif Networking). Pour intercepter/observer le trafic sur un appareil non rooté lors de tests dynamiques :

• Utilisez un proxy système + faites confiance au CA utilisateur ou utilisez d'autres techniques génériques de contournement TLS Android.
• Astuce spécifique à RN : si l'application inclut Flipper en production par erreur (outils de débogage), le plugin réseau Flipper peut exposer les requêtes/réponses.

Pour des techniques génériques d'interception Android et de contournement de pin, référez-vous à :

Make APK Accept CA Certificate

Objection Tutorial

Problèmes récents dans les bibliothèques RN populaires (quoi surveiller)

Lors de l'audit des modules tiers visibles dans le bundle JS ou les bibliothèques natives, vérifiez les vulnérabilités connues et vérifiez les versions dans package.json/yarn.lock.

• react-native-mmkv (Android) : les versions antérieures à 2.11.0 enregistraient la clé de chiffrement optionnelle dans les journaux Android. Si ADB/logcat est disponible, des secrets pourraient être récupérés. Assurez-vous d'avoir >= 2.11.0. Indicateurs : utilisation de react-native-mmkv, déclarations de journal mentionnant l'initialisation de MMKV avec chiffrement. CVE-2024-21668.
• react-native-document-picker : les versions < 9.1.1 étaient vulnérables à la traversée de chemin sur Android (sélection de fichiers), corrigé dans 9.1.1. Validez les entrées et la version de la bibliothèque.

Vérifications rapides :

grep -R "react-native-mmkv" -n {index.android.bundle,*.map} 2>/dev/null || true
grep -R "react-native-document-picker" -n {index.android.bundle,*.map} 2>/dev/null || true
# If you also have the node_modules (rare on release): grep -R in package.json / yarn.lock

Références

• https://medium.com/bugbountywriteup/lets-know-how-i-have-explored-the-buried-secrets-in-react-native-application-6236728198f7
• https://www.assetnote.io/resources/research/expanding-the-attack-surface-react-native-android-applications
• https://payatu.com/wp-content/uploads/2023/02/Mastering-React-Native-Application-Pentesting-A-Practical-Guide-2.pdf
• CVE-2024-21668 : react-native-mmkv enregistre la clé de chiffrement des journaux sur Android, corrigé dans v2.11.0 (NVD) : https://nvd.nist.gov/vuln/detail/CVE-2024-21668
• hbctool (et forks) pour assembler/désassembler Hermes : https://github.com/bongtrop/hbctool