Il boot via PXE (Preboot Execution Environment) è un metodo che consente a un computer di avviarsi e caricare un sistema operativo da una risorsa di rete anziché da un dispositivo di archiviazione locale, come un hard disk, un’unità SSD oppure un supporto di memorizzazione esterno di tipo USB. Questa tecnologia è particolarmente utile in ambienti di gestione remota dei sistemi, come i data center o le reti aziendali, in cui è necessario installare o aggiornare i sistemi operativi su più macchine senza dover utilizzare supporti fisici.
Non significa che PXE non sia utilizzabile anche in ufficio o in ambienti domestici: nell’articolo dedicato a come installare Windows via PXE attraverso la rete, abbiamo visto che è necessario configurare un sistema server nella LAN. Quest’ultimo contiene le risorse necessarie per l’avvio, come l’immagine del sistema operativo che si desidera distribuire. Il protocollo DHCP (Dynamic Host Configuration Protocol) è spesso utilizzato per assegnare indirizzi IP e trasferire le informazioni di avvio ai computer che richiedono il boot via PXE.
Lato client, per impostare l’avvio del sistema attraverso PXE, è necessario modificare la sequenza di boot a livello BIOS: l’opzione PXE dev’essere la prima, con una priorità superiore al boot da unità esterne e supporti di memorizzazione locali.
Schema del boot di un sistema attraverso PXE e il protocollo IPv6 (fonte: Quarkslab)
PixieFail: perché le vulnerabilità nell’implementazione di PXE sono critiche
I ricercatori di Quarkslab hanno scoperto ben 9 gravi vulnerabilità in Tianocore EDK II (Extensible Firmware Interface Development Kit II), l’implementazione open source di riferimento utilizzata in UEFI. Il risultato è che eventuali utenti malintenzionati possono interferire con il processo di avvio PXE dei sistemi usati in azienda per disporre il caricamento di codice dannoso.
Le varie falle di sicurezza, complessivamente battezzate con il nome PixieFail, hanno a che fare con il supporto di IPv6 e di una serie di protocolli aggiuntivi che estendono la superficie di attacco. Le lacune in questione, se sfruttate, possono consentire attacchi DoS (Denial of Service), l’acquisizione di informazioni riservate, l’esecuzione di codice in modalità remota (RCE), l’avvelenamento della cache DNS e il dirottamento (hijacking) delle sessioni di rete.
Esaminando il report di Quarkslab, emerge che le vulnerabilità più critiche in assoluto sono quelle contraddistinte dagli identificativi CVE-2023-45230 e CVE-2023-45235. La prima, infatti, riguarda una scorretta gestione delle opzioni Server ID (identificatore del server) di lunghezza eccezionalmente lunga nell’ambito del protocollo DHCPv6. Il DHCPv6 è utilizzato nel contesto di PXE per ottenere un indirizzo IP e altre informazioni di rete necessarie durante il processo di avvio.
La generazione di un errore di buffer overflow si verifica quando i dati ricevuti superano la dimensione del buffer che dovrebbe contenerli. In questo caso, lo sfruttamento “furbo” di opzioni Server ID lunghe può consentire all’attaccante di sovrascrivere parti della memoria portando all’esecuzione di codice malevolo o a crash del sistema.
La seconda falla è simile avendo sempre a che fare con le opzioni Server ID e portando anch’essa a un errore di buffer overflow. In questo caso, la situazione potenzialmente “esplosiva” si presenta al momento dell’utilizzo di un messaggio Advertise, quando tramite PXE il server annuncia le risorse di rete disponibili.
La radice dei problemi di sicurezza
Quarkslab indica in NetworkPkg, parte del progetto EDK II, la radice del problema. Si tratta del componente responsabile dell’implementazione del supporto per l’avvio di rete (network boot) attraverso il protocollo PXE.
Le vulnerabilità identificate in NetworkPkg sono infatti specificamente collegate alla fase di avvio di rete e hanno a che fare con le modalità attraverso le quali EDK II implementa il supporto PXE, che è critico per l’avvio dei sistemi in ambienti aziendali e nei data center.
La risoluzione dei problemi individuati presuppone la correzione del codice sorgente dell’implementazione PXE (in questo caso, NetworkPkg) per mitigare le vulnerabilità e proteggere il sistema da possibili minacce di sicurezza.
L’impatto delle vulnerabilità in PXE è ampio
Secondo gli esperti di Quarkslab, le vulnerabilità PixieFail interessano un ampio ventaglio di dispositivi e vendor diversi. I ricercatori citano AMI, Phoenix, Insyde, ARM, Microsoft mentre il bollettino elaborato e pubblicato da CERT/CC fa riferimento anche a Intel.
In forza della complessità legata alla risoluzione delle vulnerabilità in questione, il CERT/CC statunitense ha ripetutamente posticipato la divulgazione dell’esistenza dei vari problemi di sicurezza in PXE decidendosi a pubblicare un avviso solo a metà gennaio 2024 (le falle erano già note da agosto 2023).
Allo stato attuale, la maggior parte delle patch sono ancora in fase di preparazione mentre Tianocore ha fornito le correzioni per una parte delle vulnerabilità.
Di fatto, come anticipato nell’introduzione, i soggetti maggiormente esposti a rischi di attacco sono le realtà che si occupano di gestire un gran numero di sistemi. In particolare, quindi, i provider di servizi cloud.
Non è necessario predisporre un server dannoso o ottenere privilegi di alto livello per lanciare un attacco. Tutto ciò che serve a un aggressore è l’accesso alla rete locale e la capacità di inviare e ricevere pacchetti, senza bisogno di alcun accesso fisico. È però indispensabile che il supporto IPv6 sia abilitato.
I buoi, comunque, sono già usciti dalla stalla: i ricercatori di Quarkslab hanno infatti provveduto a pubblicare, in questo repository GitHub, il codice PoC (Proof-of-Concept). Si tratta di 9 script Python che permettono di prendere di mira ognuna delle vulnerabilità scoperte in PXE.