NOS: privégegevens KLM-reizigers waren gemakkelijk te verzamelen

De persoonlijke vluchtinformatiepagina's van KLM-klanten waren eenvoudig te verzamelen en in te zien door onbevoegden. Dat blijkt uit onderzoek van de NOS. Daarop staan vaak telefoonnummers, e-mailadressen en in sommige gevallen paspoortgegevens. Het lek is inmiddels opgelost.

De NOS en beveiligingsonderzoeker Benjamin Broersma wisten 'in een paar uur tijd' ruim 900 werkende URL's met persoonlijke vluchtinformatie van klanten te scrapen, zo schrijft het medium op maandagochtend. Daarin stonden vaak ook privégegevens. Naast de e-mailadressen en telefoonnummers, waren in sommige gevallen ook paspoortgegevens in te zien. Op de vluchtinformatiepagina's was ook de optie aanwezig om paspoort- en visuminformatie aan te passen en te verwijderen, hoewel de NOS niet heeft getest of dat daadwerkelijk mogelijk was. KLM wilde dat ook niet bevestigen. Het datalek heeft ook invloed op klanten van Air France.

De URL's in kwestie worden door KLM per sms verstuurd naar klanten. Deze hyperlinks met vluchtinformatie worden gepersonaliseerd met zes tekens, zodat ze gemakkelijk in een sms passen. Deze bleken daarom niet uniek genoeg. Het is mogelijk om op grote schaal dergelijke links in te voeren. Gemiddeld waren 1 op de 100 tot 200 automatisch ingevoerde links ook daadwerkelijk geldig, meldt de NOS.

De links van KLM en Air France gebruiken hoofdletters, kleine letters en cijfers, waardoor er minstens 56,8 miljard verschillende combinaties mogelijk zijn. Volgens de conservatiefste schatting van de NOS, werkte ongeveer 0,5 procent van de geprobeerde combinaties. Geëxtrapoleerd zou dat neerkomen op ongeveer 284 miljoen juiste combinaties. Het is echter niet bekend hoeveel werkende vluchtinfopagina's er daadwerkelijk zijn. KLM wilde dat niet bevestigen tegenover de NOS.

KLM heeft het beveiligingsprobleem vrijdagmiddag opgelost. De luchtvaartmaatschappij deed dat binnen een paar uur nadat het door de NOS op de hoogte werd gesteld van het probleem. Mensen die nu een geldige link benaderen, moeten eerst inloggen in de Mijn Reis-omgeving van KLM of Air France. Het is niet bekend of het lek is misbruikt. Volgens de KLM sloeg het systeem 'al alarm' door de 'grote hoeveelheid verdachte activiteit' uit het onderzoek van de NOS en Broersma. Die deden naar eigen zeggen echter geen moeite om die activiteit te verhullen. De gebruikte IP-adressen van de NOS en Broersma werden na ruim vijf uur geblokkeerd.

Reacties (139)

[emphy]

Volgens de KLM sloeg het systeem 'al alarm' door de 'grote hoeveelheid verdachte activiteit' uit het onderzoek van de NOS en Broersma. Die deden naar eigen zeggen echter geen moeite om die activiteit te verhullen. De gebruikte IP-adressen van de NOS en Broersma werden na ruim vijf uur geblokkeerd.

Het komt mij voor dat een reactietijd van vijf uur onacceptabel is.

Dat is al in de fysieke wereld veel te lang om kopiëren te voorkomen (inclusief reistijd naar de copy-shop), laat staan in de digitale.

[SinergyX]

Het direct blokkeren van een IP lost weinig op, als je de methode/bron niet weet, dan switchen ze en gaan ze rustig verder. Nu kunnen ze eerst volledig in beeld brengen wat 'dit' IP adres precies heeft gedaan en zo dus ook hele methode/werkwijze achterhalen.

[Skit3000]

Ze kunnen niet direct blokkeren, want de meeste aanvragen zullen van het IP-adres van het publieke Wifi-netwerk van Schiphol (of andere luchthavens) komen en dat moet gewoon beschikbaar blijven. En ja, die zouden ze kunnen whitelisten, maar dan kan een aanvaller gewoon op Schiphol zelf gaan staan met een laptop en zo alsnog deze beveiliging omzeilen.

[Reptile209]

Wel als je ook kijkt naar het aantal ongeldige requests. Bij normaal gebruik zal er, verwacht ik, sporadisch iemand een verkeerde of verlopen link benaderen. Een hacker is random codes aan het proberen met een 0,5-1,5% success rate. Als je dus heel veel ongeldige requests in een korte tijd krijgt, weet je dat er stront aan de knikker is... Dat zou je vanaf ieder IP kunnen doen, incl. congrescentrum, Schiphol en grote hotels. En dan desnoods dat IP max 20 minuten blocken na 10 ongeldige aanvragen ofzo, dat maakt het al een heel stuk moeilijker.

En natuurlijk de search space vergroten door de URL langer te maken, zoals al gesuggereerd. Niet te lang, ivm overtypen, maar 1-2 characters extra maakt het exponentieel moeilijker.

[bwerg]

Wel als je ook kijkt naar het aantal ongeldige requests. Bij normaal gebruik zal er, verwacht ik, sporadisch iemand een verkeerde of verlopen link benaderen

Nu ben je aan het micro-engineeren. Dat kan je achteraf doen omdat je nu de precieze situatie weet, maar als je van tevoren voor elke situatie een specifieke noodrem gaat ontwerpen dan kun je beter je tijd steken in gewoon überhaupt een wat betere beveiliging implementeren.

Automatisch IP's afsluiten is een lelijke hack om om een veel fundamenteler probleem heen te werken. Los dat fundamentele probleem geautomatiseerd op, en laat de ad-hoc acties aan de hand van monitoring gewoon handmatig doorgevoerd worden. Een workaround gaan perfectioneren is een verspilling van tijd en moeite.

[Reactie gewijzigd door bwerg op 23 juli 2024 08:42]

[Aldy]

Dat kan je achteraf doen omdat je nu de precieze situatie weet, maar als je van tevoren voor elke situatie een specifieke noodrem gaat ontwerpen dan kun je beter je tijd steken in gewoon überhaupt een wat betere beveiliging implementeren.

Elke keer als er ergens een lek is geconstateerd zie je de beste stuurlui aan wal staan. Valt deze keer mee dat ze de beveiligers bij KLM niet van amateurisme beschuldigen. De 'stuurlui' begrijpen niet hoe moeilijk het is om bij beveiliging pro-actief te zijn. In tegenstelling tot veel reacties hier dacht ik bij het lezen van het artikel: Dat hebben ze snel gedaan.

[Skit3000]

Je kunt het wel blokkeren, maar daar heb je ook die ~50.000 KLM-reizigers op Schiphol mee die niet meer bij hun reisdocumenten kunnen.

[Zoop]

En als je weet als hacker zijnde dat ze op deze manier reageren, kan je dat expres gaan doen. Op een druk momentje dit geintje uithalen en net als men erbij moet het (even) plat ligt. Goedkope manier om chaos te zaaien.

[Dennisb1]

maar dan kan een aanvaller gewoon op Schiphol zelf gaan staan met een laptop en zo alsnog deze beveiliging omzeilen.

Maar dan moet je als aanvaller dat wel weten dat ze dat hebben gedaan.

[Left]

Eh nee, als een cyber attack bezig is waarbij attackers zeer gevoelige gegevens aan het verzamelen aan het zijn zoals bv paspoortgegevens, dan moet dat ip adres direct geblokkeerd worden, ook al is het het Wifi adres van Schiphol.

[Skit3000]

In een ideale wereld ja, maar het probleem is dat je niet weet welke van de requests van het publieke IP-adres van Schiphol komen van de aanvaller, en welke van de 50.000 reizigers die allemaal hun ticket op proberen te halen.

De oplossing moet dus niet gezocht worden in het blokkeren van IP-adressen, maar in het beter beveiligen van de toegang tot deze gegevens door bijvoorbeeld een langere unieke link te gebruiken (zoals ze nu doen) of na het openen van de link te vragen naar iets wat alleen de eigenaar van het ticket weet (geboortedatum, achternaam, etc).

[Sfynx]

De oplossing moet dus niet gezocht worden in het blokkeren van IP-adressen, maar in het beter beveiligen van de toegang tot deze gegevens door bijvoorbeeld een langere unieke link te gebruiken (zoals ze nu doen) of na het openen van de link te vragen naar iets wat alleen de eigenaar van het ticket weet (geboortedatum, achternaam, etc).

Een cyberattack die nu bezig is stop je daar nu niet mee. Dat is het punt van het blokkeren op netwerkniveau.

[Skit3000]

Als je het echt wilt stoppen, moet je je hele systeem afsluiten. Misschien heb je wel verdachte activiteit gedetecteerd vanaf één ip-adres, maar er kunnen nog (tien)duizenden anderen zijn. Vijf uur na afloop afsluiten is natuurlijk sowieso te laat, dus daar hadden ze het nooit mee gered.

Afsluiten heeft in ieder geval ook tot direct gevolg dat waarschijnlijk duizenden reizigers meer moeite hebben om bij hun vluchtgegevens te komen, terwijl je nog steeds niet zeker weet of al die aanvragen van hetzelfde ip-adres nu wel of geen aanval waren.

[ChipSlayer]

Het beste is om authenticatie en autorisatie op orde te hebben. De url wordt in feite naar de bezoeker gestuurd via een sms. Maak gebruik van MFA, stuur in deze sms een token mee die uniek is. De authorisatie is dat alleen de specifieke telefoonnummer van de klant de token heeft. Deze moet ter authenticatie opgegeven worden wanneer de url bezocht wordt.
Als een klant meerdere malen hierop probeert te bruteforcen, blokkeer of geef diegene een time-out op via een IDPS.

[Skit3000]

Een token in de sms zetten is hetzelfde als de token in de link zetten.

Stel dat dit de sms was die KLM uitstuurde:

Welkom bij KLM, bekijk nu je boarding card op klm.nl/boardingcard/abcdef.

