Il tuo gateway VPN è compromesso: cosa è realmente esposto
Un gateway VPN violato vede dentro il proprio tunnel, ma non significa controllare ogni sessione. Separa traffico, portata e segreti memorizzati prima del ripristino.
Un gateway VPN si trova all’estremità del tunnel che protegge, il che significa che termina quella crittografia invece di lasciarla passare. Se un attaccante controlla l’host, il tunnel continua a sembrare sano dall’esterno mentre la macchina nel mezzo non è più affidabile. La domanda utile non è se tutto venga decifrato. È cosa quell’host poteva vedere, dove poteva arrivare e quali segreti erano realmente memorizzati su di esso. Queste tre risposte differiscono molto, e la risposta differisce con esse.
Il gateway termina il tunnel, quindi vede all’interno
La crittografia in una VPN procede salto per salto, e il gateway è il salto. Rimuove lo strato esterno, applica la politica e inoltra il pacchetto interno, quindi ogni pacchetto trasportato esiste in forma leggibile nella memoria di quell’host in qualche momento. È il progetto e non un difetto. È anche il motivo per cui compromettere il gateway è un evento diverso dal compromettere la crittografia del tunnel.
La prima cosa che l’attaccante guadagna è la posizione: la capacità di osservare il traffico trasportato, alterare l’inoltro o rispondere al posto di un backend. Ciò che guadagna dopo dipende dall’host, ed è qui che le persone sopravvalutano. L’accesso al gateway da solo non consegna le chiavi di sessione TLS di un browser, perché non sono mai state sul gateway.
Tre esposizioni che non hanno la stessa dimensione
Dividi la domanda in traffico trasportato, sistemi raggiungibili e segreti memorizzati, poi rispondi a ciascuna separatamente.
| Exposure | What the attacker gains | What does not follow |
|---|---|---|
| Carried traffic | Plaintext of whatever the tunnel forwards without its own encryption | Keys for TLS sessions that terminate at the application |
| Reachable systems | Whatever the backends accept from the gateway's address | Control of every connected client endpoint |
| Stored secrets | The specific keys, tokens and accounts present on that host | Possession of every client certificate or of a CA key |
La riga centrale è quella che viene saltata. Un gateway di solito ha una route verso reti private e un indirizzo di origine di cui i backend si fidano già, quindi la domanda interessante è cosa quei backend consentono da quell’indirizzo. Una politica di accesso client ristretta è un buon controllo, ma un attaccante sull’host non è limitato all’interfaccia che userebbe un client normale.
La riga inferiore decide quanto dura l’incidente. Una chiave server e una chiave CA hanno raggi d’azione completamente diversi, e così un account amministratore locale e un token di monitoraggio in sola lettura.
HTTPS dentro il tunnel resta HTTPS
Il TLS dell’applicazione termina nell’applicazione, non al gateway VPN, quindi un gateway compromesso osserva testo cifrato per quei flussi. È un limite reale a ciò che l’attaccante ottiene, e vale la pena dirlo chiaramente, perché l’affermazione opposta diffonde panico e decisioni sbagliate. Due condizioni lo infrangono. Se sul percorso c’è un componente di ispezione con un certificato attendibile, il gateway può vedere testo in chiaro per progetto. Se l’endpoint dell’applicazione stesso è compromesso, il tunnel è irrilevante.
Quindi la risposta a cosa hanno visto è condizionale, e dovrebbe essere scritta come condizioni invece di essere annunciata come verdetto.
Cosa deve cambiare prima di fidarsi di nuovo
Ricostruire l’host è necessario e raramente sufficiente. Un attaccante che detiene ancora un account di gestione, una credenziale di distribuzione o una chiave di firma può rimettere l’host come preferisce. Il ripristino deve partire da un percorso amministrativo che non dipenda dalla macchina compromessa.
Inventaria cosa c’era prima di decidere cosa ruotare. Chiavi, account di servizio, token API, utenti locali, attività pianificate, relazioni di fiducia e la pipeline di distribuzione sono tutti candidati, e ognuno ha un proprietario che dovrebbe confermarlo.
ss -lntup
getent passwd
crontab -l
ip route show table allQuell’elenco è il modo più rapido per vedere cosa offriva l’host e dove poteva arrivare. Conserva prima le prove, secondo il processo del responsabile della risposta, perché una ricostruzione distrugge esattamente ciò di cui ha bisogno un’indagine. NIST SP 800-61 Revisione 3 tratta preparazione, rilevamento, risposta e ripristino come parti di un unico processo di rischio, non come un’istruzione di riavvio.
Confini che rendono il prossimo meno costoso
Vale la pena costruire quattro confini prima di averne bisogno. Mantieni un percorso di ripristino indipendente che non si autentichi tramite il gateway. Mantieni l’autorità di firma separata dall’host che serve il traffico. Limita fin dove può arrivare il gateway, così un gateway compromesso non sia automaticamente una rete di gestione compromessa. E registra a chi appartiene ogni credenziale, così la rotazione è una telefonata invece di un progetto di archeologia.
Nessuna di queste impedisce la compromissione. La delimitano, e fanno la differenza tra una settimana brutta e un trimestre brutto.