Direct naar de inhoud
Beveiligingsnieuws

Focus keyphrase: Impliciet vertrouwen in 4G/5G-kernen

impliciet vertrouwen

Onderzoekers van Nanyang Technological University (Singapore) hebben een opvallende beveiligingsles blootgelegd: in 4G- en 5G-core netwerken duiken kwetsbaarheden op die voortkomen uit één terugkerende denkfout. Die fout noemen ze impliciet vertrouwen tussen functies binnen de core. Wanneer een aanvaller die zwakte kan bereiken, kunnen aanvallen leiden tot denial-of-service (DoS) en zelfs session hijacking, waarbij een netwerkverbinding ongeautoriseerd wordt overgenomen.

In totaal gaat het om 84 eerder onbekende kwetsbaarheden die zijn gevonden in meerdere open-source 4G/5G-core implementaties. Het onderzoek maakt duidelijk dat cloud-native deployments het traditionele vertrouwensmodel kwetsbaarder maken dan veel organisaties wellicht verwachten.

Waarom impliciet vertrouwen riskant is in de core

In klassieke opzet waren de interfaceverbindingen tussen netwerkfuncties vaak fysiek geïsoleerd. Daardoor ontstond een ‘trust zone’: componenten gingen er impliciet van uit dat berichten binnen die zone veilig waren. Met de verschuiving naar cloud-native omgevingen verandert het speelveld. De onderzoekers beschrijven dat het trust model in zo’n omgeving “fragile” wordt en dat de aanvalsvlakken vergroten.

Het patroon dat zij observeren: core-netwerkcomponenten handelen berichten af alsof die altijd correct en betrouwbaar zijn. Dat gaat niet alleen over de inhoud, maar ook over berichtformaat, berichtsemantiek en zelfs beschikbaarheid van resources. Als componenten te blind reageren op input van interne peers, ontstaat een gat dat buitenstaanders of kwaadwillende clients kunnen benutten.

Waar de kwetsbaarheden zijn gevonden

De studie richt zich op de signaalinterfaces van LTE/5G-core netwerken. De bevindingen bestrijken twee LTE-implementaties (Open5GS en OpenAirInterface) en vijf 5G-implementaties: Open5GS, free5GC, OpenAirInterface, SD-Core en eUPF. Daarbij gaat het om twee kernsignaalprotocollen: GTP-C en PFCP.

Belangrijk detail uit het onderzoek: veel van deze cores ondersteunen zowel research-testbeds als commerciële omgevingen. Dat maakt de impact breder dan één specifieke installatie.

84 nieuwe issues, grotendeels met CVE’s

Om iTrues (implicit trust errors) te ontdekken, ontwikkelden de onderzoekers een aanpak die gebruikmaakt van een groottaalmodel (LLM) in een multi-agent systeem. Die methode helpt bekende fouten te samenvatten, te categoriseren en vervolgens te gebruiken als startpunt voor het vinden van nieuwe iTrues.

Een lastige stap is het terugdringen van hallucinaties en false positives. Volgens de paper wordt dit aangepakt met een code-checking methode waarin code-specifiaties worden vergeleken. Pas daarna volgen LLM-gedreven stappen om proof-of-concept (PoC) exploits te genereren, iteratief getest en bijgeschaafd op basis van resultaten in concrete core-implementaties.

Na het doorlopen van dit proces kwam het onderzoek uit op 84 eerder onbekende kwetsbaarheden. Daarvan zijn er 83 bevestigd en 81 voorzien van een CVE-identificatie.

DoS en session hijacking via protocolmisbruik

Niet elke kwetsbaarheid leidt direct tot dezelfde impact, maar de onderzoekers beschrijven twee aanvalstype-sporen die samenhangen met de iTrues: DoS en session hijacking.

DoS: crashen bij het verwerken van core-berichten

In een hypothetisch DoS-scenario tegen Open5GS (LTE) kan een aanvaller GTPv2-C berichten sturen om een fout te triggeren tijdens het parsen van GTPv2-C Create Session Request berichten. Het effect: het Serving Gateway Control plane (SGW-C) valt uit (crash).

Session hijacking: verkeer naar de aanvaller sturen

Voor session hijacking beschrijven de onderzoekers een keten van stappen die draait om PFCP-berichten richting de User Plane Function (UPF). In grote lijnen komt het erop neer dat een aanvaller een PFCP Session Modification Request kan injecteren, waarbij een bestaande Packet Detection Rule (PDR) ID wordt hergebruikt met een lagere precedence (dus een hogere prioriteit) dan die van het slachtoffer.

