🔐 Prova de Conceito: Aplicativo Android Meesho – Implementação Criptográfica Insegura (AES-CBC sem Integridade + Derivação de Chave Fraca)

Autor: Soyam Arya (também conhecido como honest_corrupt) Data da Descoberta: Março de 2026 Aplicativo Afetado: Aplicativo Android Meesho (com.meesho.supply) Status: Em Verificação Categoria: Criptografia Insuficiente / Falha de Integridade de Dados

🎯 Resumo

Este relatório documenta uma vulnerabilidade criptográfica no aplicativo Android Meesho, onde dados sensíveis são criptografados usando AES/CBC/PKCS5Padding sem proteção de integridade, e a chave de criptografia é derivada usando o inseguro algoritmo de hash MD5.

O aplicativo constrói payloads criptografados no formato:

Base64(IV) . Base64(texto cifrado)

No entanto, devido à ausência de autenticação (por exemplo, HMAC ou modo AEAD como AES-GCM), a implementação é vulnerável a:

• Adulteração do texto cifrado
• Possíveis ataques de padding oracle
• Ataques de derivação de chave fraca

Isso viola múltiplas diretrizes do OWASP Mobile Top 10 e do MASVS relacionadas à criptografia.

📉 Classificação da Vulnerabilidade

🛠️ Detalhes Técnicos

🔍 Implementação da Criptografia

A engenharia reversa revelou a seguinte lógica:

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

❌ Problemas Identificados

1. Derivação de Chave Fraca (MD5)

• MD5 está obsoleto e é inseguro
• Nenhum salt ou iteração é usado
• Geração de chave previsível é possível

2. Proteção de Integridade Ausente

• Nenhum HMAC ou assinatura é aplicado
• O texto cifrado pode ser modificado sem detecção

3. Uso do Modo AES-CBC

• O modo CBC não fornece autenticidade
• Vulnerável a ataques de padding oracle se as respostas de erro forem diferentes

🎥 Prova-de-Conceito (Conceitual)

O payload criptografado é transmitido em requisições de API como:

http POST /api/endpoint

message=Base64(IV).Base64(texto cifrado)

🧪 Teste de Adulteração

Passo 1: Interceptar Requisição

Capture a requisição via Burp Suite:

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

Passo 2: Modificar o Texto Cifrado

Altere um único byte no texto cifrado:

`` Original: ...KLMNOPQRST...

Modificado: ...KLMNOPQRSU... ``

--

Passo 3: Repetir a Requisição

Envie a requisição modificada ao servidor.

🔥 Comportamento Observado (A ser preenchido pelo testador)

• O servidor aceita o texto cifrado modificado
• A resposta difere (possível padding oracle)
• Vazamento de mensagens de erro
• Manipulação de dados observada

⚠️ Impacto Potencial

• Violação de Integridade de Dados: Atacantes podem alterar payloads criptografados
• Ações Não Autorizadas: Manipulação de parâmetros de API
• Exposição de Dados Sensíveis: Possível descriptografia via ataque de oracle
• Ataques de Repetição (Replay): Sem autenticação de requisição ou validação de nonce

🧪 Passos para Reprodução

1. Instale o aplicativo Android Meesho
2. Configure o proxy do Burp Suite
3. Intercepte a requisição de API contendo o parâmetro message
4. Modifique a parte do texto cifrado
5. Repita a requisição e observe a resposta

🔐 Correções Sugeridas

• Substitua AES-CBC por AES-GCM ou ChaCha20-Poly1305
• Substitua MD5 por PBKDF2 / Argon2 / bcrypt
• Implemente HMAC (Encrypt-then-MAC)
• Valide a integridade antes da descriptografia

🧾 Linha do Tempo da Divulgação

🙋‍♂️ Sobre o Pesquisador

Soyam Arya (também conhecido como honest_corrupt) IDs CVE: CVE-2025-5154, CVE-2025-6748 Testador de Penetração de Aplicativos Móveis e Web

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