2.364 Nederlandse bedrijfswebsites met ernstige beveiligingslekken

Toen ik in oktober 2012 op internet op zoek was naar een nieuwe auto, kwam ik een autobedrijf tegen waar ik een auto wou gaan kopen:

1-v2(bovenstaande website is van een willekeurig bedrijf uit de lijst die ik later beschrijf)

Omdat ik het nogal eng vind om bij een via het internet gevonden bedrijf een auto te gaan kopen, heb ik lichtelijk en oppervlakkig naar de website gekeken van de aanbieder. Kijkend naar aanwijzingen die duiden op oplichting of fraude. Je weet maar nooit. Continue reading

Posted in responsible disclosure, search engine optimization, security vulnerability, website security | 15 Comments

Password hash disclosure in Linksys Smart WiFi routers

This is my tale about reporting a specific security vulnerability in a major product, just to give some insight in how responsible disclosures are handled by a security researcher (me) and various software companies (Cisco, Linksys and Belkin).

On May 17 in 2013 I found a severe password hash disclosure in a Cisco Linksys EA6700 router. At that time this was the top model that Linksys had to offer for consumers. The router is a Linksys Smart WiFi router. Continue reading

Posted in password, responsible disclosure | 5 Comments

Wat te doen tegen hard coded databasewachtwoorden in configuratiebestanden?

Kreeg vandaag de volgende vraag binnen waarvan mijn antwoord ook voor anderen nuttig kan zijn:

Is er een beveiligingsoplossing tegen hard coded databasewachtwoorden, zoals bijvoorbeeld het geval is bij websites die in de programmeercode het MySQL-wachtwoord in een configuratiebestand hebben opgeslagen? Wanneer dit wachtwoord in verkeerde handen valt, dan heeft een kwaadwillend persoon direct de kroonjuwelen van de database in handen. Kan asymmetrische encryptie of kunnen certificaten eventueel uitkomst bieden?

Dit is een goeie vraag. Helaas is er niet echt een oplossing. Het wachtwoord is namelijk de toegangspoort tot MySQL en dus niet uit te bannen. MySQL is hierin niet uniek als platform. Wachtwoorden zijn als authenticatiemiddel een noodzakelijk kwaad om toegang tot allerlei services te krijgen. Algemeen gesproken is er geen heiligmakende oplossing tegen hard coded wachtwoorden. Wel zijn mitigerende maatregelen te nemen. Continue reading

Posted in password, security, website | Leave a comment

Test voor vatbaarheid op afstand wissen van alle gegevens op een mobiele telefoon

Heb een test online gezet waarmee je kan controleren of je mobiele telefoon vatbaar is voor het op afstand wissen van al je gegevens op je telefoon (door het bezoeken van een kwaadaardige website). De test is onschuldig en laat alleen het unieke IMEI-nummer van je telefoon zien.

Als je een Samsung telefoon hebt, dan valt het *sterk* aan te bevelen de test uit te voeren.

Posted in drive-by, security vulnerability, test | Leave a comment

Security audits as an integral part of PHP application development

More often than not, web applications start off as a bright idea, which is then brought into realization at a fast and furious pace, with little eye for anything but result. Once all envisioned functionality is incorporated in the design and the project is launched, developers will be assigned to the next project.

Notwithstanding a few bug fixes, the final – yet essential – step of software development is more often than not, omitted: the security audit. Despite the fact that these checks are regarded as tedious and superfluous, practice shows that it is time well spent: numerous, often severe vulnerabilities come to light.

In the presentation below that I gave at the PHP UK Conference in London, I’ll detail how to incorporate security checks into the software development process. I’ll also step through the implementation, and caveats of a security audit.

The slides that I used:

6959109687_76954c0070_b

Posted in PHP security, presentation, security audit, website | Leave a comment

Foutief gebruik van de term ‘kwetsbaarheden’

Hopelijk draag ik met dit artikel iets bij aan het opbouwen van correcte vocabulair in de Nederlandse tak van informatiebeveiliging. Iets waar ik mij al lang en breed aan stoor is de term ‘kwetsbaarheden’.

