TL; DR
@szc-ft/mcp-szcd-client è un client Model Context Protocol (MCP) pubblicato su npm che configura automaticamente gli assistenti di programmazione AI, ovvero il tipo di pacchetto di collegamento che uno sviluppatore installa in modo che un agente IDE possa comunicare con un servizio di libreria di componenti. Ha una lunga cronologia di rilascio dall'aspetto ordinario (versioni 71) e una fase di installazione innocua. Nessuna operazione nella fase post-installazione riguarda le credenziali.
Il comportamento di lettura delle credenziali si trova a un livello più in profondità, in una skill MCP raggruppata chiamata local-browser-test. Quando quella competenza è connect() durante le corse di routine, invoca _decryptCredentials() — che decifra ogni password salvata nel profilo locale di Chrome/Edge (tutti i siti, non la singola applicazione che un test del browser prenderebbe di mira) utilizzando l'API di protezione dei dati di Windows (DPAPI) e AES-256-GCM. Il set decrittografato viene scritto in chiaro su ~/.szcd-mcp/deps/decrypted-creds.json e restituito all'interno del risultato dello strumento MCP della competenza, che confluisce nel server MCP remoto predefinito del pacchetto, mcp.szcd-mcp.top.
Questo è uno schema della catena di approvvigionamento che merita di essere denominato: la funzionalità sensibile non è in un hook di installazione (dove la maggior parte degli scanner e dei revisori guardano) ma in una skill MCP che viene eseguita solo quando un operatore punta lo strumento sul proprio browser in esecuzione. Lo chiamiamo SkillLeakMEW classifica @szc-ft/mcp-szcd-client (versioni 0.38.0 and 0.39.0) come dannoso.
Nota a margine — Abilità MCP: un insieme autonomo di istruzioni e script di supporto che un server MCP espone a un agente di IA come funzionalità richiamabile. L'agente lo invoca come uno strumento; gli script vengono eseguiti sulla macchina dello sviluppatore.
Anatomia dell'attacco
La confezione presenta due aspetti molto diversi.
Il volto che un recensore vede per primo è il percorso di installazione. Il manifesto dichiara postinstall: node scripts/postinstall.jse quello script fa esattamente quello che dice il README: collega MCP integrazioni negli IDE e installa un pacchetto correlato, @szc-ft/sketch-mcp-serverNon raggiunge mai il codice delle credenziali. Uno scanner che si ferma all'installazione hooks — il punto storicamente più affidabile in cui cercare — vede uno strumento per sviluppatori pulito e senza particolari problemi. Questo pacchetto era stato infatti valutato come sicuro in una precedente fase di revisione.
Il volto che conta si raggiunge solo attraverso l'abilità combinata. La catena:
- Uno sviluppatore esegue il test del browser locale competenza su un'istanza di Chrome/Edge avviata con una porta di debug remoto. Questo è il metodo documentato per utilizzare la competenza.
- L'abilità è Collegare() (lib/browser-engine.js) chiamate _decryptCredentials() alla riga 246.
- _decryptCredentials() chiamate decryptAllPasswords({ filter: '%' }). '%' Il filtro è il dettaglio che trasforma una semplice funzionalità di test in un vero e proprio successo: seleziona ogni origine memorizzata anziché il singolo sito in fase di test.
- lib/decrypt-passwords.js legge il browser os_crypt chiave crittografata, esegue powershell … ProtectedData::Unprotect (DPAPI) per recuperare la chiave AES, quindi AES-256-GCM-decifra ogni credenziale salvata.
- Il set completo decrittografato è scritto su ~/.szcd-mcp/deps/decrypted-creds.json in chiaro e restituito come la competenza Strumento MCP risultato.
- Tale risultato viaggia indietro attraverso il canale MCP al server predefinito del pacchetto, mcp.szcd-mcp.top — lo stesso host documentato nel README e in scripts/lib/common.js.
Una breve nota sul perché il passaggio 4 funzioni. Su Windows, Chrome ed Edge non memorizzano le password salvate in chiaro: ogni credenziale è crittografata con una chiave AES-256-GCM, e tale chiave è a sua volta sigillata con DPAPI, che la associa all'account utente corrente. Il recupero di una password richiede quindi due passaggi: il primo Dati protetti::Rimuovi protezione per recuperare la chiave AES (operazione riuscita perché il codice viene eseguito come utente connesso, esattamente il contesto fornito dal terminale di uno sviluppatore), quindi una decrittazione GCM di ogni blob memorizzato letto dal browser os_crypt-Archivio protetto. Questo è un metodo ben noto, offline e silenzioso: non richiede password principale, non interagisce con il browser e non effettua alcun passaggio di rete fino all'inoltro dei risultati. È lo stesso meccanismo primitivo utilizzato da molti ladri di informazioni commerciali: la novità qui sta solo nel modo in cui viene veicolato.
Il decrittatore non è casuale. È raggruppato tre volte — sotto standard-abilità/, estensione opencode/e qwen-extension/ — una copia per ogni superficie di assistente AI supportata, in modo che la funzionalità segua l'assistente configurato dallo sviluppatore.
Il contrasto con un test automatico del browser legittimologin è tutta la storia. Un vero assistente di test decifra le credenziali per il prima applicazione è eserciziocisIn questo caso, il processo lo utilizza all'interno dello stesso processo e non lo memorizza né lo inoltra mai. Qui, la routine decifra tutto, lo scrive su disco in chiaro e lo restituisce attraverso un confine di rete a un server remoto.
Cronologia e evento scatenante
Per comprendere l'esposizione, è importante analizzare due comportamenti.
L'attivazione è facoltativa, non automatica. L'installazione del pacchetto non legge alcuna credenziale. La decrittazione viene eseguita solo quando uno sviluppatore la invoca attivamente test del browser locale abilità contro un browser che hanno avviato in modalità di debug remoto. Ciò restringe materialmente chi è interessato rispetto a un post-installazione carico utile che si attiva ogni installazione di npm.
La confezione è di qualità, non usa e getta. L'editore ha distribuito 71 versioni e mantiene una più ampia @szc-ft suite di librerie di componenti MCP. Il decrittatore delle credenziali è presente in entrambe le versioni contrassegnate (0.38.0 e 0.39.0) con un'impronta digitale identica, invocata dallo stesso browser-engine.js:246 Punto di ingresso. Il pacchetto è ancora disponibile su npm al momento della stesura di questo documento.
Questa combinazione – un editore affermato, una fase di installazione innocua e una funzionalità che si attiva solo in base a uno specifico flusso di adesione – è esattamente il motivo per cui un classificatore automatico ha previsto "sicuro" e una precedente revisione ha confermato tale previsione. Il comportamento anomalo si risolve solo con la lettura manuale degli script di supporto della skill.
Indicatori di compromesso
Audit dei difensori Utensili MCP dovrebbe trattare il abilità la directory come ambito, non solo il manifesto e gli script di installazione.
Attribuzione e comportamento osservato
Descriviamo il comportamento, non la motivazione.
Il pacchetto è pubblicato sotto un account npm stabilito con un multi-pacchetto coerente @szc-ft Suite MCP e una lunga cronologia delle versioni. Non esiste un canale di comando e controllo nascosto dedicato: le credenziali decrittografate vengono restituite tramite il server MCP documentato del pacchetto stesso, mcp.szcd-mcp.top, piuttosto che verso un punto di consegna anonimo. La fase di installazione è assolutamente innocua.
Ciò che trasforma questo da "funzionalità di convenienza aggressiva" a classificazione dannosa è la combinazione osservabile di ambito e destinazione: le decrittazioni di routine contro tutti i credenziali del browser salvate invece della singola applicazione che un test eseguirebbecise, li salva su disco in chiaro e li trasmette dall'host attraverso il canale MCP. Un test automatico del browser-login Una funzionalità che si comportasse in questo modo sarebbe, di fatto, indistinguibile dalla raccolta di credenziali, ed è proprio su questo effetto che un difensore deve basare la propria analisi.
Notiamo onestamente che l'attivazione è di tipo opt-in e che l'editore è consolidato; entrambi i fatti sono riportati nel record sopra. Nessuno dei due modifica il risultato osservabile per uno sviluppatore che esegue la skill: le password salvate per ogni sito nel suo profilo browser vengono eliminate dal dispositivo.
Impatto, tendenze e linee guida per i difensori
SkillLeak è un incidente che riguarda un singolo pacchetto, ma il punto cruciale è la piattaforma di distribuzione che utilizza.
I meccanismi della catena di fornitura del settore sono calibrati per garantire l'esecuzione in fase di installazione: preinstallare/post-installazione hooks, beacon di confusione di dipendenza, typosquat con un payload in index.js. MCP modifica la geometriaUn pacchetto MCP può inviare un manifesto e una fase di installazione completamente puliti, portando il suo comportamento conseguente all'interno di un abilità — un pacchetto che l'agente IA richiama in seguito, su istruzione dello sviluppatore, utilizzando le risorse dello sviluppatore stesso. Questa funzionalità viene integrata con l'assistente e rimane inattiva finché un normale flusso di lavoro ("esegui il test del browser") non la attiva.
Per i team che adottano gli strumenti MCP:
- Competenze di revisione, non solo di compilazione dei documenti. Estendere la revisione del pacchetto al competenze/, *-estensione/e directory equivalenti. Il codice più sensibile potrebbe non comparire mai in un hook di installazione.
- Fai attenzione al gonfiaggio del cannocchiale. Una capacità che dichiara uno scopo ristretto (testare un'app) ma opera ampiamente (filtro: '%' (su tutte le origini memorizzate) è un segnale di allarme indipendente dall'intento.
- Considera i risultati dello strumento MCP come un canale di uscita. I dati restituiti da una skill vengono inviati dall'host al server MCP configurato per il client. È necessario tenere traccia di queste destinazioni nello stesso modo in cui si farebbe con qualsiasi connessione in uscita.
- Riesaminare gli aggiornamenti di versione dei pacchetti MCP "affidabili". Un editore affermato e una lunga storia di rilasci non sostituiscono la lettura del codice sorgente di ogni versione, come dimostra questo caso, che ribalta una precedente valutazione di sicurezza.
Concretamente, tre controlli a basso costo avrebbero portato alla luce questo pacchetto prima che uno sviluppatore eseguisse la skill. In primo luogo, una scansione del contenuto delle directory delle skill per l'accesso all'archivio delle credenziali locali: riferimenti a os_crypt, Dati protetti/DPAPI, o di un browser Login Dati file — segnala la capacità indipendentemente da quale hook di installazione esista. In secondo luogo, un controllo di ambito su qualsiasi routine di decrittazione/lettura che accetta un selettore jolly (filtro: '%' e equivalenti) piuttosto che un identificatore vincolato cattura l'inflazione test-to-harvest. In terzo luogo, confrontando l'insieme degli host che un pacchetto può raggiungere (qui, mcp.szcd-mcp.top) rispetto alle destinazioni che la sua documentazione dichiara di richiedere trasforma il canale dei risultati MCP in un punto di uscita verificabile. Nessuna di queste richiede l'esecuzione del codice.
Decrittazione delle credenziali tramite DPAPI e os_crypt Si tratta di una vecchia tecnica; la nuova frontiera consiste nell'offrirla tramite una skill basata su un agente AI che si attiva solo in base a un flusso di lavoro di adesione esplicita. Aspettatevi una maggiore diffusione di questo modello di funzionalità integrate in una skill, man mano che gli strumenti MCP si moltiplicano, e adattate di conseguenza l'ambito della revisione.
