SonicWall SMA1000: patchi, resetti le password, e sono ancora dentro

Il reset che non serve a niente

Quando un'appliance di sicurezza viene compromessa, il manuale di risposta è quasi sempre lo stesso: si applica la patch, si cambiano le password, si torna al lavoro. È il riflesso giusto per la maggior parte degli incidenti. Per quello che è successo a luglio 2026 sulle appliance SonicWall SMA1000, non basta — e capire perché non basta è tutto il senso di questo dossier.

Il 14 luglio 2026 SonicWall pubblica l'advisory SNWLID-2026-0008 per due falle sulla serie SMA1000: CVE-2026-15409, un Server-Side Request Forgery con CVSS 10.0, e CVE-2026-15410, una code injection con CVSS 7.2. Entrambe, scrive il vendor, «confermate come attivamente sfruttate in the wild». La squadra di Managed Detection and Response di Rapid7 le aveva viste in azione prima della disclosure: erano zero-day.

Un proxy che il dispositivo offre di suo

La prima falla non richiede una password. L'appliance SMA1000 espone, sull'applicazione «SonicWall WorkPlace» servita sulla porta 443, una funzione di proxy websocket raggiungibile al percorso /wsproxy. Quella funzione apre un tunnel TCP — un netcat via browser — verso l'host e la porta che gli passi nei parametri dell'URL. Il difetto è che non controlla dove punti quel tunnel. Se gli chiedi localhost, ti apre un canale verso i servizi interni che l'appliance tiene dietro il proprio firewall, mai pensati per essere raggiunti da fuori.

1. 01
   /wsproxy esposto

   tunnel websocket verso host e porta a scelta dell'attaccante
2. 02
   host = localhost

   il tunnel punta ai servizi interni dell'appliance
3. 03
   Erlang su :1050

   il cookie di autenticazione è cablato nel codice: nessuna password
4. 04
   comando come root

   remove_hotfix con path traversal esegue uno script come root

Questi servizi interni sono meno induriti proprio perché «tanto stanno su localhost». Rapid7 ha scritto un exploit contro il processo Erlang in ascolto su localhost:1050: il cookie che quel processo usa per autenticare le chiamate è cablato nel codice, uguale su ogni dispositivo, quindi non serve conoscere alcun segreto. Da lì, una chiamata RPC os:cmd esegue comandi di sistema. Il primo passo era finito: da internet, senza credenziali, a esecuzione di codice sull'appliance — nel contesto dell'utente couchdb.

Da localhost a root

Il secondo bug serve a diventare amministratore. CVE-2026-15410 è un path traversal nel flusso remove_hotfix del servizio ctrl-service, che ascolta sulla porta 8188. Il servizio si aspetta il nome di un hotfix da rimuovere; l'attaccante gli passa invece una sequenza di traversamento come ../../../../var/tmp/privesc che punta a uno script che ha già caricato sul dispositivo. Il sistema lo rende eseguibile e lo lancia come root, per poi riavviare l'appliance. Nei log di monitoraggio di sistema recuperati da Rapid7 la sequenza è visibile riga per riga: chmod +x, esecuzione dello script, shutdown -r now. La catena — SSRF senza autenticazione, poi esecuzione codice, poi escalation a root — è completa.

Ma se il dossier finisse qui, sarebbe un normale bollettino di patching. Il punto viene dopo.

Cosa hanno portato via

Con l'accesso root, gli attaccanti non hanno installato ransomware. Hanno svuotato l'appliance di tre cose precise: le credenziali ad alto valore, i database delle sessioni attive e le configurazioni dei semi TOTP — i segreti condivisi che generano i codici a sei cifre dell'autenticazione a più fattori. Rapid7 è esplicita sul motivo: questa raccolta locale «era progettata per garantire un accesso persistente a lungo termine, capace di sopravvivere alle normali bonifiche a livello di rete».

Qui sta la ragione per cui il riflesso «patcha e cambia le password» fallisce. La password la puoi cambiare. Il token di sessione già emesso lo puoi invalidare, se ci pensi. Ma il seme TOTP è il segreto che sta dietro al secondo fattore: è la rete di sicurezza pensata per il giorno in cui la password trapela. Se l'attaccante se n'è andato con quel seme, può generare da sé i codici MFA validi di ogni utente — e continuerà a farlo dopo la patch, dopo il reset delle password, finché quei semi non vengono rigenerati uno per uno. Non a caso, l'unica lista di rimedi che cita esplicitamente il reset dei token TOTP è quella di un vendor che ha visto la compromissione da vicino.