Deze veelgebruikte term is echter geen correct Nederlands. Op de één of andere manier gebruikt bijna de gehele Nederlandse beveiligingsbranche deze term, waarschijnlijk door de veel gemaakte verkeerde vertaling van de Engelse term ‘vulnerabilities’. Een Google zoekopdracht op ‘kwetsbaarheden’ leert dat dit woord 103.000 keer voorkomt in Google’s database. Doordat iedereen deze fout maakt, wil dat nog niet zeggen dat het een correcte term is (geworden).

Kwetsbaar is een bijvoegelijk naamwoord. Kwetsbaarheid is echter een zelfstandig naamwoord, door de -heid toevoeging en heeft geen meervoud. De taalkundige term voor dit soort woorden is overigens singulare tantum (altijd enkelvoud), en in dit geval drukt dit woord een toestand uit. Zelfredzaamheid is een vergelijkbaar woord – het zelfredzaam zijn, en daarvan is evident dat een meervoud ridicuul is: zelfredzaamheden.

‘Vulnerabilities’ is het beste te vertalen met ‘zwakke plekken’ of ‘kwetsbare punten’.

Posted in jargon, security | Leave a comment

NU.nl gehackt: Malware-analyse

NU.nl is gehackt, zo schrijft hun weblog vandaag, waarbij mogelijk 100.000 computers zijn besmet met kwaadaardige code. Ik was benieuwd naar wat voor kwaadaardige code werd geïnjecteerd en heb deze dan ook geanalyseerd. Continue reading

Posted in analysis, drive-by, security vulnerability, website | 66 Comments

Telegraaf breekt Apple embargo op iPad 3

Op de website van Apple wordt nog helemaal niet over de iPad 3 gesproken. Wie ook zoekt in de Apple website op de zinsnede ‘iPad 3’ vindt maar 2 resultaten – wat overigens false positives zijn, terwijl de zoekopdracht ‘iPad 2’ goed is voor 494 resultaten.

Van Apple is bekend dat zij nooit publiceren over een product in ontwikkeling en ze een strategie hanteren om uit het niets een product te lanceren. Dat is slimme marketing, maar werkt alleen bij totale geheimhouding. Continue reading

Posted in Apple, legal | 1 Comment

Beveiligingslekken bij SNS Bank in procedure creditcard opheffen

Heb zojuist mijn SNS Creditcard opgezegd, want ik gebruikte deze niet – en dan is het maar veiliger en goedkoper om de kaart op te heffen. Echter, schrik ik wel van de manier hoe de SNS Bank deze procedure ingeregeld heeft:

“Als u de SNS Creditcard per direct opheft, vragen we u uit veiligheidsoverwegingen het volgende te doen: Knip de creditcard door en plak hem op dit formulier.” Continue reading

Posted in credit card, security vulnerability, SNS Bank | 3 Comments

ICT-ers zijn heer en meester in gebruik van jargon

In mijn werk in de ICT (ja, daar heb je de eerste al …) kom ik een ongelofelijke hoeveelheid afkortingen tegen, meer dan in andere branches. Bij sommige projecten hou ik zelfs noodgedwongen referentielijsten bij waarin ik afkortingen en de betekenissen hiervan zet, teneinde de communicatiestroom te kunnen ontsleutelen. Deze lijst loopt in sommige projecten op tot over de 100 uniek gebruikte afkortingen.

De meest sprekende anecdote vind ik wel van dat een niet nader te noemen en zelfverklaarde beveiligingsexpert in begin 2000 volmondig verklaarde dat een MAC adres een netwerkadres is van een Mac (zo’n computer van Apple). Nou, dan heb je toch echt de plank volledig misgeslagen. Continue reading

Posted in ICT, jargon | 1 Comment

Wat is een veilige aanpak voor downloadscripts?

Via een forum post op PFZ.nl kwam ik de onderstaande vraag tegen. Uit de beveiligingsscans die ik op websites uitvoer, zie ik vaak de onderstaande aanpak terug komen. Daarom leek het mij nuttig om deze casus ook via de weblog weer te geven.

