🔐 Proof of Concept: Meesho Android App – Unsichere kryptografische Implementierung (AES-CBC ohne Integrität + schwache Schlüsselableitung)

Autor: Soyam Arya (alias honest_corrupt) Datum der Entdeckung: März 2026 Betroffene App: Meesho Android App (com.meesho.supply) Status: In Überprüfung Kategorie: Unzureichende Kryptografie / Fehler bei der Datenintegrität

🎯 Zusammenfassung

Dieser Bericht dokumentiert eine kryptografische Schwachstelle in der Meesho Android-Anwendung, bei der sensible Daten mit AES/CBC/PKCS5Padding ohne Integritätsschutz verschlüsselt werden und der Verschlüsselungsschlüssel mit dem unsicheren MD5-Hashing-Algorithmus abgeleitet wird.

Die Anwendung erstellt verschlüsselte Nutzlasten im Format:

Base64(IV) . Base64(Chiffretext)

Aufgrund des Fehlens einer Authentifizierung (z. B. HMAC oder AEAD-Modus wie AES-GCM) ist die Implementierung jedoch anfällig für:

• Manipulation des Chiffretexts
• Potenzielle Padding-Oracle-Angriffe
• Schwache Schlüsselableitungsangriffe

Dies verstößt gegen mehrere OWASP Mobile Top 10- und MASVS-Kryptografierichtlinien.

📉 Schwachstellenklassifizierung

🛠️ Technische Details

🔍 Verschlüsselungsimplementierung

Die Reverse-Engineering-Analyse ergab die folgende Logik:

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);

❌ Identifizierte Probleme

1. Schwache Schlüsselableitung (MD5)

• MD5 ist veraltet und unsicher
• Kein Salt oder Iterationen verwendet
• Vorhersagbare Schlüsselerzeugung möglich

2. Fehlender Integritätsschutz

• Kein HMAC oder Signatur angewendet
• Chiffretext kann ohne Erkennung modifiziert werden

3. Verwendung des AES-CBC-Modus

• Der CBC-Modus bietet keine Authentizität
• Anfällig für Padding-Oracle-Angriffe, wenn sich Fehlerantworten unterscheiden

🎥 Proof-of-Concept (Konzeptionell)

Die verschlüsselte Nutzlast wird in API-Anfragen wie folgt übertragen:

http POST /api/endpoint

message=Base64(IV).Base64(Chiffretext)

🧪 Manipulationstest

Schritt 1: Anfrage abfangen

Anfrage über Burp Suite abfangen:

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

Schritt 2: Chiffretext modifizieren

Ein einzelnes Byte im Chiffretext ändern:

`` Original: ...KLMNOPQRST...

Modifiziert: ...KLMNOPQRSU... ``

--

Schritt 3: Anfrage erneut senden

Modifizierte Anfrage an den Server senden.

🔥 Beobachtetes Verhalten (Vom Tester auszufüllen)

• Server akzeptiert modifizierten Chiffretext
• Antwort unterscheidet sich (möglicher Padding-Oracle)
• Fehlermeldungs-Leckage
• Datenmanipulation beobachtet

⚠️ Mögliche Auswirkungen

• Verletzung der Datenintegrität: Angreifer können verschlüsselte Nutzlasten verändern
• Unbefugte Aktionen: Manipulation von API-Parametern
• Offenlegung sensibler Daten: Mögliche Entschlüsselung über Oracle-Angriff
• Replay-Angriffe: Keine Anfrageauthentifizierung oder Nonce-Validierung

🧪 Reproduktionsschritte

1. Meesho Android App installieren
2. Burp Suite Proxy konfigurieren
3. API-Anfrage mit dem Parameter message abfangen
4. Chiffretext-Teil modifizieren
5. Anfrage erneut senden und Antwort beobachten

🔐 Empfohlene Korrekturen

• AES-CBC durch AES-GCM oder ChaCha20-Poly1305 ersetzen
• MD5 durch PBKDF2 / Argon2 / bcrypt ersetzen
• HMAC implementieren (Encrypt-then-MAC)
• Integrität vor der Entschlüsselung validieren

🧾 Offenlegungszeitplan

🙋‍♂️ Über den Forscher

Soyam Arya (alias honest_corrupt) CVE-IDs: CVE-2025-5154, CVE-2025-6748 Penetrationstester für Mobile & Web-Anwendungen

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