Per una trentina di ore, tra il 28 e il 30 agosto, una parte di Internet ha creduto che i server di aggiornamento di Softaculous si trovassero da un'altra parte. Non per un errore di configurazione: per un dirottamento BGP deliberato, che ha consegnato a un attaccante il traffico diretto all'endpoint da cui migliaia di server di hosting scaricano gli aggiornamenti di Virtualizor, il pannello usato dai provider per creare e gestire VPS.

Il risultato è quello che l'industria teme da anni e che raramente si vede documentato così bene: un pacchetto di aggiornamento malevolo consegnato attraverso il canale ufficiale, con un certificato TLS valido e nessun avviso di sicurezza.

Come è andata, minuto per minuto

Softaculous ha pubblicato una ricostruzione insolitamente trasparente, basata sui dati di routing pubblici di RIPE RIS.

Alle 20:57 UTC del 28 agosto l'autonomous system AS62390 (NexonHost) ha iniziato ad annunciare il prefisso 162.55.80.0/24 — un blocco di indirizzi Hetzner che ospita diversi sistemi Softaculous — passando dal transito AS6204 (Zet.net). L'annuncio era più specifico di quello legittimo di Hetzner (162.55.0.0/16) e, per le regole di selezione del percorso BGP, ha quindi avuto la precedenza su ogni rete che lo ha accettato. L'attaccante ha inoltre mantenuto AS24940 (Hetzner) in coda all'AS path, così da apparire come origine legittima.

I numeri della diffusione sono significativi: tutti i 368 peer collector di RIPE RIS hanno visto la rotta dirottata a un certo punto; nei momenti di picco fino a circa il 72% dell'intero campione aveva il percorso migliore che passava dall'attaccante. La rotta è stata però estremamente instabile — circa 10.600 ritiri registrati nella finestra — e questo, paradossalmente, ha limitato i danni: un server riceveva il pacchetto avvelenato solo se il suo controllo aggiornamenti capitava in un intervallo dirottato.

L'incidente si è svolto in due ondate (28 agosto sera - 29 mattina, poi 29 sera - 30 mattina), separate da circa undici ore di traffico pulito. Hetzner ha applicato la contromisura — annunciare direttamente il /24 — solo intorno alle 08:50 UTC del 29 agosto, circa dodici ore dopo l'inizio, e Softaculous scrive esplicitamente di non essere stata avvisata in modo proattivo dal provider.

Il certificato valido è il dettaglio che conta

Il passaggio più istruttivo è un altro. L'attaccante ha ottenuto da Let's Encrypt un certificato TLS tecnicamente valido per i domini Softaculous, perché anche la validazione automatica della proprietà del dominio veniva instradata attraverso il dirottamento. La copertura pressoché globale dell'annuncio ha reso poco efficace anche la verifica da più punti di osservazione.

Il certificato copriva ventisei nomi, tra cui virtualizor.com, api.virtualizor.com, files.virtualizor.com, softaculous.com, webuzo.com e sitepad.com. Per un client di aggiornamento — e per un browser — la connessione era indistinguibile da quella legittima.

È il punto da cui ripartire per capire il resto: il TLS non stava proteggendo nulla, perché l'autorità di certificazione e il client vedevano lo stesso Internet dirottato.

Il payload

Softaculous ha confermato che un pacchetto di aggiornamento Virtualizor malevolo è stato effettivamente consegnato a un numero limitato di installazioni. La ragione per cui è passato è dichiarata senza giri di parole: i client di aggiornamento del prodotto non verificavano crittograficamente i pacchetti. Non c'era firma da controllare.

L'indicatore di compromissione noto è un'unità systemd:

  • /etc/systemd/system/java-jre-update.service, con il corrispondente servizio java-jre-update abilitato o in esecuzione.

Secondo le analisi pubbliche, il pacchetto installava silenziosamente chiavi SSH non autorizzate per garantire accesso persistente e un componente Java pensato per l'esecuzione di codice remoto: su un nodo Virtualizor questo significa controllo del livello hypervisor, cioè di tutte le macchine virtuali dei clienti ospitate su quel server.

Poiché le risposte malevole non hanno mai toccato i log di Softaculous, non esiste un elenco definitivo dei server colpiti. Ogni installazione va considerata in perimetro fino a verifica contraria.

