Negli ultimi anni hanno preso sempre più piede soluzioni NAC (Network Access Control), basate sul protocollo 802.1x. Come tutte le soluzioni di sicurezza, occorre attentamente valutare le modalità di funzionamento per poterle inserire in una corretta strategia per la Cybersecurity.

Mi rendo conto che questa valutazione richiede conoscenze tecniche molto specifiche, e spesso chi le valuta si basa su quanto viene descritto nei datasheet. Questo post ha tre scopi:

• rendere consapevoli le persone che valutare in modo errato una soluzione di sicurezza espone le organizzazioni a minacce;
• descrivere i passi con i quali un threat actor può sfruttare le debolezze delle soluzioni NAC,
• essere divulgativo e quindi comprensibile anche a persone non strettamente tecniche.

Premessa: le soluzioni NAC

Prima di tutto occorre fare una panoramica sulle soluzioni NAC o Network Access Control. Queste soluzioni si basano sul protocollo 802.1x per autenticare e autorizzare i dispositivi connessi. Alcune soluzioni, mediante componenti aggiuntivi, si occupano anche di valutare il comportamento dei dispositivi, per identificare eventuali anomalie.

Il problema che queste soluzioni si propongono di risolvere è quindi legato all’accesso non autorizzato alle porte Ethernet da parte di dispositivi non autorizzati. In particolar modo queste soluzioni proteggono porte per loro natura accessibili a persone, e in particolar modo: uffici e aree pubbliche.

Nel tempo queste soluzioni si sono evolute consentendo non solo l’autenticazione, ma anche l’autorizzazione e la profilazione dei dispositivi connessi. In altre parole è possibile configurare in modo dinamico le porte Ethernet in base ai dispositivi connessi. Questa funzionalità è di grande aiuto per migliorare e automatizzare la gestione di aree campus molto grandi e dinamiche.

L’autenticazione dei dispositivi connessi si basa sul protocollo 802.1x: lo switch chiede al dispositivo di autenticarsi e le autenticazioni sono validate tramite server esterni. L’autenticazione può avvenire tramite username e password o tramite certificato. Una volta che il dispositivo si è autenticato, il canale è attivo fino alla scadenza della sessione, che deve poi essere rinnovata.

Nel tempo le soluzioni sono evolute per supportare più dispositivi connessi, ad esempio:

• telefono con computer in cascata;
• computer con macchine virtuali;
• …

Nel mondo reale esistono tuttavia numerosi dispositivi che non implementano il protocollo 802.1x. Le soluzioni NAC si sono ulteriormente “evolute” (forse sarebbe più corretto dire “involute”), autenticando i dispositivi in base al MAC address degli stessi: questa funzionalità è detta MAB o MAC Address Bypass. Appare ovvio che il termine “bypass” non possa essere associato ad una funzionalità di sicurezza, e infatti ricordiamo che le soluzioni NAC vengono usate anche per automazione.

La più importante considerazione riguarda però la modalità con cui viene stabilita una sessione autenticata. 802.1x permette di autenticare il canale, non i singoli pacchetti. Nello specifico lo switch associa la sessione autenticata al MAC address del dispositivo. Un attacker può quindi inserire un dispositivo malevolo tra il dispositivo autenticato e lo switch, sfruttando il canale autenticato.

L’ultima considerazione riguarda i dispositivi che io chiamo “silenti”. Affinché le soluzioni NAC possano funzionare, i dispositivi connessi devono supportare 802.1x o trasmettere almeno un pacchetto per far conoscere il proprio MAC address allo switch. Alcuni dispositivi sono predisposti a ricevere dati ma non a trasmetterli rendendo impossibile l’utilizzo di qualsiasi soluzione NAC.

Configurare lo switch

La configurazione dello switch dovrebbe essere ben valutata per ridurre al minimo i rischi, che, come vedremo dopo, sono comunque presenti.

Ciascuna porta Ethernet può essere configurata in varie modalità a seconda del vendor. Prendendo in esame switch Cisco, le modalità sono:

• Multi-Host: una volta che la porta è stata autenticata dal dispositivo connesso, qualsiasi altro dispositivo può utilizzare il canale (ad esempio nel caso siano presenti macchine virtuali).
• Multi-Domain: ciascun dispositivo connesso, facendo parte di una specifica VLAN, deve essere autenticato (ad esempio nel caso siano presenti telefono e computer in cascata)-
• Multi-Auth: ciascun MAC address che si presenta sulla porta Ethernet deve essere autenticato.
• MAB: non viene fatta una vera autenticazione, ma solo una verifica che il MAC address sia abilitato.

