Security

Wie kent het nog: De “Drie keer kloppen”-campagne van Nederlandse Vereniging van Banken (NVB) om klanten bewust te maken van beveiliging bij internetbankieren? In tv-spotjes, websites en tijdschriften werden mensen bewust gemaakt van het feit dat ze zelf deels verantwoordelijk zijn voor de veiligheid van hun online bankverkeer. Daarbij werden drie punten gegeven die je als gebruiker moest controleren of ze wel kloppen. Als eerste moet je de beveiliging van je computer nalopen: heb je alle updates geïnstalleerd, heb je antivirus, etc.? Als tweede moet de website kloppen. Wat hiermee bedoeld werd was dat je moest kijken of je op de juiste website zit (kijk naar de url) en of je het slotje in je url balk ziet (als je HTTPS gebruikt). Dit is om phishing en man in the middle (mitm) aanvallen tegen te gaan. Als derde moet je regelmatig je rekeningafschriften controleren zodat je, als het dan toch misgaat, zo snel mogelijk fraude opmerkt en maatregels kan nemen. ...

Here is another blog about Plimus. It seems like they don’t want to communicate or fix security issues instead they continue building new features. It’s a shame that a company that handles money as a primary business doesn’t have security as a top priority. This blogpost is about a feature that I have warned Plimus about, but haven’t been able to test because a Plimus employee actively refused to give me access to this feature, even after the engineer in charge for security asked me explicitly to test and report more security problems. So keep this in mind when you read this blog: I have not tried to exploit this. ...

It’s been a while since I have reported a few security bugs to Plimus. It took a few blogposts explaining the issues publicly before I got in contact with an engineer. I understand that making backwards incompatible changes to your customer facing API’s is not a trivial task, however the way Plimus handles these issues is just terrible. One engineer asks me for more feedback while in the same mail thread another Plimus employee demands proof I’m PCI certified and wants to know what applications I’m going to build before I get access to the test API of Plimus. If you don’t even let me test security bugs before I report them you won’t get the bugreport at all. Maybe I can test them after you have gone live and customers already depend on the API. ...

