Odido casus - Tweefactor authenticatie is NIET de heilige graal!

Door Marco Dufour

Odido datalek

Op 12 februari ’26 werd bekend dat criminelen binnengedrongen waren in het netwerk van Odido waarbij ze toegang hadden tot gevoelige persoonsgegevens van miljoenen Nederlanders. Of ze deze daadwerkelijk hebben buitgemaakt en naar zichzelf verstuurd, is op het moment van schrijven (16 februari ’26) nog niet zeker, maar op de website van Odido staat dat de daders informatie hebben gedownload. Per gebruiker (klant) verschilt het hoeveel data er is gelekt, waarbij er door Odido vier categorieën zijn gedefinieerd. Wat echter wel zeker is, is dat het bij de zwaarst getroffen categorie gaat om de volgende gegevens die Odido in een email naar diens getroffen klanten heeft geopenbaard:

• De volledige naam
• Het klantnummer bij Odido
• Adres en woonplaats
• Telefoonnummer
• Emailadres
• Het bij Odido bekende IBAN (bankrekeningnummer)
• Geboortedatum

Wat niet is gelekt (volgens diezelfde mail van Odido):

• Identificatiegegevens: nummer en geldigheid van het paspoort of rijbewijs
• Het wachtwoord van “Mijn Odido”
• De belgegevens (wie wanneer waar naartoe heeft gebeld)
• De locatiegegevens
• Factuurgegevens
• Scans van identiteitsbewijzen

Wat is bekend over de aanval?

In het weekend van 7 en 8 februari bereikten Odido de eerste signalen dat er sprake was van een datalek. Daarop is het bedrijf direct begonnen met nader onderzoek. Samen met de interne en externe cyberbeveiligingsexperts is direct actie ondernomen. Zodra het datalek bevestigd was is besloten de Autoriteit Persoonsgegevens en de betrokken klanten zo snel mogelijk te informeren.

De NOS berichtte op 13 februari het volgende:

De buitgemaakte gegevens zijn voor zover bekend nog niet gepubliceerd, maar kunnen worden gebruikt voor phishing aanvallen richting de Odido klant of door zich voor te doen als die klant richting andere bedrijven (identificatiefraude).

Nadere analyse

Uit de beschrijving die NOS heeft gepubliceerd, kan worden opgemaakt dat Odido gebruikmaakte van tweefactor authenticatie. Er zijn diverse manieren om te authenticeren, maar het lijkt erop dat de volgende twee mechanismen zijn gebruikt:

• controle op basis van wat iemand weet: wachtwoord
• controle op basis van wat iemand heeft: authenticatie app(?)

Middels social engineering (een phishing email) is het de aanvallers gelukt om wachtwoorden van een aantal klantenservicemedewerkers te achterhalen. Hieruit kan worden opgemaakt dat de betreffende medewerkers op dat moment niet scherp genoeg waren om zo’n nepmail te kunnen herkennen of waren ze er (nog) niet genoeg in getraind om ze te kunnen herkennen. Nu zou je deze mensen kunnen betichten van onoplettendheid. Echter, de “kwaliteit” van phishing mails, met name die van “spearphishing mails” waarbij de email helemaal op maat is gemaakt voor het beoogd slachtoffer, wordt steeds beter. Met een uitgelekt stukje tekst van een zeker persoon kun je bijvoorbeeld opdracht geven aan een Artificial Intelligence (AI) tool om een mail te schrijven die geheel in de stijl is opgesteld van die persoon. Het herkennen van phishing mails wordt daarmee met de dag moeilijker.

Oke, tot zover de phishing mail en het uitlekken van het wachtwoord. Dan hebben we nog de tweede vorm van authenticatie: het goedkeuren middels (naar ik vermoed) een authenticatie app op de smartphone van de Odido medewerker. Ook hier is middels social engineering omheen gewerkt. De crimineel heeft de klantenservicedeskmedewerker(s) gebeld en zich voorgedaan als een Odido medewerker van de ICT afdeling. Bij een groot bedrijf als Odido kent een medewerker niet alle andere medewerkers. Verder wist de criminele beller ook iets wat een ander niet zou (moeten) kunnen weten: de inloggegevens van de klantenservicedeskmedewerker! Althans, zo kan het slachtoffer gedacht hebben. Normaliter kent de ICT afdeling echter nooit de wachtwoorden van medewerkers omdat die niet in klare tekst opgeslagen worden in de authenticatie database, maar middels een “hashing algoritme” worden omgezet in een onomkeerbare reeks karakters van waaruit je het wachtwoord niet meer kunt herleiden.

De crimineel heeft een inlogpoging gedaan om als de helpdeskmedewerker in te loggen, waarop er in de authenticatie app een melding komt of de inlogpoging moet worden geaccepteerd. De “ICT medewerker” overtuigt het slachtoffer dat dit een gerechtigde poging is, omdat... Ja, waarom? Omdat er een probleem was met het account van het slachtoffer? In ieder geval was het overtuigend genoeg dat de medewerker het inlogverzoek accepteerde.

