Red Hot Cyber
Sicurezza Informatica, Notizie su Cybercrime e Analisi Vulnerabilità
Marimo è un ambiente open source per notebook Python, spesso usato da data scientist, sviluppatori e specialisti AI per lavorare in modo interattivo su codice e dati; non è il classico prodotto enterprise ma proprio per questo spesso non viene speso troppo tempo sui concetti della governance di sicurezza. Marino è utilizzato in ambienti R&D, laboratori o infrastrutture ibride e quando esponi questi ambienti, soprattutto per una comodità di gestione, magari anche solo per qualche ora, diventano subito oggetti d’attacchi.
Il fatto che uno strumento nasca per facilitare il lavoro non lo rende sicuro, anzi, spesso questi strumenti o agevolazioni diventano proprio il tallone d’Achille di tutta l’infrastruttura stessa, spesso gli ambienti o i programmi/prodotti pensanti per gli ambienti produttivi o operativi tendono a sacrificare la sicurezza in nome della velocità e Marimo è uno di questi.
La CVE-2026-39987 è talmente semplice e banale nella sua dinamica che è disarmante: un endpoint WebSocket (/terminal/ws) espone un terminale interattivo senza autenticazione, con accesso diretto a una shell con i privilegi del processo. La sua semplicità non richiede nessuna tecnica avanzata, nessuna catena complessa di exploit ed è proprio questa semplicità a renderla letale perché abbassa la soglia d’ingresso a chiunque sappia leggere un advisory con un minimo di attenzione.
Questo, in un ecosistema in cui si tende a valutare la pericolosità di una vulnerabilità dalla sua complessità tecnica, espone il modello ad un utilizzo ed ad una pericolosità devastante, visto che non serve essere un ricercatore di sicurezza o un laboratorio attrezzato, basta semplicemente sapere dove guardare.
Nel giro di pochi istanti dall’accesso, l’attaccante si muove agilmente: verifica l’esecuzione dei comandi, esplora l’ambiente con i soliti whoami, pwd, ls, poi punta subito dove conta davvero. File .env, variabili d’ambiente, chiavi SSH, credenziali cloud tutto recuperato in meno di tre minuti, senza lasciare tracce evidenti. È una sequenza quasi chirurgica, che rivela una conoscenza precisa di cosa cercare e dove trovarlo; non è il comportamento di chi esplora a caso, ma di chi sa già quale sia il valore reale di un ambiente di sviluppo compromesso.
Il dato che cambia tutto è uno solo: “meno di 10 ore tra la disclosure pubblica e il primo sfruttamento documentato”. Evento da attenzionare proprio perchè non avviene dopo un exploit pubblico o dopo un PoC su GitHub. Questo significa che il vecchio modello mentale è saltato definitivamente e non esiste più una finestra di patch comoda in cui analizzare con calma, pianificare, testare. Disclosure, exploit e data exfiltration convivono ormai nello stesso arco temporale, e l’attaccante non aspetta più niente. Chi lavora in sicurezza deve fare i conti con questa realtà senza sconti: il tempo non è più dalla nostra parte, e fingere il contrario è un lusso che nessuna organizzazione può permettersi.
C’è però un dettaglio che passa quasi inosservato e che cambia davvero il quadro, questo accatto non sembra il classico attacco automatico che prova tutto finché arriva a destinazione. In questo caso qualcuno è entrato, qualcuno ha guardato, qualcuno ha provato due comandi e ha capito dove si trovava. Poi, successivamente, è tornato per lavorare con tutta calma. Questo è un comportamento molto più vicino a quello di un pentester che a uno script automatizzato e lanciato a caso su internet ed è questo il vero punto che fa la differenza oggi: non serve più aspettare il tool pronto all’uso, se l’attaccante sa leggere un advisory fatto bene, ha già metà del lavoro fatto, il resto routine, esperienza e capacità di muoversi in un ambiente sconosciuto senza fare rumore. La competenza, in questo contesto, vale più dell’automazione e questo dovrebbe preoccupare più di qualsiasi scanner.
Marimo in sé per se non è “il bersaglio grosso” è semplicemente uno di quegli strumenti nati per lavorare comodi, veloci e spesso in locale. quand’è che nasce il problema? quando, per praticità, quel “locale” diventa raggiungibile dall’esterno, un po per comodità ed un po per superficialità, magari per condividere un notebook con un collega, magari per lavorare da remoto, magari perché “tanto è solo temporaneo” ed è lì che si apre la porta. Il temporaneo ed il comodo vanno in contrapposizione con le sicurezza e questa è la combinazione più pericolosa che esista, perchè, come spesso accade, le configurazioni provvisorie diventano permanenti, i servizi esposti “per cinque minuti” restano online per settimane e la cosa più pericolosa di tutte è che nessuno ci torna sopra finché non succede qualcosa. Come ho sempre detto, non servono infrastrutture complesse per fare danni, bastano ambienti di sviluppo o industriali esposti senza controllo, servizi pubblicati di fretta, configurazioni lasciate aperte perché “è più comodo così”.
Inoltre, c’è anche una questione di visibilità che vale la pena nominare esplicitamente. Gli strumenti come Marimo spesso non rientrano nei perimetri monitorati dai team di sicurezza, la governance su questi prodotti/servizi non passano dai processi di approvazione IT, non vengono censiti negli asset register, non finiscono nelle scansioni periodiche, anzi , spesso, parlare di governance su questi ambienti è utopistico perchè vivono in una zona grigia tra il personale e il professionale, tra il prototipo e la produzione ed è proprio per questo che sfuggono ai controlli. Quando si usano paroloni come “shadow IT” non si fa un semplice inglesismo, ma, si cerca di dare la giusta evidenza ad un mondo spesso immerso nella nebbia e soprattutto non si immagina che questi ambienti di sviluppo locali esposti su una porta possano avere un WebSocket aperto.
Questo evento non è solo una vulnerabilità critica ma è un segnale preciso, una sorta di campanello d’allarme, di dove siamo arrivati e di come il modello reattivo non regge più. Oggi se un servizio è esposto il tempo tra vulnerabilità e compromissione si misura in minuti, non più in giorni. La sicurezza non può più partire dalla patch, deve partire dalla riduzione dell’esposizione, dalla mappatura reale di ciò che è raggiungibile dall’esterno, dalla consapevolezza che quando la vulnerabilità diventa pubblica, il problema è già in corso. Aspettare l’advisory per iniziare a ragionare non è una strategia; è una scommessa sul tempo, e il tempo, come dimostra questa storia, non è più dalla nostra parte.