Iedereen die een beetje handig is met computers en al wat jaartjes meeloopt op het internet kent ze wel: default wachtwoorden op routers. Als je op een netwerk zit en je met je webbrowser naar het IP-adres van de router surft (meestal http://192.168.1.1/ ) kom je op de beheerpagina van je router. Soms hoef je niet in te loggen; meestal volstaat een standaard login (username=admin password=admin). Dat is natuurlijk erg grappig; je kan ongevraagd met de instellingen rommelen van de mensen waar je op bezoek bent. De iets slimmere nerds hadden in de gaten dat veel routers ook te bereiken waren via het internet, ook vaak met standaard wachtwoorden beveiligd. Dat maakt het al leuker: je kan opeens vanuit je luie stoel met heel veel internetverbindingen spelen. Dat is nog eens kattekwaad! Maar waarom doet niemand hier wat aan? De meeste mensen zetten een router neer, pluggen met veel moeite de stekkers erin. Als alles werkt zijn ze al lang blij. Ze beseffen zich niet dat er nog allemaal ingewikkelde instellingen veranderd kunnen worden en dat die beveiligd moeten worden met een wachtwoord. ...

Een tijdje geleden is mij de mobiele applicatie voor internetbankieren van de ING opgevallen. Door de combinatie van de gevoeligheid van mobiele platforms (In dit geval Android, maar het issue is niet Android specifiek.) en het ontbreken van TAN-codes als tweede factor voor de authenticatie zag ik een aanvalsvector waarvoor ik niet zag hoe daar tegen verdedigd zou worden. De lek zou ernstig zijn omdat er zonder je medeweten saldo van je rekening afgeschreven zou kunnen worden en dat op grote schaal bij gebruikers van deze mobiele app. In mijn onderzoek heb ik delen van de app reverse engineered en veel geleerd over de communicatie van de applicatie met de ING servers. Op een gegeven moment ben ik me gaan realiseren dat als ik daadwerkelijk de zwakte overtuigend wilde demonstreren ik de wet zou moeten overtreden. Dat gaat mij een stap te ver. Door mijn onderzoek heb ik ook wat geleerd over de afwegingen die de ING heeft gemaakt en wat ik van de ING wil is dat ze duidelijk communiceren wie verantwoordelijk is als er iets misgaat. Het technische verhaal kan ik zonder moeilijke details te gebruiken uitleggen. Het ouderwetse internetbankieren bij de ING werkt via de browser. Als je een virus op je computer zou hebben, zou dat virus betalingen kunnen aanpassen, wachtwoorden afluisteren, etc. Om dat te voorkomen zijn TAN-codes bedacht. Op het moment dat je een betaling uitvoert krijg je een smsje met details over de betaling die je op dat moment wilt doen met een eenmalig te gebruiken TAN-code. Die code moet je vervolgens invoeren om de betaling af te ronden. Daarmee bewijs je dat je niet alleen kan inloggen onder de account van de bezitter van de rekening, maar dat je ook controle hebt over zijn of haar telefoon. Omdat telefoons meestal onafhankelijk zijn van de desktop computers van een persoon maak je de drempel om in te breken in de bankrekening dusdanig veel hoger dat deze vorm van beveiliging erg effectief is. Tot zover lijkt alles in orde. ...

Veiligheid in de digitale wereld krijgt de laatste tijd veel aandacht. Door het hacken van Diginotar zijn mensenlevens in gevaar gekomen en vanaf dat moment lijken veel mensen zich te beseffen dat de veiligheid van onze digitale infrastructuur toch eigenlijk best wel belangrijk is. Om het punt duidelijk te maken dat veiligheidslekken eerder regel dan uitzondering zijn is Brenno de Winter met Lektober gekomen: elke dag van de maand oktober publiceerde hij een lek in een website van een bedrijf of een overheidsinstelling. De timeing had niet beter kunnen zijn. Ik krijg opeens van alle kanten vragen over cookies, hackers en het volggedrag van Google en Facecook. Ik zie dat als een goede ontwikkeling en we kunnen het ons niet veroorloven om hier niks mee te doen. ...

Veel bedrijven hebben tegenwoordig grote databases met gegevens over mensen. Soms gaat er wel eens iets fout en dan liggen de gegevens van een heleboel mensen op straat. Ik wil dat zodra gegevens lekken dat het bedrijf (of overheid!) verplicht is zonder onnodige vertraging alle betrokkenen in te lichten over de lek. Ik zal proberen een aantal redenen te geven waarom deze meldplicht nodig is. Schadebeperking Bij een datalek zijn vaak veel mensen een slachtoffer. Afhankelijk van wat er gelekt is kan het heel verstandig zijn om wachtwoorden te veranderen, apps te deinstalleren of in extreme gevallen zelfs identiteitsdiefstal verzekering af te sluiten. De realiteit is echter dat de bedrijven die lekken vaak helemaal niet willen toegeven dat er data gelekt is. Het is dan onmogelijk om zelf maatregelen te nemen. Ook als het bedrijf gegevens lekt door een inbraak en het bedrijf doet aangifte tegen de dader hebben de slachtoffers van de lek daar niets aan. Ze kunnen hun eigen data er niet door terugkrijgen en het zal ook niet helpen om ze te informeren over de lek. ...

Gisteren heb ik een heel goed gesprek gehad bij T-Mobile in Den Haag. Ik werd vriendelijk ontvangen door Ruud Huigsloot (Manager E-Services&Webcare Internet & New Media), iemand van pr en de juriste die o.a. verantwoordelijk is voor de privacybescherming van klanten. Het gesprek was informeel, ik vond het zelfs gezellig, maar wel inhoudelijk. Na een korte voorstelronde heb ik kort herhaald wat er gebeurd is vanuit mijn perspectief. Het punt wat voor mij het belangrijkste was, het ontkennen van de lek door T-Mobile, heb ik in perspectief kunnen plaatsen. Niet alleen was de situatie niet helemaal representatief omdat T-Mobile wist dat er een journalist bij betrokken was, emoties werden ook belangrijk in de reacties van T-Mobile omdat ze zich nogal in de maling genomen voelden. Juist het feit dat T-Mobile zich anders gaat gedragen onder druk is een kwetsbaarheid en het niet informeren van de klant is naar mijn mening altijd fout. Maar omdat T-Mobile zich dit ook heel goed lijkt te beseffen en omdat de situatie niet helemaal representatief is voor een echte identiteitsdiefstal heb ik wel begrip voor de afwijkende behandeling door T-Mobile. ...

Zoals elk modern bedrijf heeft ook T-Mobille een Twitter account om vragen van klanten te kunnen beantwoorden en mensen te informeren over storingen en onderhoud. Zoals elke brave klant volg ik dan ook @tmobile_webcare zodat ik van elke bui die een storing veroorzaakt op de hoogte blijf. Wat blijkt: Ik ben niet de enige. Een aantal van de mensen die ik volg op Twitter zijn ook T-Mobile klanten en maken af en toe ook gebruik van @tmobile_webcare waardoor ik het hele gesprek over en weer kan volgen. Meestal verzoekt @tmobile_webcare vrij snel om het gesprek over DM (Direct Message, oftwel berichten die niet publiek zijn) voort te zetten. Logisch, want je wilt niet zomaar je telefoonnummer of adres twitteren. Toch komt het wel eens voor dat er iets mis gaat en er toch gevoelige gegevens openbaar gemaakt worden. Een sterk voorbeeld daarvan is het publiceren van login naam en wachtwoord van een klant (Bron: Webwereld). Nadat ik zelf een aantal onhandige tweets van T-Mobile had opgemerkt besloot ik er wat over te zeggen. ...

This morning I got a phone call from a phone number in Isreal. It was Tal, an engineer from Plimus. Tal wanted to know about the issues I had found and what solutions I had in mind. Tal also explained their plans for fixing all issues and all the issues that are involved with changing their API. I’ll be keeping an eye on Plimus to see how they are doing, but now I’m confident that someone at Plimus understands their security issues and they are working on fixing them. ...