2FA is NIET de heilige graal!

Uit bovenstaand incident blijkt duidelijk dat 2FA er niet voor zorgt dat je honderd procent veilig bent. Vaak lees je bij datalekken: er was geen gebruik gemaakt van 2FA of dat een account tijdelijk geen 2FA had en daardoor kon worden misbruikt. Alsof 2FA het datalek had kunnen voorkómen. Misschien in een aantal gevallen wel, maar het ligt er geheel aan hoe de mensen zélf omgaan met 2FA. Dat geldt zowel aan de kant van de gebruiker als aan de kant van het ICT beheer.

2FA implementatie

Wanneer een organisatie over wil gaan naar een veiliger manier van inloggen en daarbij kiest voor 2FA, dan is het zeer belangrijk dat één ding niet wordt vergeten: vertel de gebruiker hóé die om moet gaan met 2FA. Zo mag een medewerker, laten we die persoon A noemen, bijvoorbeeld vlak voor de zomervakantie niet zijn of haar smartphone aan een collega (persoon B) geven, zodat die de taken van A af kan handelen door namens persoon A in te loggen gedurende de weken dat A op vakantie is.

Ook is het niet toegestaan om een authenticatieverzoek te accorderen wanneer je zelf niet aan het inloggen bent; dat geldt óók wanneer persoon B van de ICT afdeling claimt te zijn en hierom vraagt of zich voordoet als jouw manager of CEO. Dankzij AI kunnen criminelen zich steeds eenvoudiger voordoen als een ander persoon (bijvoorbeeld jouw CEO), zowel in geschreven tekst als in audio of zelfs video. Er zijn al incidenten bekend waarbij een hoge manager via een videovergadering opdracht gaf om geld naar een (onbekende) rekening over te maken, waarbij het echter helemaal niet die hoge manager was, maar een via AI gegenereerde kloon.

Ook vanuit de kant van de ICT professional moet bekend zijn hoe er om moet worden gesprongen met 2FA. Stel dat de ICT medewerker gebeld wordt door een collega die zijn of haar smartphone thuis heeft laten liggen en daardoor niet in kan loggen. Zou de ICT medewerker even voor één keer de 2FA eis willen uitzetten zodat de collega vandaag gewoon kan werken? Er ligt namelijk een klus die echt vandaag af moet, er is dus haast bij! NEE! Dat mag niet! Althans, niet zonder grondige check of die collega inderdaad die collega is én of het überhaupt mag dat je zomaar even de 2FA uit gaat zetten voor iemand. Daar zou een procedure voor geschreven moeten worden waar de ICT medewerker zich vervolgens aan moet houden.

Het juiste gebruik van 2FA

Ongeacht welke vorm van 2FA (of MFA, Multi Factor Authenticatie) je ook kiest, zorg ervoor dat eenieder weet hoe het werkt, wat die ermee moet doen, wat die er NIET mee moet of mag doen én waar hij/zij moet zijn wanneer het inloggen niet werkt.

Voor de ICT afdeling moeten er procedures zijn voor het initieel instellen van 2FA, voor het resetten van 2FA, voor het verwijderen van 2FA (als dat al toegestaan is) en een standaard procedure voor alle gevallen die niet onder de hiervoor genoemde procedures vallen. Die laatste klinkt heel vreemd, maar zie het zo: je kunt nog zoveel mogelijke situaties bedenken die nu of in de toekomst plaats zouden kunnen vinden, altijd is er echter wel een moment dat er een situatie is die je (nog) niet had voorzien. Daarvoor is die laatste procedure. Daarin zou bijvoorbeeld kunnen staan dat er een escalatie richting (C)ISO dient plaats te vinden. Hierdoor haal je belangrijke beslissingen weg bij mensen die niet security als primaire taak hebben en kan de ISO of de CISO bepalen wat in zo’n situatie de beste procedure is om te volgen.

Tot slot

Odido is aangevallen. Miljoenen gegevens van Nederlanders liggen (potentieel) op straat. Het is nu zaak om al die mensen uit te leggen waar de gevaren liggen, wat zij zouden kunnen verwachten en zorgen dat zij weerbaarder zijn opdat ze niet trappen in de te verwachten phishing aanvallen die ongetwijfeld plaats zullen vinden. Ook is het zaak om bedrijven zover te krijgen dat zij de identiteit van (potentiële) klanten controleren op meer dan de zojuist uitgelekte persoonsgegevens. Hierbij denk ik bijvoorbeeld aan de standaardvragen van telefonische servicedeskmedewerkers:

• Wat is uw postcode en huisnummer?
• Wat zijn de laatste 3 cijfers van het bij ons bekende bankrekeningnummer?
• Wat is uw geboortedatum

Laten al deze antwoorden nu net uitgelekt zijn....

1 week geleden