Computerbeveiliging
- Hoe je bad guys buiten de deur houdt
[Verwijderd]
09-08-2014, 10:53 door [Account Verwijderd], 10 reacties
Laatst bijgewerkt: 09-08-2014, 16:51
[Verwijderd]
Reacties (10)
In de transactiegegevens kan niets worden gewijzigd, dus de kaarthouder wiens gegevens zichtbaar waren, kon geen financieel nadeel ondervinden.”
Lol die gasten hebben zeker nooit gehoord van identiteit diefstal :P
Kon? Dit kan dus nog steeds, want ze zijn nu software aan het testen om dit lek te sluiten. Tjonge jonge, wat wordt het er toch allemaal professioneel van als je zaken uitbesteedt aan bedrijven. En zo klantvriendelijk en goedkoop.
Zijn ze niet in strijd met de WCC en de WBP bezig trouwens? Of telt dat niet als je betaald wordt door de overheid?
Oehoe overheid, marktwerking werkt alleen als de klanten wat te kiezen hebben, anders zijn ze beter af met een planeconomie!
Zijn ze niet in strijd met de WCC en de WBP bezig trouwens? Of telt dat niet als je betaald wordt door de overheid?
Oehoe overheid, marktwerking werkt alleen als de klanten wat te kiezen hebben, anders zijn ze beter af met een planeconomie!
Beetje een vaag en onduidelijk verhaal; want wat was nu exact het 'lek'?
Zelf geven ze aan dat het 'lek' niet reproduceerbaar is, maar wel dat het 'soms' mogelijk is om andermans gegevens in te zien.
Klinkt dus eerder als een probleem met een interne (sessie) sleutel generator die niet volledig (secure) random nummers uitgeeft. Dan doet de wet van de grote getallen de rest... Dus zeker fout; maar m.i. niet echt 'exploitable'...
Maar zonder meer technische achtergrond info blijft dit koffiedik kijken.
NB: wat me trouwens wel angstig maakt is dat ze de fout kennelijk al gevonden en gefixt hebben, maar tot dinsdag te tijd nodig hebben om deze naar productie te krijgen! Lijkt erop dat de prioriteit pas omhoog gegaan is na publicatie in de media - en dan nog eens plus vier dagen. Ik ken bedrijven waar zo'n melding (klant ziet andermans gegevens) dezelfde avond gefixt _moet_ zijn...
Zelf geven ze aan dat het 'lek' niet reproduceerbaar is, maar wel dat het 'soms' mogelijk is om andermans gegevens in te zien.
Klinkt dus eerder als een probleem met een interne (sessie) sleutel generator die niet volledig (secure) random nummers uitgeeft. Dan doet de wet van de grote getallen de rest... Dus zeker fout; maar m.i. niet echt 'exploitable'...
Maar zonder meer technische achtergrond info blijft dit koffiedik kijken.
NB: wat me trouwens wel angstig maakt is dat ze de fout kennelijk al gevonden en gefixt hebben, maar tot dinsdag te tijd nodig hebben om deze naar productie te krijgen! Lijkt erop dat de prioriteit pas omhoog gegaan is na publicatie in de media - en dan nog eens plus vier dagen. Ik ken bedrijven waar zo'n melding (klant ziet andermans gegevens) dezelfde avond gefixt _moet_ zijn...
Had niets anders verwacht dan dat dit zou gaan gebeuren. En ja, what's next?
En dan te bedenken dat men 1 Euro per kaartje bij moet betalen, wil iemand juist dit soort situaties voorkomen.
Pleur op, met die pokkekaart.
En dan te bedenken dat men 1 Euro per kaartje bij moet betalen, wil iemand juist dit soort situaties voorkomen.
Pleur op, met die pokkekaart.
Heel af en toe worden sessies verward. En de fix is net uit: https://issues.apache.org/bugzilla/show_bug.cgi?id=47714
Door Anoniem: Heel af en toe worden sessies verward. En de fix is net uit: https://issues.apache.org/bugzilla/show_bug.cgi?id=47714
Ik zie geen fix daar. Wel hints dat het probleem wel in de applicatie zal zitten en een algemene observatie die zou wijzen op (alweer) een architectuurfout. Met andere woorden, het is een type probleem dat al jaren bekend is maar af en toe weer opduikt omdat er mensen niet nagedacht hebben over wat ze nou eigenlijk aan het doen zijn.Overigens, "heel af en toe" maal "twee miljoen geregistreerde gebruikers" kan al gauw "dagelijks gedonder" betekenen.
Door Eric-Jan H te A.
Chrome x64 en inlogpagina zijn nog steeds geen vriendjes. Kan iemand dat bevestigen?
Chrome x64 en inlogpagina zijn nog steeds geen vriendjes. Kan iemand dat bevestigen?
Door Anoniem:
Ja ik zie alleen een hint dat het een applicatiefout betreft.
ik kan mij herinneren dat wij in het relationale databasesysteem DB2 van het grote en robuuste IBM ook tegen een dergelijke fout zijn aangelopen. Dat was voor de tijd dat DB2 zoiets als een "unique identifier" veld kreeg.
De ontwerper was er van uitgegaan dat een timestamp wel uniiek zou zijn. En hij had dat in zijn testomgeving met een bulktest ook bewezen. De timestamps lagen ver genoeg uit elkaar om er "zeker" van te zijn. De ontwerper had er alleen geen rekening mee gehouden dat de karakteristieken in een productieomgeving heel anders kunnen zijn in de vorm van aantallen threads, grootte van resourcepools en toegewezen cpu-tijd.
Het gevolg laat zich raden. De eerst volgende verbetering was om de combinatie key+timestamp dan maar "uniek" te verklaren. Een gok die tot de introductie van de "unique identifier" heeft gefungeerd.
Ik zie geen fix daar. Wel hints dat het probleem wel in de applicatie zal zitten en een algemene observatie die zou wijzen op (alweer) een architectuurfout
Ja ik zie alleen een hint dat het een applicatiefout betreft.
ik kan mij herinneren dat wij in het relationale databasesysteem DB2 van het grote en robuuste IBM ook tegen een dergelijke fout zijn aangelopen. Dat was voor de tijd dat DB2 zoiets als een "unique identifier" veld kreeg.
De ontwerper was er van uitgegaan dat een timestamp wel uniiek zou zijn. En hij had dat in zijn testomgeving met een bulktest ook bewezen. De timestamps lagen ver genoeg uit elkaar om er "zeker" van te zijn. De ontwerper had er alleen geen rekening mee gehouden dat de karakteristieken in een productieomgeving heel anders kunnen zijn in de vorm van aantallen threads, grootte van resourcepools en toegewezen cpu-tijd.
Het gevolg laat zich raden. De eerst volgende verbetering was om de combinatie key+timestamp dan maar "uniek" te verklaren. Een gok die tot de introductie van de "unique identifier" heeft gefungeerd.
Beetje vreemd. Een account wordt verwijderd en als gevolg daarvan ook de bijdrage van dat account.
Maar de reacties blijven in het luchtledige hangen.
Of je laat de bijdrage staan (desnoods met als account "Verwijderd")
Of je haalt ook de reacties weg.
Wel er even voor zorgen dat er geen account "Verwijderd" kan worden aangemaakt. ;-)
Maar de reacties blijven in het luchtledige hangen.
Of je laat de bijdrage staan (desnoods met als account "Verwijderd")
Of je haalt ook de reacties weg.
Wel er even voor zorgen dat er geen account "Verwijderd" kan worden aangemaakt. ;-)
Door Anoniem: Beetje vreemd. Een account wordt verwijderd en als gevolg daarvan ook de bijdrage van dat account.
Maar de reacties blijven in het luchtledige hangen.
Er bestaan meer caches dan die van Google en The internet Archive.Maar de reacties blijven in het luchtledige hangen.
OV-chipkaart lekt gegevens
09-08-2014, 10:53 door ( XXXX )
Laatst bijgewerkt: 09-08-2014, 16:51
Hallo security-forum-leden! Vandaag heb ik een verbijsterend stukje gelezen in het NRC. Een gedeelte hieruit:
De reisgegevens van mensen die een ov-chipkaart gebruiken en een account hebben op ov-chipkaart.nl zijn momenteel niet geheel veilig. Door een technisch probleem is het mogelijk dat reisgegevens, inclusief naam, adres, woonplaats en rekeningnummer soms zichtbaar zijn voor anderen en deels gewijzigd kunnen worden. Op ov-chipkaart.nl kunnen reizigers hun transactiegegevens inzien en hun saldo verhogen. Meer dan twee miljoen kaartgebruikers hebben er een account.
Het lek openbaarde zich onlangs toen een kaarthouder een nieuw account aanmaakte. Tot zijn verbazing kreeg deze persoon daarbij zicht op de reisgegevens van twee andere kaarthouders. Het ging om een anonieme kaartgebruiker en een man uit Arnhem. Van deze Arnhemmer waren ook zijn adresgegevens zichtbaar, plus e-mailadres en rekeningnummer. Bovendien konden deze gegevens nu worden gewijzigd.
Het lek openbaarde zich onlangs toen een kaarthouder een nieuw account aanmaakte. Tot zijn verbazing kreeg deze persoon daarbij zicht op de reisgegevens van twee andere kaarthouders. Het ging om een anonieme kaartgebruiker en een man uit Arnhem. Van deze Arnhemmer waren ook zijn adresgegevens zichtbaar, plus e-mailadres en rekeningnummer. Bovendien konden deze gegevens nu worden gewijzigd.
En leest u allen even mee: Translink wist van het lek, maar wat deed ze precies om de gebruikers te beschermen of te informeren????
Trans Link Systems, het bedrijf achter de ov-chipkaart, erkent het probleem. De kaarthouder kon volgens het bedrijf inderdaad het rekeningnummer en de adresgegevens van de andere kaarthouder inzien en wijzigen.
Zelf heb ik geen OV-chipkaart, maar 1 ding weet ik nu wel: ik ga er nooit gebruikt van maken.
Link: http://www.nrc.nl/nieuws/2014/08/09/gegevens-reizigers-chipkaart-niet-veilig/
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
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?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
