FortiBleed: perché una password trapelata bastava per prendere il controllo di un FortiGate

Il 6 ottobre 2026 l’FBI e il Secret Service statunitense hanno pubblicato un avviso congiunto su FortiBleed, una campagna contro i firewall Fortinet FortiGate esposti su Internet e i relativi gateway VPN (avviso FBI/USSS). L’avviso cita il conteggio di SOCRadar, che rileva oltre 86.644 dispositivi compromessi in 194 paesi, e descrive la campagna come tuttora in corso.

L’aspetto più notevole è ciò di cui gli attaccanti non hanno avuto bisogno. L’analisi di Fortinet è netta: «Non si tratta di una nuova vulnerabilità di Fortinet» (Fortinet PSIRT). Non è servito alcun exploit. Gli attaccanti hanno semplicemente effettuato l’accesso.

Come ha funzionato

L’avviso ricostruisce la campagna a partire dal server degli stessi attaccanti, che lo avevano lasciato esposto. In sintesi:

Trovare le pagine di accesso. Scansioni automatiche di Internet alla ricerca dei portali VPN FortiGate.
Provare password note. Credential stuffing e password spraying, alimentati da dump di precedenti fughe di dati Fortinet e dai log degli infostealer.
Craccare le restanti. Gli hash delle password sottratti ai dispositivi compromessi finivano su un cluster di GPU per il cracking offline. La debole memorizzazione SHA-256 legacy delle password degli amministratori ha facilitato il compito.
Restare dentro. Sul firewall venivano creati nuovi account amministratore. In alcuni casi gli account dei proprietari sono stati eliminati o le loro password modificate, e le vittime si sono ritrovate chiuse fuori dai propri dispositivi.
Vendere l’accesso. Configurazioni VPN funzionanti ed elenchi di bersagli venivano confezionati per altri criminali. L’avviso rileva che FortiBleed è stato un punto d’ingresso per gli affiliati ransomware.

Ogni fase precedente a «restare dentro» poggia su un unico presupposto: un nome utente e una password validi bastano per accedere alla VPN o all’interfaccia di amministrazione del firewall.

Che cosa spezza la catena

Togliete quel presupposto e gli strumenti principali della campagna smettono di funzionare. Se la VPN e la console di amministrazione richiedono anche un’approvazione sul telefono dell’utente, una password provata in massa, acquistata o craccata non equivale più a un accesso. È un tentativo fallito e, con un’approvazione leggibile, è anche un segnale: qualcuno ha appena usato quella password, e la persona a cui appartiene vede una richiesta che non ha avviato.

Sia l’avviso sia Fortinet collocano l’autenticazione a più fattori su ogni account amministratore e VPN tra le prime raccomandazioni. È la parte di cui si occupa Notakey. Un FortiGate può inviare gli accessi VPN e amministratore a un server RADIUS, e l’auth-proxy Notakey si inserisce in quel percorso RADIUS: lascia che il vostro server RADIUS esistente verifichi la password, poi chiede un’approvazione sul telefono e risponde di sì solo quando entrambe le verifiche hanno esito positivo. La configurazione è descritta nella nostra guida alla 2FA VPN con RADIUS.

Che cosa non risolve

Preferiamo essere precisi piuttosto che vendervi qualcosa.

Un dispositivo già compromesso. L’MFA sui nuovi accessi non può nulla contro gli account creati dagli attaccanti, le sessioni che già detengono o una configurazione che hanno modificato. Vengono prima le misure indicate dall’avviso stesso: terminare tutte le sessioni amministrative e VPN, reimpostare le password, confrontare utenti e configurazione con una copia sicuramente integra e memorizzare le password degli amministratori con PBKDF2 anziché con gli hash legacy.
Un’interfaccia di gestione esposta. La prima raccomandazione dell’avviso è limitare l’amministrazione da Internet: host attendibili (bene), una policy local-in (meglio) o nessuna amministrazione da Internet (l’ideale). Un secondo fattore su un’interfaccia che non dovrebbe essere raggiungibile è la soluzione più debole.
Pagine di phishing che inoltrano un accesso in tempo reale. L’avviso chiede un’MFA resistente al phishing. Secondo la definizione del governo statunitense, ciò significa FIDO/WebAuthn o PKI, dove la chiave è legata al sito reale. Un’approvazione sul telefono fa sì che una password provata in massa o craccata non basti più, ed è proprio su questo che la campagna faceva leva. Da sola, però, non ferma un attaccante che fa da proxy a un accesso reale attraverso una pagina falsa, come spieghiamo nel nostro articolo sull’MFA fatigue e sugli attacchi relay. Per i pochi account che amministrano il firewall stesso, vale la pena valutare chiavi legate al sito.

Se usate FortiGate

Tre indicazioni pratiche prima di mettere qualsiasi approvazione sul telefono davanti a un FortiGate. Provengono dalla documentazione di Fortinet; non abbiamo testato noi stessi un FortiGate in laboratorio, e un FortiGate comunica con l’auth-proxy tramite RADIUS standard come qualsiasi altro concentratore VPN.

Aumentate i timeout RADIUS. Per impostazione predefinita FortiGate concede all’intero scambio RADIUS 5 secondi (remoteauthtimeout) e reinvia una richiesta dopo 5 secondi (timeout sul server RADIUS) (Fortinet: come funzionano insieme i due timer). Bastano per una verifica della password, non perché una persona tiri fuori il telefono. L’auth-proxy tiene aperta la richiesta mentre l’utente decide (30 secondi per impostazione predefinita), quindi entrambi i valori devono superare ampiamente quella finestra. Il suggerimento di Fortinet osserva che, a valori uguali, il FortiGate invia comunque la richiesta una seconda volta. L’auth-proxy riconosce una richiesta reinviata e la ignora, quindi l’utente non deve approvare una seconda volta, ma impostare il timeout di reinvio come il più lungo dei due fa sì che lo scambio si limiti a una sola richiesta. Per esempio, 60 secondi in totale e 90 prima di un reinvio (notakey-proxy sta per il nome che avete dato alla voce del server RADIUS che punta all’auth-proxy):
```
config system global
    set remoteauthtimeout 60
end

config user radius
    edit "notakey-proxy"
        set timeout 90
    next
end
```
Gli amministratori possono usare lo stesso percorso. FortiGate supporta l’autenticazione remota degli amministratori tramite un server RADIUS (Fortinet: autenticazione remota per gli amministratori), compreso un account amministratore wildcard per tutti i membri di un gruppo RADIUS (Fortinet: configurazione degli account amministratore wildcard). In questo modo l’approvazione protegge anche la console a cui puntavano gli attaccanti, non solo la VPN.
Tenete sempre una via di rientro. FortiBleed ha chiuso i proprietari fuori dai loro stessi dispositivi. Mantenete un amministratore locale di emergenza con una password lunga e univoca, raggiungibile solo da host attendibili, e provatelo prima di averne bisogno.

Da dove iniziare

Verificate tre cose questa settimana: se l’amministrazione del vostro firewall è raggiungibile da Internet, se qualche account VPN o amministratore accede ancora con la sola password e come sono memorizzate le password degli amministratori. Se la risposta alla seconda domanda è sì, quella è proprio la falla per cui FortiBleed è stato costruito.

Provate la demo dal vivo per approvare un accesso dal vostro telefono in circa due minuti, oppure richiedete una demo e mapperemo i vostri accessi VPN e firewall su un progetto pilota.