Als ze in plaats daarvan een sms stuurde zoals hieronder, dan is het token uit de link + het losse token samen nog steeds net zo sterk (of zwak) omdat iemand nog steeds alle mogelijkheden af kan gaan:

Welkom bij KLM, bekijk nu je boarding card door het token "def" in te vullen op klm.nl/boardingcard/abc.

Je kunt wél dit bericht sturen, waarbij gebruik gemaakt wordt van iets wat je krijgt (de link) en iets wat je weet (je telefoonnummer):

Welkom bij KLM, bekijk nu je boarding card door de laatste vier cijfers van je telefoonnummer in te vullen op klm.nl/boardingcard/abcdef.

Maar, zelfs in dat geval kan je geen IP-adressen blokkeren als er een x-aantal keer een verkeer nummer is ingevuld, want dan kunnen die andere 49.999 reizigers op Schiphol van die dag óók niet meer bij hun reisdocumenten.

En ja, je kunt het wat slimmer maken en zeggen dat dat IP-adres alleen voor die ene link geblokkeerd is, maar dan kan een aanvaller alsnog net zo lang doorgaan tot 'ie beet heeft (als is het met een getal van 4 cijfers raden 10.000 keer moeilijker dan alleen een token van 6 letters).

[Witte]

Je kan dit vrij slim doen. Je sms't een url naar de klant, en hij moet op de webpagina inderdaad de laatste 4 cijfers van zijn mobiel intypen, hetzelfde mobiele nummer als waar de sms naar toe is gestuurd.
Doet de klant dit 3x fout, dan moet hij 5 minuten wachten, of beter nog, de oude url wordt ongeldig gemarkeerd en er wordt 2 minuten later een nieuwe via sms aangeboden.
Dit lijkt me niet gemakkelijk te brute-forcen.

[R4gnax]

Zomaar alles op het beloop laten en in vivo gaan analyzeren waar een inbreker mee bezig is, zou eigenlijk niet mogen. Als er misbruik / inbraak vermoed wordt ben je onder de AVG/GDPR verplicht hier zsm een einde aan te maken en gegevens veilig te stellen.

[Cergorach]

Zou je dat dan even de exacte tekst kunnen quoten? En wat jij zegt 'zsm' betekend 'zo spoedig mogelijk' met de na drup op mogelijk. Is iemand die tig requests maakt een inbreker of een onhandige klant? En een IP blokkeren is niet een einde maken aan een inbraakpoging.

[vickypollard]

Ik denk niet dat een onhandige klant duizenden verschillende vluchtinformatiepagina's probeert op te vragen.

[Cergorach]

Nee, maar het IP van bv. de wifi in de RAI bv. weer wel...

[Left]

Je kan aan het sessionId direct zien of het om 1 attacker gaat of 1000 verschillende gebruikers via hetzelfde ip adres.

[cariolive23]

Hier doe je dan wel de aanname dat de aanvaller slechts één sessionId gebruikt. En daar is geen enkele reden voor

[Zoop]

Waarom niet? Kan iets simpels zijn, een of ander reader programmaatje die jouw vluchtgegevens in de gaten moeten houden oid, wachtwoord gewijzigd en nu staat hij dat wellicht tig keer per minuut foutief te doen. Om maar eens iets te noemen. Verkeerd werkende software of een website die api calls doet, of whatever kan dit ook prima veroorzaken, hoef niet per se kwaadwillend te zijn.

[Klauwhamer]

Nou, wanneer je hebt nagedacht over visibility en monitoring in je suite zou dat écht vrij snel duidelijk moeten zijn, hoor. KLM stelt notabene dat dit het geval was. Toch koos men er voor om pas na vijf uur actie te ondernemen. Dat is laakbaar als je het afzet tegen de API domweg onbeschikbaar maken -- al dan niet tijdelijk. Waarom heb je anders in vredesnaam dat alarm ingesteld, als je het én negeert én niet in staat bent om een snel assessment te maken waarom het af gaat. We hebben het hier over KLM, niet over de plaatselijke bakker.

[djwice]

Dus je stelt voor om miljoenen klanten geen toegang te geven tot hun vlucht informatie?

Ik vind de mitigerende maatregel: "login verplicht, alleen eigen data inzien" veel eleganter en een structurele oplossing.

Waar vind je een ander bedrijf met miljoenen klanten die dit in 5 uur gecontroleerd live zet?

