Attacco a Marimo: Come un Hacker Umano ha Conquistato un Bastion in 8 Secondi
La recente dimostrazione di un attacco contro il notebook Marimo ha messo in luce una realtà preoccupante: gli aggressori esperti possono muoversi a velocità quasi automatica senza alcun supporto di intelligenza artificiale. In otto secondi, un operatore ha sfruttato una vulnerabilità RCE per ottenere l’accesso a un bastion SSH, dimostrando che la maestria umana resta una minaccia di primo piano. Questo caso evidenzia come le catene di credenziali, le chiamate a servizi cloud e gli script personalizzati possano essere orchestrati in pochi istanti, mettendo a dura prova le difese tradizionali. L’analisi di Sysdig fornisce spunti cruciali per comprendere le tattiche, le tecniche e le procedure (TTP) adottate da questi attori, e per rafforzare le contromisure in ambienti ibridi e multi‑cloud.
- Tempo medio di pivot da RCE a bastion: 8 secondi, pari alla velocità tipica di attacchi assistiti da AI.
- Utilizzo di un toolkit Python “hand‑rolled” senza dipendenze da framework noti, evitando firme di rilevamento tradizionali.
- Catena di credential‑pivot completa: RCE → AWS Secrets Manager → chiave SSH privata → accesso al bastion.
Rilevanza Strategica: CRITICA
1. La vulnerabilità di Marimo e il contesto di sfruttamento
Il CVE‑2026‑39987, con un punteggio CVSS di 9.3, è una vulnerabilità di remote code execution pre‑autenticata che colpisce tutte le versioni del notebook Marimo. La sua gravità deriva dalla possibilità di aprire un canale WebSocket verso l’endpoint “/terminal/ws”, consentendo l’esecuzione di comandi arbitrari sul server. Dopo la divulgazione pubblica, la vulnerabilità è stata sfruttata entro poche ore, dimostrando la rapidità con cui i threat actor possono passare dalla scoperta alla compromissione. Sysdig ha tracciato la prima connessione al server da parte dell’attaccante (IP 172.236.12[.]17) alle 12:52 p.m., seguita da una sequenza di operazioni che hanno portato, entro 8 secondi, alla creazione di una sessione SSH sul bastion host. Questo scenario evidenzia due punti critici: la mancanza di protezioni di rete per isolare i notebook interattivi e l’insufficiente monitoraggio dei canali WebSocket, spesso trascurati dagli strumenti di sicurezza tradizionali.
2. La catena di credential‑pivot: da Marimo a AWS Secrets Manager
Una volta ottenuto un shell interattiva sul nodo compromesso, l’attaccante ha eseguito un toolkit Python sviluppato ex‑novum. Il codice ha effettuato una chiamata a AWS Secrets Manager, sfruttando le credenziali di IAM associate all’istanza EC2 vulnerabile. Da lì, è stata estratta una chiave privata SSH memorizzata come segreto, che è stata scritta su disco locale e immediatamente utilizzata per autenticarsi al bastion host. La capacità di interagire con i servizi cloud senza lasciare tracce evidenti (nessun tool pubblico riconoscibile) rende questa fase particolarmente pericolosa: i log di AWS possono mostrare solo chiamate legittime se non sono correttamente correlati con l’attività di rete interna. Inoltre, l’attaccante ha mantenuto una sessione di nove ore, eseguendo più di 850 comandi interattivi, dimostrando che la rapidità iniziale non esclude una fase di “dwell time” prolungata per l’esfiltrazione di dati o per il posizionamento di backdoor persistenti.
3. Implicazioni per la difesa e raccomandazioni operative
Il caso Marimo evidenzia la necessità di adottare un approccio difensivo a più livelli. Prima di tutto, è fondamentale isolare i notebook interattivi dietro firewall a livello di applicazione e limitare l’accesso ai WebSocket solo a indirizzi IP autorizzati. L’attivazione di sistemi di detection basati su comportamento (UEBA) può rilevare pattern anomali come l’avvio di processi Python non firmati o l’uso di canali di rete insoliti. In secondo luogo, le credenziali di IAM devono essere gestite con il principio del “least privilege” e le chiamate a Secrets Manager dovrebbero essere monitorate con alert specifici per accessi da IP interni non comuni. Infine, la sicurezza del bastion host deve includere l’uso di MFA, la rotazione frequente delle chiavi SSH e il logging dettagliato di tutte le sessioni SSH, integrato con un SIEM capace di correlare eventi cloud e on‑premise. Implementare queste misure non elimina la possibilità di attacchi manuali veloci, ma riduce drasticamente la superficie di attacco e aumenta le probabilità di rilevare e contenere le intrusioni prima che possano compromettere asset critici.
In conclusione, sebbene l’AI stia accelerando il ritmo delle minacce, la competenza umana resta un fattore decisivo. Gli operatori esperti possono ancora costruire exploit su misura, aggirare le trappole automatizzate e sfruttare vulnerabilità complesse con una velocità sorprendente. Le organizzazioni devono quindi combinare tecnologie avanzate di rilevamento con processi di hardening rigorosi, garantendo una visibilità completa su tutte le fasi della catena di attacco. Solo così sarà possibile mitigare il rischio di compromissioni rapide e mantenere una postura di sicurezza resiliente nel panorama attuale.