Skip to content
KitploitKITPLOIT
StrumentiBlog
Invia
StrumentiBlog
Invia

Strumenti di Hacking, PenTest e Cybersecurity per il tuo Arsenale di Sicurezza!

Kitploit è una directory di strumenti di hacking, cybersecurity e pentesting. Scopri gli ultimi aggiornamenti dei progetti per trovare vulnerabilità, analizzare sistemi, automatizzare i test e rafforzare la tua sicurezza.

··Feed·Contatto·Privacy·© 2026 Kitploit

Directory degli strumenti

Categorie

Vedi tutte le categorie
Loading categories
CVE-2025-46408 — Verifica impropria del nome host nell'applicazione Android EagleEyes Lite | Kitploit
Strumenti/GitHubGitHub/shinycolumn/cve-2025-46408
Sicurezza AndroidAnalisi delle VulnerabilitàExploitPenetration TestingSicurezza MobileApprendimento e Formazione
GitHubshinycolumn/cve-2025-46408

CVE-2025-46408

Verifica impropria del nome host nell'applicazione Android EagleEyes Lite

Vedi Repository
2111 mesi faNon ancora revisionato

Più Popolari

Vedi tutti →

Scopri gli strumenti più utilizzati dalla nostra community.

Esplora tutti gli strumenti

Sfoglia la nostra collezione di strumenti

Vedi tutti gli strumenti →
Condividi

CVE-2025-46408

Verifica del nome host impropria nell'applicazione Android EagleEyes Lite

1. Panoramica


  • Nome: EagleEyes(Lite)
  • Versione: 2.0.0
  • Fornitore: AVTECH
  • CWE: CWE-297: Validazione impropria del certificato con host non corrispondente
  • CVSS: 9.8 CRITICO
  • Stringa vettore: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

2. Riepilogo

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.

3. Dettagli

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.

root@kitploit:~
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.

4. Prova di concetto (PoC)

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.

PoC Per la crittografia insufficiente delle informazioni sensibili nei parametri, fare riferimento a CVE-2025-50110.

5. Raccomandazioni

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.

6. Riferimenti

  • https://www.cve.org/CVERecord?id=CVE-2025-46408
  • https://nvd.nist.gov/vuln/detail/CVE-2025-46408
  • https://github.com/shinyColumn/CVE-2025-50110
  • https://github.com/shinyColumn/CVE-2025-50944
Scarica lo strumento