De Belgische eID-app Connective is onderzocht op ernstige beveiligingsproblemen. De kwetsbaarheden zijn inmiddels opgelost, maar ze tonen pijnlijk aan hoe gevoelig digitale identiteit is: als een browserextensie vertrouwensfuncties op de verkeerde manier aanbiedt, kan een aanvaller de deur naar fraude en misbruik openzetten.
De software wordt door miljoenen mensen gebruikt in België en speelt een rol bij authenticatie en het plaatsen van juridisch bindende e-handtekeningen. Juist daarom is het extra relevant dat meerdere bank- en overheidsdiensten afhankelijk zijn van de manier waarop Connective het eID-verkeer afhandelt.
Wat is Connective en waarom is het zo belangrijk?
Connective is een browserextensie ontwikkeld door Nitro Software Belgium. In België gebruiken meer dan twee miljoen gebruikers de oplossing om hun digitale identiteit te verifiëren. Daarnaast maakt de app het mogelijk om e-handtekeningen te zetten die juridisch bindend zijn.
Volgens de onderzoeker worden Connective en de onderliggende eID-functionaliteit ingezet door onder meer acht van de tien grootste Belgische banken en meer dan zestig overheidsinstanties. Daardoor raakt een fout in de app niet alleen de gebruiker, maar ook het bredere ecosysteem van digitale diensten.
Hoofdfout: website-check ontbreekt
Het meest fundamentele probleem was dat Connective onvoldoende controleerde welke website probeerde te communiceren met de extensie. Door die ontbrekende verificatie kon elke pagina—of zelfs een ingesloten advertentie—direct interactie afdwingen met de app op het apparaat van een slachtoffer.
Met die positie kon een aanvaller zonder zichtbare toestemming gevoelige informatie uitlezen. De onderzoeker beschrijft dat een kwaadwillende website gekoppelde gegevens zoals eID-gerelateerde informatie en betaalkaartgegevens stilletjes kon lezen.
Daarnaast kon de aanval draaien om het misleiden van gebruikers. De app kan pop-ups tonen die lijken op officiële authenticatie, maar door een zwak ontwerp konden aanvallers de tekst in die dialoog aanpassen. Tegelijk werd het domein waar het verzoek vandaan kwam niet duidelijk getoond, waardoor gebruikers niet eenvoudig konden beoordelen of de prompt legitiem was of een phishing-proxy.
PIN misbruik maken voor onrechtmatige handtekeningen
Wanneer een gebruiker een eID-PIN invoert in zo’n prompt, stuurt de app de PIN terug naar de website die het verzoek initieerde. Daarmee kreeg de aanvaller een bruikbaar geheim in handen.
Volgens de beschrijving kon de aanvaller vervolgens met die PIN ongeautoriseerde goedkeurings- of tokenmechanismen genereren. Dat opent de deur om, zodra de fysieke eID-kaart in een kaartlezer zit, e-handtekeningen te vervalsen.
Belangrijk detail: deze aanval draait niet om “magische” toegang tot het kaartje zelf, maar om het feit dat de extensie vertrouwen opbouwt op basis van een interactie die niet sterk genoeg was beperkt tot de juiste herkomst.
Impact op het digitale vertrouwensmodel
De kwetsbaarheid raakt het volledige vertrouwensmodel van België’s digitale identiteitsketen. Zelfs als andere dienstverleners zelf geen fouten hebben, kunnen ze alsnog kwetsbaar worden door hun afhankelijkheid van eID-signatures.
De onderzoeker noemt bijvoorbeeld overheidsportalen zoals CSAM.be en derde partijen zoals itsme. Met gestolen of misbruikte signatuurmogelijkheden kan een aanvaller digitale identiteiten registreren of bestaande accounts overnemen.
Daarmee gaat het effect verder dan identiteitsdiefstal: het kan ook leiden tot het verplaatsen van macht binnen digitale registraties en authenticatiestromen.
Los daarvan: remote code execution via lokale bestandsverwerking
Naast de fouten rond herkomstvalidatie en PIN-afhandeling is er ook een remote code execution-kwetsbaarheid gevonden. Die werkt onafhankelijk van de vraag of een eID-kaart in een lezer was gestoken.
De kern zat in hoe de toepassing bestanden verwerkt op de lokale computer. Hierdoor kon een kwaadwillende website de extensie dwingen code uit te voeren die door de aanvaller zelf werd aangestuurd. De uitvoering gebeurde op gebruikersniveau.
Opmerkelijk is dat de aanval als een zogenaamde drive-by kan plaatsvinden: een gebruiker hoeft geen technische vaardigheden te hebben, alleen verleid te worden om een bestand te downloaden dat zich voordoet als een normaal document en vervolgens een relevante pagina te bezoeken.
De onderzoeker wijst er bovendien op dat de zwakte theoretisch ook kon worden uitgebuit in een vorm van zelfverspreiding. Door in te loggegevens of sessies te grijpen en slachtoffers door te sturen naar kwaadaardige links, kon de aanval makkelijker nieuwe doelen bereiken.
Patch en afhandeling door Nitro
Nitro heeft de problemen uiteindelijk verholpen. In totaal duurde dat 146 dagen na de eerste melding. Het bedrijf publiceerde updates die onder meer gericht waren op het blokkeren van ongeautoriseerde oorsprongsverzoeken en het beveiligen van de manier waarop met de eID-PIN wordt omgegaan.
De laatste fase van de security-afdwinging werd afgerond in late juli. Er zijn volgens de bron geen CVE’s toegewezen.
De onderzoeker heeft de bevindingen publiek gedeeld op DEF CON en daarnaast een blogpost met extra technische details uitgebracht. Nitro reageerde niet op het commentaarverzoek dat in het bericht werd genoemd.
Wat kun je als organisatie of IT-team leren van deze casus?
Hoewel de kwetsbaarheid in Connective zat, laat de aanpak van de onderzoekers en het uiteindelijke patchen ook lessen zien voor bredere securitypraktijk. Met name bij identiteits- en ondertekeningscomponenten is de grens tussen “web” en “vertrouwd” extreem kritisch.
1) Herkomst en toestemming moeten altijd hard worden afgedwongen
Als een applicatie niet zorgvuldig controleert welke bron toegang vraagt, ontstaat er ruimte voor misbruik via willekeurige pagina’s. Denk daarbij aan checks op domeinen, correcte afbakening van communicatiekanalen en duidelijke trust boundaries.
2) UI-beschikbaarheid is niet genoeg: toon waar het verzoek vandaan komt
Gebruikers zien pas dat iets verdacht is als de interface voldoende context geeft. In deze casus speelde het ontbreken van een zichtbare domeinweergave in de authenticatiepop-up.
Organisaties kunnen dit vertalen naar eigen richtlijnen: zorg dat interfaces bij gevoelige handelingen niet alleen “een pop-up” tonen, maar ook concreet maken welke partij de actie aanvraagt.
3) Behandel token- en PIN-stromen als waardevolle assets
Een PIN of authenticatietoken is geen “tijdelijke” input, maar een sleutel richting acties. Als die waarde via een fout terug naar een ongewenste bestemming kan stromen, wordt de kans op fraude direct groter.
4) Kijk ook naar secundaire gevolgen zoals RCE
Deze ontdekking bevatte meer dan één gebrek. Zelfs als een deel van de keten dicht is, kunnen andere zwakheden—zoals verwerking van lokale bestanden—nog steeds code-uitvoering mogelijk maken. Daarom is het zinvol om niet alleen te patchen wat “nu” lijkt te kloppen, maar de hele aanvalsketen te evalueren.
Snelle vergelijking met andere securitycasussen op de site
De discussie over misbruik van vertrouwde flows sluit inhoudelijk aan bij andere meldingen waar een ogenschijnlijk technisch probleem zich vertaalt naar identiteits- of toegangsschade. Zo beschrijft de TrueConf hack hoe backdoored installers de softwareketen kunnen ondermijnen. En in Microsoft 365 AitM phishing zie je hoe aanvallers met de juiste tussenlaag accounts en sessies kunnen bedreigen.
Ook al gaat het hier om andere producten, de rode draad blijft: zodra een aanval vertrouwensbeslissingen omzeilt, ontstaat er ruimte voor datadiefstal, omzeiling en uiteindelijk schadelijke acties.
Conclusie
De Belgische eID-app Connective is getroffen door meerdere kritieke kwetsbaarheden: een gebrek aan website-validatie leidde tot het heimelijk communiceren met de extensie, het uitlezen van gevoelige gegevens, het misleiden van gebruikers om een eID-PIN te delen en het mogelijk maken van onrechtmatige goedkeuring en e-handtekeningen. Daarnaast werd een remote code execution-vraagstuk gevonden dat losstond van het inpluggen van de eID-kaart.
Gelukkig zijn de issues inmiddels opgelost door Nitro, met updates die onder andere ongeautoriseerde oorsprongsverzoeken blokkeren en PIN-verwerking beter beveiligen. Voor gebruikers en organisaties blijft deze case vooral een waarschuwing: bij identiteit en ondertekening is de trust-chain niet onderhandelbaar.