Als de UPF dat dubbele accepteert en de regels vervolgens sorteert op precedence, schuift de kwaadwillende regel vóór de legitieme regel. Tijdens packet verwerking matcht de UPF dan de door de aanvaller opgegeven PDR als eerste. Dat resulteert in een nieuw forwarding-pad tussen de UPF en de aanvaller, waardoor het uplinkverkeer van de gebruiker niet naar het internet maar naar de aanvaller wordt doorgestuurd.

De paper benadrukt daarbij ook een mechanisme dat het mogelijk maakt om berichten te ‘smokkelen’ en grenzen te omzeilen: via tunneling en boundary bridging worden PFCP of GTP-C berichten verpakt zodat ze, bij afwezigheid van strikte boundary enforcement, over de grens worden gebracht en vervolgens door core-componenten worden geparseerd.

Wat deze fouten betekenen voor mobiele operatoren

De onderzoekers signaleren dat sommige 5G-iTrues zijn overgenomen uit 4G-achtergronden. Dat illustreert hoe beveiligingsrisico’s “generaties kunnen springen” wanneer legacy componenten onvoldoende worden aangepast aan moderne deploymentvormen.

Bovendien ligt succes van DoS of session hijacking niet alleen bij een bug in code. De aanvaller moet ook praktische toegang hebben: bijvoorbeeld het IP-adres van core-componenten (denk aan openbare documentatie, passieve enumeratie of actieve scanning) en de mogelijkheid om interne core-interface-paden te benaderen. In het laatste geval kan ook een malicious User Equipment (UE) een rol spelen door zorgvuldig samengestelde payloads in de uplink data door te sturen.

Remediatie: voorbeelden uit de praktijk

Hoewel het onderzoek breed is, benoemen de auteurs ook concrete real-world uitkomsten. Zo is de session hijacking-kwetsbaarheid inmiddels verholpen in een vendorproduct: Dotouch heeft het defect in XproUPF gepatcht (met CVE-2026-8233, CVSS-score 4.6).

Voor een andere commerciële 5G-core vendor wordt nog gewerkt aan mitigatie. Dat onderstreept de noodzaak om snel te prioriteren op impact, blootstelling en exploitbaarheid—zeker nu het om een patroon gaat en niet om één geïsoleerde fout.

Hoe je dit vertaalt naar acties binnen je beveiligingsproces

Los van specifieke vendors geldt volgens het verhaal uit het onderzoek één kernpunt: vertrouw nooit op ‘interne’ berichten zonder echte validatie. Dat vraagt om technische controle op het niveau van implementatie én op het niveau van configuratie en bereikbaarheid.

Concreet kun je denken aan:

  • Strakkere boundary enforcement voor core-interfacepaden, zodat tunneling geen onverwachte parsing mogelijk maakt.
  • Validatie van berichtformaat en semantiek vóór componenten berichten uitvoeren of doorgeven.
  • Resource checks en veilige afhandeling wanneer verwachte structuren of beschikbaarheid ontbreken.
  • Inventarisatie van open-source cores die je draait, inclusief versiebeheer en patchstatus.
  • Threat modeling voor bereikbaarheid: welke IP’s en poorten zijn vanuit de buitenwereld mogelijk benaderbaar?

Als je bredere context zoekt over hoe patchen en snelle respons in netwerkomgevingen werkt, kan dit artikel je helpen: Beveiligingswaarschuwingen week 31: patch nu. En wanneer je naar vergelijkbare kwetsbaarheden binnen telecom-achtige infrastructuur kijkt, is het relevant om te zien hoe snel updates soms nodig zijn bij platforms—zoals eerder bij VMware kwetsbaarheden.

Conclusie: minder blind vertrouwen, meer harde validatie

Het onderzoek maakt impliciet vertrouwen tot een centraal beveiligingsprobleem in moderne 4G- en 5G-core netwerken. Zodra aanvallers de juiste componenten kunnen bereiken en componenten te blind blijven voor de inhoud en context van berichten, ontstaan serieuze risico’s: van DoS tot session hijacking.

Voor netwerkoperators en security teams is de belangrijkste boodschap helder: herstel niet alleen afzonderlijke bugs, maar versterk het principe achter de mitigatie—namelijk dat core-functies geen interne trust mogen aannemen zonder strikte, technische validatie. Dat is precies wat cloud-native omgevingen nodig hebben om het trust model weer robuuster te maken.

Bron: https://thehackernews.com/2026/07/researchers-report-84-flaws-in-4g-and.html