Fortinet, ecco come mitigare la vulnerabilità di bypass dei sistemi di autenticazione

Fortinet sta esortando i suoi clienti a patchare urgentemente le proprie appliance contro la vulnerabilità critica di bypass dell’autenticazione nei sistemi FortiOS, FortiProxy e FortiSwitchManager in quanto risulta essere già sfruttata in attacchi.

L’exploit, infatti, non si è fatto attendere e lo zero-day era già in vendita a 0,673 bitcoin, circa 12.600 dollari, prima ancora della diffusione dei vari Proof Of Concept (PoC).

Inoltre, nelle ultime 24h, si è osservato un rapido aumento dei tentativi di sfruttare questa vulnerabilità. Con un trend in aumento adesso che i vari PoC sono disponibili pubblicamente in rete.

I dettagli della vulnerabilità nei sistemi Fortinet

Ricordiamo che la grave vulnerabilità era stata resa pubblica dalla stessa Fortinet con un “Security Bulletin” datato 7 ottobre 2022.

Se sfruttata, consente a un attaccante di bypassare il sistema di autenticazione, garantendosi l’accesso all’interfaccia di amministrazione, il tutto da remoto. La vulnerabilità è nota con il Common Vulnerabilities and Exposure CVE-2022-40684 e ha un punteggio secondo il Common Vulnerbility Scoring System (CVSSv3) di 9.6 su 10.

Per realizzare la gravità e l’estensione di questa vulnerabilità ci basta pensare all’utilizzo e alla distribuzione a livello mondiale dei sistemi Fortinet. Dando una rapida occhiata con Shodan sulla diffusione dei prodotti Fortinet possiamo notare che l’italia rientra nei top dieci, all’ottavo posto.

Quali sistemi affligge la vulnerabilità

I sistemi impattati dalla vulnerabilità sono i seguenti:

• FortiOS version 7.2.0 through 7.2.1
• FortiOS version 7.0.0 through 7.0.6
• FortiProxy version 7.2.0
• FortiProxy version 7.0.0 through 7.0.6
• FortiSwitchManager version 7.2.0, and
• FortiSwitchManager version 7.0.0

Come funziona la vulnerabilità nei sistemi Fortinet

FortiOS gestisce le chiamate API inoltrando tutte le richieste ad un’interfaccia accessibile esclusivamente dall’interno, responsabile del processo di autenticazione.

L’attaccante può sfruttare la vulnerabilità mascherando la chiamata API come se fosse una chiamata del sistema interno, autenticandosi così su tutti gli endpoint API esposti all’esterno.

Difatti il sistema effettua diverse chiamate ad una funzione, soprannominata dai ricercatori, api_check_access.

Esaminando la funzione, ne salta subito all’occhio un’altra, chiamata api_check_access_for_trusted_source che prima controlla se l’opzione socket vdom è attendibile e poi passa ad una funzione, soprannominata is_trusted_ip_user_agent.

La funzione controlla che il parametro client_ip sia 127.0.0.1 e che l’header dello User-Agent corrisponda con il secondo parametro. La chiamata alla funzione viene fatta tramite due parametri: Node.js e Report Runner. Il primo sembra aggiungere una convalida, mentre il secondo parametro ci consente di bypassare l’autenticazione ed eseguire chiamate API.

Quindi, per sfruttare la vulnerabilità, all’utente malintenzionato gli basterà:

• utilizzando il “Farwarded header” impostere il parametro client_ip al valore 127.0.0.1;
• utilizzare lo user-agent Report Runner.

Qualsiasi richiesta HTTP verso l’interfaccia che soddisfa queste condizioni, mette il sistema completamente nelle mani dell’attaccante che a questo punto è in grado di modificare le configurazioni di rete o aggiungere un nuovo utente a quelli già presenti.

Nota: esistono altre versioni dell’exploit che sfruttano la vulnerabilità, utilizzando un insieme di condizioni diverse, ad esempio, utilizzando lo User-Agent: Node.js.

Potremmo sintetizzare la nostra richiesta http nel seguente modo:

PUT /api/v2/cmdb/system/admin/admin HTTP/1.1

Host: {{Hostname}}
User-Agent: Report Runner
Content-Type: application/json
Forwarded: for=[127.0.0.1]:8000;by=[127.0.0.1]:9000;
Content-Length: 610
{
“ssh-public-key1”: “fake-key”
}

Nella figura sottostante, invece, è riportato il codice Python del PoC disponibile anche su GitHub.

Gli IoC che rivelano accessi non autorizzati

I log del device compromesso presentano la seguente stringa, nella colonna “User”:

user=”Local_Process_Access”

come abbiamo visto precedentemente anche la presenza di un entry, Node.js o Report Runner nella colonna “User Interface” rappresenta un IoC.

Come mitigare la vulnerabilità

È disponibile la patch ufficiale che permette il fix della vulnerabilità, eseguendo l’upgrade alle seguenti versioni:

• FortiOS version 7.2.2 o successive;
• FortiOS version 7.0.7 o successive;
• FortiProxy version 7.2.1 o successive;
• FortiProxy version 7.0.7 o successive;
• FortiSwitchManager version 7.2.1 o successive.

Il workaround se non è possibile applicare la patch

È utile segnalare che Fortinet ha pubblicato anche un workaround che consente di mettere in sicurezza i sistemi Fortinet impattati dalla vulnerabilità anche quando non è possibile applicare la patch.

Innanzitutto, occorre disabilitare l’accesso HTTP/HTTPS all’interfaccia. In alternativa, è utile circoscrivere il range di indirizzi IP che può accedere all’interfaccia:

config firewall address
edit “my_allowed_addresses”
set subnet <MY IP> <MY SUBNET>
end

Successivamente creare un Address Group:

config firewall addrgrp
edit “MGMT_IPs”
set member “my_allowed_addresses”
end

Quindi, creare la policy per restringere l’accesso solo al gruppo predefinito:

config firewall local-in-policy
edit 1
set intf port1
set srcaddr “MGMT_IPs”
set dstaddr “all”
set action accept
set service HTTPS HTTP
set schedule “always”
set status enable
next
edit 2
set intf “any”
set srcaddr “all”
set dstaddr “all”
set action deny
set service HTTPS HTTP
set schedule “always”
set status enable
end

Se la porte non sono quelle di default, è necessario creare un oggetto per l’accesso amministrativo alla GUI:

config firewall service custom
edit GUI_HTTPS
set tcp-portrange <admin-sport>
next
edit GUI_HTTP
set tcp-portrange <admin-port>
end

usando l’accortezza di tilizzare i due “oggetti” invece di “http e https”

Il workaround per i sistemi Fortinet FortiProxy

Disabilitare l’accesso HTTP/HTTPS all’interfaccia. In alternativa, circoscrivere il range di indirizzi IP che può accedere all’interfaccia:

config system interface
edit port1
set dedicated-to management
set trust-ip-1 <MY IP> <MY SUBNET>
end