Il modo più semplice per riprodurre la vulnerabilità è usando bcdedit /set debug on sul sistema di destinazione e riavviando la macchina/VM. Questo fa sì che il driver dell'adattatore di rete predefinito diventi kdnic.sys, che è molto propenso a coalescere i pacchetti. Se stai cercando di riprodurre la vulnerabilità su una configurazione diversa, dovrai portare il sistema in una posizione in cui coalesce i pacchetti che hai inviato. Puoi leggere la sezione di risoluzione dei problemi qui sotto per maggiori dettagli.

dimostrazione

cve-2024-38063.webm

rca approssimativa

Puoi leggere questa ottima analisi della vulnerabilità di Marcus se sei interessato ai dettagli tecnici. I dettagli che ho scritto qui sotto hanno lo scopo di servire come riassunto, piuttosto che come analisi tecnica seria.

• In certe situazioni, Windows unisce più pacchetti IP insieme e li elabora in batch. Prima elabora gli header di estensione in ogni pacchetto, e solo dopo passa a elaborare i dati in ogni pacchetto.
• Durante l'elaborazione degli header di estensione, gli oggetti pacchetto di questi pacchetti uniti sono collegati in una lista collegata. Ogni oggetto pacchetto contiene un oggetto NET_BUFFER che contiene i dati del pacchetto bufferizzato. All'offset 0x30 abbiamo anche un campo current-offset che indica quanto è stato analizzato il pacchetto. In questa fase, il valore dell'offset sarà generalmente 0x28, indicando che l'header IPv6 è stato analizzato ma nient'altro.
• Quando si elabora l'header di estensione 'destination options' in tcpip!Ipv6pReceiveDestinationOptions, un errore di parsing causerà la chiamata di tcpip!IppSendErrorList. Questa funzione chiama tcpip!IppSendError su ogni oggetto pacchetto nella lista collegata (partendo da quello corrente).
• Sotto certe condizioni (ad es. se il pacchetto è unicast), tcpip!IppSendError ha effetti collaterali. 'Riporta' i dati del pacchetto bufferizzato all'inizio e resetta il campo current-offset a zero.
• Tuttavia, in tutta questa catena di eventi, solo il primo pacchetto è marcato come avente un errore (offset 0x8C). Ciò significa che il driver continuerà a elaborare gli header di estensione di altri pacchetti nella lista collegata, anche se sono stati 'riportati' in IppSendError.
• L'elaborazione di quei pacchetti che sono stati riportati viene quindi eseguita con dati inaspettati: i dati del pacchetto bufferizzato puntano all'inizio del pacchetto (cioè l'header IPv6) invece che agli header di estensione, e il valore del campo offset è zero invece di 0x28.

strategia

• Per abusare della vulnerabilità, utilizziamo Ipv6pReceiveFragment. La funzione analizza l'header di estensione del frammento e assume che il campo offset del pacchetto sarà almeno 0x28 quando calcola la lunghezza dei dati non-header nel pacchetto sottraendo 0x30 dal valore corrente dell'offset. Questo valore viene poi memorizzato nell'oggetto di riassemblaggio il cui scopo è riassemblare il pacchetto frammentato.
• Nel nostro caso, la funzione verrà chiamata su un pacchetto che è stato riportato da IppSendError. Il valore dell'offset sarà zero e aumentato a 8 da qualche parte prima in Ipv6pReceiveFragment. Quando si calcola la dimensione dei dati non-header, il valore andrà in underflow e sarà uguale a 0xffd8 (la sottrazione è fatta in 16 bit).
• Il valore della lunghezza è utilizzato solo in due punti successivamente:
  • Ipv6pReassembleDatagram, dove viene usato per calcolare la lunghezza di un buffer di output del pacchetto riassemblato. Tuttavia, tutti i calcoli sono fatti in 32 bit e c'è un controllo di integrità che la lunghezza totale non superi 0xFFFF, cosa che in questo caso accade.
  • Ipv6pReassemblyTimeout, dove viene usato allo stesso modo. Tuttavia, i calcoli qui sono fatti in 16 bit e si verifica un overflow di interi. Questo porta a un buffer overflow quando si copiano i dati nel buffer successivamente.

Per innescare Ipv6pReassemblyTimeout, il mittente del frammento deve rimanere inattivo per 1 minuto. La nostra strategia è quindi:

• Inviare opzioni di destinazione malformate per innescare IppSendError, seguite da un pacchetto frammento
• Sperare che i due pacchetti siano coalesciuti e che l'oggetto del secondo pacchetto veda i suoi dati e offset resettati
• Causare l'underflow in Ipv6pReceiveFragment e creare un nuovo oggetto di riassemblaggio con una lunghezza dei dati del frammento che sia un valore alto a 16 bit
• Attendere 1 minuto senza inviare altri pacchetti in modo che Ipv6pReassemblyTimeout venga innescato.
• Causare un overflow di interi nel calcolo della dimensione del buffer in Ipv6pReassemblyTimeout e innescare un heap-based buffer overflow.

I pacchetti nello script sono inviati a raffica in modo che ci sia una maggiore probabilità che vengano coalesciuti. Il payload principale è piuttosto semplice:

• Pacchetto IPv6 con un header di estensione 'destination options' con dati di opzioni malformati che innescheranno un errore di parsing
• Frammento IPv6 #1, che speriamo venga concatenato al primo pacchetto
• Frammento IPv6 #2 (stesso id), che potrebbe anche essere concatenato ai primi due, ma il suo scopo principale è completare il secondo frammento in modo che non vengano generati errori nel caso in cui l'elaborazione normale avvenga

Impostiamo anche manualmente i campi hop limit e flow label nell'header IPv6. Ricordiamo che i dati del pacchetto bufferizzato vengono resettati a causa della vulnerabilità. Ciò significa che, quando si elabora il pacchetto frammento, l'header IPv6 verrà interpretato come dati dell'header del frammento. Il campo hop limit nell'header IPv6 verrà interpretato come uno dei bit del campo id nell'header del frammento. Cambiandolo, ci assicuriamo di innescare la vulnerabilità per diversi frammenti diversi e causare diverse corruzioni, aumentando la probabilità di un crash (dato che questa è una PoC, dopotutto). Il campo flow label dell'header IP verrà interpretato come i campi offset e 'more indicator' dell'header del frammento. Impostandolo a 1, indichiamo che ci sono altri header in arrivo (quindi essere in grado di innescare Ipv6pReassemblyTimeout in seguito) e che l'offset è zero (poiché questo è il primo pacchetto con tale id in arrivo).

note

• Quanto sopra è solo una strategia per sfruttare il problema introdotto dall'innescare la vulnerabilità. Ho usato questa strategia perché era abbastanza semplice e non volevo perdere tempo a esaminare altre possibilità. Non sarei sorpreso se altre persone uscissero con strategie molto migliori presto.
• Cosa richiede la vulnerabilità:
  • Capacità IPv6 sul sistema di destinazione, capacità di ricevere pacchetti (pre-firewall)
  • Capacità di far coalescere i pacchetti inviati dal sistema di destinazione in una certa misura. Alcune coppie adattatore + driver sono molto propense a farlo, mentre altre sembrano più riluttanti. Potrebbero esserci trucchi o catene di pacchetti speciali che si possono usare per far sì che Windows RSC coalesca i pacchetti indipendentemente dall'adattatore o dallo stato della rete, ma non ho prove per questo.
• Cosa non richiede la vulnerabilità:
  • Invio a raffica di pacchetti, la PoC lo fa solo per aumentare la probabilità di coalescenza e innescare più corruzioni come dimostrazione.
  • Situazioni di carico pesante sul sistema di destinazione, poiché la coalescenza potrebbe accadere in molte situazioni diverse.
  • Impostazioni specifiche sul sistema di destinazione, oltre al fatto che IPv6 sia abilitato.
  • (Molto probabilmente) Attendere un minuto per innescare la corruzione, ho usato solo questa strategia di abusare della vulnerabilità perché era la più semplice. C'è una possibilità molto reale che la situazione problematica causata dalla vulnerabilità possa essere sfruttata in modo più diretto.
  • (Molto probabilmente) Pacchetti unicast, li uso perché il percorso del codice che stiamo usando in Ipv6pReassemblyTimeout richiede che il pacchetto frammento originale sia inviato come unicast.

risoluzione dei problemi

Se non funziona, potrebbe essere perché:

• Il sistema di destinazione non è raggiungibile tramite IPv6:
  • Disabilita il firewall di Windows
  • Esegui ping -6 {indirizzo_ipv6} dal PC host
  • Assicurati di ricevere una risposta
  • Riabilita il firewall
• Il sistema di destinazione non riceve pacchetti:
  • Installa Wireshark sul sistema di destinazione e verifica che i pacchetti inviati dallo script arrivino
• scapy segnala "Mac address to reach destination not found. Using broadcast.":
  • Devi trovare l'indirizzo MAC della macchina di destinazione
  • Questo può essere fatto eseguendo il comando ping di cui sopra e controllando la risposta in Wireshark (campo eth source address)
  • Potresti anche usare scapy: Ether(raw(sr1(IPv6(dst={your_dest_ip})/ICMPv6EchoRequest()))).src, ma a volte non funziona
  • Una volta ottenuto l'indirizzo MAC, inseriscilo nel campo mac_addr nello script ed esegui lo script
• I pacchetti non vengono coalesciuti sul sistema di destinazione:
  • A seconda del tuo adattatore di rete/driver, potrebbe essere difficile far coalescere i pacchetti a Windows senza ricorrere a qualcosa come inondare il target simile a un ddos.
  • Puoi provare a modificare le impostazioni del tuo adattatore, ad esempio "Packet Coalescing", "Interrupt Moderation", "Interrupt Moderation Mode", "Recv Segment Coalescing", a seconda di quali sono disponibili. Ad esempio, impostare "Interrupt Moderation Mode" su "Extreme" sul mio server dedicato rende la vulnerabilità riproducibile.
• Se tutto il resto fallisce, puoi collegare un debugger del kernel e controllare alcune cose:
  • tcpip!Ipv6pReceiveDestinationOptions -> tcpip!Ipv6pProcessOptions -> tcpip!IppSendErrorList viene colpito?
  • Metti un breakpoint su tcpip!Ipv6pProcessOptions e controlla se [rcx] è zero per tutto il tempo. Se sì, allora i pacchetti non vengono coalesciuti per qualche motivo.
  • Metti un breakpoint su tcpip!Ipv6pReceiveFragment e controlla se [rcx+0x30] è uguale a zero. Se non lo è, allora la vulnerabilità non è stata innescata per qualche motivo.