Per anni la sicurezza delle reti mobili ha fatto affidamento anche su un presupposto architetturale preciso: ciò che si trova all’interno del core network è protetto perché accessibile soltanto da componenti fidati, collocati in infrastrutture controllate dall’operatore. La trasformazione cloud native del 4G e soprattutto del 5G sta però rendendo questa impostazione sempre più difficile da sostenere.
A mettere in discussione uno dei principi storici della sicurezza telecom è una ricerca condotta dalla Nanyang Technological University di Singapore, i cui ricercatori hanno utilizzato un sistema multi-agent basato su Large Language Model (LLM), chiamato iFinder, per analizzare diverse implementazioni del mobile core. Il risultato è rilevante sia per la quantità dei problemi individuati sia per il metodo utilizzato: 84 vulnerabilità precedentemente sconosciute in sette implementazioni di core 4G e 5G, 83 delle quali confermate dagli sviluppatori responsabili e 81 associate a identificativi Common Vulnerabilities and Exposures (CVE).
Il dato mette insieme due trasformazioni che stanno procedendo in parallelo. Da una parte il core delle reti mobili si sta spostando verso architetture distribuite, container, Kubernetes e infrastrutture cloud; dall’altra l’intelligenza artificiale (AI) sta aumentando la capacità di analizzare grandi quantità di codice, individuare pattern ricorrenti e verificare automaticamente la possibilità di sfruttare una vulnerabilità.
Per gli operatori la questione riguarda quindi sia la robustezza delle nuove architetture di rete, sia la velocità con cui cambierà la ricerca delle vulnerabilità. Strumenti come iFinder possono essere utilizzati per rafforzare i processi di sicurezza, ma la stessa capacità di automazione può diventare disponibile anche a soggetti ostili.
Indice degli argomenti
Dal perimetro fisico al core cloud native
Le reti mobili di quarta e quinta generazione sono nate portandosi dietro un presupposto derivato dalle generazioni precedenti. Le interfacce attraverso le quali comunicano componenti quali Serving Gateway (S-GW), Mobility Management Entity (MME), Session Management Function (SMF) e User Plane Function (UPF) erano state concepite per funzionare all’interno di ambienti fisicamente isolati e direttamente controllati dagli operatori.
Di conseguenza, alcuni protocolli utilizzati dal core non prevedono nativamente livelli di autenticazione paragonabili a quelli normalmente imposti ai sistemi esposti su Internet. Il GPRS Tunnelling Protocol-Control Plane (GTP-C), utilizzato per messaggi di controllo relativi per esempio alla creazione delle sessioni e alla mobilità, e il Packet Forwarding Control Protocol (PFCP), con il quale viene gestito il modo in cui la User Plane Function inoltra il traffico degli utenti, si basano in larga misura sulla protezione garantita dal perimetro infrastrutturale.
Il problema emerge quando quel perimetro cambia natura.
Con il 5G cloud native le funzioni di rete possono essere eseguite come microservizi containerizzati all’interno di cluster Kubernetes, anche su ambienti di cloud pubblico o ibrido, attraversando in alcuni casi infrastrutture condivise tra più tenant o fornitori. Una configurazione errata, un workload compromesso, una segmentazione insufficiente o permessi di rete troppo estesi possono quindi rendere raggiungibili interfacce che erano state progettate partendo dall’ipotesi opposta.
La ricerca evidenzia proprio questo passaggio. Quello che gli autori definiscono problema di “implicit trust”, cioè di fiducia implicita, deriva dal fatto che alcune funzioni del core accettano messaggi provenienti dalla rete interna considerandoli attendibili senza verificarli con sufficiente rigore. Un approccio comprensibile quando le apparecchiature si trovavano all’interno di strutture fisicamente isolate, ma molto più problematico quando quelle stesse funzioni diventano software distribuito su infrastrutture condivise.
Il concetto di “interno” smette così di coincidere automaticamente con quello di “sicuro”.
Come funziona iFinder
La seconda parte significativa della ricerca riguarda lo strumento utilizzato per trovare le vulnerabilità. iFinder non si limita a interrogare un modello linguistico chiedendogli di individuare errori nel codice. È stato progettato come un sistema composto da più agenti specializzati, combinando capacità degli LLM, analisi strutturata del software, confronto con le specifiche del 3rd Generation Partnership Project (3GPP), l’organizzazione che sviluppa gli standard delle reti mobili, e verifica pratica degli exploit.
Il sistema parte dall’analisi delle vulnerabilità già note e delle specifiche tecniche per ricavare una serie di schemi ricorrenti. Tra questi figurano l’assenza di controlli su campi obbligatori dei messaggi, la verifica insufficiente della loro lunghezza, valori che non vengono validati correttamente, controlli mancanti sullo stato della sessione, riferimenti a identificativi non verificati e assenza di limiti nell’allocazione delle risorse.
Un agente cerca quindi nel codice percorsi compatibili con questi modelli. Un secondo livello confronta i risultati con le procedure previste dalle specifiche 3GPP per ridurre i falsi positivi. Infine un ulteriore agente prova a generare un proof of concept (PoC), cioè una dimostrazione pratica della possibilità di sfruttare la vulnerabilità, lo esegue in un ambiente di test e modifica progressivamente l’exploit sulla base dei risultati ottenuti.
È un aspetto importante perché mette in evidenza anche i limiti dell’utilizzo diretto degli LLM nella cybersecurity. Secondo i risultati riportati dalla ricerca, eliminando il passaggio di verifica rispetto alle specifiche il numero dei falsi positivi cresce da 19 a 62 e la precisione viene sostanzialmente dimezzata. L’efficacia deriva quindi dall’integrazione tra generazione di ipotesi attraverso il modello linguistico e passaggi di controllo deterministici.
Più che un hacker completamente autonomo, iFinder si comporta come una pipeline automatizzata capace di restringere progressivamente il campo delle possibili vulnerabilità e verificarne la consistenza.
PFCP e GTP-C concentrano la maggior parte dei problemi
L’analisi è stata condotta su sette configurazioni relative a cinque progetti: Open5GS e OpenAirInterface nelle configurazioni Long Term Evolution (LTE), e Open5GS, free5GC, OpenAirInterface, SD-Core ed eUPF per il 5G.
La distribuzione delle vulnerabilità non è uniforme. PFCP concentra 47 degli 84 problemi individuati, principalmente nel codice delle User Plane Function, mentre altri 37 riguardano GTP-C e si concentrano soprattutto nei Serving Gateway. Open5GS in configurazione LTE registra il numero maggiore di segnalazioni, con 30 vulnerabilità confermate e associate a CVE; seguono free5GC con 14 casi e OpenAirInterface 5G con 11.
La categoria più frequente riguarda un comportamento apparentemente semplice: l’utilizzo di un campo obbligatorio di protocollo senza verificare prima che quel campo sia effettivamente presente nel messaggio ricevuto. I ricercatori hanno rilevato 31 casi di questo tipo.
Altre vulnerabilità riguardano l’esaurimento delle risorse, quando una funzione di rete continua ad allocare memoria o stato in risposta a richieste controllabili dall’attaccante senza imporre un limite, oppure messaggi malformati sui quali mancano verifiche sufficienti relative a lunghezza e limiti.
Il fatto che problemi simili emergano in implementazioni indipendenti porta la ricerca a individuare una criticità più ampia rispetto al singolo errore di programmazione. Le vulnerabilità riflettono anche modalità con cui i protocolli e le architetture hanno storicamente attribuito fiducia ai messaggi scambiati all’interno del core.
Per questo il tema riguarda direttamente vendor e operatori impegnati nella trasformazione delle reti. Correggere singoli bug rimane indispensabile, ma la progressiva virtualizzazione delle funzioni rende necessario intervenire anche sui criteri con cui viene stabilita la fiducia tra i diversi componenti.
Il rischio più concreto è il dirottamento del traffico
Tra i problemi individuati, quello con l’impatto operativo più immediato riguarda una vulnerabilità di session hijacking in PFCP, identificata come CVE-2026-8233.
Quando uno smartphone o un altro dispositivo si collega alla rete, la Session Management Function stabilisce una sessione PFCP con la User Plane Function. Una Packet Detection Rule (PDR) indica alla UPF come deve essere gestito il traffico associato all’utente.
In alcune delle implementazioni analizzate non veniva correttamente imposto il requisito di unicità dell’identificativo PDR all’interno della sessione. Un soggetto in grado di inviare messaggi PFCP verso l’interfaccia N4 della User Plane Function potrebbe quindi creare una nuova regola utilizzando l’identificativo della regola esistente ma assegnandole una priorità superiore. La UPF potrebbe a quel punto applicare la regola manipolata e deviare il traffico uplink dell’utente verso una destinazione controllata dall’attaccante.
L’aspetto che rende il caso particolarmente significativo è che la catena di attacco non è stata verificata soltanto in un progetto open source o in un ambiente sperimentale. Il team della Nanyang Technological University l’ha successivamente confermata su due deployment commerciali di core 5G, non identificati pubblicamente.
Occorre però evitare una lettura che trasformi la vulnerabilità in un attacco effettuabile direttamente da Internet. Lo sfruttamento richiede infatti di poter raggiungere l’interfaccia interna del core, conoscere l’indirizzo del componente bersaglio ed essere in grado di inviare messaggi PFCP arbitrari.
Sono condizioni restrittive, ma diventano più realistiche in presenza di segmentazioni errate, infrastrutture condivise, configurazioni cloud non adeguatamente protette o workload adiacenti già compromessi. È proprio l’evoluzione infrastrutturale del core a modificare la valutazione del rischio rispetto all’epoca delle appliance collocate in ambienti fisicamente separati.
L’intelligenza artificiale accelera anche la corsa alle vulnerabilità
La ricerca assume un peso ulteriore se osservata dal punto di vista della velocità con cui gli strumenti basati sull’intelligenza artificiale possono modificare il vulnerability management.
Su un insieme di 22 vulnerabilità già documentate utilizzato come riferimento, iFinder ha raggiunto una precisione del 75%, un recall del 68,2% e un valore F1 del 71,4%, indicatore che combina precisione e capacità di individuare correttamente i casi rilevanti, contro il 31,8% ottenuto da una configurazione basata su un singolo prompt LLM privo delle successive fasi di verifica.
L’agente incaricato di costruire gli exploit ha inoltre prodotto proof of concept funzionanti per l’86,4% delle vulnerabilità utilizzate nel test, contro il 36,4% del sistema non iterativo. La possibilità di correggere automaticamente l’exploit sulla base degli errori prodotti durante l’esecuzione è quindi uno degli elementi che aumentano maggiormente l’efficacia del sistema.
Questi numeri non rendono però iFinder uno strumento infallibile. Alcune vulnerabilità sono sfuggite perché non rientravano nei sei pattern sui quali era stata addestrata la pipeline; altre richiedevano di ricostruire percorsi di esecuzione distribuiti su più moduli. Gli stessi autori riconoscono inoltre che il modello può valutare in maniera errata la possibilità di sfruttare un problema quando entrano in gioco transizioni di stato particolarmente complesse e specifiche della singola implementazione.
L’AI accelera quindi la ricerca delle vulnerabilità, ma non sostituisce l’analisi umana della sicurezza, soprattutto quando occorre comprendere relazioni tra componenti e comportamenti dell’intero sistema.
Il cambiamento principale riguarda piuttosto la scala. Automatizzare una parte consistente della ricerca significa aumentare il numero di componenti analizzabili e ridurre il tempo necessario per passare dall’individuazione di un’anomalia alla costruzione di un exploit verificabile.
Per gli operatori questo può diventare uno strumento potente di prevenzione. Ma introduce anche una pressione ulteriore sui tempi di correzione, perché la stessa classe di tecnologie può abbassare le barriere d’ingresso per chi cerca vulnerabilità con finalità offensive.
Patch e audit diventano prioritari per UPF e gateway
Le indicazioni operative che emergono dalla ricerca partono dai componenti sui quali si è concentrato il maggior numero di vulnerabilità.
Gli operatori che utilizzano le implementazioni coinvolte dovrebbero innanzitutto verificare di avere installato versioni aggiornate, concentrando l’attenzione in particolare su User Plane Function e Serving Gateway. Al momento della pubblicazione della ricerca, 58 delle 83 vulnerabilità open source confermate risultavano già corrette; il vendor Dotouch aveva inoltre applicato una remediation al proprio prodotto XproUPF, mentre per un secondo deployment commerciale il processo era ancora in corso.
Accanto alla verifica delle patch, la raccomandazione è effettuare un audit della raggiungibilità delle interfacce del core. In particolare, l’interfaccia N4 tra Session Management Function e User Plane Function e le interfacce S11/S5 utilizzate dal traffico GTP-C dovrebbero essere accessibili esclusivamente ai componenti che ne hanno effettivamente bisogno.
La segmentazione diventa quindi una misura centrale. Nei casi in cui le funzioni di rete non assicurino ancora adeguati controlli sull’unicità degli identificativi o sulla coerenza dello stato della sessione, la ricerca suggerisce anche sistemi di intrusion detection in grado di intercettare PDR duplicate o conflittuali mentre una sessione è attiva.
Il problema investe anche i processi organizzativi. Se l’automazione consente di individuare decine di vulnerabilità in tempi molto più brevi rispetto alle tradizionali attività manuali, patch validation, testing e distribuzione degli aggiornamenti dovranno essere in grado di sostenere una frequenza maggiore.
Nei network core, dove un aggiornamento può incidere su componenti critici e deve essere verificato con particolare attenzione prima di raggiungere l’ambiente di produzione, questa accelerazione rappresenta una sfida rilevante.
Dal perimetro allo zero trust
La conseguenza più ampia della ricerca riguarda infine il modo stesso in cui viene progettata la sicurezza delle reti mobili.
Le interfacce 3GPP interne devono essere considerate sempre meno come canali implicitamente affidabili e sempre più come superfici da proteggere con autenticazione reciproca, segmentazione, validazione rigorosa dei messaggi e controlli sullo stato delle sessioni.
È l’applicazione al mobile core di un principio zero trust: la provenienza di un messaggio da una porzione interna della rete non è sufficiente per considerarlo legittimo.
La Cloud Security Alliance (CSA) collega esplicitamente i risultati dello studio alle precedenti indicazioni sullo zero trust nelle reti cellulari. Il passaggio verso architetture distribuite e cloud native ha infatti proceduto più rapidamente dell’aggiornamento di alcune delle assunzioni di sicurezza presenti nei protocolli telecom tradizionali.
Per i vendor significa progettare le funzioni di rete inserendo mutual authentication, verifica rigorosa degli input, controllo degli identificativi, invarianti di stato e limiti all’allocazione delle risorse come caratteristiche strutturali, anziché come protezioni aggiunte successivamente.
Per gli operatori significa invece rivedere la sicurezza della rete anche dal punto di vista della micro-segmentazione, delle autorizzazioni tra workload, della configurazione Kubernetes e dell’esposizione delle interfacce interne.
La ricerca su iFinder anticipa inoltre una trasformazione destinata a riguardare l’intera cybersecurity delle infrastrutture telecom. Sistemi multi-agent capaci di leggere specifiche, analizzare codice, formulare ipotesi e verificare automaticamente gli exploit aumenteranno la quantità di vulnerabilità che possono essere cercate e testate.
La risposta non potrà quindi limitarsi a un’accelerazione delle patch. Il passaggio al cloud native impone di eliminare progressivamente la fiducia implicita dalle architetture del core mobile, assumendo che anche un messaggio proveniente dall’interno debba dimostrare di essere autentico, coerente e autorizzato.
È su questa trasformazione che rischia di giocarsi la prossima fase della sicurezza del 5G: reti sempre più software-defined e distribuite richiedono controlli progettati per un ambiente nel quale il confine tra “dentro” e “fuori” è molto meno definito di quanto lo fosse nelle generazioni precedenti.
Partecipa alla community