
Verifica impropria del nome host nell'applicazione Android EagleEyes Lite
EagleEyes Lite (versione 2.0.0) disabilita la verifica del nome host durante la comunicazione HTTPS utilizzando SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER.
Di conseguenza, l'applicazione accetta certificati TLS indipendentemente dai valori del Common Name (CN) o del Subject Alternative Name (SAN), consentendo a un attaccante di impersonare il server legittimo con qualsiasi certificato valido o autofirmato.
Un avversario posizionato sulla stessa rete può sfruttare questa debolezza per effettuare un attacco MITM, intercettando o alterando la comunicazione sensibile tra l'applicazione e i servizi backend AVTECH.
Quando il dispositivo esegue versioni di Android inferiori a 8.0, quindi SDK_API_26 è impostato su false, il metodo non restituisce GetHttpsUrlResponse().
Invece, esegue la logica vulnerabile all'interno del blocco 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);
...
}
...
}
Qui, l'uso di SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER disabilita la corretta verifica del nome host, il che significa che la connessione TLS riesce anche se il CN (Common Name) o il SAN (Subject Alternative Name) del certificato del server non corrisponde al nome host richiesto.
Di conseguenza, un attaccante può impersonare il server legittimo con un certificato falsificato e lanciare attacchi MITM per intercettare o modificare la comunicazione sensibile.
Eseguendo lo script di hooking Frida hook.js, il valore di SDK_API_26 è stato forzato a false per emulare una versione Android inferiore. Questo ci ha permesso di monitorare se il metodo GetHttpsResponse() veniva invocato.
Di conseguenza, abbiamo confermato che GetHttpsResponse() è stato chiamato con successo durante l'esecuzione.
Per la crittografia insufficiente delle informazioni sensibili nei parametri, fare riferimento a CVE-2025-50110.
L'applicazione dovrebbe rimuovere l'uso di SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER e imporre una verifica rigorosa del nome host per tutte le connessioni HTTPS. I campi Common Name (CN) o Subject Alternative Name (SAN) del server devono essere validati rispetto al nome host richiesto, utilizzando HttpsURLConnection.getDefaultHostnameVerifier() o un verificatore rigoroso equivalente.
Inoltre, qualsiasi logica di fallback legacy che disabilita i controlli del nome host per versioni Android più vecchie dovrebbe essere rimossa o sostituita con implementazioni sicure per garantire una validazione TLS coerente.