Responsible Disclosure

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. (Update: er komen geen updates meer) ...

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

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

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

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

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

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

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

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