shinycolumn/cve-2025-46408Verificación incorrecta del nombre de host en la aplicación EagleEyes Lite para Android
EagleEyes Lite (versión 2.0.0) desactiva la verificación del nombre de host durante la comunicación HTTPS mediante el uso de SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER.
Como resultado, la aplicación acepta certificados TLS independientemente de los valores de su Nombre Común (CN) o Nombre Alternativo del Sujeto (SAN), lo que permite a un atacante suplantar al servidor legítimo con cualquier certificado válido o autofirmado.
Un adversario ubicado en la misma red puede explotar esta debilidad para llevar a cabo un ataque MITM, interceptando o alterando la comunicación sensible entre la aplicación y los servicios backend de AVTECH.
Cuando el dispositivo ejecuta versiones de Android anteriores a 8.0, es decir, cuando SDK_API_26 está establecido en false, el método no devuelve GetHttpsUrlResponse().
En su lugar, ejecuta la lógica vulnerable dentro del bloque 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);
...
}
...
}
Aquí, el uso de SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER desactiva la verificación adecuada del nombre de host, lo que significa que la conexión TLS se establece correctamente incluso si el CN (Nombre Común) o el SAN (Nombre Alternativo del Sujeto) del certificado del servidor no coinciden con el nombre de host solicitado.
Como resultado, un atacante puede suplantar al servidor legítimo con un certificado forjado y lanzar ataques MITM para interceptar o modificar la comunicación sensible.
Al ejecutar el script de hooking de Frida hook.js, el valor de SDK_API_26 se estableció forzosamente en false para emular una versión inferior de Android. Esto nos permitió monitorear si el método GetHttpsResponse() era invocado.
Como resultado, confirmamos que GetHttpsResponse() se llamó exitosamente durante la ejecución.
Para el cifrado insuficiente de información sensible en parámetros, consulte CVE-2025-50110.
La aplicación debe eliminar el uso de SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER y aplicar una verificación estricta del nombre de host para todas las conexiones HTTPS. Los campos de Nombre Común (CN) o Nombre Alternativo del Sujeto (SAN) del servidor deben validarse contra el nombre de host solicitado, utilizando HttpsURLConnection.getDefaultHostnameVerifier() o un verificador estricto equivalente.
Además, cualquier lógica heredada de respaldo que desactive las comprobaciones de nombre de host para versiones antiguas de Android debe eliminarse o reemplazarse por implementaciones seguras para garantizar una validación TLS coherente.