shinycolumn/cve-2025-46408Verificação inadequada de nome de host no aplicativo Android EagleEyes Lite
O EagleEyes Lite (versão 2.0.0) desativa a verificação de nome de host durante a comunicação HTTPS ao usar SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER.
Como resultado, o aplicativo aceita certificados TLS independentemente dos valores de Common Name (CN) ou Subject Alternative Name (SAN), o que permite que um invasor se passe pelo servidor legítimo com qualquer certificado válido ou autoassinado.
Um adversário posicionado na mesma rede pode explorar essa fraqueza para realizar um ataque MITM, interceptando ou alterando a comunicação sensível entre o aplicativo e os serviços de backend da AVTECH.
Quando o dispositivo executa versões do Android anteriores à 8.0, ou seja, SDK_API_26 está definido como false, o método não retorna GetHttpsUrlResponse().
Em vez disso, executa a lógica vulnerável dentro do bloco try.
public static String GetHttpsResponse(String str) {
if (SDK_API_26) {
return GetHttpsUrlResponse(str);
}
try {
...
X509HostnameVerifier x509HostnameVerifier = SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER;
SSLSocketFactory socketFactory = SSLSocketFactory.getSocketFactory();
socketFactory.setHostnameVerifier(x509HostnameVerifier);
...
}
...
}
Aqui, o uso de SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER desativa a verificação adequada do nome de host, o que significa que a conexão TLS é bem-sucedida mesmo que o CN (Common Name) ou SAN (Subject Alternative Name) do certificado do servidor não corresponda ao nome de host solicitado.
Como resultado, um invasor pode se passar pelo servidor legítimo com um certificado falsificado e lançar ataques MITM para interceptar ou modificar a comunicação sensível.
Ao executar o script de hooking Frida hook.js, o valor de SDK_API_26 foi forçado para false para emular uma versão inferior do Android. Isso nos permitiu monitorar se o método GetHttpsResponse() foi invocado.
Como resultado, confirmamos que GetHttpsResponse() foi chamado com sucesso durante a execução.
Para informações sobre criptografia insuficiente de dados sensíveis em parâmetros, consulte CVE-2025-50110.
O aplicativo deve remover o uso de SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER e impor verificação rigorosa do nome de host para todas as conexões HTTPS. Os campos Common Name (CN) ou Subject Alternative Name (SAN) do servidor devem ser validados em relação ao nome de host solicitado, usando HttpsURLConnection.getDefaultHostnameVerifier() ou um verificador rigoroso equivalente.
Além disso, qualquer lógica de fallback legada que desative a verificação do nome de host para versões antigas do Android deve ser removida ou substituída por implementações seguras para garantir validação TLS consistente.