IP-blocking heeft geen nut, de rate was laag (200x900 per 5 uur: 10 per seconde. Met AWS cloud zou deze 5 uur durende aanval $0.0378 kosten.
Het is dus geen poging tot het leeg trekken van de hele database. Dat zou te lang duren. En het zijn niet de kosten die de hacker tegenhouden om op te schalen. Typisch white-hat gedrag.

[Klauwhamer]

Euh, die API is niet de enige manier tot die informatie. Beter ga je niet met drogredeneringen strooien. Het is ook heel typisch on de schade aan de kant van de klant volledig te negeren (mogelijke identiteitsfraude) en KLM schouderklopjes te geven voor het herstellen van een kneiter van een ontwerpfout.

[djwice]

Je krijgt een sms en klikt en krijgt de informatie niet. Wat nu?
Dat is volgens mij niet een situatie waar je tienduizenden klanten in wil brengen, toch?

De gevolgen van het lek blijft KLM verantwoordelijk voor. Dat staat los van de mitigerende maatregel die na het lek effectief is geworden.

[Reactie gewijzigd door djwice op 23 juli 2024 08:42]

[wiseger]

Als de blokkade automatisch plaats vind na een x aantal requests dan werkt dat prima.

[dutchgio]

Nee want dan kun je dus precies een script maken wat na X aantal requests van IP-adres wisselt om daar onder te blijven.

[PikachuNL]

Klopt, maar elke drempel is er één. De grote criminelen hou je er waarschijnlijk niet mee tegen, de script kiddies weer wel.

[The Third Man]

Ik weet niet hoe jij met de drempels omgaat die je tegenkomt, maar ik stap daar doorgaans overheen. Een Too Many Requests ban is een van de eerste maatregelen die een API hacker kan verwachten, dus ik vind het vrij naïef om te denken dat het ook maar 1 aanval tegenhoudt. Sterker nog ik zou zelfs verwachten dat hackers standaard IP adressen spreiden en andere obfuscatie toepassen om zo lang mogelijk onder de radar te blijven.

[Zyppora]

"Ja sorry maar de laatste keer dat we sloten op de voordeur hadden zitten zijn ze door het raam naar binnen gekomen, dus we doen voortaan maar geen sloten meer."

Dat iets makkelijk te omzeilen is betekent nog niet meteen dat je zo'n maatregel, die de huidige aanval wél stopt, niet hoeft in te zetten. Zeker wanneer het over klantgegevens gaat ben je verplicht deze fatsoenlijk te beschermen en een van de makkelijkste first lines of defense is brute force mitigation. Dat hoeft dan nog niet meteen een ip ban te zijn, maar kan ook simpelweg zijn dat responses voor dat ip adres langer gaan duren.

[The Third Man]

Lekkere stropop, want dat zeg ik nergens. Zie de discussie-draad erboven

- Als de blokkade automatisch plaats vind na een x aantal requests dan werkt dat prima.
- Nee want dan kun je dus precies een script maken wat na X aantal requests van IP-adres wisselt om daar onder te blijven.
- Klopt, maar elke drempel is er één. De grote criminelen hou je er waarschijnlijk niet mee tegen, de script kiddies weer wel.

Aangeven dat de drempel dermate zwak is, is in mijn optiek een argument waarom de drempel dus veel zwaarder moet. Een slot is dus een logischere stap (en zie ook KLM's eerste maatregel, dat er nu een authorisatie-laag is toegevoegd). Niet dat de drempel afwezig zou moeten zijn want 'die is toch te laag'.

[Zyppora]

Je geeft toch echt heel duidelijk aan dat je zelf ook gewoon over drempels heen stapt en dat het naief is om te denken dat API hackers zich door een 'Too Many Requests' ban laten tegenhouden. Dat klinkt mij toch echt in de oren als 'het helpt toch niet', met impliciet erachteraan 'dus waarom uberhaupt proberen?'. En ja, het klopt dat je dat nergens expliciet zegt, maar de toon/woordkeuze in je post brengt nonverbaal wel deze gedachte met zich mee.

Feit blijft gewoon dat NOS blijkbaar een responstijd heeft van 5 uur (!!) op het moment dat een semi-DOS aanval gedetecteerd wordt voordat er ook maar iets van actie ondernomen wordt en dat is gewoon veel en veel te lang. Deze white-hat hackers hebben ook nog eens geen enkele maatregel genomen om met hun 'aanval' onder de radar te blijven, wat het hele verhaal gewoon onacceptabel maakt. Het minste wat ze hadden moeten doen is bij massale opvraging vanaf een enkel IP adres dat IP adres tijdelijk in de ban doen. Dat is wat er gezegd is, en dat is ook gewoon de enige juiste respons op zo'n aanval. Dat de gemiddelde hacker dit voorziet en gaat IP hoppen, doet daar niks aan af.

[djwice]

Een aanval van 10 requests per seconde is geen (semi-)DOS aanval voor een systeem dat miljoenen requests per minuut, afhandelt.

Van dit soort dingen zien ze dagelijks meerdere keren.
De meeste schrapers zijn sneller dan dit. En die stoppen vaak uit zichzelf als ze zien dan ze 1 op 200 succes hebben.

Vaak is zo iets een fout geconfigureerde software aan de cliënt kant. Je wil hackers/scrapers niet een IP-switch spelletje in jagen, want dan wordt het lastiger voor jou, niet voor de cliënt. Je wil goed gezinde ontwikkelaars ook niet tegen werken (is het Red team bezig?). Dus welke oplossing had jij voor ogen dat geen kat-en-muis-spelletje start?

En wie weet zat de hacker al lang in een honeypot, maar denkt ie 900 bestaande resultaten gekregen te hebben...

[Reactie gewijzigd door djwice op 23 juli 2024 08:42]

[Kriekel]

Inderdaad, het is niet of maar en. Zowel verdachte requests blokkeren als een langere code en code's invalideren als deze niet meer van toepassing zijn.

[Jaran]

Elke drempel is beter dan geen, maar automatisch blokkeren van requests het houd hooguit wat bot netwerken tegen.
Als ''script kiddie'' is het dusdanig simpel dat wij dat al deden op de middelbare school om blokkades te omzeilen, dus dat lijkt mij niet de oplossing voor een dusdanig groot bedrijf, was het maar zo simpel!

[TheVivaldi]

Tja, als je één iemand arresteert die teveel drugs bij zich heeft en daardoor mogelijk een dealer is, en de agenten zijn weg, dan komt de volgende alweer. En hetzelfde kan gelden voor inbrekers. Precies hetzelfde principe. Moeten we dan ook maar stoppen met dealers en inbrekers arresteren en wachten tot de organisaties erachter aan het licht komen?

[Reactie gewijzigd door TheVivaldi op 23 juli 2024 08:42]

[Kip]

De juiste aanpak is dat het bedrijf ervan uitgaat dat dit ook misbruikt zal worden. Elke dienst waarin persoonsgegevens worden verwerkt, moet op verschillende manieren en lagen worden beveiligd. Als de dienst vanaf het internet toegankelijk is, neemt de kans op aanvallen aanzienlijk toe. Bij deze aanpak hoort een plan voor het geval van misbruik, waarop geautomatiseerde preventieacties kunnen worden gebaseerd.

Ik vraag me af of het alarm specifiek betrekking had op misbruik, of eerder een beheeralarm was, zoals een hoge belasting op een dienst of veel foutmeldingen op een webserver.

Het blokkeren van IP-adressen heeft wel zin om de impact te beperken. De aanvaller moet dan van IP-adres veranderen en de tools of scripts herstarten. Een meer geavanceerde aanvaller heeft dit echter vaak al voorbereid. Maar meestal kiezen ze voor de gemakkelijkste route. Aan de andere kant zijn de gegevens van KLM zeer interessant voor inlichtingendiensten. Hebben ze voldoende logs om te bepalen of dit ooit op een geavanceerde manier is misbruikt?

Een Captcha heeft meer zin. De directe oplossing zou kunnen zijn om de 6 tekens in de URL te vergroten tot meer tekens, of een tweede factor toe te voegen die op een andere manier wordt ontvangen, zoals via e-mail. Sommige maatschappijen gebruiken de invoer van een achternaam ter controle. Hierbij speelt de eeuwige afweging tussen beveiliging en gebruiksgemak.

[Cergorach]

Het blokkeren van IP-adressen heeft wel zin om de impact te beperken.

Maar waar zet je je limiet qua hoeveel requests van 1 IP? Met in gedachte dat je heel veel zakelijke klanten hebt die in grote hotels en/of evenementen kunnen zitten. Je kan niet al die hotels en evenementen gaan bijhouden met IP, door die te rainbowlisten, dat gaat gegarandeerd fout.

Even in gedachte houden dat een 747-400 416-524 passagiers kan hebben en dat in een periode van 5 uur kunnen dat prima 44.000 passagiers zijn, veel meer op spits periodes, zoals de feestdagen overdag...

[Kip]

Hierbij is het van belang om goed te begrijpen hoe de dienst wordt gebruikt en welke waarde het toevoegt voor zowel de gebruikers als KLM. Wordt de dienst door elke klant gebruikt en hoe wordt deze netwerktechnisch benaderd? Op basis daarvan kan de impact van de mitigatie worden bepaald. Het bijhouden van specifieke IP-blokken van hotels en andere identificatiegegevens lijkt mij niet haalbaar.

Zet dit af tegen de impact van het lekken van persoonsgegevens, zowel op de klanten als op het bedrijf en de medewerkers. Op basis daarvan kan een weloverwogen afweging worden gemaakt. Helaas gebeurt dit vaak pas achteraf.

[Cyberpuppy]

Dus we laten de inbreker maar binnen om precies te kunnen analyseren wat hij precies meeneemt, in plaats van dat we hem aan de deur stoppen als hij te lang aan het slot aan het rommelen is.

[batumulia]

Je wordt gemind op deze reactie, maar ik ben het ook met je eens dat 5 uur veel te lang is. Vooral als er een systeem in plaats is die al verdacht gedrag laat zien, in zulke gevallen kun je beter gelijk blokkeren en achteraf pas onderzoek doen en niet eerst afwachten. Lijkt mij?

[J_van_Ekris]

Vooral als er een systeem in plaats is die al verdacht gedrag laat zien, in zulke gevallen kun je beter gelijk blokkeren en achteraf pas onderzoek doen en niet eerst afwachten. Lijkt mij?

Je vergeet dat dit een URL is die gebruikt wordt om tickets te laten zien. "Gelijk blokkeren en achteraf onderzoeken" betekent dat je mogelijk een betalende klant in een vliegveld toegang tot zijn reisbewijs ontzegd, en hem/haar dus laat stranden. Iemand die gegarandeerd een hele serieuze schadeclaim zal indienen als je hem onterecht dit aandoet.

En er zijn legale redenen waarom veel calls uit een enkel ip-adres komen: een groot reisgezelschap bijvoorbeeld dat samen in één hotel en een vliegtuig zit. Je kunt het punt maken dat het "raadwerk" met vele foute URL's zou moeten opvallen, maar ik weet niet of dat normaal ook veel voorkomt (ik weet niet of bijvoorbeeld een SMS met een bepaalde karakterset op een Japanse of Chinese telefoon zo goed omgaat met de omzetting naar een URL of andere ruis). De hoeveelheid ruis die men normaal heeft is hier best bepalend in de reactiesnelheid.

[Reactie gewijzigd door J_van_Ekris op 23 juli 2024 08:42]

[rneeft]

Dat heb je het over tientallen, waarbij er 1 adres is per 10 seconden (menselijk handelen) maar als je honderde uitvoer binnen luttele seconden lijkt me dat verhaal niet meer toepassing.

Daarnaast is het altijd mogelijk op het vliegveld een nieuwe reis bewijs te printen.

[J_van_Ekris]

Dat heb je het over tientallen, waarbij er 1 adres is per 10 seconden (menselijk handelen) maar als je honderde uitvoer binnen luttele seconden lijkt me dat verhaal niet meer toepassing.

We weten niets over de snelheid van de requests die door de NOS zijn gedaan.

Daarnaast is het altijd mogelijk op het vliegveld een nieuwe reis bewijs te printen.

In theorie wel, maar in praktijk zeker een zeer lastige omdat die mensen wegbezuinigd zijn. Zeker als je niet op de Shiphol zit, geef ik je het te doen (ik spreek uit ervaring).

Nog afgezien van het feit dat door je late check-in je grote kans hebt om op de stand-by lijst te eindigen.

[Finraziel]

We kunnen wel wat extrapoleren hoor... Ze hebben er ruim 900 gevonden en het kostte 100 tot 200 pogingen om er een te vinden. Dat zijn 90k tot 180k pogingen. Na 5 uur zijn ze geblokkeerd. Als ze die 5 uur ook bezig geweest zijn dan komt dat uit op 5 tot 10 pogingen per seconde.

[Patrickkkk]

Tenzij er meerdere mensen op hetzelfde netwerk zitten (bedrijven, scholen) een dan wordt het allemaal iets minder eenvoudig

[Kip]

Denk ook aan mobile providers die meerdere data gebruikers achter NAT zetten. Dan lijkt het alsof ze van een IP komen.

[mocean]

IP adres van Schiphol Wifi bijvoorbeeld...

[b12e]

CG-NAT is allang niet meer enkel op mobiel zo, heel veel (vaste) internetproviders passen dit ook al toe.

[Zoop]

Kijk eens hoe de meeste twitter widgets reageerde op moment dat ze api dichtgooide, ze gingen vervolgens met zn allen praktisch iedere seconde staan re-tryen wat uiteindelijk twitter dos-te.

Dus zoiets hoeft niet per se een malafide aard te hebben. Je hebt maar een programmaatje nodig dat meerdere keren per minuut gaat zitten proberen. Stop dan 100 man samen die dat programmaatje gebruikt, en je hebt al dat soort request aantallen. Waarschijnlijk zitten ze dan ook nog eens op dezelfde wifi (die van vliegveld bijv), dus ip blokkeren gaat dan gewoon niet zo simpel (daarnaast, ff op het allerlaatste moment al die mensen van nieuwe geprinte reisbewijzen te voorzien is natuurlijk ook chaos).

Hoe dan ook, requests blokkeren is vaak echt niet zo simpel.

[Skit3000]

Sterker nog, de meeste aanvragen zullen vanaf hetzelfde IP-adres komen; het IP-adres van de internetverbinding via waar het openbare Wifi-netwerk van Schiphol (of andere luchthavens) communiceert. Met 70.000 reizigers per dag, waarvan elke pagina die ze openen ook nog eens in het laden van afbeeldingen, javascript, en css-bestanden resulteert zijn dat al snel miljoenen HTTP-verbindingen. Veel succes om daar die hacker uit te filteren (en het is ze toch gelukt, na vijf uur).

[Jemboy]

My 2 cents: IP-adres Schiphol, whitelisten. Whitelist ook de "belangrijke" IP-adressen als die er zijn.
Bij x aantal pogingen van een niet gewhiteliste IP-adres, deze blokkeren met oplopende tijden, bv. 10 minuten, 30 minuten, 1 uur, 4 uur, 24 uur, permanent.
Stel dat je bij elke 5 fouten een "drempel" zet, dan heeft iemand bij een blokkering van 1 uur, al 15x een foute inlog gedaan.
Eigenlijk hoort er bijna nihil fouten plaats te vinden, omdat de link die KLM genereerd "altijd" goed moet zijn.
Dus bij de 1e en 2e blokkering moeten er al belletjes gaan rinkelen.
Daarnaast ging dit om een SMS naar een mobiel, dat nummer is nog unieker dan je IP-adres.
Dus if IP-adres=IP-adres Schiphol, but foute request=5 then block SMS sturen naar 06-nummer hacker.
Veel succes om als hacker 1000 simkaarten klaar te hebben staan.

[J_van_Ekris]

My 2 cents: IP-adres Schiphol, whitelisten. Whitelist ook de "belangrijke" IP-adressen als die er zijn.

Nu ben ik het verleden admin geweest bij een vrij groot forum. En heb ik per ongeluk het hele Vodafone netwerk geblocked op de firewall. Hackers waren we kwijt, maar ook 50% van onze legitieme gebruikers.

Het punt is, het is ondoenlijk alle grote spelers in de gaten te houden. Al zou je je beperken tot alle vliegvelden: waarom zou de IT club van een vliegveld in het midden-oosten bij de KLM melden dat het ip-adres is gewijzigd? Waarom zouden de hotels in de buurt van Schiphol dit doen? Op Schiphol zelf zitten al 3 enorme hotels die puur en alleen bedoeld zijn reizigers op tijd voor hun connecting flight te hebben.

Whitelisten klinkt leuk als je een klein huisnetwerk hebt, maar het is niet te doen als de hele wereld je klant is en je geen flauw idee hebt wat daar gebeurt.

[Skit3000]

De oplossing is natuurlijk om naast de link die wordt verzonden, om andere input te vragen op de pagina zelf zoals "laatste drie letters van achternaam" of "dag en maand van geboortedatum". Dat is nog steeds geen 100% beveiliging, maar zorgt wel dat als nu 1 op de 200 requests data teruggeeft, dat wordt teruggebracht tot 1 op de anderhalf miljoen ofzo.

[mrmrmr]

Je denkt iets te makkelijk over links. De content van emails kan worden herschreven waardoor bijvoorbeeld spaties en andere tekens worden geintroduceerd (email servers: Postfix, Sendmail, voormalige Sun/Oracle Netscape). Daarnaast zijn er content- en characterset-encoding issues zoals @J_van_Ekris zegt. De links kunnen dus op 'natuurlijke' wijze breken.

[Cocytus]

Wat een onzin, je kunt een boardingpass gewoon laten printen op het vliegveld.

[lenwar]

Je gaat hier wel heel kort door de bocht met je conclusies

"Gelijk blokkeren en achteraf onderzoeken" betekent dat je mogelijk een betalende klant in een vliegveld toegang tot zijn reisbewijs ontzegd, en hem/haar dus laat stranden.

Op een gemiddeld vliegveld zijn servicebalies aanwezig. Ook zullen veel mensen hun ticketinformatie vantevoren hebben gedownloaded danwel uitgeprint. (uiteraard niet allemaal)

Op het moment dat dit zou gebeuren, kan er eventueel worden opgeschaald. Het systeem kan natuurlijk ook platliggen door een verstoring, Daar moeten ze ook processen voor hebben.

En er zijn legale redenen waarom veel calls uit een enkel ip-adres komen: een groot reisgezelschap bijvoorbeeld dat samen in één hotel en een vliegtuig zit

Dat is geen valide reden voor de achterlijke hoeveelheden die de NOS heeft veroorzaakt. Pakkembeet 0,5% laten we zeggen 1% van de URLs waren valide. Ze hadden 900 URLs gevonden. Dat waren 90000 (bij 1%) verzoeken. Dat is een heel flink gezelschap die massaal de verkeerde URLs intikte. En die waren ook nog is allemaal op de hotel/vliegtuig-Wifi verbonden zonder VPN-achtige zaken.

De oplossing die ze hebben gegeven: "Inloggen om bij je privégegevens te komen" is natuurlijk idioot dat dit niet al aanwezig was. Hier is gewoon domweg geen excuus voor.

Edit: 90000, niet 9000. @Alex3 attendeerde me daar even op.

[Reactie gewijzigd door lenwar op 23 juli 2024 08:42]

[J_van_Ekris]

Op een gemiddeld vliegveld zijn servicebalies aanwezig. Ook zullen veel mensen hun ticketinformatie vantevoren hebben gedownloaded danwel uitgeprint. (uiteraard niet allemaal)

Nu vlieg ik "vrij regelmatig" voor mijn werk, en zeker op de kleinere Europese bestemmingen heb ik al jaren geen KLM servicebalie meer gezien. Soms vervangen door een automaat, maar bijna onvindbaar.

En tickets printen doe ik al jaren niet meer. Tegenwoordig zit die QR-code in de KLM app, die hoogstwaarschijnlijk achter dezelfde firewall zit die je blokkeert.

Op het moment dat dit zou gebeuren, kan er eventueel worden opgeschaald. Het systeem kan natuurlijk ook platliggen door een verstoring, Daar moeten ze ook processen voor hebben.

Als Amadeus er uit ligt, vliegt KLM niet meer. En elke andere maatschappij ook niet meer. Er zijn de afgelopen jaren verschillende partial outages bij Amadeus geweest, en dat is het moment waarop de vliegwereld gewoon stilvalt (ze doen namelijk alle passengerhandeling voor KLM/AF, Lufthansa, BA, etc.). Zoek maar eens op het internet.

[lenwar]

En tickets printen doe ik al jaren niet meer. Tegenwoordig zit die QR-code in de KLM app, die hoogstwaarschijnlijk achter dezelfde firewall zit die je blokkeert.

Maar die KLM-app downloaded dus die informatie niet? (dat zou ik wel verwachten namelijk). De maatschappijen met wie ik vloog hadden die info lokaal in de app staan.

Printen doe ik zelf ook al jaren niet wanneer ik is vlieg, maar ik zie vrij veel mensen wel met papiertjes rondlopen.

[J_van_Ekris]

Maar die KLM-app downloaded dus die informatie niet? (dat zou ik wel verwachten namelijk). De maatschappijen met wie ik vloog hadden die info lokaal in de app staan.

Weet ik niet eigenlijk. Ik ben op zakenreis niet zo kostenbewust vrees ik. Kan me goed voorstellen dat er zaken gecached worden, maar ik zie gate changes vaak eerder op de app verschijnen dan dat ze op kleinere vliegvelden gemeld worden, dus er wordt wel info actief opgehaald.

[Left]

Met KLM heb ik het nog nooit meegemaakt, maar wel een keer met SwissAir dat hun ticketsysteem eruit lag. Toen werd er wel gewoon overgeschakeld op de servicebalie, mensen die geen ticket hadden geprint en ook niet in hun Wallet hadden werd gevraagd om het alsnog bij een automaat te gaan printen.

Uiteraard duurde dit allemaal een eeuwigheid en leidde dit tot vertraging, maar ze vlogen wel gewoon.

[Alex3]

Pakkembeet 0,5% laten we zeggen 1% van de URLs waren valide. Ze hadden 900 URLs gevonden. Dat waren 9000 (bij 1%) verzoeken. Dat is een heel flink gezelschap die massaal de verkeerde URLs intikte. En die waren ook nog is allemaal op de hotel/vliegtuig-Wifi verbonden zonder VPN-achtige zaken.

Rekenen is ook een kunst. 90000, of 180000 bij 0,5%.

[lenwar]

Rekenen is ook een kunst. 90000, of 180000 bij 0,5%.

Je hebt gelijk. Nulletje te weinig getypt. Bedankt voor de niet-sarcastische correctie! 👍🏻

[Z80]

je blokkeert alleen de vlucht info. die in dit geval veel te veel info bevat.
vlucht gegevens, vertraging en gate zijn voldoende. eventueel aangevuld met stoel nummer.
de ticket heb ja al in de mail, of via de login portal.

[cariolive23]

Het aantal requests vanaf één ip adres, zegt iets over het netwerk maar relatief weinig of het nou goed of fout is. Het aantal foute requests, een 99% in dit geval, zegt hier wel iets over. En dat geldt ook voor diverse gegevens die je uit de header krijgt, die zijn hier hoogstwaarschijnlijk iedere keer hetzelfde of vergelijkbaar.

Na een tiental request zou je al een goed beeld moeten hebben van de aanval: vrijwel ieder request vanaf ip X, is voor een klant die niet bestaat.

En dat beeld ontstaat binnen enkele seconden. Hier kun je geautomatiseerd een actie op ondernemen.

[Cergorach]

...gelijk blokkeren en achteraf pas onderzoek doen en niet eerst afwachten.

Dit is een simpele risico analyse: Hoeveel schade doet het als je het direct blokkeert, hoe veel schade doet het als het open blijft staan? En dan kijken we naar financiële schade voor het bedrijf en schade die klanten op het bedrijf kunnen verhalen. Dan is al vlot duidelijk waar meer schade is, zeker als we kijken naar wettelijke reactie tijden vanuit GDPR, dan is 5 uur voor een vliegtuigmaatschappij helemaal niets en prima acceptabel.

Een andere vraag is dan natuurlijk: Was dit een slim ontwerp? Nope!

[Klauwhamer]

Maar waar baseer jij dan op dat vanuit GDPR gezien een reactietijd van 5 uur op een lek van (bijzondere) persoonsgegevens acceptabel is? Volgens mij is dit freewheelen met de term "mogelijk" ten faveure van een organisatie die dit veel beter moet doen. Ook vind ik je definitie van "schade" tamelijk beperkt als je nagaat dat identiteitsfraude van KLM-klanten een kostenpost is waar maar moeilijk een bedrag op te plaatsen valt in je risicoanalyse [als KLM].

[Reactie gewijzigd door Klauwhamer op 23 juli 2024 08:42]

[CAPSLOCK2000]

Het komt mij voor dat een reactietijd van vijf uur onacceptabel is.

Dat is al in de fysieke wereld veel te lang om kopiëren te voorkomen (inclusief reistijd naar de copy-shop), laat staan in de digitale.

Ik vind het moeilijk om te zeggen wat te lang of snel genoeg is. Van de brandweer mag je verwachten dat ze 10 minuten na melding ter plekke zijn maar het is natuurlijk wel heel duur. De meeste andere sectoren zijn niet zo snel. Bij een normaal (IT-)contract krijg je op z'n vroegst de volgende dag een reactie. Als het sneller dan dat moet wordt het al snel heel erg duur. En als je niet alleen een reactie wil ("dank u voor het melden van uw probleem") maar ook een oplossing helemaal.

KLM heeft na 5 uur gereageerd en dat is echt niet slecht als er mensen bij betrokken zijn die uit bed gebeld moeten worden, moeten uitzoeken wat er mis is en een oplossing bedenken. Het is niet goed genoeg om een lek te voorkomen, maar een reactie is natuurlijk altijd achteraf en dus te laat.

De vraag is wat we redelijkerwijs kunnen verwachten... en hoeveel we daarvoor willen betalen. Een hoop mensen altijd voor het goedkoopste product gaan, zeker als ze het verschil niet direct kunnen zien. Sterker nog, de meeste klanten ervaren strenge beveiliging als vervelend.

Net als bij alle "luxe"-producten gaat de prijs razendsnel omhoog als iets meer wil dan gemiddeld. De hele maatschappij (niet alleen IT) zit permanent op de rand van het absolute minimum doen waar we mee weg komen.

Goed, data beveiligen is dus duur, zeker als je mensen nodig hebt om te reageren.
Een computer kan sneller reageren áls de computer weet dat er iets mis is. Voorlopig hebben we nog altijd mensen nodig om met uitzonderingen om te gaan en mensen hebben uren nodig om te reageren. Dat kan altijd nog beter en sneller maar het wordt al snel te duur.
De conclusie is dat we een andere oplossing nodig hebben dan "snel reageren".

Het beste is natuurlijk om problemen helemaal te voorkomen ("voorkomen is beter dan genezen") maar ook dat heeft z'n grenzen, uiteindelijk kan er altijd ergens iets mis gaan.

Een nuttige aanpak is nadenken over hoe je de schade beperkt als het toch mis gaat.
Dat begint met dataminimalisatie: wat er niet is kan ook niet uitlekken.
Sla zo dus min mogelijk op en vraag je in iedere stap af welke data je echt nodig hebt en welke data de gebruiker moet kunnen zien. Een pagina met persoonlijke vluchtinformatie hoeft niet al je persoonsgegevens te bevatten, die weet je zelf wel.
Zelfs als je informatie later nodig hebt is het misschien niet nodig om die nu al te delen. In veel gevallen is een tijdelijk klantnummer het enige dat je nodig hebt om een bestelling af te handelen en hoeft alleen de postbode te weten wie de klant echt is.

Maar ook dataminimalisatie kan lekken niet helemaal voorkomen, er zijn nu eenmaal systemen die wel een hoop gevoelige data moeten opslaan. Een interessante maatregel is het opzettelijk vertragen van je systemen. Als je iedere verzoek om informatie met 0.1s vertraagt dan wordt het onmogelijk om meer dan 10 stuks informatie per seconde te laten lekken. Als een normale gebruiker 1 pagina opvraagt dan is een eenmalige vertraging van 0.1s onmerkbaar maar als je 1000 pagina's opvraagt dan duurt het opeens 10 seconde.
In dit geval waarbij maar 0.5% van de links werkt moet je 200 pagina's opvragen om 1 werkende te krijgen en dat duurt 2 seconde. In uur tijd kun je dan maximaal 1800 werkende pagina's te pakken krijgen.*

1800 lekken per uur is nog steeds veel maar zonder beperking zouden het er honderden per seconde zijn. Hoe langzamer het gaat hoe meer tijd er is voor (menselijk) ingrijpen. Hoe minder buit er binnen wordt gehaald hoe minder het de moeite waard is voor criminelen om er tijd in te steken.

Onze computers zijn helemaal ingericht vanuit de gedachte dat alles zo snel mogelijk moet, maar soms is het slim om bewust wat vertraging in te bouwen.

* slimmerikken denken nu direct aan parallelisatie om de ratelimiter te ontwijken, dat zul je inderdaad moeten voorkomen. Dat is geen probleem, niks is perfect, geen enkele beveiligingsmiddel kan in z'n eentje alles tegen houden.

[Groningerkoek]

KLM heeft na 5 uur gereageerd en dat is echt niet slecht als er mensen bij betrokken zijn die uit bed gebeld moeten worden, moeten uitzoeken wat er mis is en een oplossing bedenken. Het is niet goed genoeg om een lek te voorkomen, maar een reactie is natuurlijk altijd achteraf en dus te laat.

5 uur om een paar IP's te blokkeren welke ruim meer dan 100.000 calls verrichten naar persoonlijke gegevens waarvan 99,5% een call voor een niet bestaande "dossier" is. Is hoe je het ook wendt of keert ongelofelijk slecht.

Dit systeem krijgt normaal amper foutieve IP's te verwerken omdat men met klikbare url's werkt. En dan ineens zoveel foute aanvragen vanaf een paar IP's. Dit had binnen minuten automatisch opgepakt moeten worden. Als men dit langzamer had gedaan en een voorziening om IP's snel te wisselen had men zeer waarschijnlijk de hele database binnen kunnen trekken. En dan heb je klantgegevens van 284 Miljoen boekingen op straat liggen.

[J_van_Ekris]

Dit systeem krijgt normaal amper foutieve IP's te verwerken omdat men met klikbare url's werkt. En dan ineens zoveel foute aanvragen vanaf een paar IP's. Dit had binnen minuten automatisch opgepakt moeten worden.

Ik weet niet of dit zo is eerlijk gezegd. Ik durf zelfs heel stellig het tegenovergestelde te beweren. KLM doet namelijk haar passenger handling absoluut niet zelf. De passenger handling wordt namelijk door Amadeus gedaan (een partij die dit ook voor Lufthansa, Britisch Airways, etc. werkt). Dus de technische vraag is of het uberhaupt door KLM gezien wordt omdat veel door het backend van Amadeus wordt gedaan. En zoals ik het lees is het een URL-shortner waarbij je waarschijnlijk direct bij de reguliere mobiele website uitkomt. Er is met de introductie van mobiele browsers zo'n 20 jaar geleden geen noodzaak meer om een aparte website voor telefoons te bouwen. En die website krijgt, net als elke andere publiek staande website, altijd dagelijks al een hoop ellende over zich heen.

Als men dit langzamer had gedaan en een voorziening om IP's snel te wisselen had men zeer waarschijnlijk de hele database binnen kunnen trekken. En dan heb je klantgegevens van 284 Miljoen boekingen op straat liggen.

Je beseft dat dit gaat om zaken als boardingpassen en incheckgegevens etc.., die maar 30 uur voor vertrek actief worden?

[Groningerkoek]

Het boeit niet wie dit systeem beheert. Feit blijft dat het hier ging om gegevens bij 1 bedrijf namelijk Air-France/KLM, men verstuurt klikbare links en dan is met gemiddeld 77.000 passagiers per dag het toestaan van ongeveer 36.000 calls per uur waarvan ongeveer 99,5% foutief van slechts een paar IP's een zeer kwalijke zaak. Als er al detectie op zit dan is die zeer slecht ingesteld.

30 uur voor vertrek, en blijkbaar dus nog jaren daarna, waarbij persoonsgegevens en bij sommigen zelfs paspoortgegevens dus veel te gemakkelijk op straat komen te liggen.

[J_van_Ekris]

Het boeit niet wie dit systeem beheert. Feit blijft dat het hier ging om gegevens bij 1 bedrijf namelijk Air-France/KLM, men verstuurt klikbare links en dan is met gemiddeld 77.000 passagiers per dag het toestaan van ongeveer 36.000 calls per uur waarvan ongeveer 99,5% foutief van slechts een paar IP's een zeer kwalijke zaak. Als er al detectie op zit dan is die zeer slecht ingesteld.

Het punt is dat het systeem wat aangevallen is waarschijnlijk dagelijks veel meer ellende ziet, en dat die aantal foutmeldingen niet eens opvallen. Operationele systemen op het internet liggen voortdurend onder vuur, uit alle hoeken. Mensen die een volledige dictionary op het root-wachtwoord loslaten, etc.. En uit dat soort ellende een gerichtere aanval vissen is niet makkelijk. Die mensen op zo'n SOC zijn continue bezig aanvallen af te slaan.

[Groningerkoek]

Binnen 1 uur 56.000 ongeldige calls van slechts een paar IP's op een systeem wat toegankelijk wordt gemaakt met clickable links (dus procentueel een zeer lage foutfactor aangaande passagiersgedragingen) voor een bedrijf met gemiddeld 77.000 passagiers per dag. En dat kon dan urenlang doorgaan terwijl er gegevens weglekken.

Mag jij normaal vinden, ik vindt dat ongelofelijk amateuristisch en dan deugt het systeem gewoon niet. En wat de mensen allemaal doen boeit mij niet zoveel dit hoort het systeem zelf af te vangen.

Daarnaast is het belachelijk dat gegevens van anderen zo simpel zijn te benaderen, dit verwacht je bij de bingo actie van de slagerij om de hoek, maar het is een multinational onwaardig.

[J_van_Ekris]

Binnen 1 uur 56.000 ongeldige calls van slechts een paar IP's

Jij schrikt er van. Ik noem dat "Just another boring day on the internet". De realiteit is dat elk public-facing systeem elke dag continue shit voor zijn kiezen krijgt die daar niet thuis hoort omdat iemand zijn werk niet goed heeft gedaan, of omdat iemand besloten heeft bij je in te breken. En er zitten mensen in een SOC die continue moeten overwegen het systeem plat te leggen, of dat ze vertrouwen op de ontwikkelaars dat die hun deel van de beveiliging goed gedaan hebben.

Want een miljoen mislukte inlogpogingen op een server in een etmaal is namelijk iets waar niemand in de security nog van schrikt of een server voor plat legt. Dat is business as usual en waar je kijkt of de beveiliging op applicatieniveau zijn werk doet.

systeem wat toegankelijk wordt gemaakt met clickable links (dus procentueel een zeer lage foutfactor aangaande passagiersgedragingen) voor een bedrijf met gemiddeld 77.000 passagiers per dag.

Allereerst weet niemand hier hoe die architectuur in elkaar zit. Bepaalde API's en weblets worden vrij frequent opgehaald omdat je passagiers van hele actuele info moet voorzien. Een app die elke seconde polt is niet vreemd, en dan is 77.000 passagiers per dag ineens veel traffic.

Als dit een URL shortner is met een doorverwijzing naar de mobiele website, dan begint die mobiele website als het goed is foutmeldingen te geven. Maar een (mobiele) website ligt altijd en continue onder vuur, dus het is maar de vraag of je uit de reguliere Mount Everest van foutmeldingen deze specifieke aanval pikt. Nog afgezien van het feit dat men mogelijk bezig is om de zoveelste Russische hackerbende af te slaan. Achteraf is altijd makkelijk praten, maar in situ is het een stuk pittiger.

[Reactie gewijzigd door J_van_Ekris op 23 juli 2024 08:42]

[Groningerkoek]

"Jij schrikt er van."

Dat zuig je uit je grote duim. Ik zeg alleen dat het er dusdanig veel meer zijn van maar een paar IP's dan wat te verwachten is van de eigen gebruikersgroep voor het beoogde doeleinde dat het systeem daar op in hoort te grijpen.

Dat heeft niets met schrikken van aantallen te maken.

[djwice]

Met welke maatregel? Mijn indruk is dat er adequaat is gehandeld door login te verplichten.

Op een van de websites die op mijn platform draait hebben we gemiddeld een half miljoen aanval requests per dag die we kunnen onderscheiden van het normale verkeer. Dat is business as usual. Soms zien we daarnaast een aanval met slechts 200 request of minder, maar zeer doel gericht en uitzichzelf gestopt. Dan moet je op gaan passen. Dan weet je dat je binnen afzienbare tijd een speciaal "cadeautje" gaat krijgen.

[Reactie gewijzigd door djwice op 23 juli 2024 08:42]

[Groningerkoek]

Het gaat er niet om hoeveel aanvallen je krijgt, het gaat erom hoeveel afwijkende links je te verwerken krijgt in verhouding tot hoeveel normaal verkeer je te verwachten hebt. Je moet verkeer wat je krijgt vergelijken tegen hoeveel normaal verkeer je verwerkt dan vallen verschillen veel sneller op. 1.000 inlogpogingen is voor veel systemen niets, maar als het 1.000 inlogpogingen zijn binnen een uur bij de website van de slager om de hoek dan zijn het er wel zoveel meer dan het normale verkeer dat het systeem dit al als verdacht aan dient te merken.

180.000 verschillende pogingen om persoonsgegevens op te vragen in 5 uur via een systeem welke vluchtgegevens vrijgeeft voor passagiers voor een bedrijf welke gemiddeld 77.000 passagiers verwerkt per dag is veel. Dit via slechts een paar IP's is eg veel. En aangezien ze alleen met directe links werken en dus een zeer kleine foutmarge is 56.000 foute aanvragen per uur belachelijk veel. Wat jij daarvan vindt moet jij weten, ik vindt het belachelijk dat dit kon op deze manier en ook dat het urenlang kon doorgaan.

En leuk die log-in. Je mag het adequaat noemen maar het is wel de put dempen als het kalf al verdronken is.

[djwice]

Ik hoor vooral je mening. Resteert nog antwoord op de vraag; Nog steeds de vraag, welke mitigerende maatregel zou jij nemen, die het normale verkeer niet verstoort, de aanvalfrequestie niet gaat toenemen en je niet moet gaan vechten tegen een multitude aan IP-adressen?

Ik heb al aangegeven wat ik doe, jij nog niet.

[djwice]

180.000 requests in 5 uur is niet veel: 10 per seconde. Je wil een hacker soms niet opjagen door te laten weten dat je hem op het spoor bent.
Zeker als je weet dat er een permanente mitigerende maatregel aan komt.
Alles is dan beter dan dat de hacker gaat opschalen / uit het vizier raakt. Wellicht was ook al achterhaalt op welk adres de computer stond. En was het nationaal cyber security team al betrokken.

Welllicht zat ie al in een honeypot?

[Groningerkoek]

Wellicht was het Mickey Mouse of Donald duck.. aan wellicht hebben we niet zoveel.

Voor een server hoeft het inderdaad niet veel te zijn, ik had miljoenen per uur voor mijn site en dat is al niet eens zo enorm veel. Maar het gaat mij er niet om af het er wel of niet veel zijn voor een server.

Dit is een systeem waarbij je derden toegang geeft tot hun persoonlijke gegevens, en de toegang wordt verstrekt via direct links en allereerst is er een belachelijk simpel systeem waarbij je super simpel de "unieke" code van anderen kunt raden. En dan ontbreekt er ook nog afdoende controle op als mensen dit gaan doen, en gegevens worden belachelijk lang toegankelijk gehouden. En het zou toch onzin zijn om als het een gedeeld systeem is om je parameters alleen zo in te stellen dat het geheel wordt bewaakt, want dan kun je dus super-simpel een deel leeg trekken en geen alarmbelletje welke afgaat. Doe er wat langer over, doe wel een poging om uit het zicht te werken en men merkt er niets van.

Dan kun je er wel van alles bij gaan halen, maar dat boeit toch allemaal niet. De feiten zijn simpel:

1- Veel te simpele url
2- Veel te veel records / duur geldigheid url veel te lang
3- Veel te weinig controle

[djwice]

Welke effective mitigerende maatregel die niet opgemerkt zou worden door de hacker stel jij voor dat binnen die 5 uur operationeel had moeten worden?

De 'feiten' die jij opsomt geven een beperkte kijk op de werkelijkheid. Vandaar mijn suggesties met 'wellicht' om je meer inzicht te geven in wat er nog meer op de achtergrond speelt.

[Reactie gewijzigd door djwice op 23 juli 2024 08:42]

[Groningerkoek]

Grappig hoe jij het hebt over "wellicht" en "suggesties" maar het enige wat jij zeker weet is dat ik een beperkte kijk heb op de "werkelijkheid" een werkelijkheid die jij niet kent.

[Blokker_1999]

Zonder te weten op welke manier de detectie gebeurd is, wat de limieten zijn en aan welk tempo men URLs opvroeg tijdens het onderzoek kunnenw e niet weten of dit snel of traag was. Wat wil je dan? 3 ongeldige requests en blokkeer het adres maar?

Je moet altijd een balans vinden tussen iets wat werkbaar is en iets wat veilig is. Ultieme veiligheid online heb je nooit,

[lenwar]

Ze hadden 900 URLs gevonden in die 5 uur.
Ze gaven aan dat 0,5% tot 1,0% van de URLs geldig bleek.

Dat komt dus neer op 90000 (bij 1%) tot 180000 (bij 0,5%) verzoeken in 5 uur. Dat zijn 300-600 verzoeken per minuut.

Edit: 90.000, niet 9000 (en dus 300-600 per minuut)

[Reactie gewijzigd door lenwar op 23 juli 2024 08:42]

[J_van_Ekris]

Met andere woorden: als de timing enigzins slim is, verborgen in het reguliere verkeer.

[lenwar]

Vanuit 1 à 2 ip-adressen?
De absolute hoeveelheden zijn inderdaad niet schokkend, maar wel vanuit 1 à 2 adressen.

[J_van_Ekris]

Zoals anderen al aangaven: voor een hotspot op een vliegveld zou dat niet vreemd hoeven zijn....

[dutchgio]

In de digitale wereld gaat het er echter wat anders aan toe.
Je kunt niet zomaar na x aantal requests een IP-adres blokkeren, zeker als blijkt dat de NOS dit ook gewoon vanaf de eigen IP-adressen uitvoert.

En voor een daadwerkelijke aanvaller is een IP blokkade ook maar een beperkte maatregel. Die is juist in staat om door middel van een VPN/cloud proxy voortdurend van IP-adres te wisselen om dat tegen te gaan.

[Reactie gewijzigd door dutchgio op 23 juli 2024 08:42]

[svane]

Je gaat hieraan voorbij dat slechts één op de 200 request een geldige code bevatte. Er is niks mis mee om na bijv. 5 foute pogingen een ip-adres tijdelijk te blokkeren.

Nee, je lost daarmee niet alles op. Maar een aanvaller heeft dan wel zo'n 40 ip-addressen nodig per nuttig stuk informatie. Misschien zou je zelfs een 'shadow'-block willen doen. waar het lijkt alsof een code niet geldig is (ook al is deze het wel), om de aanvaller niet wijzer te maken dan hij/zij al is na een blokkade.

Ik neem 't ze niet kwalijk dat het niet waterdicht was, maar er is wel een verschil tussen een deur die wagenwijd open staat, of één die op een kiertje staat.

[Piemol]

Probleem is natuurlijk met dat systeem dat als je de publieke wifi van Schiphol gebruikt, en ze dan dat ip adres blokkeren, je niet één persoon blokkeert maar een compleet (gast)netwerk van een bedrijf. Stel dat er bij duizenden reizigers op een dag 3 zijn die even het linkje aanpassen of een oude openen die niet meer geldig is: block!
Zelfs bij een heel klein bedrijfsnetwerk kan een simpele block op ip al erg frustrerend zijn voor legitieme gebruikers.

[svane]

Dat is een goed punt interdaad. Je zou dat weer kunnen whitelisten, maar dat wordt wel een flinke administratieve rompslomp.

Misschien op te lossen met een service als ReCaptcha of Turnstile? Die kijken ook naar andere factoren dan alleen IP-adres. Al kleven daar weer mogelijk andere (privacy) problemen aan.

[J_van_Ekris]

Je gaat hieraan voorbij dat slechts één op de 200 request een geldige code bevatte. Er is niks mis mee om na bijv. 5 foute pogingen een ip-adres tijdelijk te blokkeren.

Dat hangt af van hoe foutgevoelig dat kanaal van nature al is. Ik kan me voorstellen dat men een hoop ruis heeft door telefoons die rare dingen doen met URL's met tekensets die ze normaal niet gebruiken bijvoorbeeld. In de perfecte wereld zou dat niet mogen bestaan, maar als KLM heb je er wel mee te dealen.

Ik neem 't ze niet kwalijk dat het niet waterdicht was, maar er is wel een verschil tussen een deur die wagenwijd open staat, of één die op een kiertje staat.

Het ontwerp is brak, dat ben ik helemaal met je eens.

[svane]

Goed punt. Ik verwacht eerlijk gezegd niet dat kleine-letters/hoofdletters/cijfers op veel telefoons problemen opleveren en ik denk al helemaal niet dat waneer iemand voor de 6e keer op een link klikt, dan het dan ineens wel werkt, maar ik ben het ermee eens dat wild gaan blokkeren na 5 pogingen ook weer z'n eigen problemen kan veroorzaken.

Ik ben ook totaal niet bekend met alle eigenaardigheden met SMS in allerlei talen
Het zet me wel aan het denken. Automatisch wat smsjes naar collega's sturen is een no-brainer, zo gebeurd. Ga je 't hebben over een groot internationaal publiek als KLM, dan heb je ineens veel meer wat er mis kan gaan.

[Dr. Horrible]

Misschien niet na 5 pogingen, maar wel na 100 foute pogingen.

[dutchnltweaker]

Wat ik me afvraag, worden er geen jaarlijkse audits of andere tests omtrent veiligheid gegevens? Dan zou zo iets simpels als dit toch naar voren moeten komen? ook het feit dat ze het blijkbaar snel hebben opgelost op hun IT afdeling vind ik het best opmerkelijk dat het over het hoofd is gezien.

Volgens de KLM sloeg het systeem 'al alarm' door de 'grote hoeveelheid verdachte activiteit' uit het onderzoek van de NOS en Broersma. Die deden naar eigen zeggen echter geen moeite om die activiteit te verhullen. De gebruikte IP-adressen van de NOS en Broersma werden na ruim vijf uur geblokkeerd.

In die 5 uur genoeg kunnen doen, als je zo alert bent als KLM moet het toch sneller kunnen dan 5 uur? Gegevens buit maken is al erg, maar stel dat het nog geheimere data was geweest..

[Reactie gewijzigd door dutchnltweaker op 23 juli 2024 08:42]

[Ruthhl3ss]

Daar komen de papieren tijgers zoals de ISO27001 etc. naar voren. Helaas wordt dit gezien als een vooraanstaand certificaat maar het is slechts een papierenwerkelijkheid.

Een dergelijk systeem zou, zoals je zelf ook aangeeft, elk jaar een gepentest moeten onder gaan of na een substantiele update.

[Orangelights23]

Helemaal eens m.b.t. ISO (en ik heb er tientallen geïmplementeerd bij organisaties in Europa...). Wel is het zo dat een pentest niet betekent dat dit soort kwetsbaarheden gevonden worden. Een pentest is uiteindelijk een handmatige oefening op basis van de kennis en kunde van de pentester, de scope en de tijdsduur. Allemaal beperkingen die kunnen zorgen dat kwetsbaarheden niet gevonden kunnen worden. Ook kan deze kwetsbaarheid geïntroduceerd zijn door een recente wijziging, waardoor er blijkbaar iets mis is binnen hun change en risico management processen.

[CAPSLOCK2000]

We hebben het natuurlijk allemaal nodig.
Inhoudelijk ben ik redelijk tevreden met ISO27001 maar het wordt veel groter gemaakt dan het is.
ISO27001 is geen einddoel maar een ondergrens, ISO27001 is geen garantie dat je organisatie veilig is.

Helaas wordt het vaak wel gezien als een soort stappenplan naar veiligheid. Bedrijven gaan iso27001 "doen" en typisch betekent dat men eens per jaar een formulier invult samen met een auditor en dat het klaar is als overal een vinkje staat.

Dat is zo iets als alleen je tanden poetsen op de plekken waar de tandarts zegt dat je gaatjes hebt. Je gebit wordt niet beter van de tandarts bezoeken, je zal zelf moeten poetsen en je hele mond moeten doen, niet alleen waar het spiegeltje van de tandarts bij kan.

Je moet iedere dag zelf poetsen/flossen/raggen/... . Als je alleen poetst op de dag dat je naar de tandarts moet of niet al je tanden poetst dan heeft het weinig zin. Als je alleen maar naar de tandarts gaat om foto's te laten maken ben je helemaal niet slim bezig want rontgenstraling is schadelijk en je gebit wordt er niet beter van.

Zo ook iso27001. Als je doel (alleen) is om iso27001 te halen dan kun je het net zo goed niet doen en zit het waarschijnlijk alleen maar in de weg. Als de boel wel goed geregeld is dán is ISO27001 een mooi middel om aan te tonen dat het goed is en gebieden te vinden waar het nog beter kan.

[Reactie gewijzigd door CAPSLOCK2000 op 23 juli 2024 08:42]

[Ruthhl3ss]

Helemaal mee eens.

Vaak is het echter wel het doel alleen om ISO27001 te halen waardoor het in dat geval een papierenwerkelijkheid is.

[Dennisdn]

Als je het zo ziet dan begrijp je ISO misschien niet helemaal. De vastgelegde procedures (de "papieren tijger") zijn slechts een een klein onderdeel van het managementsysteem. Het draait om alle interacties tússen die procedures: als-dit dan-dat. Om daarin zaken mooier voor te kunnen doen dan ze zijn moet je bewust fraude pleggen, en dát is een heel ander level want een ISO beschermt niet tegen criminaliteit.

[Reactie gewijzigd door Dennisdn op 23 juli 2024 08:42]

[Cergorach]

Bij de KLM: wat voor 'nog geheimere data'? Hun geheime basis met al hun goudstaven?

Jaarlijks testen klinkt makkelijk, maar is dat absoluut niet. Dit soort dingen testen is net als een mens testen op bv. vergif, dan ben je er niet met 1 test, je moet voor elk stofje een aparte test draaien, als er 1000 giftige stoffen zijn zal je 1000x een test moeten draaien. Elk systeem is in deze vergelijking een mens, dus aantal giftige stoffen x het aantal mensen. En dergelijke grote enterprises/multinationals kunnen ook weer duizenden systemen hebben. Je zou dus miljoenen tests moeten doen per jaar...

Maar OK, je heb al die tests gedaan in een jaar, twee dagen later is er een UX aanpassing die spontaan dit gat maakt, dan heb je alsnog een gat. Bij zaken zoals Red Teaming worden dit soort zaken niet echt mee genomen, men probeert meer binnen te dringen dan persoonsgegevens te verzamelen. En als het Red Team een methode heeft gebruikt die geheel deze webapp niet heeft aangeraakt, dan kijkt men er ook geheel niet naar, men is meer gefocused op wat het Red Team heeft gedaan...

Het is IT, het wordt heel snel complex en bij grote organisaties heeft niemand meer het gehele overzicht. Dan heb je weer A werkt, B werkt, maar werkt A+B? In dit soort gevallen zijn er zoveel bewegende onderdelen dat je meer A+B+C+infinity hebt.

Is het acceptabel? Nee! Komt het vaak voor? Ja! Vind men het vaak? Nee... Over het algemeen pas als het te laat is...

[Groningerkoek]

Bij de KLM: wat voor 'nog geheimere data'? Hun geheime basis met al hun goudstaven?

Passagierslijsten kunnen al heel gevoelig zijn, maar vergeet de ladingslijsten ook niet. Als uitlekt dat jij of ik met vakantie gaan kan slecht zijn, maar weten welke vlucht een krat vol diamanten van Amsterdam naar Zürich brengt is informatie die je voor veel geld kunt verkopen.

[Hans1990]

Hoera, ze kunnen 1 bad actor detecteren na 5 uur. 900 hits met hitrate van 0,5% betekent 180 000 calls. In 5 uur tijd is dat 10/sec. Ik ben oprecht verbaasd dat zoiets vanaf 1 IP is gelukt

Laat KLM maar niet horen dat er professionele netwerken zijn die tienduizenden IPs aanbieden. Iemand kan maandenlang dit laten draaien en zodoende tienduizenden persoonsgegevens hebben losgepeuterd. Goed dat nu het lek wel snel is gedicht.

[Reactie gewijzigd door Hans1990 op 23 juli 2024 08:42]

[Cergorach]

Maar goed dat je niet de beveiliging doet...

Het nhow Rai hotel in Amsterdam heeft 650 kamers en zou prima 1000+ gasten kunnen hebben, vanuit hoeveel IPs denk je dat men vanuit de wifi het internet op gaat? Dan de beurzen, etc. daar zit je ook op het wifi, zeker als het een internationale beurs is, zal je veel klanten hebben die met het vliegtuig weer vertrekken. Dan is opeens 900 hits in 5 uur geen enorm issue meer...

[Knorretje-]

Maar dat zijn wel allemaal legitieme hits natuurlijk. Dit waren 99.5% hits die een niet-bestaande code opvragen.. dat is natuurlijk verdacht. Los van de SMS zou nooit iemand dat adres handmatig aanroepen.

[Hans1990]

Even opnieuw lezen, want blijkbaar moeilijk...

Ik heb het niet over 900 bezoeken; maar over 900 positieve resultaten (hits) met een hitrate van 0.5%. We hebben het dan over 180k calls vanaf 1 IP.

Natuurlijk krijgt een site als KLM veel meer calls per dag. KLM vervoert 77 miljoen passagiers per jaar, zo'n 211k per dag. Als elke passagier meerdere keren op zo'n link naar de status kijkt, dan zitten alle normale bezoeken in dezelfde orde grootte (afgezonderd piek/dal momenten) als dit script.

Nee, daarvoor hoef je geen ster in beveiliging voor te zijn om te snappen dat zoiets verdacht is.

[Reactie gewijzigd door Hans1990 op 23 juli 2024 08:42]

[dutchgio]

Wel erg slordig, een URL zonder authenticatie en 6 tekens is wel een schoolvoorbeeld van hoe het niet moet.

[codekloppertje]

Het is misschien niet zo erg als ze een detectie/blokkeer systeem hadden dat na 2 verkeerde pogingen een IP adres zou blokkeren. Want dat zou eigenlijk niet kunnen, op een verkeerde url klikken.

Verder vraag ik me af hoe recent de gegevens zijn en of die niet al gewoon verwijderd hadden moeten worden. Want als ze 0.5% hit-kans hebben dan betekent dat 36^6 * 0.5% = 10 miljoen records. Dat is niet van de laatste maand.

[Reactie gewijzigd door codekloppertje op 23 juli 2024 08:42]

[pumpidumpi]

Het is misschien niet zo erg als ze een detectie/blokkeer systeem hadden dat na 2 verkeerde pogingen een IP adres zou blokkeren. Want dat zou eigenlijk niet kunnen, op een verkeerde url klikken.

Het lastige is dat er 1000'den mobiele telefoons op 1 ip adres (kunnen) zitten. Dus dan is 2 foute pogingen erg weinig en heb je veel te vaak een false positive.

[mocean]

Precies, de pagina om in te checken moet 3 dagen open staan ongeveer...

[pe0mot]

30 uur

[Groningerkoek]

0,5% hit kans bij 36,8 Miljard mogelijke combinaties geeft 284 Miljoen records.

77 Miljoen passagiers voor Air-France/KLM per jaar (geen hoeveel het er waren in de corona periode) Maar dit gaat dus minimaal een paar jaar terug.

[codekloppertje]

Denk dat je een typo hebt. Bedoel je door hoofd en kleine letters en cijfers = 62 chars => 62 tot de macht 6? Da's 56.8 miljard.

[Groningerkoek]

Ik had die foutieve 36 bij het overhaast typen overgenomen doordat jij ook het getal 36 gebuikte. (geen idee waarom)

Het is inderdaad 56.8 Miljard. En ik heb geen idee waarom jij van 36 tekens uitgaat en bij 10 Miljoen records komt terwijl zeer duidelijk in de artikel staat dat men grote en kleine letters gebuikt. En ze hebben zelfs al voor ons uitgerekend om hoeveel records het ongeveer gaat, namelijk 284 Miljoen.

[codekloppertje]

Ik denk dat ik alleen het T artikel heb gelezen. Mogelijk heeft de NOS 't later ook toegevoegd (?)

Ik vind de tweakers samenvatting wel anders dan het NOS artikel.

[Groningerkoek]

Stond al in het Tweakers artikel

[mfkne]

Vreemd dat ze nog steeds SMS blijven sturen ipv gewoon via e-mail. Als je internet toegang hebt op je telefoon kun je e-mails ontvangen, en zonder internet op je telefoon heb je aan die SMS ook niks. Zou dat hele gebeuren met korte links om binnen een bericht te passen meteen oplossen.

[SuPaToLL]

Psst, SMS is niet afhankelijk van internet.

[mfkne]

Zeker, maar als je de link wilt volgen moet je wel Internet hebben.

[J_van_Ekris]

Ze gebruiken het volgens mij als tweede kanaal, buiten de app om. Dit kanaal heeft een veel hogere aandachtswaarde.

Heeft mij wel eens een gemiste vlucht gescheeld. Door een boekingsfout ging mijn vlucht een dag eerder dan ik had aangegeven, en een SMS met "U kunt nu inchecken voor uw vlucht voor morgen" komt dan wel binnen kan ik je zeggen.

[marktweakt]

En alweer een groot bedrijf dat met geen/slechte beveiliging zeer kritische gegevens van ons aan elke kwaadwillende gratis aanbiedt.

Enig idee wat er kan gebeuren als zo'n kwaadwillend iemand je identiteit hierdoor steelt? Nou ga er maar vanuit dat dat op z'n minst zeeer onplezierig kan worden!

En als je dan denkt dat je schade die je hierdoor leidt kunt verhalen op het bedrijf dan heb je het ook mooi mis. Dan zeggen ze rustig dat je maar moet aantonen dat die schade het gevolg van hun datalek is. En dat is bijna onmogelijk omdat ze natuurlijk geen enkele informatie verschaffen.

De regelgeving en het toezicht van de overheid schiet op alle fronten tekort en voor bedrijven/instellingen is het niet lonend om zwaar te investeren in de best mogelijke beveiliging van onze gegevens.

Mijn pleidooi is dan ook om de bewijslast in het geval van schadeclaims n.a.v. datalekken om te draaien. Het bedrijf/instelling moet in dit geval maar aantonen dat de schade niet is geleden als gevolg van het datalek.
Dit is volgens mij de enige manier waarop deze tsunami aan datalekken kan worden gestopt.

[litebyte]

Inderdaad, en schandalig. Zeker bij zoiets als een luchtvaartmaatschappij, met gegevens die naast privacy gevoelig ook daadwerkelijk een gevaar kunnen betekenen voor deze of gene die bijv. gevlucht is of op een andere manier risico lopen als dit soort gegevens uitlekken.

Er zou een soort van schadeclaim systeem moeten komen, dan niet alleen m.b.t. luchtvaart/lekken van gegevens, maar natuurlijk ook voor andere bedrijven. Het excuus zal dan natuurlijk zijn dat bedrijven om claims te voorkomen veel meer kosten moeten gaan maken en dit dan moeten doorberekenen aan de klant.

[cariolive23]

Er wordt hier in de reacties volop gediscussieerd over het blokkeren van het gebruikte ip-adres, of dat wel of niet zinvol is, etc. Maar imho is deze discussie irrelevant, want daar gaat het helemaal niet om: Wat is het doel van de API en welke informatie wil je via de API beschikbaar stellen?

Wanneer je op basis van een reserveringscode de vertrektijden van de vluchten wilt delen, prima. Dat is niet supergeheim en zonder persoonsgegevens lijkt mij dat geen probleem. Maar waarom zou je mijn mailadres of telefoonnummer gaan delen? Die gegevens ken ik zelf ook wel. En niet alleen dat, waarom zou je die delen zonder dat de klant inlogt op zijn persoonlijke pagina?

Informatie die niet beschikbaar wordt gesteld via de API, kun je ook niet stelen via deze API.

Dat er in een korte tijd honderden requests vanaf één ip-adres komen, is niet zo bijzonder. Het aantal foute requests in een korte tijd is dan wel weer bijzonder, maar soms kun je daar dan ook vrij weinig tegen beginnen. Een aanval via een congres centre, grote hotelketen, of Schiphol zelf, kun je niet stoppen zonder de service offline te halen

[lovly_1]

En dan drukt de EU en Digital Identity door en alles daaraan koppelen, rijbewijs, medische data, etc. inclusief CBDC dat blijkbaar allang besloten is.

https://youtu.be/CUUGppXauQE?si=P8oqL2ZpGCJYemZj

een zeer groot risico dus.

[StewieDog]

Ik ben al gestopt met kijken na het vertellen van de kwaliteiten van die gast, vlijmscherpe tong en fotografisch geheugen...? Lijken me niet per definitie skills om mee te bewijzen dat je het allemaal weet. Daarnaast heeft het totaal niets te maken met dit lek. Tenzij de EU en KLM hetzelfde bedrijf hebben ingehuurd om links per smsjes mee te verzenden en ook jan en alleman laten inloggen met een link. Maar ik neem aan (ja, gevaarlijk) dat de EU je niet laat inloggen obv een link maar dat mfa een noodzaak is.

De EU heeft zich ook aan haar eigen regels te houden, dus een risico, ja dat zeker. Een groot? Mwah...

[Elidibus]

Mits goed geimplementeerd ben ik hier voorstander van. Wat ik als burger graag zou hebben is een digitale identiteit, waarbij ik vanuit mijn "wallet" andere partijen kan authenticeren om mijn gegevens te kunnen zien en welke gegevens specifiek. Dat ik vervolgens ook die authenticatie terug kan intrekken. Dit zorgt ervoor dat ik ten all tijden weet waar mijn gevoelige persoonlijke data "is" en wie er toegang tot heeft/heeft gehad.

Of het systeem zo gemaakt gaat worden is natuurlijk een tweede en dat is vooralsnog koffiedik kijken.

[Elidibus]

Toch interessant hoe zoiets werkt, als je via de voordeur op een vliegtuig wil stappen wordt je volledig doorgelicht en stellen ze vragen over een iets te grote knoop in je broek. (is niet allemaal KLM, maar toch). Maar als je via de achterdeur gevoelige informatie wil binnenharken staat de deur op een kier. Dit soort informatie is voor terroristen (horen ze graag) bijzonder waardevol, want ze weten dan perfect wie, wanneer, waar op het vliegtuig zal stappen en kunnen dan de juiste kandidaat uitzoeken om iets mee te smokkelen of te onderdrukken iets te doen dat ze eigenlijk niet willen doen.

[croc]

Uiteindelijk ben je de URLs aan het brute-forcen, en krijg je daardoor random data terug. Je kan dus niet op vlucht of datum gaan filteren, tenzij je alle data (constant) binnen haalt.

Wel goed om te lezen dat KLM het binnen een paar uur na melding al opgelost/aangepast had.

Een andere oplossing had kunnen zijn om na x verkeerde URLs een tijdelijke IP van op te leggen. Daarin heb je 2 variabelen die je kan tweaken. Ja, er kan nog foutieve data worden opgevraagd in theorie, maar in praktijk is het niet meer bruikbaar met .5% hit rate.

[StewieDog]

Wie heeft überhaupt verzonnen dat inloggen met een link per sms een goed idee is? Het lijkt mij toch meer dan logisch dat je minimaal dan nog een wachtwoord of boekingnr moet invullen voordat je bij je gegevens komt.

Ik had waarschijnlijk zelf ook meteen andere combi's geprobeerd als ik het wist dat het met mijn inlog zo kon. Kleine kans dat het lukt natuurlijk maar je zult maar een voltreffer hebben en een 'leuk geintje' willen uithalen.

Edit: ooit trouwens met een vriend geprobeerd bij een site waar de naam gewoon in de link stond. Naam van vriend erin en zat in zijn account...

[Reactie gewijzigd door StewieDog op 23 juli 2024 08:42]