abraxas/msquic-compat-vn-key-poisonProof-of-concept e laboratorio che dimostrano un attacco DoS handshake di tipo key-poison con negoziazione di versione compatibile QUIC in MsQuic v2.6.1, con una prova di iniezione UDP e analisi della correzione.
abraxaslabs.tech · github.com/abraxas · @abraxas_null · [email protected] · msquic-compat-vn-key-poison
MsQuic v2.6.1 (a01333cf) - Microsoft
La negoziazione di versione compatibile dovrebbe attendere finché il client non è effettivamente in grado di elaborare un pacchetto della nuova versione. Questo albero esegue il commit della versione e ricrea le chiavi Initial nel momento in cui un long header appare compatibile, per poi proseguire. Il "undo" in caso di fallimento della decifratura ripristina il numero di versione e lascia le chiavi su v2. Un pacchetto di tipo Handshake o troncato non raggiunge nemmeno quel undo.
Un singolo datagramma UDP dalla 4-tupla del server interrompe l'handshake di un client predefinito. Il processo rimane attivo. Nessun RCE.
| ID | nessuna CVE al momento |
| CWE | CWE-345, CWE-347, CWE-670 |
| CVSS | Alto: 7.5 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H |
| Prodotto | MsQuic |
| Affetto | v2.6.1 (a01333cf); ancora su main quando ho verificato |
| Auth | UDP non autenticato, la sorgente deve essere la 4-tupla del server (on-path, oppure IP spoof del server più la porta del client) |
| Licenza | GNU Affero GPL v3.0 |
| Lab | solo 127.0.0.1 |
Durante un handshake QUIC v1, inviare un datagramma long-header con sorgente l'indirizzo e la porta del server. La versione è QUIC v2 (RFC 9369, wire 6b 33 43 cf). DestCidLength è 0. I client predefiniti usano un socket UDP connesso esclusivo, quindi accettano un DCID di lunghezza zero. La libreria lo tratta come negoziazione di versione compatibile prima di AEAD, deriva nuove chiavi Initial, poi o non raggiunge mai il revert in caso di fallimento della decifratura (il tipo Handshake è differito; un Initial troncato restituisce FALSE prima) oppure ripristina Stats.QuicVersion e lascia le chiavi su v2.
Il server reale continua a parlare v1. Il client ritrasmette con i salt v2. Quel tentativo non raggiunge mai Connected. Le altre connessioni sullo stesso processo non sono toccate. Questo è un DoS dell'handshake, non un RCE.
Off-path richiede IP spoof del server più la porta UDP effimera del client. On-path è sufficiente. Il binding esclusivo significa che l'attaccante non ha bisogno del CID.
Ho letto prima l'ondata di GHSA del 2026 su microsoft/msquic: hostname MITM (GHSA-w5f4-fx9m-m4q7, questo tag è il cherry-pick), path-UAF RCE (GHSA-92f5-vc22-8j33), ACK underflow (GHSA-gvvw-8j96-8g5r). Quei sink sono chiusi su v2.6.1.
Poi header dei pacchetti, CID, negoziazione di versione, retry, stateless reset, CIBIR. La VN compatibile RFC 9368 è ciò che resta. QuicConnRecvHeader vede un mismatch di versione, chiede se è compatibile, scrive OriginalQuicVersion, imposta CompatibleVerNegotiationAttempted, assegna Stats.QuicVersion, chiama QuicCryptoOnVersionChange e prosegue. Il commento dice che i parametri di trasporto verificheranno ChosenVersion più tardi. Quei TP non arrivano mai se l'handshake non viene mai decifrato.
Il fallimento della decifratura sembra una correzione finché non lo si legge:
Connection->Stats.QuicVersion = Connection->OriginalQuicVersion;
Connection->State.CompatibleVerNegotiationAttempted = FALSE;
Nessun secondo QuicCryptoOnVersionChange. Le etichette HKDF restano su v2. I pacchetti di tipo Handshake differiscono (HANDSHAKE > ReadKey=INITIAL) e RecvHeader restituisce FALSE, quindi quell'undo non viene mai eseguito.
Non mi è servito src/tools/attack. Sette byte sono sufficienti.
Vicoli ciechi già registrati: iniettare sulla porta di ascolto del server (il client è connesso in modo esclusivo, non lo vedrà); inoltrare l'Initial prima del poison su loopback (l'handshake termina prima, il poison arriva tardi); getchar() come attesa del server di esempio (Docker non è una tastiera); clone shallow con sottomodulo openssl vuoto (l'immagine deve recuperare v2.6.1 e inizializzare openssl); qualsiasi long header spazzatura come prova (un 11223344 non compatibile resta comunque Connected - la parte interessante è la v2 compatibile). Teatro: un payload CRYPTO, una reverse shell, RCE. Il testimone è l'esito dell'handshake.
cd lab
./run.sh
Il proxy UDP 127.0.0.1:18150 è l'indirizzo a cui si connette il client. Il vero server quicsample è 127.0.0.1:18151. Sul primo datagramma del client il PoC invia un Handshake v2 troncato f06b3343cf0000 dal socket del proxy, poi inoltra. Assicurarsi di associarlo al loopback.
control_connected=1
inject_connected=0
negative_connected=1
inject_hex=f06b3343cf0000
SUCCESS MSQUIC-COMPAT-VN-KEY-POISON-WITNESS
CONTROL è solo inoltro e deve risultare Connected. NEGATIVE inietta prima f0112233440000 e deve comunque risultare Connected. INJECT è l'unica fase che muore.
Non chiamare QuicCryptoOnVersionChange finché il pacchetto che lo attiva non viene decifrato. A ogni fallimento dopo un commit (RecvHeader FALSE e fallimento della decifratura) ripristinare la versione e derivare le chiavi di nuovo verso OriginalQuicVersion. Ignorare Handshake / 0-RTT come trigger di VN compatibile. Solo un Initial decifrabile della nuova versione dovrebbe effettuare il cambio.
connection.c · crypto.c · binding.c · version_neg.c