Table of Contents
AutoJack: il nuovo attacco che incrina la fiducia in localhost
Microsoft ha descritto AutoJack come una nuova catena di attacco che, stando alla ricerca pubblicata dall’azienda, può trasformare una semplice pagina web malevola in un mezzo per eseguire codice sul computer della vittima. Succede quando un agente software carica contenuti dal web e, allo stesso tempo, interagisce con servizi privilegiati in esecuzione in locale.
Il punto della ricerca è abbastanza netto: se un agente software può leggere il web e parlare con servizi privilegiati che girano sulla stessa macchina, il perimetro di fiducia di localhost non regge più come prima.
In concreto, il contenuto controllato da un attaccante non va a colpire direttamente il sistema operativo. Passa invece attraverso l’agente, che finisce per fare da intermediario “fidato”.
A quel punto basta aprire la pagina. Da lì, spiega Microsoft, il software locale può essere spinto a contattare un servizio MCP in esecuzione sulla macchina e ad avviare processi arbitrari, senza che l’utente debba fare altro.
AutoJack, il nuovo attacco che incrina la fiducia in localhost
Per i ricercatori di Microsoft, l’aspetto più rilevante della scoperta non riguarda soltanto AutoGen Studio. Il problema è più a monte, ed è architetturale.
Se un agente locale eredita identità e privilegi di un servizio esposto su 127.0.0.1, allora una pagina remota può, di fatto, “parlare” con quel servizio passando proprio attraverso l’agente, almeno secondo la ricostruzione di Microsoft.
È il classico caso di confused deputy.
Il programma agisce con l’autorità dell’utente, ma viene portato a compiere azioni che servono gli interessi di un aggressore. La dimostrazione tecnica pubblicata da Microsoft, del resto, mette in fila diversi elementi che vanno proprio in questa direzione.
Le tre debolezze concatenate che hanno aperto la strada alla RCE
L’exploit mostrato da Microsoft univa tre problemi distinti nell’implementazione WebSocket del protocollo MCP in AutoGen Studio.
Il primo riguardava una allowlist delle origin che, sempre secondo Microsoft, poteva essere aggirata, perché l’agente di navigazione locale finiva di fatto per ereditare l’identità di localhost.
Il secondo punto era l’assenza di autenticazione su alcuni percorsi WebSocket MCP. In base alla ricerca, i controlli standard lì non venivano applicati e non c’erano protezioni aggiuntive a compensare.
Il terzo problema stava nella gestione non sicura di un parametro chiamato server_params. Veniva passato via URL, decodificato e poi inoltrato direttamente alla logica di creazione dei processi, senza alcuna lista di eseguibili consentiti, almeno per quanto riportato da Microsoft.
Il risultato? Un attaccante, sempre stando alla ricostruzione dei ricercatori, poteva indicare comandi come PowerShell, Bash o altri binari già presenti sul sistema e ottenere così l’avvio di processi arbitrari. Tradotto: esecuzione remota di codice a livello host.
Impatto reale e stato delle correzioni
Microsoft ha chiarito di aver segnalato il problema internamente al Microsoft Security Response Center (MSRC) e che il codice vulnerabile era presente solo nelle build di sviluppo con supporto MCP.
La correzione, a quanto riferito dall’azienda, è arrivata prima di qualunque rilascio pubblico su PyPI. Se così stanno le cose, la falla non sarebbe mai finita nell’attuale pacchetto di produzione.
È una distinzione che conta. Ma il nodo centrale resta.
Il rischio, infatti, non si esaurisce in un singolo progetto. Microsoft avverte che vulnerabilità dello stesso tipo potrebbero comparire in un’intera classe di framework per agenti autonomi.
Perché il caso interessa anche le aziende
La ricerca di Microsoft si inserisce in un filone sempre più ampio di problemi di sicurezza legati ai software autonomi: trappole costruite per agenti che navigano sul web, attacchi contro assistenti di sviluppo, catene che partono dall’iniezione di istruzioni e arrivano fino all’esecuzione di codice, senza dimenticare i bug di esposizione dei dati in strumenti commerciali.
Per le aziende il messaggio è semplice: i modelli di difesa tradizionali non bastano più quando un software può leggere il web, prendere decisioni operative e interagire con risorse locali sensibili.
La direzione indicata dagli esperti, riassunta anche da Microsoft, passa da zero trust, sandboxing e da un principio molto netto: ogni azione generata dall’agente, compreso il codice che produce o i comandi che propone, va trattata come non affidabile per default.
E qui si apre anche una questione più profonda, quasi etica: ha davvero senso considerare affidabile per default un agente che legge il web, prende decisioni operative e mette mano a risorse locali sensibili?
