🔐 Preuve de concept : Application Android Meesho – Implémentation cryptographique non sécurisée (AES-CBC sans intégrité + dérivation de clé faible)

Auteur : Soyam Arya (alias honest_corrupt) Date de découverte : mars 2026 Application concernée : Application Android Meesho (com.meesho.supply) Statut : En cours de vérification Catégorie : Cryptographie insuffisante / Défaillance de l'intégrité des données

🎯 Résumé

Ce rapport documente une vulnérabilité cryptographique dans l'application Android Meesho où les données sensibles sont chiffrées à l'aide de AES/CBC/PKCS5Padding sans protection d'intégrité, et où la clé de chiffrement est dérivée à l'aide de l'algorithme de hachage MD5 non sécurisé.

L'application construit des charges utiles chiffrées au format :

Base64(IV) . Base64(texte chiffré)

Cependant, en raison de l'absence d'authentification (par exemple, HMAC ou mode AEAD comme AES-GCM), l'implémentation est vulnérable à :

• La falsification du texte chiffré
• D'éventuelles attaques par oracle de padding
• Des attaques de dérivation de clé faible

Cela viole plusieurs directives du OWASP Mobile Top 10 et les recommandations cryptographiques MASVS.

📉 Classification de la vulnérabilité

🛠️ Détails techniques

🔍 Implémentation du chiffrement

L'ingénierie inverse a révélé la logique suivante :

Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding");

byte[] iv = new byte[16];
new SecureRandom().nextBytes(iv);

SecretKeySpec key = new SecretKeySpec(
    MD5(str), "AES"
);

cipher.init(ENCRYPT_MODE, key, new IvParameterSpec(iv));

String message = Base64(iv) + "." + Base64(ciphertext);

❌ Problèmes identifiés

1. Dérivation de clé faible (MD5)

• MD5 est obsolète et non sécurisé
• Aucun sel ni itération utilisé
• Génération de clé prévisible possible

2. Absence de protection de l'intégrité

• Aucun HMAC ni signature appliqué
• Le texte chiffré peut être modifié sans détection

3. Utilisation du mode AES-CBC

• Le mode CBC ne fournit pas d'authenticité
• Vulnérable aux attaques par oracle de padding si les réponses d'erreur diffèrent

🎥 Preuve de concept (conceptuelle)

La charge utile chiffrée est transmise dans les requêtes API comme suit :

http POST /api/endpoint

message=Base64(IV).Base64(texte chiffré)

🧪 Test de falsification

Étape 1 : Intercepter la requête

Capturez la requête via Burp Suite :

` message=AbCdEfGhIj...xyz.KLMNOPQRST... ``

Étape 2 : Modifier le texte chiffré

Modifiez un seul octet dans le texte chiffré :

`` Original : ...KLMNOPQRST...

Modifié : ...KLMNOPQRSU... ``

--

Étape 3 : Rejouer la requête

Envoyez la requête modifiée au serveur.

🔥 Comportement observé (à remplir par le testeur)

• Le serveur accepte le texte chiffré modifié
• La réponse diffère (possible oracle de padding)
• Fuite de messages d'erreur
• Manipulation des données observée

⚠️ Impact potentiel

• Violation de l'intégrité des données : Les attaquants peuvent modifier les charges utiles chiffrées
• Actions non autorisées : Manipulation des paramètres API
• Exposition de données sensibles : Déchiffrement possible via attaque par oracle
• Attaques par rejeu : Aucune authentification de requête ni validation de nonce

🧪 Étapes de reproduction

1. Installez l'application Android Meesho
2. Configurez le proxy Burp Suite
3. Interceptez la requête API contenant le paramètre message
4. Modifiez la partie du texte chiffré
5. Rejouez la requête et observez la réponse

🔐 Corrections suggérées

• Remplacez AES-CBC par AES-GCM ou ChaCha20-Poly1305
• Remplacez MD5 par PBKDF2 / Argon2 / bcrypt
• Implémentez HMAC (Chiffrer puis MAC)
• Validez l'intégrité avant le déchiffrement

🧾 Chronologie de divulgation

🙋‍♂️ À propos du chercheur

Soyam Arya (alias honest_corrupt) Identifiants CVE : CVE-2025-5154, CVE-2025-6748 Testeur d'intrusion mobile et web

• 🌐 Blog : https://soyamaryawork.blogspot.com
• 💻 GitHub : https://github.com/honestcorrupt
• 🔗 LinkedIn : https://www.linkedin.com/in/soyam-arya-a90356312