“Ik heb op mijn klantenwebsite een plaats waar men eigen facturen kan opslaan. Nu wil ik het graag zo beveiligen dat men niet de facturen van andere klanten kan downloaden. De manier waarop ik het wil opslaan is als hieronder staat weergegeven, via twee variabelen. Is dit veilig?

/klantenmappen/{$klantnummer}/facturen/{$factuurnummer}.pdf

Ik zou bestanden met vertrouwelijke inhoud nooit opslaan met een te raden bestandsnaam en ik zou ook nooit rechtstreeks naar een vertrouwelijk bestand linken. Een kwaadwillend persoon kan op oplopende nummers zoeken en zo documenten terug vinden. Dit kan worden verwezenlijkt via een script dat dit automatiseert en duizenden GET aanvragen op de webserver afvuurt.

Wat is wel veilig? Continue reading

Posted in website security | Leave a comment

Noodzaak meldplicht datalekkage bedrijfsleven

Vandaag las ik het nieuwsbericht dat Neelie Kroes zich op dit moment bezig houdt met een meldplicht voor datalekkage in het bedrijfsleven. Iets wat ik al jaren roep, wordt eindelijk behandeld in de politiek. Je zal je misschien afvragen: “Waarom is een meldplicht hiervoor een goed idee?”.

Vanuit mijn IT beveiligingsbedrijf help ik bedrijven om beveiligingslekken te vinden en te verhelpen in IT infrastructuur. Vaak is de aanleiding voor bedrijven om een beveiligingsscan uit te laten voeren alleen gedreven uit de noodzaak voor het behalen van een certificaat of door een wettelijke verplichting, zoals bijvoorbeeld in de gezondheidszorg het geval is. Wanneer een scan wordt uitgevoerd, komen daaruit bijna altijd vrij ernstige, nog tot dusver onbekende beveiligingsrisico’s naar voren.

Door een datalekkage meldplicht te verplichten, dwing je bedrijven om proactief te investeren in beveiliging. Dat bedrijven dit niet doen blijkt wel uit mijn ervaring, maar nog vele malen belangrijker, door de recente grootschalige hackincidenten die met grote gemak door hackersbewegingen LulzSec en Anonymous zijn uitgevoerd. Bedrijven zijn als de dood dat door een hack het imago en het vertrouwen in het bedrijf afneemt. Wanneer nu een bedrijf gehackt wordt, wordt dit intern snel afgehandeld en gehoopt dat de buitenwereld hier nooit over te horen zal krijgen. In bijna alle gevallen wordt er geen aangifte gedaan, want daarmee geef je als bedrijf aan dat je je eigen beveiliging niet op orde hebt.

De oplossing is vrij simpel: Openheid van zaken dwingt een betere beveiliging af. Verplicht bedrijven om hackincidenten te rapporteren. Daarmee voorkom je voor een deel dat incidenten zullen plaatsvinden, omdat de gevolgen daarvan vergroot worden door de meldplicht.

Posted in data leakage, security audit | Leave a comment

Hoe Knuz.nl het lekken van gegevens over 280.000 leden had kunnen voorkomen

Zojuist las ik een bericht op www.security.nl dat de datingsite www.knuz.nl persoonlijke gegevens lekt van 280.000 leden:

“Door een fout in de inlogprocedure waren de privégegevens van 280.000 leden van de gratis datingsite Knuz.nl voor enige tijd voor onbevoegden toegankelijk, zo heeft Security.nl na een tip ontdekt. Een bezoeker van de website die via zijn KPN Mobiel verbinding de pagina benaderde, kreeg het onderstaande adminscherm te zien. Hier zijn de e-mailadressen, IP-adressen, ongehashte wachtwoorden, nicknaam en profielgegevens van 280.000 ingeschreven leden te vinden.”

