Una vulnerabilità di Microsoft 365 Copilot Enterprise permetteva di avviare istruzioni senza una conferma esplicita dell’utente dopo il semplice clic su un collegamento. La parte più singolare della vicenda è che i ricercatori di Varonis hanno scoperto il parametro necessario interrogando lo stesso Microsoft Copilot. Microsoft ha già corretto il problema.

Ci sono vulnerabilità che richiedono mesi di reverse engineering. Altre vengono scoperte analizzando pacchetti di rete, codice e comportamenti anomali.

Quella individuata in Microsoft 365 Copilot Enterprise ha invece una storia decisamente particolare.

I ricercatori della società di sicurezza Varonis stavano cercando un modo per capire se fosse possibile aggirare una delle protezioni di Copilot. L’obiettivo era verificare se un comando potesse essere eseguito automaticamente dopo il semplice clic su un link.

Inizialmente Copilot rifiutava di collaborare.

Continuando però a fare domande sempre più precise sul funzionamento delle proprie protezioni, l’assistente ha progressivamente fornito dettagli sull’architettura interna.

Fino a rivelare il tassello mancante: un parametro non documentato capace di attivare automaticamente un prompt.

Microsoft Copilot ha spiegato come aggirare la sua stessa protezione

Il comportamento normale di Copilot prevedeva una barriera importante.

Un prompt inserito attraverso un collegamento non avrebbe dovuto essere eseguito automaticamente. L’utente doveva prima compiere un gesto esplicito, per esempio premere un tasto o confermare l’operazione.

I ricercatori volevano capire proprio come funzionasse questa protezione.

Hanno quindi iniziato a interrogare Copilot sul motivo per cui l’esecuzione automatica fosse impedita, sulla struttura dei collegamenti e sul comportamento della pagina quando un comando veniva già inserito nel campo del prompt.

Ogni risposta aggiungeva un nuovo dettaglio.

Secondo Lior Adar, Senior Researcher di Varonis, persino i rifiuti iniziali contenevano informazioni utili sull’architettura del sistema.

Alla fine Copilot ha indicato un parametro interno che non risultava documentato pubblicamente.

Il parametro nascosto era ?autorun=1

Il parametro scoperto dai ricercatori era ?autorun=1.

Abbinato a un secondo parametro già conosciuto, utilizzato per inserire una richiesta nel campo di Copilot, consentiva di avviare automaticamente il comando senza richiedere un’ulteriore interazione da parte dell’utente.

Era proprio il comportamento che la protezione avrebbe dovuto impedire.

In condizioni normali, infatti, un collegamento può aprire Copilot e predisporre una richiesta. L’esecuzione deve però essere autorizzata dall’utente.

Con il parametro individuato da Varonis, quella barriera poteva essere aggirata.

A quel punto era sufficiente convincere una persona a cliccare su un collegamento preparato appositamente.

Bastava un clic sul link

L’attacco sviluppato dai ricercatori è stato chiamato Co-Snitch.

Lo scenario prevedeva l’invio di un URL attraverso email, chat, un sito di phishing o anche un codice QR.

Dopo il clic, il browser apriva Copilot utilizzando la sessione già autenticata della vittima.

Il parametro nascosto consentiva quindi di avviare automaticamente il prompt.

Copilot poteva a quel punto elaborare la richiesta sfruttando il contesto disponibile nell’account, comprese le applicazioni collegate e le informazioni accessibili alla sessione.

In alcuni test, Varonis è riuscita a fare in modo che Copilot cercasse informazioni nella posta elettronica e le trasmettesse verso un server controllato dai ricercatori.

Tra i dati a rischio anche password e credenziali

La dimostrazione non si è fermata all’indirizzo email di un mittente.

I ricercatori hanno verificato che la stessa tecnica poteva essere utilizzata per chiedere a Copilot di cercare nella casella di posta eventuali password o altre credenziali ricevute attraverso email.

Se trovate, queste informazioni potevano essere inserite all’interno di una richiesta verso un server esterno.

La vittima non doveva digitare nulla.

Il passaggio iniziale restava il semplice clic sul collegamento.

Per rendere meno evidente il contenuto sottratto e ridurre il rischio di errori durante la trasmissione, i dati potevano inoltre essere codificati prima dell’invio.

È proprio questa combinazione a rendere la vulnerabilità particolarmente seria: un’azione minima da parte dell’utente poteva avviare una catena molto più complessa.

L’attacco continuava anche chiudendo la scheda

Varonis ha inoltre osservato un comportamento particolarmente interessante.

Una volta avviata la richiesta, la catena poteva continuare fino al completamento anche se l’utente chiudeva rapidamente la scheda di Copilot.

Il prompt poteva coinvolgere più passaggi, utilizzare connettori e avviare richieste di rete.

Questo rendeva ancora meno evidente ciò che stava accadendo.

La persona poteva cliccare sul link, vedere per un attimo Copilot e chiudere la pagina senza rendersi conto delle operazioni avviate.

Microsoft ha già corretto la vulnerabilità

La falla non risulta più sfruttabile con la stessa tecnica.

Varonis aveva segnalato il problema a Microsoft diversi mesi prima della pubblicazione della ricerca.