Anche l'area clienti e il portale di fatturazione erano tra i sistemi dirottati: chi ha effettuato l'accesso o inserito dati di pagamento nella finestra dell'incidente deve considerare la sessione potenzialmente intercettata.

Cosa significa per gli hosting provider e le aziende italiane

Il primo punto riguarda chi rivende infrastruttura. L'Italia ha un tessuto denso di provider di hosting e VPS di piccola e media dimensione, molti dei quali usano proprio pannelli come Virtualizor o equivalenti. Per un operatore di questo tipo la compromissione del nodo di virtualizzazione non è un incidente interno: è un incidente che si propaga a tutti i clienti ospitati, che a loro volta possono avere obblighi propri. È esattamente lo scenario che la NIS2 chiama rischio della catena di fornitura, letto dal lato di chi la catena la fornisce.

Il secondo punto è più tecnico e più risolvibile di quanto si creda. Un dirottamento come questo si contrasta con RPKI e Route Origin Validation. Se il titolare del prefisso pubblica un ROA che copre il blocco senza estendere la lunghezza massima fino al /24, l'annuncio più specifico risulta invalido e le reti che applicano ROV lo scartano. La domanda operativa per un'azienda italiana non è quindi teorica: il mio transit provider applica ROV? Ho pubblicato i ROA per i miei prefissi? Sono due verifiche che si fanno in una mattinata e che, in questo caso, avrebbero fatto la differenza tra ricevere un aggiornamento e riceverne un altro.

Il terzo punto è il più scomodo. Quasi tutti i pannelli di controllo, gli agent di monitoraggio e i tool di gestione che girano con privilegi di root sui server italiani si aggiornano tramite HTTPS senza verifica della firma del pacchetto. Il modello di fiducia è "il certificato è valido, quindi il file è autentico". Questo incidente dimostra che le due cose non coincidono. La firma del pacchetto non è un dettaglio da roadmap: è il confine di fiducia. Nella valutazione di un fornitore di software infrastrutturale, la domanda "i vostri aggiornamenti sono firmati e la firma è verificata dal client?" andrebbe messa accanto a quelle sulle certificazioni.

Il contesto normativo

Per un provider di servizi cloud o un data center italiano rientrante nel perimetro NIS2, un aggiornamento malevolo che raggiunge il livello hypervisor è con ogni probabilità un incidente significativo: scatta la notifica al CSIRT Italia, con pre-allarme entro 24 ore dalla conoscenza e notifica entro 72 ore. Il fatto che l'origine sia un fornitore terzo non sposta l'obbligo, che resta in capo al soggetto.

Sul piano GDPR, se la compromissione dell'hypervisor ha esposto dati personali trattati per conto dei clienti, il provider agisce tipicamente da responsabile del trattamento e deve informare senza ingiustificato ritardo i titolari, che valuteranno la notifica al Garante ai sensi dell'art. 33. Chi ha inserito credenziali o dati di pagamento nell'area clienti nella finestra indicata rientra nella stessa valutazione.

Cosa fare subito

  • Cercare l'indicatore di compromissione su ogni server Virtualizor: /etc/systemd/system/java-jre-update.service. Se è presente, non cancellarlo: il server è compromesso, va preservata l'evidenza e contattato il vendor prima di bonificare.
  • Aggiornare a Virtualizor 3.2.9.9, rilasciata il 1° settembre con uno strumento di analisi di sicurezza nel pannello di amministrazione.
  • Ruotare tutte le API key di Virtualizor dal pannello master, limitare l'accesso API a indirizzi IP fidati e rimuovere ogni chiave non riconosciuta.
  • Verificare le chiavi SSH autorizzate di root e di tutti gli utenti, gli account creati di recente, i cron job e i timer systemd inattesi, le connessioni in uscita anomale. Restringere SSH a indirizzi fidati.
  • Rigenerare le API key dell'area clienti su softaculous.com/clients e reimpostare la password; se la stessa password è stata riutilizzata altrove, cambiarla ovunque.
  • Controllare gli estratti conto se sono stati inseriti dati di pagamento tra il 28 agosto alle 20:57 UTC e il 30 agosto alle 06:10 UTC.
  • Verificare RPKI: pubblicare i ROA per i propri prefissi e chiedere formalmente ai propri transit provider se applicano Route Origin Validation.
  • Censire i software infrastrutturali che si aggiornano senza verifica della firma e trattarli come rischio noto, non come dettaglio implementativo.