Aggiornamento cumulativo di febbraio 2025 KB5051989: nuova vulnerabilità che consente di bypassare AppLocker in Windows 11 23H2 kiosk
Se gestisci chioschi multi‑app su Windows 11 23H2, l’aggiornamento KB5051989 può aprire una falla critica: rinominando un eseguibile vietato in msedge.exe l’esecuzione non viene più bloccata da AppLocker. In questa guida analizziamo il problema e le contromisure operative.
Panoramica della regressione
La cumulative update KB5051989 (Patch Tuesday di febbraio 2025) introduce un cambiamento nella logica di controllo eseguibile/nome applicazione di AppLocker. Prima dell’aggiornamento, anche se un binario non firmato e vietato — ad esempio cmd.exe copiato in una cartella utente — veniva rinominato in msedge.exe, il motore continuava a identificarlo come non consentito e ne impediva l’avvio.
Dopo l’installazione della CU, la stessa operazione aggira il filtro: AppLocker si limita a confrontare il nome del file (che combacia con una regola “Publisher & Path Allow” per Microsoft Edge) senza verificare ulteriori attributi. Il comportamento è confermato su installazioni fresh da ISO con la patch già inclusa, il che evidenzia una regressione di codice e non un side‑effect di upgrade in‑place.
Implicazioni di sicurezza
- Elevazione di privilegi locale: gli utenti di un chiosco possono lanciare prompt dei comandi, PowerShell o qualsiasi altro payload binario rinominandolo opportunamente.
- Riduzione della postura difensiva: tutta la struttura di difesa in profondità fornita da AppLocker decade; l’attaccante guadagna accesso a strumenti che possono scaricare o eseguire codice addizionale.
- Compliance e normativa: ambienti retail, self‑service banking o education che basano l’hardening sulle regole AppLocker violano potenzialmente requisiti PCI‑DSS o ISO 27001.
Ambiente interessato
- Windows 11 23H2 — build 22631.4890
- Mondo multi‑app kiosk configurato via CSP o Provisioning Package
- AppLocker attivato con modalità di enforcement su regole Publisher e/o Path
Conferma del bug: procedura passo‑passo
- Avvia la sessione kiosk o accedi con l’utente dedicato.
- Copia
C:\Windows\System32\cmd.exein%USERPROFILE%\Downloads\. - Rinomina il file in
msedge.exe. - Fai doppio clic sul nuovo eseguibile.
Risultato atteso: AppLocker blocca l’esecuzione.
Risultato osservato: il prompt dei comandi si avvia normalmente.
Il test è stato ripetuto con powershell.exe, regedit.exe e binari personalizzati non firmati, ottenendo lo stesso outcome.
Timeline della segnalazione
- Giorno 0 – Scoperta del comportamento anomalo e apertura discussione su forum specialistico.
- T+2 h – Community support Microsoft replica e inoltra il feedback via Feedback Hub ai team interni.
- T+1 g – Creata issue dedicata su Microsoft Learn (Windows / Kiosk & AppLocker) per maggiore visibilità.
- T+3 g – Confermata la riproducibilità su ISO 23H2 slipstreamed con CU di febbraio.
Azioni consigliate
Finché non sarà disponibile una patch correttiva dagli sviluppatori Windows, si consiglia la seguente strategia di mitigazione multilivello.
| Passo | Obiettivo | Dettagli operativi |
|---|---|---|
| Isolamento temporaneo | Ridurre la superficie d’attacco | Disinstallare la CU KB5051989 dagli endpoint sensibili o sospenderne il roll‑out mediante WSUS/Intune. |
| Segnalazione ufficiale | Accelerare il fix | Oltre al Feedback Hub, aprire un ticket MSRC se si ritiene la falla di sicurezza; allegare PoC, registri AppLocker e firma del file renominato. |
| Misure di contenimento | Difesa in profondità | Convertire le regole AppLocker da “Publisher/Path” a Hash dove operativamente sostenibile. Valutare il passaggio a Windows Defender Application Control (WDAC), che non presenta il bug. Irrigidire ACL NTFS sui percorsi utente (Downloads, Desktop) per impedire la copia di eseguibili. |
| Monitoraggio & testing | Verificare la correzione | Allestire un ambiente di staging con snapshot pre‑ e post‑CU; scrivere script di regression test che tentano il bypass ad ogni nuova build Insider Release Preview. |
Approfondimento tecnico: perché la regola viene ignorata?
Analisi preliminare dei log ETW indica che il modulo AppXSvc ridotto nelle ultime revisioni di Windows 11 effettua un controllo semplificato sul campo OriginalFileName del PE. Poiché il binario rinominato non possiede metadata validi (o è vuoto), il servizio ricade sul valore del filename, che — nello scenario test — coincide con msedge.exe. La normalizzazione CRC/SHA del file, che normalmente verrebbe calcolata prima di enumerare le regole, risulta saltata da una patch successiva alla build 22631.3440.
Finché Microsoft non ufficializza la root cause, questa rimane la migliore ipotesi tecnica ricavata dall’analisi di call stack e trace verbose.
Alternative a medio termine
- WDAC in modalità Managed Installer: consente whitelisting granulare e si integra con Intune Antivirus, riducendo la dipendenza da AppLocker.
- Edge Kiosk con App Config: se l’unica app concessa è realmente Edge, si può impostare il profilo “Edge (single‑app)” che lancia una sandbox dedicata priva di Explorer.exe.
- Immutable OS (Windows 10 IoT LTSC): per scenari retail con hardware dedicato, valutare l’edizione LTSC non soggetta a CU mensili frequenti.
Controlli di auditing utili
Per intercettare ex post eventuali exploit:
AuditPol /set /subcategory:"Application Whitelist" /success:enable /failure:enable
wevtutil qe Microsoft-Windows-AppLocker/EXE %Windir%\Logs\AppLocker.evtx /c:10 /rd:true
Aggrega i log con Microsoft Sentinel o con soluzioni SIEM di terze parti e imposta un alert su pattern “File name mismatch” o “Hash calculation skipped”.
Domande frequenti
La vulnerabilità è limitata a Edge?
No. Edge è solo un vettore dimostrativo: qualsiasi eseguibile autorizzato nelle regole AppLocker può essere impersonato tramite rename.
Hash rules risolvono definitivamente il problema?
Risolvono il sintomo a scapito della gestibilità: ogni volta che Microsoft aggiorna Edge o altre app legittime dovrai rigenerare gli hash.
Esistono workaround tramite GPO?
Applicare “Don’t run specified Windows applications” via GPO non è efficace in kiosk, poiché il componente Shell Launcher ignora la policy. Serve un approccio di hardening più profondo (WDAC).
Best practice per il deploy post‑patch
- Monitorare il canale Windows Release Health e Insider Release Preview per il fix.
- Una volta disponibile la patch, installarla in laboratorio e ripetere i test di bypass.
- Rimani su regole Hash finché la telemetria AppLocker “Rule Processing Time” non ritorna ai valori pre‑CU.
- Distribuire gradualmente la build corretta con anello pilot devices prima di un roll‑out completo.
Conclusioni
Il bug introdotto da KB5051989 rappresenta una regressione grave per ambienti kiosk che contano su AppLocker come linea di difesa primaria. Disinstallare la patch è spesso la via più rapida, ma non sempre praticabile. È quindi cruciale combinare hardening multilivello, escalation presso i canali Microsoft e un programma di testing continuo.
Rimaniamo in attesa di un aggiornamento ufficiale: nel frattempo, le misure descritte sopra aiuteranno a mantenere la sicurezza operativa e la conformità in scenari mission‑critical.