Onderzoeker Adam Gowdiak meldt kwetsbaarheden in eSIM
Adam Gowdiak, oprichter en CEO van Security Explorations, meldt een manier te hebben gevonden om via een eSIM-kwetsbaarheid malafide applets te installeren op de eSIM. Gowdiak wees jaren geleden al op een kwetsbaarheid in Oracle Java Card, een applicatieomgeving voor chips die draaien op apparaten met beperkte capaciteit. Het ging om een zogeheten 'type confusion', ontstaan door het ontbreken van bytecode-verificatie in de Java Card's Virtual Machine (VM)-implementatie. Oracle meldde destijds dat de bevindingen van Gowdiak 'niet toepasbaar' waren, en heeft het probleem daarom nooit opgelost.
Nu meldt Gowdiak deze onopgeloste kwetsbaarheid te hebben gebruikt voor het omzeilen van de beveiliging van eSIM's. De onderzoeker legt uit hiervoor wel initieel fysieke toegang nodig te hebben tot een Kigen eUICC (een systeem waarmee eSIM profielen beheert op een telefoon) om de private key te kunnen achterhalen waarmee de telefoons zich authenticeren bij mobiele netwerkproviders. Met behulp van deze sleutel kon hij vervolgens willekeurige eSIM-profielen van mobiele netwerkoperators downloaden in plain text, die de sleutels bevatten die nodig zijn voor het installeren van eSIM-profielen. Met behulp van deze sleutels en dankzij het ontbreken van de juiste controles in eSIM kon hij kwaadaardige applets over-the-air (OTA) installeren op de eSIM.
De kwetsbaarheid heeft geen Common Vulnerabilities and Exposures (CVE)-nummer gekregen. Wel is het beveiligingsprobleem beoordeeld met een score van 6.7 op de Common Vulnerability Scoring System (CVSS)-schaal.
En precies daar kunnen hackers vaak hun gang gaan: systemen die zo complex zijn dat bijna niemand het meer snapt.
[Met behulp van deze sleutel kon hij vervolgens willekeurige eSIM-profielen van mobiele netwerkoperators downloaden in plain text,]
Welk service gaat nu op verzoek onversleutelde informatie versturen. Dit lijkt me dan niet een eSIM probleem, maar meer een service response security issue.
[Met behulp van deze sleutel kon hij vervolgens willekeurige eSIM-profielen van mobiele netwerkoperators downloaden in plain text,]
Welk service gaat nu op verzoek onversleutelde informatie versturen. Dit lijkt me dan niet een eSIM probleem, maar meer een service response security issue.
Je kunt nog zo'n dik slot aan de voordeur hangen, maar als je de sleutel er naast hangt, dan kun je gewoon naar binnen.
Een kwetsbaarheid die Oracle ooit als “niet toepasbaar” bestempelde en nu wordt gebruikt om eSIM-beveiliging te omzeilen… Dat is security in een notendop: vandaag een theoretisch probleem, morgen een praktisch nachtmerriescenario.
Het feit dat het begint met fysieke toegang tot een Kigen eUICC klinkt geruststellend voor de leek, maar wie in de telecomwereld werkt weet: als je eenmaal de authenticatiesleutel hebt, is het game over. Het downloaden van willekeurige eSIM-profielen in plain text is op zich al een rode vlag, maar het installeren van malafide applets OTA maakt het helemaal interessant. Je hebt dan in feite een persistent attack surface op een hardwarecomponent die gebruikers nooit controleren.
En dat het probleem geen CVE heeft gekregen, terwijl het met een 6.7 wordt beoordeeld, voelt vreemd. Dit is niet zomaar een theoretisch issue; dit raakt aan de fundamentele integriteit van telecomauthenticatie.
Ook opvallend: dezelfde oorzaak als jaren geleden – geen bytecode-verificatie in Java Card’s VM. In 2025 nog steeds type confusion-fouten? Het voelt bijna retro, alsof iemand een bug uit 2004 heeft afgestoft en in een moderne infrastructuur heeft geplakt.
Als er één les uit dit verhaal komt: low-level platformen zoals SIM/eSIM zijn geen “set and forget”-technologie. Wanneer je baseert op oude standaarden met bekende gaten, creëer je problemen die jaren later terugkomen – vaak op een veel grotere schaal.
Je bent niet ingelogd en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.
Cybersecurity Trainer / Full Stack Developer
Ben je toe aan een nieuwe job waarmee je het verschil maakt? Wil jij je security kennis graag delen en hands-on laten zien hoe cybersecurity in de praktijk echt werkt? Werk je net als wij graag samen met enthousiaste en gedreven collega's? Bij ons geen bureaucratie maar open communicatie en een werkomgeving gericht op samenwerking.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?