Questo è il percorso alternativo nel senso della CWE-288. Stessa superficie di richiesta, invocazione del parser più debole, raggiungibile da chiunque possa inviare una GET con un parametro di query SAMLResponse.

2. il gate per le assertion non firmate tratta la configurazione predefinita come ALLOW.

All'interno del gestore di redirect, quando la richiesta non trasporta SigAlg/Signature, la parola di configurazione per rejectUnsignedAssertion viene confrontata e diramata così:

I valori della parola sono: 2 = rejectUnsignedAssertion ON (il predefinito), 3 = STRICT. Il je invia 2 ad accept. Solo STRICT raggiunge la riga di log di deny:

Quindi su un sistema con configurazione predefinita, un'assertion non firmata consegnata al binding di redirect viene analizzata (strict off), accettata oltre il gate per le non firmate (ON interpretato erroneamente come allow), e poi esegue i normali passaggi post-analisi: controlli di issuer/audience/subject rispetto alla configurazione dell'azione SAML, quindi costruzione della sessione da campi forniti dall'attaccante. Nessun digest, nessuna verifica RSA, in nessun punto di quella rotta. Il binding POST non è influenzato allo stesso modo — passa strict al parser e rifiuta correttamente l'input non firmato.

Prerequisiti secondo il bollettino, confermati contro il binario: le build dalla 14.1-43.56 / 13.1-61.28 in poi richiedono un'azione SAML associata a un vserver Gateway o AAA (la normale configurazione SAML SSO, quindi la maggior parte delle implementazioni SAML è idonea). Le build precedenti registrano la rotta con il solo vserver.

forma dell'exploit

Una GET. Costruisci una risposta SAML senza alcun <ds:Signature>, applica DEFLATE + base64 e invia:

I valori che devono corrispondere alla configurazione dell'azione SAML del target: Issuer dell'assertion = l'ID entità IdP, Audience = l'ID entità SP, Recipient/Destination = l'URL ACS, e su configurazioni transazionali un InResponseTo da una AuthnRequest attiva. --mint esamina il redirect di login pre-autenticazione del gateway stesso per catturarli (la SAMLRequest nell'header Location li trasporta tutti). Un 302 verso /vpn/ più un cookie NSC_AAAC / NSC_TASS reale (non i marcatori di eliminazione xyz) è una sessione falsificata come qualsiasi NameID tu inserisca.

utilizzo

--safe-oracle esiste perché le due configurazioni restituiscono pagine di errore diverse prima che accada qualsiasi cosa simile a una sessione, il che è anche il modo in cui i difensori possono auto-verificarsi senza toccare un IdP reale. Eseguilo contro la tua attrezzatura.

demo

demo/demo.gif (anche demo.mp4, e demo/demo.cast se vuoi riprodurlo con asciinema play): build interessata dall'immagine docker, la configurazione predefinita word-2, i due rami binari disassemblati dal nsppe fornito, e il controllo dell'endpoint del PoC. L'ultimo miglio, l'emissione della sessione, richiede un VPX con licenza — CPX Express rifiuta le sessioni AAA a livello di licenza — che è ciò che lab/record-demo.sh cattura quando ne hai uno.

laboratorio

lab/setup-cpx.sh avvia l'esatta build interessata in docker:

e configura un'azione SAML con rejectUnsignedAssertion ON, una policy e un vserver Gateway. Due avvertenze imparate a proprie spese:

• CPX Express non include una licenza utente SSLVPN/AAA. Il vserver serve /cgi/samlauth ma ogni richiesta finisce su 480 Login exceeds maximum allowed users. Abbastanza buono per riprodurre configurazione + endpoint + stato binario, non il cookie di sessione finale.
• Per l'esecuzione completa dell'emissione di sessione ti serve un VPX con la licenza gratuita Developer Edition (My Citrix → download → NetScaler VPX, poi CTX587663 per il flusso di licenza). Stessa CLI dello script di setup, poi lab/record-demo.sh registra l'intera sequenza asciinema: versione, configurazione, safe-oracle, sessione falsificata, controllo negativo STRICT.

Gli offset del binario fornito sopra provengono direttamente da quell'immagine:

rilevamento / mitigazione

• Aggiorna a 14.1-73.32+ / 13.1-63.21+. Non esiste una soluzione alternativa supportata.
• set samlAction <name> -samlRejectUnsignedAssertion STRICT blocca il vettore di redirect sul percorso vulnerabile (fa diventare word==3). Tieni presente che STRICT cambia anche ciò che il sistema si aspetta dal tuo IdP (requisiti di firma di Response + Assertion), che è presumibilmente il motivo per cui Citrix fornisce ON come predefinito e perché "basta impostare STRICT" non è una soluzione alternativa pulita per tutti.
• Rilevamento: richieste a /cgi/samlauth che trasportano SAMLResponse su GET (le risposte del binding di redirect sono rare in natura — i browser fanno POST), payload non firmati e il differenziale delle pagine di errore sopra descritto.

legale

Solo per test di sicurezza autorizzati: il tuo laboratorio, o target esplicitamente in scope per un programma su cui sei autorizzato. L'autore non è affiliato a Citrix né al team di segnalazione originale.

cronologia

• 2026-08-19 — bollettino Citrix CTX696939, correzioni distribuite
• 2026-09 — questo writeup sulla causa principale e il PoC

Licenza MIT, vedi LICENSE.