Laddove possibile occorre preferire, in ordine, Multi-Auth, Multi-Domain, Multi-Host, MAB (nota: le definizioni dipendono dal vendor, l’importante è capire il concetto).

MITM su 802.1x

Dal punto di vista dell’attacker, nella peggiore delle ipotesi, mettersi in mezzo tra un dispositivo autenticato e uno switch, significa essere trasparente. Nello specifico significa, in ordine:

1. inoltrare qualsiasi dato da e verso lo switch, senza applicare alcun filtro sui frame locali;
2. attendere che il canale sia autenticato;
3. emettere dati usando solamente il MAC address e l’indirizzo IP del dispositivo autenticato.

Ci sono due strade possibili per implementare quando sopra:

1. costruire uno switch software eseguito in user-space, ottenendo probabilmente delle performance non così ottimali;
2. sfruttare i componenti offerti da Linux lavorando quindi in kernel-space con delle performance migliori, a costo però di alcune limitazioni.

In riferimento al secondo approccio, i tre passi si traducono operativamente in:

1. compilare un kernel custom affinché tutti i frame siano inoltrati da Linux Bridge;
2. leggere il MAC address del dispositivo connesso;
3. analizzare i dati passanti fino ad ottenere l’indirizzo IP del dispositivo connesso e il MAC address del gateway;
4. configurare un Linux Bridge, iptables ed ebtables affinché sia possibile comunicare con l’esterno usando MAC address e indirizzo IP del dispositivo connesso;
5. attivare un covert channel che permetta di sfruttare il dispositivo malevolo da remoto.

Il risultato sarà un dispositivo praticamente invisibile, gestibile da remoto.

Strategie di difesa

Programmare un dispositivo per sfruttare in modo trasparente una sessione 802.1x autenticata non è semplice ma nemmeno troppo complesso. Occorre quindi considerare il rischio che porte con accesso promiscuo possano essere compromesse come descritto precedentemente.

Da svariati anni il mio approccio è quello di considerare reti ad accesso promiscuo alla stregua di reti DMZ: aree ad alto rischio che richiedono alta visibilità e policy molto restrittive. Non è possibile fare alcuna assunzione sulla sicurezza dei dispositivi connessi.

Un primo approccio è quindi quello di aumentare la visibilità, aggiungendo l’analisi comportamentale dei dispositivi: se una stampante comincia a comunicare con un sito remoto sconosciuto, facendo upload più o meno consistenti, una luce rossa dovrebbe accendersi da qualche parte.

Un secondo approccio prevede di utilizzare un approccio del tipo zero trust, creando delle policy che permettano lo stretto necessario e nulla di più, limitando così il campo d’azione di eventuali dispositivi malevoli. In questo senso l’uso di Private VLAN può aiutare a ridurre ulteriormente la superficie d’attacco. Occorre però tenere sempre presente come un dispositivo viene autenticato: se ad esempio uno specifico computer viene autenticato in base all’utente che lo utilizza, e se a seguito dell’autenticazione utente i firewall utilizzano l’indirizzo IP dell’utente come base per valutare le policy, allora questo meccanismo non può essere considerato sicuro. Infatti il dispositivo malevolo che abbiamo ipotizzato sopra utilizzerà lo stesso indirizzo IP assegnato all’utente.

Un terzo approccio, poco diffuso, ma estremamente efficace prevede di usare un layer aggiuntivo costituito da IPSec o analoghi protocolli. Questa modalità, che a me piace molto, considera le reti promiscue come se fossero reti pubbliche: gli utenti che si attestano su queste reti devono utilizzare sistemi di VPN per accedere alle reti aziendali interne.

Esiste un ulteriore approccio, non ancora applicabile, che riguarda la possibilità di cifrare il canale dispositivo - switch e renderlo inutilizzabile da attacchi MITM. MACSec (802.1ae) è lo standard che implementa questo tipo di funzionalità ma ad oggi non è implementato su switch di accesso e su dispositivi endpoint.

Riferimenti

• An oddly specific post about group_fwd_mask
• Configuring 802.1X Port-Based Authentication
• Protocol and Password Compatibility
• Configuring PAP
• Defeating Wired 802.1X with a Transparent Bridge Using Linux
• Bypassing Port Security In 2018