Analisi delle tecniche di post-sfruttamento delle VPN
Analisi riassuntiva
In questo blog, i ricercatori di Akamai evidenziano la minaccia sottovalutata del post-sfruttamento delle VPN; in altre parole, utilizziamo tecniche che possono essere usate dagli autori delle minacce dopo aver violato un server VPN per penetrare ulteriormente nella rete.
Tra i risultati della ricerca, figurano varie vulnerabilità che hanno influito sulle VPN di Ivanti Connect Secure e FortiGate.
Oltre alle vulnerabilità, viene descritta una serie di tecniche senza correzione che possono influire sui prodotti di Ivanti Connect Secure e FortiGate, nonché, potenzialmente, su altri server VPN.
Dalla nostra ricerca, emerge come, in molti casi, un server VPN violato potrebbe consentire ai criminali di ottenere facilmente il controllo su altre risorse critiche presenti nella rete.
Questo blog si propone di aumentare la consapevolezza di questi rischi e presentare le best practice da seguire per gli addetti alla sicurezza al fine di minimizzare i rischi legati alle tecniche di post-sfruttamento delle VPN.
Introduzione
Tutti abbiamo sentito già questa storia: una vulnerabilità critica è stata scoperta in un server VPN e sfruttata in rete. Gli amministratori si affrettano a correggerla con le patch. Il panico si diffonde sui social media.
L'anno scorso è stato alquanto impegnativo per la sicurezza delle VPN: sembrava come se ogni mese una vulnerabilità critica venisse corretta con una patch o scoperta dopo essere stata sfruttata in rete dai criminali. Anche se questo tipo di attività ha registrato un notevole incremento nel 2023, non è una novità. I criminali da tempo cercano di sfruttare i server VPN perché sono accessibili da Internet, presentano una vasta superficie di attacco e mancano spesso di sistemi di sicurezza e monitoraggio.
Storicamente, i server VPN sono stati principalmente violati per conseguire un solo obiettivo: l'accesso iniziale ad una rete. I criminali violano i server VPN su Internet e li usano per creare una falla iniziale alla rete interna per poi condurre le loro intrusioni.
Anche se questo approccio è molto efficace, ci chiediamo: il controllo su un server VPN deve essere considerato solo come porta di accesso alla rete?
Vogliamo esaminare cos'altro è possibile fare.
Il blog riportato di seguito esplora le tecniche di post-sfruttamento delle VPN che possono essere usate da un criminale che ha già violato un server VPN con altri mezzi (vulnerabilità, credenziali rubate, ecc.) per conseguire ulteriori obiettivi.
Sfruttare le VPN
L'approccio principale utilizzato dai criminali per eseguire le tecniche di post-sfruttamento consiste nel prendere di mira il sistema operativo di un dispositivo. Dopo aver ottenuto l'esecuzione di codice remoto (RCE), un criminale può inserire un impianto personalizzato sul sistema operativo del dispositivo preso di mira. Da questo punto, il criminale può controllare ogni aspetto della VPN, ad esempio, può utilizzare apposite funzioni per esfiltrare informazioni sensibili, tentare di eludere il rilevamento manipolando i registri o modificare la configurazione del sistema per mantenere la persistenza sul dispositivo.
Anche se questo approccio offre molti vantaggi, presenta uno svantaggio principale: è costoso. Poiché le apparecchiature, di solito, vengono eseguite su un sistema operativo personalizzato, l'impegno richiesto per sviluppare e mantenere un impianto personalizzato su un dispositivo VPN può risultare significativo. Pertanto, le tecniche di post-sfruttamento delle VPN, di solito, venivano usate solo da criminali di alto livello sostenuti dai governi.
Un approccio diverso
Abbiamo deciso di esaminare un approccio diverso, ossia una forma "più semplice" di post-sfruttamento delle VPN. Invece di basarci su un impianto personalizzato eseguito su un sistema operativo, abbiamo deciso di abusare della funzionalità del dispositivo esistente. Ci siamo chiesti: Cosa può fare un criminale se utilizza solo l'interfaccia di gestione delle VPN?
Questo approccio, che consiste nello sfruttare le VPN, presenta almeno due vantaggi.
Questo tipo di accesso può essere più semplice da ottenere rispetto ad una RCE completa: è possibile ottenere l'accesso all'interfaccia di gestione tramite una vulnerabilità di elusione dell'autenticazione, credenziali deboli o un attacco di phishing.
Questo approccio può risultare più vantaggioso in termini di costi, evitando così di dover sviluppare un payload personalizzato.
Per i nostri test, abbiamo scelto di prendere di mira due dei principali server VPN disponibili sul mercato: Ivanti Connect Secure e FortiGate. Abbiamo scoperto 2 CVE e una serie di tecniche senza correzione che possono essere usate dai criminali che controllano il server VPN per assumere il controllo di altre risorse critiche presenti nella rete, trasformando quindi potenzialmente una violazione della VPN in una violazione dell'intera rete.
Anche se la nostra ricerca si è focalizzata su FortiGate e Ivanti, riteniamo che alcune variazioni delle tecniche che abbiamo osservato siano probabilmente applicabili ad altri server VPN e dispositivi edge.
L'abuso di server di autenticazione remoti
Alcune delle risorse più interessanti gestite da un server VPN sono le credenziali esterne. Anche se i server VPN supportano l'utilizzo di utenti locali per l'autenticazione, in molti casi viene usato un server di autenticazione esterno.
Anziché mantenere un set separato di credenziali per ogni utente, gli amministratori possono scegliere di usare un provider di identità esistente per autenticare i loro utenti. L'utente invia le proprie credenziali "normali" al server VPN, che vengono confermate tramite il server di autenticazione remoto (Figura 1).
Figura 1. Utilizzo di un server di autenticazione remoto per autenticare gli utenti
A tal scopo, è possibile usare vari tipi di server di autenticazione, ma le 2 opzioni principali sono i server LDAP e RADIUS.
Abbiamo identificato alcune tecniche che possono consentire ai criminali di sfruttare questo comportamento per violare le credenziali esterne e, di conseguenza, accedere, potenzialmente, ad altre risorse presenti nella rete.
Intercettazione delle credenziali LDAP
Un server di autenticazione molto popolare per le VPN è il server LDAP, più comunemente un controller di dominio Active Directory (AD). Con questa configurazione, gli utenti possono accedere alla VPN tramite le proprie credenziali di dominio, il che la rende un'opzione molto conveniente.
Durante la configurazione di un server di autenticazione LDAP, vengono fornite le credenziali di un account di servizio AD per consentire alla VPN di verificare le informazioni sugli utenti. Un esempio di questa configurazione in FortiGate è illustrato nella Figura 2.
Figura 2. Configurazione del server di autenticazione LDAP nella GUI di FortiGate
Quando un utente tenta di accedere a FortiGate o Ivanti tramite le credenziali LDAP, la VPN le verifica contattando il server LDAP. L'esatta implementazione varia leggermente tra un server e l'altro, quindi li analizzeremo entrambi.
Autenticazione delle credenziali LDAP in FortiGate
Per verificare le credenziali, FortiGate tenta di usarle per effettuare l'autenticazione sul server remoto. Questo processo viene eseguito tramite un semplice processo di autenticazione , in cui FortiGate invia la password al server in testo non crittografato (Figura 3).
Figura 3. Una semplice associazione LDAP rende visibile la password dell'utente in testo non crittografato
Durante questo processo, vengono trasmessi due set di credenziali: le credenziali dell'account di servizio LDAP configurate su FortiGate e le credenziali fornite dall'utente che effettua l'autenticazione. Entrambi vengono inviati in testo non crittografato.
Anche se la configurazione predefinita prevede le credenziali LDAP, FortiGate supporta, inoltre, i protocolli LDAP e TLS, che dovrebbero impedire la comunicazione in testo non crittografato.
Autenticazione delle credenziali LDAP in Ivanti
L'implementazione di Ivanti per l'autenticazione LDAP è leggermente diversa e supporta due tipi di server di autenticazione LDAP: il server LDAP normale e Active Directory (Figura 4).
Figura 4. Opzioni del server di autenticazione di Ivanti, inclusi i server LDAP e Active Directory
Server di autenticazione LDAP
Con un server di autenticazione LDAP, il processo è molto simile a quello di FortiGate, ossia quando vengono usate le credenziali LDAP non crittografate, viene eseguita una semplice associazione e l'account di servizio AD e le credenziali dell'utente che effettua l'autenticazione vengono trasmessi in testo non crittografato (Figura 5).
Figura 5. Ivanti trasmette le credenziali LDAP in testo non crittografato
Tuttavia, durante la configurazione di un server di autenticazione LDAP, l'impostazione predefinita prevede le credenziali TLS, ma sono anche supportate le credenziali LDAP. Pertanto, è meno probabile che le istanze di Ivanti utilizzino le credenziali LDAP non crittografate.
Server di autenticazione AD
Il secondo tipo di server di autenticazione LDAP che è possibile configurare è un server AD. Con questa opzione, l'autenticazione viene eseguita tramite Kerberos, quindi non viene trasmessa alcuna password (Figura 6).
Figura 6. Autenticazione LDAP tramite Kerberos
Acquisizione delle credenziali LDAP in testo non crittografato
Per FortiGate e Ivanti, le credenziali LDAP non crittografate, che vengono usate per autenticare un utente e inviate alla VPN, possono venire potenzialmente violate da un criminale che si trova tra la VPN e il server LDAP o che controlla il server VPN.
In che modo è possibile acquisire le credenziali senza inserire un impianto sul dispositivo? Fortunatamente per noi, FortiGate e Ivanti includono una funzione integrata per l'acquisizione di pacchetti. Usando questa funzione per acquisire i pacchetti LDAP, un criminale può intercettare tutte le credenziali che vengono trasmesse sulla VPN (Figura 7).
Figura 7. Utilizzo della funzione di acquisizione dei pacchetti di FortiGate o Ivanti per acquisire le comunicazioni LDAP
Nei casi in cui viene usato un protocollo sicuro, dal server non viene inviata alcuna credenziale in testo non crittografato. Ciò nonostante, un criminale se controlla la VPN può comunque acquisire le credenziali facilmente. Se controlliamo la VPN, non c'è nulla che ci impedisca di modificare la configurazione e cambiarla con le credenziali LDAP non crittografate.
Per i server LDAP normali, possiamo semplicemente cambiare la configurazione con le credenziali LDAP non crittografate. Per eseguire il downgrade di un server AD di Ivanti, possiamo usare le informazioni di connessione AD per configurare un nuovo server LDAP invece di quello esistente. In entrambi i casi, questo cambiamento sarà visibile per gli utenti e forzerà la VPN a inviare le password in testo non crittografato.
In conclusione: se viene usata l'autenticazione LDAP, indipendentemente dalla configurazione, un criminale che viola la VPN riuscirà ad ottenere facilmente le credenziali e a introdursi nel dominio.
Registrazione di un server di autenticazione fittizio
Come abbiamo detto, durante l'autenticazione di un utente remoto, la VPN contatta il server di autenticazione appropriato per verificare le credenziali fornite. Abbiamo identificato un metodo che abusa di questo flusso di autenticazione per violare le credenziali fornite da un utente alla VPN.
Questa tecnica si basa sulla registrazione di un server di autenticazione fittizio che verrà usato dalla VPN per l'autenticazione degli utenti. Per aiutare a comprendere come viene effettuata l'implementazione, dobbiamo prima descrivere alcuni dettagli del processo di autenticazione su entrambe le VPN.
Gruppi di utenti di FortiGate
È possibile concedere agli utenti di FortiGate diverse autorizzazioni e applicarvi diverse policy. Anziché gestire ogni utente singolarmente, è possibile includere gli utenti in appositi gruppi, a cui è possibile applicare policy e autorizzazioni.
Durante la configurazione di un gruppo di questo tipo, possiamo includere gli utenti provenienti da gruppi remoti, ossia presenti su un server di autenticazione remoto, ad esempio, possiamo includere gli utenti appartenenti ad uno specifico gruppo AD (Figura 8).
Figura 8. Configurazione del gruppo di utenti di FortiGate
Abbiamo osservato un comportamento interessante che si verifica durante l'utilizzo di gruppi remoti. Andiamo a configurare un gruppo di utenti che include due entità: un utente FortiGate locale e un gruppo remoto presente su un server LDAP.
Per quanto riguarda l'autenticazione, ci aspetteremmo il seguente comportamento:
Quando il membro locale del gruppo esegue l'autenticazione su FortiGate, le sue credenziali verranno verificate tramite il database degli utenti locali di FortiGate.
Quando un membro del gruppo remoto esegue l'autenticazione su FortiGate, le sue credenziali verranno verificate tramite il server LDAP del gruppo remoto.
Tuttavia, si vedrà che non è questo il caso. Dopo aver aggiunto un gruppo remoto ad un gruppo di utenti, ogni volta che qualsiasi membro del gruppo di utenti esegue l'autenticazione, FortiGate tenterà di verificare le credenziali fornite tramite il database degli utenti locali e il server di autenticazione remoto. Inoltre, se aggiungiamo più di un server remoto ad un gruppo di utenti, FortiGate tenterà di autenticare gli utenti tramite tutti i server di autenticazione configurati.
Essenzialmente, FortiGate non associa uno specifico utente con il suo metodo di autenticazione appropriato, ma semplicemente li tenta tutti. In caso di esito positivo, l'utente viene autenticato.
I regni dell'autenticazione di Ivanti
Ivanti presenta una funzione simile ai gruppi di utenti denominata i regni dell'autenticazione. A differenza dei gruppi di utenti di FortiGate, ogni regno dell'autenticazione di Ivanti è limitato ad un solo server di autenticazione. Per gestire gli utenti di diversi server, è necessario usare regni separati.
Nonostante questa limitazione (e meglio per noi), Ivanti ci consente di configurare un "server di autenticazione aggiuntivo" (Figura 9). Questa opzione consente di impostare alcune configurazioni SSO.
Figura 9. Configurazione di un server di autenticazione aggiuntivo per un regno di utenti di Ivanti
Quando viene configurato un server di autenticazione aggiuntivo, Ivanti tenterà di verificare le credenziali utilizzando entrambi i server. L'autenticazione ha esito positivo solo se viene approvata da entrambi i server.
Creazione di un server di autenticazione fittizio per esfiltrare le credenziali
Un criminale può abusare di questi comportamenti per esfiltrare le credenziali di un utente che esegue l'autenticazione su FortiGate o Ivanti, utilizzando un qualsiasi tipo di server di autenticazione remoto. Aggiungendo un server di autenticazione fittizio ad un regno o un gruppo di utenti, possiamo causare una fuga di credenziali dal server VPN su un server controllato dal criminale (Figura 10).
Figura 10. Aggiunta di un server di autenticazione fittizio per violare le credenziali del client
Queste credenziali potrebbero appartenere a client che si connettono alla VPN o ad amministratori che si connettono all'interfaccia di gestione. Qualsiasi autenticazione gestita tramite un regno o un gruppo di utenti potrebbe venire dirottata tramite questo metodo.
Per eseguire questa operazione in FortiGate, abbiamo creato un gruppo remoto che utilizza il nostro server fittizio e l'abbiamo aggiunto al nostro gruppo di utenti preso di mira. Con Ivanti, abbiamo semplicemente aggiunto il nostro server fittizio come server di autenticazione aggiuntivo per il nostro regno preso di mira.
Ora, ogni volta che un membro del regno/gruppo di utenti preso di mira esegue l'autenticazione, la VPN tenterà di verificare le credenziali fornite tramite il nostro server (Figura 11).
Figura 11. Aggiunta di un server di autenticazione RADIUS fittizio ad un gruppo di utenti
Per acquisire le credenziali, utilizzeremo un server di autenticazione RADIUS. L'autenticazione RADIUS è conveniente in questo caso per due motivi:
Le credenziali vengono inviate al server durante la richiesta iniziale senza prima verificare se l'utente sia presente o meno sul server.
Le credenziali vengono inviate al server crittografato con una chiave stabilita dal criminale allo scopo di recuperare le credenziali in testo non crittografato (Figura 12).
Figura 12. Una password crittografata in messaggio di autenticazione RADIUS
Il seguente script (basato su RFC 2865) può decrittografare le password RADIUS:
import hashlib
# Authenticator value can be obtained from the PCAP
authenticator = bytearray.fromhex("98f245b6e3724f5873fa74e576323c67")
enc = bytearray.fromhex("15644ca055b817ce683083fecebc2902016f2890660d0dfcaee214a0dbaa1046")
# Pre-shared key configured by the attacker when setting up the rogue server
secret = bytes("verygoodpsk", "utf-8")
chunk_len = 16
enc_chunks = []
dec = ""
for i in range(0, len(enc), chunk_len):
enc_chunks.append(enc[i:i+chunk_len])
for chunk in enc_chunks:
dec_chunk = b""
chunk_key = hashlib.md5(secret + authenticator ).digest()
i = 0
for enc_byte in chunk:
dec_chunk += (enc_byte ^ chunk_key[i]).to_bytes(1,"big")
dec += chr(enc_byte ^ chunk_key[i])
i+=1
authenticator = chunk
print(dec)
Una nota finale: come abbiamo già detto, quando Ivanti utilizza un server di autenticazione aggiuntivo, entrambi i server devono approvare l'utente per la riuscita dell'autenticazione. Se il nostro server non approva le credenziali fornite, gli utenti non potranno eseguire l'autenticazione su Ivanti. Per prevenire questo problema, dobbiamo garantire che il nostro server RADIUS approvi le credenziali fornite, il che può essere configurato facilmente.
Estrazione dei segreti dei file di configurazione
Probabilmente, il nostro risultato più preoccupante riguarda i file di configurazione VPN.
Tra le varie impostazioni interessanti che possiamo trovare nei file di configurazione, c'è n'è una che distingue in particolar modo, quella riguardante i segreti. Le VPN archiviano molti segreti nella loro configurazione: password degli utenti locali, chiavi SSH, certificati e, cosa più interessante, le credenziali degli account di servizi di terze parti.
Un criminale può ottenere questi file sensibili in due modi principali:
Dopo aver ottenuto il controllo di una VPN, un criminale può esportare la configurazione di un dispositivo tramite l'interfaccia di gestione.
Un criminale può individuare un file di configurazione esportato in precedenza, che è stato salvato in una posizione pubblica, come una cartella condivisa.
Per la loro protezione, i segreti vengono archiviati nel file di configurazione in un formato crittografato. La Figura 13 mostra l'esempio di un segreto crittografato in un file di configurazione di FortiGate.
Figura 13. Una password crittografata in un file di configurazione di FortiGate
Ora, andiamo a decrittografare alcuni segreti!
Decrittografia dei segreti da un file di configurazione di FortiGate
Si potrebbe pensare che i segreti siano protetti dalla funzione hash e, pertanto, non possano essere recuperati, ma, in realtà, non è proprio così. Prendiamo, ad esempio, le password di integrazione: poiché la password in testo non crittografato è richiesta per la connessione ai servizi di terze parti, deve essere archiviata con una crittografia reversibile.
Questo aspetto è stato dimostrato in un blog curato da Bart Dopheide, in cui è stato approfondito il processo di crittografia delle password in FortiGate. FortiGate utilizza il protocollo AES per crittografare tutti i segreti presenti nella sua configurazione. Quale chiave viene usata per eseguire questa crittografia? Dopheide ha scoperto che viene usata una sola chiave integrata nel codice sorgente per tutte le apparecchiature FortiGate, che non può essere cambiata. Il blog originale non la condivide, ma una rapida ricerca in Google consente di cercarla direttamente.
Fortinet ha assegnato a questa vulnerabilità il codice CVE 2019–6693 e ha implementato una correzione consentendo agli utenti di cambiare la chiave integrata nel codice sorgente con una personalizzata.
Anche dopo questa correzione, il problema attualmente è ancora molto rilevante. La chiave non è stata cambiata, pertanto, per impostazione predefinita, le apparecchiature FortiGate utilizzano ancora la stessa chiave. Pertanto, se un criminale riuscisse ad ottenere un file di configurazione da un'apparecchiatura FortiGate con la configurazione predefinita, riuscirebbe a decrittografare tutti i segreti archiviati sul dispositivo. Questo codice implementa il processo di decrittografia.
Cosa succede invece se l'amministratore di FortiGate seguisse le best practice e utilizzasse una chiave personalizzata invece di una predefinita? Abbiamo scoperto che se controlliamo la VPN, possiamo facilmente ottenere i segreti.
L'impostazione relativa alla crittografia dei dati privati viene usata per controllare la chiave di crittografia personalizzata. La cosa sorprendente è che gli amministratori possono semplicemente disabilitare questa funzione, che non richiede la conoscenza della chiave attualmente configurata e ripristina la crittografia di tutti i segreti alla chiave integrata nel codice sorgente originale.
Ripristino della crittografia
Per ripristinare la crittografia, è possibile usare i seguenti comandi dell'interfaccia della riga di comando di FortiGate:
FGT # config system global
FGT (global) # set private-data-encryption disable
FGT (global) # end
A questo punto, possiamo scaricare il file di configurazione e decrittografare i segreti utilizzando la chiave predefinita che conosciamo (esattamente come abbiamo mostrato prima).
È possibile violare molti segreti interessanti tramite questo metodo. FortiGate supporta le integrazioni con varie applicazioni tramite la funzione del "connettore esterno", che serve a vari scopi, ma la maggior parte dei quali condivide un aspetto importante, ossia richiede le credenziali per accedere all'applicazione (Figura 14).
Figura 14. Opzioni del connettore esterno di FortiGate
Pertanto, FortiGate potrebbe contenere le credenziali per accedere a servizi critici come provider di servizi cloud, SAP, Kubernetes, ESXi e molti altri.
In alcuni casi, le credenziali richiedono privilegi elevati per accedere alla rispettiva applicazione, ad esempio, l'integrazione "Poll Active Directory Server" richiede le credenziali di un account con accesso amministrativo ad un controller di dominio, trasformando subito, potenzialmente, una violazione di FortiGate in una violazione dell'intero dominio .
Decrittografia dei segreti da un file di configurazione di Ivanti
La situazione è molto simile in Ivanti, anzi, forse peggiore.
Anche Ivanti archivia i segreti con una crittografia reversibile. Se estraiamo il codice dal dispositivo e lo analizziamo, scopriremo velocemente il valore segreto utilizzato come chiave di crittografia, che è (anche in questo caso) una stringa statica (Figura 15).
Figura 15. Chiave di crittografia statica di Ivanti
Dopo aver revisionato tutta la chiave, se la esaminiamo all'inizio, possiamo dedurre che non sia cambiata almeno dal 2015, quando Juniper era proprietario di Connect Secure.
Sembra che Ivanti si sia focalizzato maggiormente sulla protezione dei segreti archiviati, implementando un algoritmo di crittografia più complesso rispetto a FortiGate. Ciò nonostante, questo processo è ovviamente ancora reversibile. Pertanto, i segreti archiviati in tutte le istanze di Ivanti vengono crittografati utilizzando una chiave statica che non può essere cambiata. I criminali potrebbero usare queste conoscenze per decrittografare qualsiasi file di configurazione di Ivanti.
Lasciamo fare ad Ivanti la decrittografia delle password per noi
Inizialmente, abbiamo eseguito il reverse engineering del processo di crittografia per creare uno strumento di decrittografia. È un processo sicuramente possibile, ma dopo aver trascorso tante ore a guardare il codice decompilato, abbiamo deciso di utilizzare un diverso approccio per la nostra PoC (Proof-of-Concept). Abbiamo lasciato fare ad Ivanti il lavoro pesante per noi.
L'idea centrale è utilizzare un'istanza di Ivanti dedicata che viene controllata da un criminale, inserirvi la password crittografata e farla decrittografare per noi (Figura 16).
Figura 16. Il processo di decrittografia di una password di Ivanti in un ambiente di laboratorio di un criminale
È possibile eseguire questa operazione decrittografia mediante i seguenti passaggi:
Ottenere una password crittografata da un file di configurazione di Ivanti
In un ambiente di laboratorio, configurare un'istanza di Ivanti e un server LDAP (ad esempio, un server Windows con Active Directory)
Sull'istanza di Ivanti creata in laboratorio, configurare un server LDAP come server che utilizza un semplice processo di autenticazione
Esportare la configurazione di Ivanti creata in laboratorio in un file
Sostituire la password LDAP crittografata esistente nel file di configurazione con la password crittografata che si sta cercando di decrittografare
Importare nuovamente il file di configurazione modificato nell'istanza di Ivanti
Ora, quando si tenta di effettuare l'autenticazione sul server LDAP, Ivanti decrittograferà la password presente nella configurazione e la invierà in testo non crittografato al server LDAP. Se si acquisiscono i pacchetti trasmessi, possiamo ottenere la password decrittografata (Figura 17).
Figura 17. Ivanti decrittografa la nostra password e trasmette il risultato tramite il server LDAP
L'autenticazione del server LDAP viene utilizzata come "interfaccia" del processo di decrittografia, ma è importante notare che non si è limitati alle password LDAP. Dai nostri test, è emerso che questa tecnica funziona per tutti i segreti archiviati nel file di configurazione, incluse (ma non solo) le password AD, le chiavi precondivise RADIUS e le chiavi API.
Password del server MDM in testo non crittografato
Ivanti supporta alcuni dei più comuni server di gestione dei dispositivi mobili (MDM) come metodi di autenticazione (Figura 18).
Figura 18. Configurazione del server MDM di Ivanti
Analogamente agli altri server di autenticazione, questa integrazione richiede le credenziali per il server MDM. Se esaminiamo la configurazione per il server MDM, scopriamo due campi interessanti: "password-encrypted" e password-cleartext". Nonostante quanto suggerito dai loro nomi, entrambi i campi vengono archiviati in testo non crittografato (Figura 19). ♂️
Figura 19. Configurazione del server MDM di Ivanti contenente le password in testo non crittografato
Tecniche di post-sfruttamento delle VPN in rete
Probabilmente, alcune delle tecniche descritte in questo post vengono già usate in rete. Nel loro rapporto Cutting Edge , in cui è stata descritta una serie di campagne di sfruttamento sferrate contro le istanze di Ivanti, i ricercatori di Mandiant hanno evidenziato come i criminali siano riusciti a violare l'account di servizio LDAP configurato sul dispositivo di Ivanti (Figure 20).
Figura 20. Il rapporto di Mandiant menziona un account LDAP violato
Anche se il rapporto di Mandiant non approfondisce il modo con cui i criminali siano riusciti nel loro intento, riteniamo che sia alquanto probabile che i criminali abbiano ottenuto le credenziali tramite uno dei metodi descritti in questo blog, ossia, estraendole dal file di configurazione o esaminando il traffico di rete.
Questi tipi di tecniche sono semplici da implementare e riteniamo che qualsiasi criminale, anche il meno esperto, riuscirebbe ad utilizzarli.
Consigli sull'utilizzo di un server VPN
Consigliamo di seguire quattro principi fondamentali durante l'utilizzo di un server VPN per minimizzare i rischi legati alle tecniche che abbiamo appena delineato:
Utilizzare una soluzione ZTNA (Zero Trust Network Access)
Limitare le autorizzazione dell'account di servizio
Utilizzare identità dedicate per l'autenticazione delle VPN
Monitorare i cambiamenti apportati alla configurazione
1. Utilizzare una soluzione ZTNA (Zero Trust Network Access)
Uno dei problemi principali legati alle VPN tradizionali consiste nel loro approccio di tipo "tutto o niente" quando si tratta di concedere all'accesso alla rete: agli utenti, quindi, viene concesso "tutto" (ossia, un accesso completo alla rete) o "niente" (ossia, nessun accesso alla rete).
Entrambe queste opzioni presentano dei problemi. Da un lato, dobbiamo fornire agli utenti l'accesso remoto alle applicazioni interne, dall'altro lato, non vogliamo che un criminale ottenga l'accesso completo alla rete se riuscisse a violare un server VPN.
A tal scopo, una soluzioneZTNA (Zero Trust Network Access) può aiutare. Definendo le policy di accesso alla rete in base alle entità, possiamo consentire agli utenti di eseguire operazioni remote approvate, riducendo, al contempo, l'impatto di una potenziale violazione.
Akamai Enterprise Application Access è una soluzione ZTNA che offre un accesso preciso alle applicazioni private in base alle identità e al contesto. Questa soluzione utilizza policy basate sulle identità e dati in tempo reale, come la posizione dell'utente, l'ora e la sicurezza dei dispositivi, per garantire agli utenti solo l'accesso alle applicazioni necessarie e non all'intera rete. Compatibile con Akamai MFA, la soluzione offre una solida funzione di autenticazione degli utenti.
2. Limitare le autorizzazione dell'account di servizio
Come descritto in questo post, è semplice recuperare le password in testo non crittografato di account di servizio archiviati sui server VPN. Non c'è un modo per evitare questo problema poiché le VPN richiedono, in alcuni casi, l'utilizzo di password in testo non crittografato.
Per ridurre l'impatto di una potenziale violazione della VPN, consigliamo di utilizzare account di servizio con una serie limitata di autorizzazioni, preferibilmente di sola lettura. Gli addetti alla sicurezza dovrebbero tentare di comprendere come un criminale potrebbe sfruttare le credenziali archiviate sulla VPN e assicurare che una violazione della VPN non conduca alla violazione di altre risorse critiche.
Alcune integrazioni richiedono un account di servizio con solide autorizzazioni per il loro funzionamento, che, se possibile vanno evitate.
3. Utilizzare identità dedicate per l'autenticazione delle VPN
Ora, sappiamo che è semplice per un criminale assumere il controllo della VPN per violare le credenziali di autenticazione degli utenti della VPN. Anche se si potrebbe essere tentati ad utilizzare i servizi di autenticazione esistenti, come il servizio AD, per autenticare gli utenti sulla VPN, consigliamo di evitare questa pratica. I criminali che assumono il controllo della VPN riusciranno ad ottenere le credenziali e ad utilizzarle per introdursi nelle risorse interne, trasformando la VPN in un single point of failure.
Al contrario, consigliamo di utilizzare un altro metodo dedicato per autenticare gli utenti sulla VPN, ad esempio, eseguendo un'autenticazione basata su certificati con certificati emessi specificamente per tale scopo.
4. Monitorare i cambiamenti apportati alla configurazione
Le tecniche che abbiamo delineato si riflettono tutte nella configurazione del dispositivo in un modo o nell'altro. Poiché la configurazione del dispositivo di rete non tende a cambiare frequentemente, questi cambiamenti possono offrire una notevole opportunità di rilevamento.
Per identificare le modifiche apportate alla configurazione, consigliamo periodicamente di estrarre la configurazione del dispositivo e confrontarla con un'immagine golden. La maggior parte dei dispositivi include funzionalità di registrazione interne per gli eventi di sicurezza e di sistema. Consigliamo di raccogliere e analizzare i registri disponibili e di utilizzarli per identificare i cambiamenti sospetti apportati alla configurazione del dispositivo.
Questi quattro principi si possono tutti ridurre al principio seguente: Non fidarsi ciecamente della VPN.
Riepilogo
I criminali prendono di mira le VPN. È un dato di fatto. Gli addetti alla sicurezza dovrebbero supporre che è solo una questione di tempo prima che un criminale ottenga l'accesso alla loro VPN ed agire di conseguenza senza perdere tempo. Gli addetti alla sicurezza devono assicurarsi che una VPN violata non possa condurre alla violazione dell'intera rete.
Cronologia delle divulgazioni
Ivanti
26.03.2024: rapporto iniziale al vendor
05.04.2024: Ivanti riceve il rapporto e conferma di lavorare ad una correzione
03.06.2024: notifica iniziale ad Ivanti relativa alla pubblicazione della nostra ricerca pianificata per il 7 agosto
27.06.2024: Ivanti dichiara di lavorare ad una correzione, ma non può confermare che i problemi verranno risolti prima della data della pubblicazione
08.07.2024: Ivanti assegna i codici CVE-2024-37374 e CVE-2024-37375 alle vulnerabilità della chiave integrata nel codice sorgente e delle password MDM in testo non crittografato, ma non ha ancora rilasciato una patch
15.07.2024: ulteriore notifica ad Ivanti relativa alla pianificazione del rilascio
07.08.2024: la ricerca viene pubblicata
Fortinet
22.03.2024: rapporto iniziale al vendor
17.04.2024: risposta iniziale di Fortinet, secondo cui tutti i problemi descritti non richiedono una correzione
21.04.2024: notifica iniziale a Fortinet relativa alla pubblicazione della nostra ricerca pianificata per il 7 agosto
30.04.2024: Fortinet ci informa che intende risolvere il problema relativo alla chiave di crittografia personalizzata da noi descritto
15.07.2024: ulteriore notifica a Fortinet relativa alla pianificazione del rilascio
23.07.2024: Fortinet dichiara che, probabilmente, non sarà in grado di rilasciare la patch prima della data della pubblicazione
30.04.2024: Fortinet ci informa che, dopo ulteriori considerazioni, ha deciso di non risolvere il problema relativo alla chiave di crittografia personalizzata perché non influisce sulla sicurezza
07.08.2024: la ricerca viene pubblicata