Impatto Sistemico

Critico (79.23)

Sintesi

In riferimento al AL05/250617/CSIRT-ITA , al fine di contrastare gli attacchi volti allo sfruttamento della vulnerabilità CVE-2025-5777 (nota anche col nome di “ CitrixBleed 2 ”), questo CSIRT raccomanda a tutti i soggetti nazionali di procedere ad opportune verifiche e all’implementazione delle procedure di mitigazione.

Note : un Proof of Concept (PoC) per lo sfruttamento della vulnerabilità risulta disponibile in rete.

Note : la vulnerabilità risulta essere sfruttata attivamente in rete.

Tipologia

Information Disclosure

Descrizione e potenziali impatti

In riferimento al AL05/250617/CSIRT-ITA , al fine di identificare e contrastare gli attacchi volti allo sfruttamento della vulnerabilità denominata “ CitrixBleed 2 ”, si riportano, nella sezione “Azioni di Mitigazione”, le procedure di mitigazione e verifica raccomandate.

La CVE-2025-5777 – di tipo “Insufficient Input Validation” e con score CVSS v4.0 pari a 9.3 – riguarda dispositivi Citrix NetScaler configurati come Gateway (ad esempio VPN virtual server, ICA Proxy, CVPN, RDP Proxy) oppure come AAA Virtual Server.

Tale vulnerabilità, così denominata per la particolare somiglianza con la CVE-2023-4966 (nota come “ Citrix Bleed ”), risiede in un errore di gestione del buffer nel parser HTTP dei suddetti prodotti.

Nel dettaglio, tramite richieste HTTP di tipo POST opportunamente predisposte, è possibile indurre la componente di NetScaler (o ADC), dedicata all’elaborazione di tali richieste, a leggere e restituire porzioni di dati al di fuori dei limiti previsti, violando così i vincoli di sicurezza della gestione della memoria.

Ciò comporta la divulgazione di informazioni altamente sensibili, tra cui:

• token di sessione attivi (per ICA, RDP e VPN);
• frammenti di chiavi private;
• credenziali o token MFA.

Si evidenzia infine che, anche a seguito dell’applicazione delle patch correttive, le sessioni attive non vengono invalidate automaticamente, ma restano valide fino alla loro naturale scadenza o fino a una revoca manuale da parte degli amministratori.

Prodotti e versioni affette

Citrix NetScaler

• Gateway 14.1, versioni precedenti alla 14.1-43.56
• Gateway 13.1, versioni precedenti alla 13.1-58.32
• ADC 14.1, versioni precedenti alla 14.1-43.56
• ADC 13.1, versioni precedenti alla 13.1-58.32
• ADC 13.1-FIPS, versioni precedenti alla 13.1-37.235-FIPS
• ADC 13.1-NDcPP, versioni precedenti alla 13.1-37.235-NDcPP
• ADC 12.1-FIPS, versioni precedenti alla 12.1-55.328-FIPS

Azioni di mitigazione

In linea con le indicazioni del vendor, si raccomanda di aggiornare tempestivamente i prodotti e di adottare le misure di mitigazione aggiuntive riportate da Citrix, seguendo le istruzioni disponibili al link riportato nella sezione Riferimenti.

In particolare:

• terminare forzatamente sessioni attive post-patch, su tutti i nodi in HA/cluster, tramite i comandi:
• kill icaconnection –all
• kill pcoipConnection -all
• rimuovere la funzionalità di pre-riempimento del campo username tramite ${http.req.user.name} per l’elemento <InitialValue> a seguito di un accesso fallito da parte dell’utente. Per maggiori informazioni consultare la guida ufficiale .

Azioni di rilevamento

Per evidenziare eventuali indicatori di possibili exploit o scanning, verificare nei log HTTP (web server, reverse proxy o NetScaler stesso) o nei sistemi di logging di sicurezza (SIEM, FPC, ecc…) richieste POST configurate come segue:

• Content-Length ≤ 6;
• Target URI:
• /p/u/doAuthentication.do;
• /nf/auth/doAuthentication.do;
• o similari (anche con parametri).

Al fine di rilevare eventuale traffico malevolo, ove gli indicatori elencati precedentemente non fossero disponibili, di seguito si propone un esempio di regole di logging che consentono l’inoltro al log collector di potenziali evidenze sospette al fine di condurre le opportune analisi.

1. Creare un Audit Message Action , (guida ufficiale al link ) con i parametri:

<logLevel>

ALERT

<stringBuilderExpr>

"LOG_ACT1 client_ip=\"" + CLIENT.IP.SRC+"\" hostname=\""+HTTP.REQ.HOSTNAME+" url=\""+HTTP.REQ.URL+"\" Content_Length=\""+ HTTP.REQ.HEADER("Content-Length")+"\""

2. Creare la relativa Responder Policy (guida al link ) con i parametri:

< action>

NOOP

<expression>

HTTP.REQ.URL.ENDS_WITH(".do") && HTTP.REQ.BODY(10).TO_LOWER.EQ("login")

3. Abilitare quanto descritto effettuando il binding della Responder Policy, seguendo le indicazioni della guida ufficiale .