Una catena di tre vulnerabilità zero-day ha consentito a un attaccante di eseguire comandi con privilegi root su un’appliance Ivanti Connect Secure senza autenticarsi. La ricostruzione pubblicata da Volexity il 13 ottobre, ripresa da The Hacker News, riguarda un dispositivo di un cliente che risultava aggiornato al momento dell’attacco. Ivanti ha corretto due componenti della catena; la correzione della terza vulnerabilità era ancora in preparazione alla data della notizia.
Una compromissione oltre il confine della VPN
I primi due difetti, un aggiramento dell’autenticazione e un’esecuzione remota di codice, sono tracciati insieme come CVE-2026-104935. Secondo Volexity, permettono di raggiungere il contesto dell’utente cgi-server; un ulteriore problema di elevazione dei privilegi porta poi all’accesso root. Il caso mostra perché un dispositivo di accesso remoto debba essere trattato come un componente critico dell’infrastruttura, non soltanto come un servizio di connettività.
La società di sicurezza ha osservato l’attività su un’appliance con versione 22.8R2.4, a partire dal 3 ottobre. Ivanti parla di sfruttamento limitato in natura. La fonte non fornisce un numero complessivo di organizzazioni coinvolte: il singolo incidente documentato non consente quindi di quantificare la diffusione della campagna o di estendere automaticamente gli stessi indicatori a tutti gli ambienti.
Aggiornare non equivale a escludere un incidente
Gli amministratori devono confrontare la propria versione con l’avviso ufficiale Ivanti, che distingue rami e release interessati. La fonte riporta versioni indicate come non affette, tra cui 22.8R2.5 e 25.1.3.0. Il percorso corretto di aggiornamento va verificato direttamente presso il produttore, evitando di interpretare il solo numero di versione come una garanzia valida per qualsiasi configurazione.
Volexity segnala anche un limite importante del controllo di integrità: la catena osservata modificava codice in memoria e ripristinava dati di configurazione, riducendo le tracce rilevabili dallo strumento. Un risultato negativo dell’Integrity Checker Tool non basta pertanto a escludere questa specifica compromissione. La valutazione può richiedere analisi di rete e memoria, condotte da personale competente e nel rispetto delle procedure di conservazione delle evidenze.
Credenziali e accessi richiedono una verifica separata
Nell’incidente analizzato, l’attaccante ha sottratto credenziali memorizzate, comprese credenziali LDAP, e ha svolto ulteriori attività contro l’ambiente Active Directory. Non risulta lasciata una web shell persistente: secondo il rapporto, la catena veniva ripetuta per eseguire nuovi comandi. L’assenza di un file sospetto non coincide quindi con l’assenza di accesso illecito.
Come misura organizzativa, chi rileva elementi compatibili dovrebbe attivare il proprio processo di risposta agli incidenti, valutare l’esposizione delle credenziali e coordinare eventuali rotazioni. La fonte non chiarisce se l’aggiornamento elimini ogni accesso già ottenuto, né propone una mitigazione temporanea universale. È una distinzione essenziale fra correggere una vulnerabilità e recuperare un ambiente compromesso.
Da portare in pratica: verificare subito inventario e advisory, pianificare le correzioni e non affidare la chiusura dell’incidente al solo esito di un controllo automatico. Aggiornamento, indagine e protezione delle identità sono attività complementari, con responsabilità e tempi da coordinare.
Fonte: https://thehackernews.com/2026/10/attacker-chains-three-ivanti-connect.html
Lascia un commento