Microsoft ha inizialmente mitigato la vulnerabilità impedendo al parametro usato per precompilare Copilot di inserire automaticamente il testo nel chatbot.

Da quel momento l’utente doveva interagire manualmente con l’interfaccia.

Questa scelta ha bloccato il percorso sfruttato nell’attacco, anche se ha avuto conseguenze sulle integrazioni di terze parti che utilizzavano quel parametro per funzioni legittime.

Successivamente Microsoft ha introdotto correzioni più complete.

Il caso viene quindi raccontato dopo l’intervento dell’azienda e non descrive una vulnerabilità lasciata intenzionalmente aperta.

Co-Snitch colpiva anche la memoria permanente di Copilot

La ricerca di Varonis ha fatto emergere anche un secondo problema.

In questo caso l’obiettivo era la memoria permanente di Copilot, utilizzata per ricordare informazioni, preferenze e istruzioni tra una conversazione e quella successiva.

I ricercatori hanno realizzato una pagina web contenente istruzioni nascoste.

Quando Copilot veniva utilizzato per riassumere quella pagina, il sistema poteva interpretare le indicazioni presenti nei metadati e utilizzarle per modificare la memoria dell’assistente.

È una forma di prompt injection indiretta.

L’utente chiede semplicemente un riassunto, ma all’interno del contenuto esistono istruzioni che cercano di influenzare il comportamento del modello.

La memoria modificata poteva restare nel tempo

La persistenza rende questo secondo scenario particolarmente interessante dal punto di vista della sicurezza.

Le informazioni inserite nella memoria potevano infatti rimanere disponibili nelle sessioni successive.

Secondo Varonis, questo tipo di manipolazione potrebbe essere utilizzato per alterare determinate risposte, filtrare informazioni oppure preparare azioni da eseguire in seguito al verificarsi di determinate condizioni.

Le memorie modificate potevano inoltre sopravvivere ad alcune normali operazioni di sicurezza dell’account.

Per accorgersi delle informazioni indesiderate, l’utente avrebbe dovuto controllare direttamente il contenuto della memoria.

Non è il primo attacco dimostrato contro Copilot

Co-Snitch arriva dopo altre ricerche dedicate alla sicurezza di Copilot.

Varonis aveva già dimostrato una tecnica contro Copilot Personal capace di avviare una catena di operazioni nascoste con una singola interazione.

A giugno era inoltre stato mostrato SearchLeak, un altro attacco focalizzato sull’esfiltrazione dei dati.

Questi casi mettono in evidenza un problema sempre più importante.

Gli assistenti AI stanno ottenendo accesso a email, documenti, calendari, memoria personale e servizi esterni.

Più cresce la loro capacità di agire, maggiore diventa l’impatto potenziale di una vulnerabilità.

Il problema delle protezioni degli assistenti AI

Un chatbot tradizionale può limitarsi a rispondere a una domanda.

Un assistente moderno può invece aprire contenuti, interrogare servizi collegati, cercare informazioni personali e avviare operazioni attraverso diversi strumenti.

Questo rende fondamentale il confine tra ciò che il modello può preparare e ciò che può eseguire autonomamente.

Nel caso scoperto da Varonis, la richiesta di una conferma dell’utente costituiva proprio una di queste barriere.

Il problema è che esisteva un parametro capace di aggirarla.

Ancora più curioso è il fatto che lo stesso sistema abbia progressivamente rivelato le informazioni necessarie per individuarlo.

È probabilmente questo l’elemento più significativo dell’intera vicenda.

Anche ciò che un modello rivela può diventare un rischio

La sicurezza di un assistente AI non riguarda soltanto gli strumenti ai quali può accedere.

Conta anche ciò che il modello conosce della propria infrastruttura e quanto è disposto a spiegare.

Copilot non avrebbe fornito immediatamente ai ricercatori una procedura completa.

Il parametro è emerso attraverso una serie di domande successive.

Ogni risposta apparentemente innocua ha però ristretto il campo, fino a permettere di ricostruire il funzionamento della protezione.

È una dinamica diversa rispetto alla classica vulnerabilità software.

Non viene attaccato soltanto il codice. Viene interrogato anche il modello per ottenere informazioni che possono aiutare a comprendere il sistema che lo circonda.

Copilot corretto, ma la lezione resta importante

Microsoft ha risolto la vulnerabilità descritta da Varonis, ma Co-Snitch mostra bene una delle difficoltà legate alla nuova generazione di assistenti AI.

Collegare un modello linguistico a email, documenti e applicazioni rende Copilot molto più utile.

Allo stesso tempo amplia enormemente ciò che potrebbe accadere quando una protezione viene aggirata.

La vicenda contiene poi un dettaglio quasi paradossale.

I ricercatori cercavano il modo di superare un sistema di sicurezza di Microsoft Copilot e il principale indizio è arrivato proprio da Copilot.

Domanda dopo domanda, l’assistente ha finito per rivelare il parametro nascosto necessario a completare l’attacco.

Microsoft ha chiuso quella strada. Il caso rimane però un esempio particolarmente efficace di quanto la sicurezza degli LLM debba considerare non soltanto ciò che possono fare, ma anche ciò che possono involontariamente raccontare.