Il backdoor dentro Active Directory

Raccolto il materiale, gli attaccanti si sono spostati verso l'interno. Rapid7 ha osservato una sequenza che descrive bene cosa significa perdere un'appliance di questo tipo: autenticazioni verso i domain controller senza alcun tunnel VPN attivo, originate direttamente dall'indirizzo IP interno dell'appliance, con nomi di workstation che non appartengono all'inventario aziendale — kali fra gli altri — sotto il contesto dell'account di servizio LDAP integrato nell'appliance stessa.

1. 9 luglio 2026
   Prima della disclosure

   I log di sistema catturano l'escalation a root in corso.

2. 14 luglio 2026
   L'advisory

   SonicWall pubblica SNWLID-2026-0008: due falle, sfruttamento confermato.

3. 14 luglio 2026
   CISA KEV

   Entrambe le CVE entrano nel catalogo, sotto la direttiva BOD 26-04.

4. 15 luglio 2026
   Rapid7

   Il team MDR pubblica l'analisi tecnica e un PoC per l'SSRF.

5. 16 luglio 2026
   Gli IOC

   Rapid7 aggiunge i nomi delle workstation e gli IP usati dagli attaccanti.

Un'appliance di accesso remoto è, per definizione, il ponte fra internet e la rete interna: è pensata per parlare con Active Directory. Quando è l'attaccante a guidarla, quel ponte legittimo diventa un canale di ingresso non monitorato — perché il traffico non arriva da un client VPN sospetto, arriva dall'apparato che deve parlare con i domain controller.

Cosa non sappiamo

Vale la regola di questo sito: dire dove finisce la certezza.

• Non c'è attribuzione. Rapid7 non nomina alcun gruppo. Gli IP osservati appartengono a un provider di hosting VPN (FNS Holdings Limited, ASN 206092): infrastruttura noleggiata e anonimizzata, che dice poco su chi ci sta dietro.
• Il racconto dell'intrusione poggia in gran parte su un solo vendor. SonicWall conferma lo sfruttamento in the wild, ma la ricostruzione dettagliata delle mosse post-accesso — furto dei semi TOTP, movimento laterale VPN-less — è di Rapid7. Forte, coerente con gli IOC pubblicati, ma per ora non replicata da terzi indipendenti.
• Il movente resta aperto. Nessun ransomware osservato finora. Furto di credenziali, persistenza durevole e pivot verso l'AD sono compatibili tanto con lo spionaggio quanto con un pre-posizionamento in vista di un'azione successiva. Dire quale sarebbe indovinare.
• Gli ID ATT&CK in testa a questo dossier sono una mappatura ragionata, non copiati da un advisory: né SonicWall né Rapid7 pubblicano un mapping ufficiale. Descrivono i comportamenti osservati, non una fonte primaria.

Cosa si fa

Prima di tutto la patch, perché non esistono workaround: portare le appliance SMA1000 (6210, 7210, 8200v e CMS) alle versioni 12.4.3-03453 o 12.5.0-02835 e superiori. Ma — ed è il punto dell'intero dossier — la patch da sola presume che tu non sia già stato colpito, e lo sfruttamento è confermato dal 9 luglio. Quindi: analisi forense dell'appliance per gli indicatori di compromissione; se ne trovi anche uno, tratta il dispositivo come compromesso e re-immagina l'hardware o ridistribuisci la macchina virtuale, cambia le password di utenti e amministratori e resetta i token TOTP — non è un passaggio decorativo, è quello che chiude la porta che il solo reset delle password lascia aperta.

Per la caccia retrospettiva gli indicatori sono documentati: nel extraweb_access.log, richieste a /wsproxy con parametri host sospetti che tornano HTTP 101, e richieste a /__api__/login o /__api__/logout con esito 200; nel ctrl-service.log, rimozioni di hotfix con un nome che contiene un path traversal; e sul lato Windows, logon NTLM (Event ID 4624, logon type 3) verso i domain controller originati dall'IP interno dell'appliance, con nomi di workstation come kali e senza una sessione VPN corrispondente.

Un CVE ti dà una versione da correggere e una data entro cui farlo. Un seme TOTP rubato non ha né l'una né l'altra: resta valido finché non lo rigeneri tu. La patch chiude la finestra da cui sono entrati. Non chiude quella che si sono portati via.