Attacchi alla Supply Chain Attraverso i Plugin: Quando un Software Fidato Diventa Malevolo

Verificate un plugin prima di installarlo. Buone recensioni, sviluppo attivo, migliaia di installazioni. Lo installate, funziona bene e ve ne dimenticate. Sei mesi dopo, lo sviluppatore del plugin vende il progetto a un acquirente sconosciuto. Il nuovo proprietario rilascia un aggiornamento. Il vostro sito lo installa automaticamente. Quell'aggiornamento contiene uno skimmer per carte di credito, una backdoor o un cryptominer. Siete appena stati colpiti da un attacco alla supply chain.

Non e un'ipotesi. Succede regolarmente in ogni ecosistema CMS, ogni registro di pacchetti JavaScript e ogni CDN. L'attacco alla supply chain e una delle tecniche piu efficaci nel toolkit di un attaccante perche sfrutta l'unica cosa contro cui non potete facilmente difendervi: la fiducia.

Come Funzionano gli Attacchi alla Supply Chain

Un attacco alla supply chain prende di mira la pipeline di sviluppo e distribuzione del software piuttosto che il bersaglio direttamente. Invece di attaccare il vostro sito, l'attaccante compromette qualcosa da cui il vostro sito dipende. Quando aggiornate quella dipendenza, tirate dentro il codice dell'attaccante.

Ci sono diversi vettori di attacco:

1. Acquisizione di Plugin/Pacchetti

Un attaccante identifica un plugin abbandonato ma ampiamente installato. Lo sviluppatore originale ha perso interesse ma il plugin ha ancora decine di migliaia di installazioni attive. L'attaccante contatta lo sviluppatore e offre di comprare il progetto, a volte per poche centinaia di dollari. Lo sviluppatore, contento di liberarsi di qualcosa che non mantiene piu, accetta.

Il nuovo proprietario ora controlla il canale di aggiornamento. Rilascia un aggiornamento che contiene codice malevolo insieme a una correzione minore dall'aspetto legittimo. Ogni sito con aggiornamenti automatici abilitati riceve il malware attraverso il meccanismo di aggiornamento fidato.

2. Compromissione dell'Account dello Sviluppatore

Invece di comprare il plugin, gli attaccanti possono rubare le credenziali dello sviluppatore. Se lo sviluppatore riusa le password (e molti lo fanno), una credenziale da una precedente violazione di dati potrebbe dare accesso al suo account WordPress.org, npm o GitHub. L'attaccante rilascia un aggiornamento malevolo sotto il nome dello sviluppatore.

3. Compromissione del CDN

Molti siti caricano librerie JavaScript da CDN pubblici. Se un attaccante compromette il CDN o la libreria ospitata su di esso, ogni sito che carica quello script ottiene la versione malevola. E successo con l'incidente Polyfill.io, dove un cambio di dominio ha portato a una situazione in cui milioni di siti caricavano potenzialmente script da una fonte non fidata.

4. Confusione delle Dipendenze

Negli ecosistemi di pacchetti come npm, gli attaccanti pubblicano pacchetti malevoli con nomi simili a pacchetti interni popolari usati dalle aziende. Se il sistema di build non e configurato correttamente, scarica il pacchetto dell'attaccante invece di quello interno.

Casi Reali: Non e Teoria

La Pipeline di Acquisizione Plugin

Sono stati documentati multipli casi in cui plugin WordPress sono stati acquistati da entita che successivamente hanno iniettato codice malevolo. Lo schema e coerente:

1. Plugin popolare con 50.000+ installazioni diventa non mantenuto
2. L'acquirente acquisisce il plugin per una piccola somma
3. Il primo aggiornamento dopo l'acquisizione appare benigno (magari una correzione di compatibilita)
4. Il secondo o terzo aggiornamento introduce codice offuscato
5. Il codice invia dati dei visitatori a server esterni, inietta link spam o crea backdoor admin

Il repository plugin di WordPress.org ha rimosso multipli plugin dopo aver scoperto iniezione di malware post-acquisizione. Ma la scoperta spesso richiede settimane o mesi, durante i quali il codice malevolo gira su migliaia di siti.

Librerie CDN Compromesse

La situazione Polyfill.io nel 2024 e stata un campanello d'allarme. Il dominio, precedentemente fidato e usato da centinaia di migliaia di siti web per servire polyfill JavaScript, e passato sotto nuova proprieta. I ricercatori di sicurezza hanno scoperto che il servizio aveva iniziato a iniettare codice malevolo negli script serviti ai visitatori. Google ha iniziato a bloccare gli annunci per i siti che usavano Polyfill.io, e Cloudflare e Fastly hanno creato mirror alternativi.