Dit is een interessante casus, aangezien door Knuz.nl een aantal fouten gemaakt worden, die – opgestapeld – vergaande gevolgen hebben. Dit incident had nooit mogen gebeuren, had eenvoudig kunnen worden voorkomen van schade had kunnen worden beperkt als een aantal beveiligingsprincipes waren toegepast. Continue reading

Posted in website security | 3 Comments

Workshop at Smart Grid Cyber Security & Privacy congress: The key to security

I’ve been invited to give a workshop at the European Smart Grid Cyber Security and Privacy congress this November about:

The key to securitySwitching to a proactive mindset towards security
Many companies strive towards an open, accessible, culture – which, unfortunately, seems to apply to their level of security as well. In this workshop, Secundity’s Sijmen Ruwhof demonstrates how to improve security. Most companies seem oblivious to the fact that they may expose vital information, with due consequences. However, it is shown from experience, that switching to an proactive mindset towards security, will save time, resources, and most importantly, money. Continue reading

Posted in security awareness, workshop | Leave a comment

Slecht wachtwoord advies

Bij Rabo Interhelp weten ze precies hoe je een veilig wachtwoord aanmaakt:

“U kunt een cijfercode van 3 cijfers en een persoonlijke code aanmaken. Deze persoonlijke code is een voor u altijd herkenbaar gegeven, zoals bijvoorbeeld uw trouwdag, een geslaagde vakantiebestemming of de naam van uw hond. Als u het maar onthoudt. In de toelichting kunt u de persoonlijke code omschrijven. Bijvoorbeeld: bij persoonlijke code vult u in: ‘Bello’, in de toelichting: ‘naam van de hond’.”

Even voor de duidelijkheid, zo hoort het dus niet. NB: Deze tekst krijg je alleen te zien als je bent ingelogd.

Posted in password | Leave a comment

Gastcollege op Hogeschool Windesheim: Informatiebeveiliging

Aanstaande woensdag (18 mei) zal ik op Hogeschool Windesheim in Almere een gastcollege geven over informatiebeveiliging aan de 4e jaars studenten van Information Engineering. Wil je hier ook bij zijn? Laat het me weten, dan zorg ik dat het geregeld wordt.

Posted in presentation | Leave a comment

Presentation: Next in security

Slides from a presentation that I gave about the developments in the hacking world:

Posted in presentation, security | Leave a comment

Bedrijfspresentatie op seminar Next in ICT: IT beveiliging

Volgende week woensdag zal ik namens Secundity een bedrijfspresentatie geven over de toekomst van IT beveiliging tijdens de seminar Next in ICT:

“On May 11th, 2011 we present our second Next in ICT international seminar. Speakers from universities, industry and commerce will address issues concerning Applied research and innovation.”

Posted in presentation | Leave a comment

Bespioneer anderen via Google

Vandaag kwam ik op google.com een support pagina tegen over Google Web History. Google wil ‘de gebruikerservaring’ verbeteren *kuch* meer omzet halen uit advertenties *kuch* door ook je zoekopdrachten op te slaan als je bent uitgelogd uit je Google Account. Je zou verwachten dat als je jezelf uitlogt, dat je dan weer anoniem voor Google wordt – niets is echter minder waar:

“Note: If you sign out of your Google Account, your browser will continue to store your search history. We will also continue to save your previous searches with Personalized Search. Learn how to turn off Personalized Search.”

Zoekopdrachten van anderen inzien
Het eerste waar ik aan dacht is dat je met deze mogelijkheid bij andere mensen kunt meekijken welke zoektermen ze in Google invullen. Dit kan je doen door bij iemand anders op zijn computer in te loggen met je Google Account en daarna vervolgens weer uit te loggen. Zoektermen die nadien op diezelfde computer worden ingevuld, kan je later weer in je Google Web History terug zien. Continue reading

Posted in Google, privacy | Leave a comment

Veiligheidsanalyse iDEAL Lite bijgewerkt

Naar aanleiding van het overleg met Rabobank Nederland is het rapport over de iDEAL Lite voorbeeldcode bijgewerkt met nieuwe informatie.

Posted in responsible disclosure, security assessment | Leave a comment