Posts

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. ...

Laptops are easy to lose or steal and you don’t want any potentially sensitive data to be stolen too. For that purpose many companies now require disk encryption. The OpenBSD softraid CRYPTO discipline has grown to be a mature piece of software and since I was long due for a fresh OpenBSD installation anyway I decided to give it a try. Let’s start with the goals: No user files should be recoverable when the laptop gets lost or stolen without knowledge of my passphrase. The boot and upgrade process should be as simple as possible. What I’m not trying to do: Provide plausible deniability: The largest disk slice is a softraid CRYPTO volume and the system asks for a passphrase on bootup. The use of encryption is obvious. Provide a secure system after other people have had physical access: The disk contains a small unencrypted part used for booting. With physical access you can easily modify the boot process to record the passphrase for example. My primary source for this procedure was this blogpost: http://geekyschmidt.com/2011/01/19/configuring-openbsd-softraid-fo-encryption ...

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. ...

Zoals uit eerdere blogposts al is gebleken ben ik de laatste tijd wel eens bezig met T-Mobile en privacy. In mijn laatste blogpost heb ik geschreven dat ik bij T-Mobile op het hoofdkantoor langs ben geweest om te praten over de beveiliging van de webcare helpdesk. Wat ik niet heb geschreven is dat ik daar ook wat anders besproken heb. Ik ben al een lange tijd actief bij Bits of Freedom en bij BoF heb ik meegewerkt aan de Privacy Inzage Machine. PIM is een hulpmiddel die inzichtelijk moet maken wat voor gegevens bedrijven verzamelen over mensen. Het belangrijkste hulpmiddel hierbij is artikel 35 van de Wet bescherming persoonsgegevens. Volgens dit wetsartikel heeft iedereen recht om de persoonsgegevens die een instelling over hem of haar verwerkt in te zien. PIM helpt mensen door automatisch een brief te genereren die gebruikt kan worden om deze inzage te verzoeken. ...

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. ...

It’s been a while since my last post about Plimus. I have contacted Plimus multiple times since and still haven’t got any response from someone with even a basic knowledge of security. They did however visit my blog and that gave me enough information to figure out that their customer support system stores passwords in plaintext. But what I want to write about is worse. Let me start by saying that what I am going to write about is not a bug, not an unpatched piece of software and not a subtle design flaw. It’s a feature. ...