La trappola di fiducia di Windows nascosta dentro un “Trusted Caller”
Un nuovo pattern di attacco mostra come un client legittimo possa diventare la via più breve per operazioni privilegiate dei driver kernel, anche quando non è coinvolta alcuna classica corruzione della memoria.
La sicurezza dei driver Windows spesso presume che la parte pericolosa sia il kernel. La lezione più recente è più inquietante: a volte il punto debole è l'app in modalità utente di cui il driver si fida già. Il pattern noto come Bring Your Own Trusted Caller, o BYOTC, si concentra proprio su quella giunzione. Invece di compromettere un driver con una corruzione della memoria, un attaccante può prendere di mira il client fidato che comunica con esso e poi sfruttare quella fiducia per ottenere operazioni privilegiate.
Questo è importante perché le interfacce dei driver non sono astratte. Spesso vi si accede tramite IOCTL, e tali chiamate possono esporre funzionalità ad alto impatto se l'autorizzazione è troppo permissiva o troppo statica. L'avvertimento tecnico è semplice: un client fidato all'avvio potrebbe non restare affidabile in seguito.
Fatti rapidi
- BYOTC è un pattern di attacco Windows basato sull'abuso di un legittimo chiamante fidato.
- La tecnica viene descritta come un modo per raggiungere operazioni privilegiate dei driver kernel senza una tradizionale vulnerabilità di corruzione della memoria.
- La superficie d'attacco si trova nella relazione tra driver e client, soprattutto dove il software in modalità utente invia richieste IOCTL.
- I driver Windows dovrebbero applicare l'accesso tramite descrittori di sicurezza e ACL sugli oggetti dispositivo.
- Controlli della piattaforma come la blocklist dei driver vulnerabili aiutano a ridurre l'abuso dei driver, ma non sostituiscono una progettazione corretta dell'autorizzazione.
Perché questo pattern è pericoloso
Dal punto di vista difensivo, BYOTC sposta l'attenzione dai meccanismi di exploit ai confini di fiducia. Se un driver kernel accetta comandi sensibili da una particolare applicazione in modalità utente, allora quell'applicazione diventa parte del perimetro di sicurezza. Se viene compromessa o comunque abusata, il driver potrebbe continuare a elaborarne le richieste come se nulla fosse cambiato.
Si tratta di un problema diverso dalla consueta storia del driver difettoso. Potrebbe non esserci alcun payload che provochi un crash, nessun puntatore corrotto e nessun evidente bug di sicurezza della memoria da individuare. Il problema è che il modello di autorizzazione può essere troppo fiducioso per un'interfaccia privilegiata pensata per resistere a condizioni ostili.
Il modello dei driver di Microsoft si basa su controlli espliciti come descrittori di sicurezza degli oggetti dispositivo, ACL e pratiche sicure di creazione dei dispositivi. Questi controlli contano perché il confine del kernel dovrebbe impedire al codice in modalità utente senza privilegi di manomettere il codice e i dati del kernel. BYOTC evidenzia cosa accade quando la logica attorno a quel confine è più debole del confine stesso.
Al momento della scrittura, le informazioni pubbliche non stabiliscono pienamente la logica esatta di validazione del chiamante, il driver specifico coinvolto o se il pattern venga sfruttato ampiamente nel mondo reale. Le informazioni disponibili supportano una valutazione del rischio, non un'affermazione definitiva su portata o prevalenza.
Cosa dovrebbero ricavarne i difensori
La lezione pratica è considerare ogni richiesta privilegiata del driver come una decisione nuova, non come una concessione di fiducia una tantum. L'accesso al dispositivo dovrebbe essere ristretto il più possibile e i percorsi IOCTL sensibili dovrebbero essere progettati assumendo che un client fidato possa essere trasformato in uno strumento d'attacco.
Questo significa verificare se un driver convalida il chiamante nel momento dell'uso, non solo quando l'applicazione apre per la prima volta il dispositivo. Significa anche fare affidamento sulle protezioni della piattaforma quando disponibili, ma senza scambiare le blocklist per un sostituto di una buona progettazione dell'interfaccia.
Conclusione
BYOTC ricorda che l'hardening moderno di Windows non riguarda solo il blocco dei binari malevoli. Riguarda il mettere in discussione le ipotesi all'interno dei canali fidati. Nella sicurezza dei driver, l'attaccante più pericoloso potrebbe non essere quello che forza la serratura - potrebbe essere quello che eredita la chiave.
WIKICROOK
- BYOTC: Bring Your Own Trusted Caller, un pattern di attacco in cui un client legittimo fidato da un driver viene abusato per raggiungere operazioni privilegiate del driver.
- IOCTL: Input/Output Control, un codice di controllo usato dalle applicazioni in modalità utente per richiedere azioni ai driver Windows.
- DeviceIoControl: Un'API Windows che invia richieste IOCTL dalla modalità utente a un driver del dispositivo.
- Descrittore di sicurezza: Una struttura di controllo degli accessi di Windows che definisce chi può accedere a un oggetto dispositivo e con quali diritti.
- ACL: Access Control List, un elenco di regole di accesso che concede o nega diritti a utenti o gruppi.
