PEAP-MSCHAPv2: Perché è ancora comune, perché è rischioso e come andare oltre

Benvenuti a questo briefing tecnico di Purple. Sono il vostro ospite e oggi affronteremo un argomento che si colloca all'intersezione tra architettura di rete, conformità della sicurezza e, a dire il vero, debito tecnico legacy. Parliamo di PEAP-MSCHAPv2. Nello specifico, vedremo perché è ancora il metodo di autenticazione più comune nel WiFi aziendale, perché è fondamentalmente rischioso nell'odierno panorama delle minacce e, soprattutto, come potete concretamente far passare la vostra organizzazione a qualcosa di migliore. Iniziamo con il contesto. Se siete un direttore IT o un architetto di rete presso un hotel, una catena di vendita al dettaglio o un grande spazio pubblico, ci sono ottime probabilità che la vostra rete WiFi del personale — e forse i vostri dispositivi aziendali — si autentichino utilizzando PEAP-MSCHAPv2. È stato lo standard predefinito per le reti WPA2-Enterprise per quasi due decenni. Perché? Perché è incredibilmente facile da implementare. Si collega direttamente ad Active Directory tramite un server RADIUS e gli utenti devono solo inserire il proprio nome utente e password Windows standard. Nessun certificato da gestire, nessuna complessa infrastruttura a chiave pubblica da creare. Funziona e basta. Ma il fatto che "funzioni e basta" non è più sufficiente. L'architettura di sicurezza alla base di PEAP-MSCHAPv2 è, per dirla senza mezzi termini, obsoleta. Entriamo nei dettagli tecnici. MSCHAPv2 si affida all'algoritmo di hashing MD4 e alla crittografia DES. Entrambi questi standard crittografici sono stati progettati negli anni '90 e sono considerati deboli da oltre un decennio. Già nel 2012, alla conferenza sulla sicurezza DEF CON, il ricercatore Moxie Marlinspike ha dimostrato che l'handshake MSCHAPv2 poteva essere violato in modo deterministico. Ha rilasciato uno strumento che riduceva il processo di violazione a un singolo crack della chiave DES, il che significa che un utente malintenzionato con una potenza di calcolo modesta — o con accesso a un servizio di cracking cloud — poteva recuperare la password in chiaro di Active Directory di un utente da un handshake catturato in poche ore, se non in pochi minuti. Quindi, in che modo un utente malintenzionato cattura effettivamente quell'handshake nel mondo reale? Questo ci porta all'attacco "Evil Twin". Immaginate l'ufficio di un'azienda o il retrobottega di un hotel. Un malintenzionato entra con un access point non autorizzato, spesso un dispositivo piccolo come un Wi-Fi Pineapple nello zaino. Configura questo AP non autorizzato per trasmettere lo stesso identico SSID della vostra rete aziendale, ad esempio "Staff-WiFi". Potenzia la forza del segnale in modo che i dispositivi vicini lo preferiscano naturalmente ai vostri access point legittimi. Quando il laptop o il telefono di un dipendente tenta di connettersi, il rogue AP funge da autenticatore e punta a un server RADIUS fittizio controllato dall'attaccante. Il dispositivo del dipendente avvia il tunnel PEAP. Ora, ecco il punto critico di vulnerabilità: il PEAP si basa sul dispositivo client che verifica il certificato digitale del server per assicurarsi che stia comunicando con il vero server RADIUS aziendale. Tuttavia, nella stragrande maggioranza delle implementazioni, i dispositivi client sono configurati in modo errato, oppure agli utenti viene semplicemente mostrato un pop-up con la domanda "Vuoi considerare attendibile questo certificato?" e fanno clic su "Sì" solo per connettersi. Una volta accettato il falso certificato, il dispositivo invia la richiesta-risposta MSCHAPv2 attraverso il tunnel. L'attaccante la intercetta, si allontana e decifra l'hash offline. Ora dispone di credenziali Active Directory valide, che può utilizzare per accedere alla VPN, al sistema e-mail o a qualsiasi altro servizio aziendale. Questo non è un rischio teorico. È una procedura operativa standard sia per i penetration tester che per i malintenzionati. E se siete soggetti a framework di conformità come PCI DSS o GDPR, affidarsi a un protocollo di autenticazione compromesso rappresenta una responsabilità significativa. Quindi, se i rischi sono così elevati, perché non siamo ancora passati oltre? La risposta risiede solitamente in un mix di complessità percepita e hardware legacy. Allontanarsi dal PEAP significa orientarsi verso l'autenticazione basata su certificati, nello specifico EAP-TLS. L'EAP-TLS rappresenta lo standard di riferimento. Richiede che sia il server sia il dispositivo client presentino un certificato digitale valido. Non vengono trasmesse password, né cifrate né in altro modo. È completamente immune agli attacchi con dizionario offline e altamente resistente agli attacchi Evil Twin, poiché il client rifiuterà silenziosamente qualsiasi server RADIUS fittizio che non disponga di un certificato firmato dalla vostra Autorità di Certificazione attendibile. Ma implementare l'EAP-TLS significa avere bisogno di un'Infrastruttura a Chiave Pubblica, o PKI. È necessario un modo per generare certificati e distribuirli in modo sicuro a ogni laptop, telefono e tablet della flotta aziendale. Cinque anni fa, creare un'infrastruttura di Servizi di certificazione Active Directory Microsoft era un progetto scoraggiante e costoso. Oggi, tuttavia, lo scenario è cambiato. Il percorso di implementazione è molto più chiaro. Se state pianificando una migrazione, ecco l'approccio pragmatico che consigliamo ai nostri clienti di Purple. In primo luogo, non è necessario effettuare un passaggio netto immediato. I moderni server RADIUS, che si tratti di Cisco ISE, Aruba ClearPass o soluzioni cloud-native, consentono di eseguire PEAP-MSCHAPv2 ed EAP-TLS contemporaneamente sullo stesso SSID. Il primo passo consiste nell'implementare la PKI. Non è più necessario crearla necessariamente on-premise. Le soluzioni Cloud PKI si integrano direttamente con il vostro provider di identità, come Entra ID o Google Workspace, e con le vostre piattaforme di Mobile Device Management come Intune o Jamf. Il secondo passaggio consiste nell'utilizzare il tuo MDM per inviare in modo silenzioso i certificati client ai tuoi dispositivi gestiti. Puoi configurare il profilo WiFi tramite MDM per preferire EAP-TLS. Ciò significa che i laptop aziendali passeranno automaticamente al metodo sicuro basato su certificati senza alcuna interazione da parte dell'utente. Il terzo passaggio è la fase di transizione. Monitori i log RADIUS. Vedrai i tuoi dispositivi gestiti autenticarsi tramite EAP-TLS, mentre i dispositivi non gestiti o legacy continueranno a utilizzare PEAP. Questo ci porta alla trappola comune: i dispositivi legacy. Cosa fare con gli scanner di codici a barre di dieci anni fa nel magazzino o con i terminali POS più vecchi che semplicemente non supportano EAP-TLS? La soluzione è la segmentazione. Non dovresti mai compromettere la sicurezza della tua rete aziendale principale per adattarti al minimo comune denominatore. Invece, isola i dispositivi legacy su una VLAN dedicata. Puoi utilizzare l'autenticazione basata su MAC combinata con rigidi controlli di accesso alla rete, assicurando che tali dispositivi possano comunicare solo con i server interni specifici di cui hanno bisogno e con nient'altro. Una volta che la tua flotta gestita è completamente migrata a EAP-TLS, puoi finalmente disabilitare PEAP-MSCHAPv2 sul tuo SSID aziendale principale, chiudendo definitivamente la finestra di vulnerabilità. Facciamo una rapida sessione di domande e risposte basata sulle richieste più comuni che riceviamo dai direttori IT. Domanda uno: "WPA3 risolve il problema di PEAP-MSCHAPv2?" Risposta: No. WPA3 migliora la crittografia via etere, ma il metodo di autenticazione EAP sottostante rimane lo stesso. Se utilizzi WPA3-Enterprise con PEAP-MSCHAPv2, sei ancora vulnerabile all'acquisizione delle credenziali tramite un Evil Twin se il client non convalida rigorosamente il certificato del server. Domanda due: "E per quanto riguarda EAP-TTLS?" Risposta: EAP-TTLS è migliore di PEAP perché incapsula l'autenticazione in un tunnel, spesso utilizzando PAP anziché MSCHAPv2, il che evita le specifiche debolezze crittografiche di MSCHAPv2. Tuttavia, si basa ancora sulle password ed è comunque vulnerabile se il certificato del server non viene convalidato. È un trampolino di lancio, ma l'obiettivo finale deve essere EAP-TLS. Domanda tre: "Che impatto ha questo sul nostro guest Purple WiFi?" Risposta: Non ha un impatto diretto. Il WiFi per gli ospiti utilizza in genere reti aperte con Captive Portal o WPA2/3-Personal, che sono separate dall'autenticazione aziendale 802.1X. Tuttavia, proteggere la rete del back-office è fondamentale per salvaguardare l'infrastruttura che supporta tutte le operazioni della tua sede, inclusi i servizi per gli ospiti e le piattaforme di analytics. In sintesi: PEAP-MSCHAPv2 ha svolto egregiamente il suo compito, ma il suo tempo è scaduto. Le falle crittografiche sono pubbliche e gli strumenti di attacco sono automatizzati. La migrazione a EAP-TLS non è più un progetto d'avanguardia; si tratta di un aggiornamento standard e realizzabile, reso significativamente più semplice dai moderni MDM e dalle soluzioni PKI cloud. Il rischio di non agire — una password di Active Directory compromessa che porta a una violazione della rete più estesa — supera di gran lunga lo sforzo operativo della migrazione. Inizia oggi stesso con un audit dei tuoi log RADIUS, identifica i tuoi dispositivi legacy e inizia a pianificare la transizione verso l'autenticazione basata su certificati. Grazie per aver ascoltato questo briefing tecnico di Purple. Per guide all'implementazione più dettagliate e diagrammi di architettura, assicurati di leggere la guida di riferimento tecnica completa che accompagna questo podcast.