Non era una vulnerabilita. Era uno sfruttamento della fiducia. I siti si fidavano di un nome di dominio, e quando la proprieta di quel dominio e cambiata, la fiducia e stata abusata.

Magecart Attraverso Script di Terze Parti

Gli attacchi Magecart sono una categoria di attacco alla supply chain che prende di mira specificamente l'e-commerce. Piuttosto che attaccare il negozio direttamente, gli attaccanti compromettono un servizio di terze parti che il negozio carica sulla pagina di checkout. Un widget chat, uno script di analytics, uno strumento di A/B testing, una piattaforma di recensioni.

La violazione di British Airways che ha portato a una multa di 20 milioni di sterline era un attacco in stile Magecart. Gli attaccanti hanno compromesso un file JavaScript caricato sulla pagina di pagamento, catturando dati delle carte per mesi prima del rilevamento.

Per maggiori dettagli su come funzionano questi attacchi di skimming, vedete il nostro articolo sui rischi del JavaScript di terze parti.

Attacchi ai Pacchetti npm

L'ecosistema npm ha visto ripetuti attacchi alla supply chain. L'incidente event-stream e un esempio noto: un pacchetto popolare (2 milioni di download settimanali) e stato preso in carico da un nuovo maintainer che ha aggiunto una dipendenza contenente codice malevolo. L'attacco e rimasto non rilevato per mesi.

Il pacchetto ua-parser-js (8 milioni di download settimanali) e stato compromesso quando un attaccante ha ottenuto accesso all'account npm del maintainer e ha pubblicato versioni contenenti cryptominer e ladri di credenziali.

Perche Questo Attacco e Cosi Efficace

Gli attacchi alla supply chain bypassano le misure di sicurezza tradizionali perche arrivano attraverso canali fidati:

• Aggiornamenti automatici: Il codice malevolo arriva attraverso lo stesso meccanismo delle patch di sicurezza legittime.
• La firma del codice non aiuta: L'attaccante controlla il canale di aggiornamento legittimo, quindi l'aggiornamento malevolo e firmato con la stessa chiave.
• I WAF non lo rilevano: Il codice malevolo fa parte della vostra applicazione, non e un attacco esterno.
• L'antivirus raramente lo rileva: Il codice e tipicamente offuscato e personalizzato.
• Scala: Un pacchetto compromesso colpisce ogni sito che ne dipende.

Come Valutare i Plugin Prima dell'Installazione

La prevenzione inizia con una selezione attenta. Prima di installare qualsiasi plugin:

Controllare la Storia dello Sviluppatore

• Da quanto tempo lo sviluppatore mantiene questo plugin?
• Mantiene altri plugin con buona reputazione?
• La proprieta e cambiata recentemente? Controllate il changelog e gli annunci.
• Lo sviluppatore e un'entita nota (un'azienda con un sito web) o un individuo anonimo?

Controllare lo Schema degli Aggiornamenti

• Quando e stato l'ultimo aggiornamento? Un plugin non aggiornato da oltre un anno e un rischio.
• Dopo un lungo periodo di inattivita, c'e stato un aggiornamento improvviso? Questo schema (dormiente, poi improvvisamente attivo) puo indicare un cambio di proprieta.

Controllare il Codice (Se Possibile)

• Il codice sorgente e disponibile su GitHub? I plugin open-source possono essere auditati.
• Il codice contiene sezioni offuscate? I plugin legittimi raramente offuscano il loro codice.
• Il plugin carica risorse esterne da domini che non riconoscete?
• Ci sono chiamate eval() o stringhe codificate in base64? Questi sono campanelli d'allarme.

Per una panoramica piu ampia sui rischi di sicurezza dei plugin, vedete il nostro articolo sulle vulnerabilita dei plugin nelle piattaforme CMS.

Come Monitorare per Compromissioni della Supply Chain

Monitoraggio dell'Integrita dei File

Mantenete un hash di base di tutti i file dei plugin. Quando avviene un aggiornamento, confrontate i nuovi file con quelli attesi. Per WordPress, diversi plugin di sicurezza offrono il controllo dell'integrita dei file. Per applicazioni personalizzate, strumenti come AIDE o OSSEC possono monitorare le modifiche ai file.

Monitoraggio delle Connessioni in Uscita

Il codice malevolo nei plugin compromessi tipicamente deve inviare dati da qualche parte. Monitorate le connessioni in uscita dal vostro server web. Se il vostro sito inizia a fare richieste HTTP a domini in Russia, Cina o provider di hosting sconosciuti, qualcosa non va.

Monitoraggio Comportamentale

Osservate cambiamenti comportamentali dopo gli aggiornamenti:

• Nuovi file JavaScript caricati nel browser
• Richieste a domini sconosciuti nella scheda network del browser
• Nuovi cookie impostati
• Cambiamenti nel comportamento dei form (specialmente form di checkout)
• Nuove query o tabelle nel database
• Aumento dell'uso delle risorse del server che potrebbe indicare cryptomining

Audit delle Dipendenze

Per progetti JavaScript, eseguite npm audit regolarmente. Per progetti PHP, strumenti come composer audit servono allo stesso scopo. Impostate l'auditing automatizzato nella vostra pipeline CI/CD.

Difese: Subresource Integrity (SRI)

La Subresource Integrity e una funzionalita di sicurezza del browser che vi permette di assicurare che le risorse scaricate da CDN o fonti esterne non siano state manomesse. Quando includete un hash SRI in un tag script, il browser verifica il file scaricato rispetto all'hash. Se non corrispondono, il browser rifiuta di eseguire lo script.

<script src="https://cdn.example.com/library.js"
        integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8w"
        crossorigin="anonymous"></script>

Se il file a quell'URL viene modificato, l'hash non corrispondera e il browser blocchera l'esecuzione. Questa e una difesa diretta contro gli attacchi di compromissione dei CDN.

Difese: Content Security Policy (CSP)

La Content Security Policy e un header HTTP che dice al browser quali fonti possono caricare risorse. Un CSP ben configurato limita significativamente cosa puo fare un plugin compromesso.

Anche se un attaccante inietta JavaScript malevolo attraverso un plugin compromesso, un CSP che limita connect-src al vostro dominio impedira a quello script di inviare dati rubati al server dell'attaccante. Un CSP che restringe script-src impedira il caricamento di script da domini non autorizzati.

Il CSP non previene la compromissione in se, ma limita gravemente i danni.

L'Argomento per Meno Dipendenze

Ogni dipendenza che aggiungete e una decisione di fiducia. State fidandovi dello sviluppatore, del suo ambiente di sviluppo, del suo hosting, della sicurezza del suo account npm, e di ogni futuro proprietario del progetto. Piu dipendenze avete, piu grande e la vostra superficie d'attacco.

Considerate: un tipico sito WordPress con 30 plugin si fida di 30 diversi team di sviluppo (spesso sviluppatori individuali) per mantenere codice sicuro, proteggere i loro account e non vendere a compratori malevoli.

Ridurre le Dipendenze

• Avete bisogno di quel plugin? La funzionalita puo essere ottenuta con 10 righe di codice personalizzato invece di un plugin da 50KB?
• Un plugin puo sostituirne tre? Una soluzione completa da uno sviluppatore affidabile e meglio di tre piccoli plugin da sviluppatori sconosciuti.
• Ospitate localmente quello che potete. Invece di caricare jQuery da un CDN, includetelo nella vostra applicazione. Ogni dipendenza esterna rimossa e un vettore di attacco supply chain in meno.
• Bloccate le versioni delle dipendenze. Usate file di lock e revisionate i cambiamenti quando aggiornate.
• Rimuovete le dipendenze non usate. Auditate regolarmente e rimuovete tutto cio che non e usato attivamente.

Checklist di Difesa Pratica

1. Auditate tutti i plugin e le dipendenze. Elencate ogni componente di terze parti che il vostro sito usa.
2. Rimuovete le dipendenze non necessarie.
3. Implementate SRI per gli script esterni.
4. Implementate una Content Security Policy.
5. Monitorate i cambi di proprieta.
6. Disabilitate gli aggiornamenti automatici ciechi. Revisionate i changelog prima di applicare gli aggiornamenti.
7. Impostate il monitoraggio dell'integrita dei file.
8. Monitorate le connessioni in uscita.
9. Eseguite audit regolari delle dipendenze.
10. Abbiate un piano di risposta agli incidenti.

Cosa Vediamo nella Pratica

Lavorando con aziende in Ticino e in tutta la Svizzera, vediamo un pattern consistente: la maggior parte delle aziende non ha mai auditato le proprie dipendenze di plugin. Hanno siti WordPress con 30-40 plugin, molti dei quali non vengono aggiornati da oltre un anno. Alcuni di questi plugin hanno cambiato proprietario senza che il proprietario del sito lo sapesse.

L'esposizione e reale. Abbiamo trovato script di analytics compromessi, plugin abbandonati con vulnerabilita note e widget di terze parti che caricano codice da domini che non appartengono piu al fornitore del servizio originale.

La sicurezza della supply chain non e qualcosa che la maggior parte delle agenzie web discute con i propri clienti. Ma dovrebbe esserlo. Se volete capire la vostra esposizione e mettere in atto le difese, contattate il nostro team. Possiamo auditare le vostre dipendenze, implementare SRI e CSP, e impostare un monitoraggio che rilevi le compromissioni in anticipo.