Analisi riassuntiva
I ricercatori di Akamai hanno creato una nuova funzionalità basata sull'AI per l'analisi immediata della causa della vulnerabilità. Questo strumento è un sistema controllato da più agenti, che viene denominato PatchDiff-AI. In questo blog, questo strumento viene utilizzato per condurre un'analisi approfondita della vulnerabilità CVE-2025-60719, che interessa quasi tutte le versioni di Windows.
La vulnerabilità: una vulnerabilità UAF (Use-After-Free) rilevata in Windows Ancillary Function Driver (afd.sys) per WinSock è stata causata da una race condition
L'impatto: escalation dei privilegi locali; un criminale con privilegi minimi può manipolare la memoria del kernel e ottenere i privilegi di sistema
La causa principale: il driver non è riuscito a impedire che un endpoint socket sia svincolato (libero), mentre altre operazioni (come Transfer, GetInformation o Connect) hanno attivamente interrotto il riferimento agli oggetti associati
La correzione: Microsoft ha aggiunto un meccanismo di barriera della sincronizzazione (AfdPreventUnbind/AfdReallowUnbind) per bloccare esplicitamente lo stato dell'endpoint durante le operazioni critiche
Continuate a leggere per scoprire in che modo lo strumento PatchDiff-AI può essere utilizzato per analizzare rapidamente la causa principale di una vulnerabilità ad alto impatto corretta da una Patch Tuesday e per consentire ai team addetti alla sicurezza di rilevare e mitigare meglio le vulnerabilità one-day.
La vulnerabilità
La CVE-2025-60719 rappresenta un notevole difetto presente nello stack di rete del kernel di Windows, in particolare all'interno di afd.sys, la pietra miliare su cui si basa l'API di Winsock, che, se sfruttata correttamente, consente ad un processo con privilegi minimi di ottenere i privilegi di sistema. Tuttavia, abbiamo testato il nostro exploit in un processo AppContainer e non è riuscito a causa di autorizzazioni insufficienti.
La vulnerabilità interessa molti prodotti di Windows, incluse tutte le seguenti versioni di Windows:
Windows Server: 2008 SP2 (x86/x64), 2008 R2 SP1, 2012, 2012 R2, 2016, 2019, 2022, 2022 23H2, 2025
Windows 11: 23H2, 24H2, 25H2
Windows 10: versioni 1607, 1809, 21H2, 22H2
Altre versioni ritirate dal commercio
L'elevato numero di versioni interessate aumenta notevolmente la superficie di attacco.
Analisi della causa principale
Tramite PatchDiff-AI, possiamo analizzare rapidamente la patch di sicurezza che, in base a quanto consigliato dal fornitore, risolve la vulnerabilità rilevata. La lettura dei risultati dello strumento indica che le modifiche del codice rilevanti riguardano i metodi AfdSocketTransfer*, AfdGetInformation, AfdBind e AfdConnect.
Uno sguardo più approfondito rivela che la causa principale di questa vulnerabilità risiede nella gestione del ciclo di vita della struttura degli endpoint AFD (denominata AFD_ENDPOINT) e nella mancanza di atomicità (sincronizzazione delle operazioni simultanee) tra il recupero di un puntatore oggetto e il suo utilizzo.
Tra una modifica e l'altra
Lo strumento PatchDiff-AI ha evidenziato un componente direttamente correlato alla logica principale della vulnerabilità: Ancillary Function Driver (afd.sys), che implementa il supporto di rete a livello di trasporto di Windows, fornisce l'interfaccia di WinSock, gestisce i socket di rete e altre funzionalità correlate all'I/O.
L'analisi dello strumento si basa sulla versione fissa 10.0.26100.7171, come parte dell'aggiornamento di sicurezza KB5068861, ed è stata testata rispetto alla versione vulnerabile 10.0.26100.6899, che fa parte dell'aggiornamento di sicurezza KB5066835.
Esistono cinque funzioni modificate in totale e sono state tutte classificate dallo strumento come relative alla sicurezza.
Analizzando la funzione AfdGetInformation, è possibile identificare il blocco di codice che è ora protetto bloccando l'operazione di annullamento dell'associazione, che impedisce il rilascio del socket (Figura 1). Poiché sappiamo che questa modifica si riferisce al ciclo di vita del socket e interferisce con il suo stato, possiamo presumere che questa modifica sia correlata ad una vulnerabilità UAF.
Fig. 1: Vista BinDiff della funzione afd!AfdGetInformation patchata accanto alla sua versione precedente
Ancillary Function Driver - Breve introduzione
Sono disponibili articoli completi sul funzionamento di Ancillary Function Driver (afd.sys) e su come utilizzarlo. In breve, si tratta di un componente di Windows responsabile della gestione dell'API di WinSock, che consente ai processi con privilegi minimi di utilizzare lo stack di rete per il protocollo TCP/IP e altri protocolli di comunicazione.
Nella Figura 2 sono presenti molti file binari di riferimento che richiamano afd.sys tramite i controlli di input/output (IOCTL). Inoltre, possiamo capire quale chiamata è correlata a quale interfaccia, collegando i punti tra le chiamate dell'applicazione in modalità utente e l'attivazione logica del modulo kernel, il che ci aiuterà in seguito ad effettuare chiamate dirette al driver ed eseguire il debug del comportamento del driver.
Fig. 2: Diagramma dell’architettura a strati di Winsock (Fonte: https://recon.cx/2015/slides/recon2015-20-steven-vittitoe-Reverse-Engineering-Windows-AFD-sys.pdf)
Nella logica
La vulnerabilità è una classica race condition che conduce ad uno scenario UAF poiché riguarda più routine di gestione, tra cui AfdSocketTransfer*, AfdGetInformation, AfdBind e AfdConnect.
Il problema principale si verifica quando un'applicazione in modalità utente genera una specifica richiesta IOCTL mentre chiude contemporaneamente il socket in un thread separato. Nella versione non corretta da patch, il driver ha recuperato i puntatori sull'endpoint, sull'oggetto file o sull'oggetto dispositivo e li ha utilizzati senza assicurarsi che la memoria sottostante fosse stata liberata dall'operazione di chiusura simultanea. In questo modo, si è creata un intervallo di tempo in cui il kernel ha funzionato su una memoria non valida, consentendo ad un criminale locale di danneggiare la memoria del kernel o di ottenere privilegi elevati.
Quando un processo chiama la funzione afd!AfdGetInformation per una specifica classe di informazioni utilizzando un handle di un socket vincolato (ascolto), comporterà il controllo di alcune condizioni necessarie, come il tipo di socket e il relativo livello di protocollo. Quindi, se seguiamo il flusso di chiamata, possiamo verificare che la funzione sottostante disponga di un switch case per le diverse operazioni che il chiamante può utilizzare.
Il blocco di codice vulnerabile risiede nel case AFD_MAX_PATH_SEND_SIZE (Figura 3). In altre parole, per colpire il percorso vulnerabile è necessario che il chiamante fornisca i valori corretti quando richiama l'interfaccia e che il socket si trovi in uno stato connesso.
class AFD_INFORMATION_CLASS(IntEnum):
AFD_INLINE_MODE = 1 # s: BOOLEAN
AFD_NONBLOCKING_MODE = 2 # s: BOOLEAN
AFD_MAX_SEND_SIZE = 3 # q: ULONG
AFD_SENDS_PENDING = 4 # q: ULONG
AFD_MAX_PATH_SEND_SIZE = 5 # q: ULONG
AFD_RECEIVE_WINDOW_SIZE = 6 # q; s: ULONG
AFD_SEND_WINDOW_SIZE = 7 # q; s: ULONG
AFD_CONNECT_TIME = 8 # q: ULONG (seconds)
AFD_CIRCULAR_QUEUEING = 9 # s: BOOLEAN
AFD_GROUP_ID_AND_TYPE = 10 # q: AFD_GROUP_INFO
AFD_REPORT_PORT_UNREACHABLE = 11 # s: BOOLEAN
AFD_REPORT_NETWORK_UNREACHABLE = 12 # s: BOOLEAN
AFD_DELIVERY_STATUS = 14 # q: SIO_DELIVERY_STATUS
AFD_CANCEL_TL = 15 # s: voidNella Figura 4, si può vedere una versione decompilata del codice vulnerabile (prima) confrontato con il codice corretto con patch (dopo).
Fig. 4: Prima e dopo l’applicazione della patch
La race condition
Il driver afd.sys mantiene il ciclo di vita dell'endpoint ed è possibile accedere all'oggetto Endpoint contemporaneamente da più thread. Nella Figura 5, m_Endpoint->State rappresenta lo stato del socket.
Fig. 5: Limitare condizionatamente l’esecuzione agli stati “bound” e “connected” (riga 171)
Per mantenere il socket in uno stato valido, il modulo kernel deve gestirlo con estrema attenzione. In questo caso, è presente un intervallo di tempo durante il quale è possibile modificare lo stato attraverso un altro thread e liberare completamente l'endpoint utilizzando il comando di controllo unbind.
Un hacker locale può sfruttare questo vantaggio creando una "gara" tra due thread:
Thread A: invia ripetutamente una IOCTL vulnerabile (ad es. IOCTL_AFD_GET_INFORMATION)
Thread B: effettua e annulla ripetutamente l'associazione all'handle del socket
Se il thread B vince la gara dopo che il thread A ha recuperato il puntatore, ma prima che il thread A lo utilizzi, il thread A interromperà il riferimento alla memoria libera.
Imbucarsi ad una festa!
Utilizzando il report PatchDiff-AI e le altre risorse, possiamo capire come utilizzare la funzione afd!AfdGetInformation e richiamarla con gli argomenti corretti per vincere la gara (Figura 6).
Fig. 6: Codice della PoC (Proof-of-Concept) che attiva la vulnerabilità
Nella Figura 7, si vede lo stack di chiamate del crash quando richiama AfdGetInformation al punto in cui è presente un'eccezione PageFault.
Fig. 7: La call stack del flusso che ha causato l’errore
Vettore di attacco
Si tratta di un bug relativo all'escalation dei privilegi locali che interessa solo il sistema locale. Un hacker in grado di eseguire un codice arbitrario da un processo locale con privilegi minimi può sfruttare la race condition e ottenere privilegi più elevati.
Sebbene lo strumento PatchDiff-AI non sia destinato a creare un exploit, può aiutare a comprendere la presunta procedura di exploit.
Inizializzazione: il criminale apre un AfdSocket valido tramite NtCreateFile().
Grooming/spraying: sebbene non sia strettamente necessario per il crash, uno sfruttamento affidabile dell'EoP, spesso, implica lo spraying dell'heap per sostituire l'AFD_ENDPOINT libero con una struttura fittizia che è controllata dal criminale.
Attivazione: il criminale lancia due thread. Il thread 1 esegue un ciclo su NtDeviceIoControlFile con l'IOCTL vulnerabile (ad es. IOCTL_AFD_GET_INFORMATION), mentre il thread 2 esegue un ciclo su IOCTL_AFD_BIND e IOCTL_AFD_UNBIND.
Esecuzione: se vince la gara, il kernel esegue una chiamata (come IoGetRelatedDeviceObject) sull'oggetto fittizio del criminale, determinando una manipolazione della memoria del kernel.
Come proteggere il proprio sistema
Applicazione della patch: l'unica protezione efficace è installare l'appropriato aggiornamento di sicurezza di Windows. La patch rafforza il driver afd.sys annullando rigorosamente l'associazione per creare un ostacolo.
Mitigazione: l'uso di un set di regole SIGMA o YARA per identificare l'interazione con AFD, che potrebbe indicare un tentativo di sfruttamento, può ridurre la minaccia. Nella maggior parte dei casi, può essere sufficiente tracciare i processi che avviano le chiamate IOCTL al driver afd ed eseguire lo spraying della memoria del pool del kernel tramite chiamate ripetute (Figura 8).
Rilevamento: poiché l'endpoint AFD (socket) viene reso visibile, in definitiva, tramite il sottosistema I/O di Windows come handle di file, possiamo intercettare le chiamate IRP e monitorare le attività sospette, in particolare gli endpoint disconnessi.
import "pe"
rule CVE_2025_60719 {
meta:
description = "Detects exploits for CVE-2025-60719 targeting afd.sys"
author = "Maor Dahan"
date = "2025-12-01"
reference = "https://github.com/akamai/CVE-2025-60719-AFD.SYS"
strings:
// Core Indicators - The specific device name is strong indicator
$str_device = "\\Device\\Afd\\Endpoint" ascii wide
$str_device_double = "\\\\Device\\\\Afd\\\\Endpoint" ascii
// Specific IOCTL constants used in the exploit
// 0x12003 = IOCTL_AFD_BIND
$ioctl_str_bind = "0x12003" ascii
$ioctl_hex_bind = { 03 20 01 00 }
// 0x12113 = IOCTL_AFD_UNBIND
$ioctl_str_unbind = "0x12113" ascii
$ioctl_hex_unbind = { 13 21 01 00 }
// 0x1207B = IOCTL_AFD_GET_INFORMATION
$ioctl_str_info = "0x1207B" ascii
$ioctl_hex_info = { 7B 20 01 00 }
condition:
($str_device or $str_device_double) and
(
(
pe.is_pe and
pe.imports("ntdll.dll", "NtDeviceIoControlFile") and
all of ($ioctl_hex_*)
)
or
(
not pe.is_pe and
(
(
all of ($ioctl_str_*) or
3 of ($ioctl_*)
)
)
)
)
}Considerazioni finali
Utilizzando PatchDiff-AI, è possibile automatizzare la correlazione tra modifiche dei file binari e logica di sicurezza in modo da individuare rapidamente la causa principale senza perdersi con modifiche del codice non rilevanti. Ciò consente ai team addetti alla sicurezza di agire rapidamente per prevenire gli exploit one-day.
Il case study relativo alla vulnerabilità CVE-2025-60719 evidenzia la complessità della gestione delle patch nei driver del kernel e come l'analisi dello strumento PatchDiff-AI sia in grado di fornire dettagli approfonditi per vari scopi.
Tag
