Sommario
Nel panorama della cybersecurity enterprise, aprile 2025 si apre con un’importante convergenza di segnalazioni da parte di Cisco e della Cybersecurity and Infrastructure Security Agency (CISA) su vulnerabilità attivamente sfruttate. In particolare, la presenza di un account amministrativo backdoor nel Cisco Smart Licensing Utility (CSLU) ha attirato l’attenzione per il suo utilizzo in attacchi reali, mentre la CISA ha aggiornato il suo catalogo KEV e pubblicato due advisory mirati ai sistemi di controllo industriale (ICS). La gravità e varietà delle vulnerabilità coinvolte mette in evidenza la crescente pressione sulle infrastrutture digitali, sia in ambito governativo che privato e per fortuna le segnalazioni portano spesso ad una correzione come avvenuto a Google per la piattaforma Cloud Run.
CSLU: l’account admin backdoor che espone le reti aziendali
Cisco ha lanciato un avviso urgente in merito alla vulnerabilità CVE-2024-20439, una falla critica che affligge il software Cisco Smart Licensing Utility (CSLU) per ambienti Windows. La vulnerabilità consiste in un account amministrativo con credenziali statiche non documentate, che consente a un attaccante remoto di ottenere l’accesso con privilegi elevati sfruttando l’API della piattaforma, a patto che l’app CSLU sia attiva (non è un servizio persistente per default).
La problematica è stata inizialmente identificata e corretta da Cisco già a settembre 2024, ma la sua gravità è esplosa nuovamente nel marzo 2025 dopo che il ricercatore Nicholas Starke ha pubblicato un’analisi completa del funzionamento della vulnerabilità, inclusa la password hardcoded. Subito dopo, Cisco ha confermato tentativi attivi di exploit “in the wild”.
Il rischio si aggrava ulteriormente con l’aggiunta della CVE-2024-20440, una vulnerabilità che consente la lettura remota di log contenenti credenziali API, facilitando così l’escalation dei privilegi da parte degli aggressori. I due exploit, se combinati, rappresentano un vettore di attacco estremamente pericoloso.
CISA: CVE-2024-20439 entra nel KEV catalog
In risposta alle attività malevole documentate, CISA ha inserito la CVE-2024-20439 nel suo catalogo delle vulnerabilità conosciute ed esplorate (KEV), sottolineando l’urgenza della mitigazione per tutte le agenzie federali statunitensi. Il termine per applicare i fix è fissato al 21 aprile 2025, secondo quanto previsto dalla Binding Operational Directive (BOD) 22-01.
CVE-2025-24813 Apache Tomcat Path Equivalence Vulnerability
Tuttavia, l’avviso non si limita al solo ambito governativo: CISA incoraggia tutte le organizzazioni pubbliche e private a intervenire prontamente, considerando l’elevato impatto di questi bug, già oggetto di sfruttamento attivo.
ICS: due nuovi advisory per la sicurezza delle infrastrutture critiche
Parallelamente all’allarme su CSLU, la CISA ha pubblicato due nuovi advisory dedicati ai sistemi di controllo industriale (ICS). Pur senza entrare nei dettagli tecnici nella comunicazione pubblica, l’agenzia segnala la presenza di vulnerabilità sfruttabili in ambienti OT, ossia quei sistemi che governano processi fisici nel settore energetico, dei trasporti, idrico e manifatturiero.
- ICSA-25-091-01 Rockwell Automation Lifecycle Services with Veeam Backup and Replication
- ICSA-24-331-04 Hitachi Energy MicroSCADA Pro/X SYS600 (Update A)
Gli operatori di infrastrutture critiche sono esortati a consultare gli advisory completi, adottare patch, segmentare le reti ICS e limitare l’accesso alle componenti più sensibili.
Cisco, backdoor e precedenti: una tendenza da non ignorare
Il caso CSLU non è isolato. Cisco ha rimosso backdoor simili in precedenza da software come IOS XE, WAAS, DNA Center e Emergency Responder. Questo suggerisce una tendenza preoccupante: la presenza ricorrente di account nascosti o credenziali statiche in software critico per la gestione IT aziendale.
Google corregge una pericolosa vulnerabilità in Cloud Run
ImageRunner, questo il nome con cui è stata battezzata la vulnerabilità scoperta dai ricercatori di Tenable, ha evidenziato un rischio significativo all’interno di Google Cloud Platform (GCP), in particolare nel servizio Cloud Run. La falla, ora corretta, avrebbe potuto consentire a un attaccante di accedere a immagini container private, eseguire codice malevolo o esfiltrare dati, sfruttando permessi IAM errati e mal configurati.
Un’escalation di privilegi nascosta tra i meccanismi interni di Cloud Run
Google Cloud Run è un servizio completamente gestito per eseguire applicazioni containerizzate in ambiente serverless. Quando viene creato o aggiornato un servizio, Cloud Run genera una nuova revisione che viene eseguita utilizzando un service agent account per prelevare le immagini necessarie dai registry come Artifact Registry o Google Container Registry.
Il problema risiedeva nella possibilità, per un’entità (utente o servizio) con i permessi run.services.update e iam.serviceAccounts.actAs, di aggiornare un servizio Cloud Run e indicare una qualsiasi immagine container privata, anche non direttamente accessibile, appartenente allo stesso progetto. In pratica, bastava avere i permessi per aggiornare una revisione e impersonare un service account, senza che fosse necessario avere accesso diretto all’immagine privata.
Conseguenze potenziali: exfiltration, reverse shell e furto di segreti
Una volta sfruttata la falla, un attore malevolo avrebbe potuto:
- Accedere a immagini container sensibili o proprietarie, contenenti codice o dati critici
- Iniettare comandi malevoli, con lo scopo di estrarre segreti, rubare dati o aprire una reverse shell
- Mascherare i payload in immagini apparentemente legittime e farli eseguire in ambienti produttivi
L’impatto è stato classificato come escalation di privilegi orizzontale, sfruttando componenti interni della piattaforma cloud per ottenere accesso oltre i limiti imposti dal controllo accessi.
La risposta di Google e il rilascio della patch
Google ha risposto con una patch distribuita il 28 gennaio 2025, che modifica il comportamento di default della piattaforma. Ora, qualsiasi entità (utente o service account) che crea o aggiorna un servizio Cloud Run deve disporre di permessi espliciti per accedere alle immagini container utilizzate.
Più precisamente, è ora richiesto il ruolo IAM Artifact Registry Reader (roles/artifactregistry.reader) sul progetto o repository contenente le immagini.
Una vulnerabilità “a cascata” nel modello di servizi cloud
Tenable ha definito questo caso un esempio del pattern “Jenga”, dove l’interconnessione tra servizi cloud può propagare vulnerabilità trasversali. Se un servizio è costruito sopra altri servizi interni (come Cloud Run lo è sopra IAM e Artifact Registry), una falla in un livello può compromettere l’intera struttura.
Questo modello riflette un rischio sottile ma pervasivo: i permessi IAM devono essere gestiti con estrema attenzione, poiché un errore di configurazione in un punto può aprire la strada ad attacchi ben più ampi.
Attenzione ai permessi impliciti nei deployment cloud
ImageRunner mostra come anche un’architettura solida come quella di GCP possa essere minata da interazioni non controllate tra i servizi. La lezione fondamentale è che la configurazione IAM deve essere trattata come parte integrante del threat model, non come semplice amministrazione di accesso.
Per proteggersi da simili scenari, è cruciale:
- Verificare che ogni entità disponga solo dei permessi minimi indispensabili (principio del least privilege)
- Monitorare attivamente le revisioni di Cloud Run, inclusi gli utenti che le modificano
- Ispezionare le immagini container in uso, soprattutto se sensibili o proprietarie
- Automatizzare le policy di sicurezza con strumenti di auditing IAM e regole di deploy sicure
Google corregge una vulnerabilità in Cloud Run che permetteva accessi non autorizzati a immagini container private tramite IAM mal configurato.
Sicurezza proattiva, visibilità completa
Il messaggio emerso da questi alert è chiaro: le minacce informatiche non aspettano. Che si tratti di un backdoor in un software enterprise o di una vulnerabilità ICS, le organizzazioni devono adottare misure proattive e tempestive, combinando l’installazione di patch con l’adozione di strumenti di monitoraggio avanzato, audit delle credenziali API, segmentazione della rete e rafforzamento delle politiche di accesso.
