How I could hack internet bank accounts of Danish largest bank in a few minutes

In August I visited the Chaos Communication Camp near Berlin. Once every four years this great and world’s greatest hacker festival is organized. I spoke with a couple of cool Danish hackers there and we talked about internet security and eventually about the security of Danish banks. Seemed like quite a lot of Danish bank have terrible HTTPS connection security (scoring a F on Qualys SSL Labs). That’s a bad sign and my gut feeling was telling me that this wouldn’t be the only security vulnerability they would have.

So I opened up the web site of Danske Bank, one of those bank sites. I clicked thru the site and was curious to see how the HTML code looked like, so opened the code of the customer login screen of the banking environment. I scrolled thru the code to get a grasp of the technology used. Then my eye caught JavaScript comments that seemed to contain internal server information. Not just a few variables, but quite a lot of confidential data actually (!). It was in URL encoded format, so I decoded it right away. Really wondering what kind of secrets it contained.

When I decoded it, I was shocked. Is this happening for real? I was less than a minute on their web site. This is just the HTML code of the login screen, one of the most visited pages of Danske Bank’s web site. I never heard of this bank, but my new friends told me it was the biggest bank in Denmark. Continue reading

Posted in responsible disclosure, website security | 183 Comments

Full disclosure: multiple critical security vulnerabilities (including a backdoor!) in PHP File Manager

In July 2010 I was looking for a web based file manager that I could use on my own web server. After some research I found the PHP File Manager from Revived Wire Media. A basic, but good looking web based file manager for just $ 5. I bought it and installed it on a test server to see how it worked and if it was safe.

After looking at it, I did some shocking findings which I’ll disclose in this article. This commercial off the shelf software product contains several critical security vulnerabilities that can be easily unauthenticated remotely exploited. On top of that, it even includes a poorly secured backdoor, leaving this web based file manager completely open.

I’ve contacted Revived Wire Media three times but got no response of them, so I’m going full disclosure.

At this moment, confidential files can be be easily downloaded from Eneco, Nintendo, Danone, Nestle, Loreal, EON, Siemens, Vattenfall, Oxford, Hilton, T-Mobile, CBS, 3M and also a couple of banks and quite a lot of other companies (lesser known to me).

One company in America that uses the file manager is active in youth care and provides mental health and substance abuse services. It has 250 mental health professionals who are probably sharing all kinds of very confidential patient information via PHP File Manager.

Continue reading

Posted in PHP security, responsible disclosure, security assessment | 36 Comments

M-FILES radioshow: ‘Rest In Privacy’

Deze week was ik te gast in de radioshow van M-FILES wat ging over online privacy. Vanaf 22:12 minuten is mijn bijdrage te horen:

Posted in hacking, podcast, privacy, security awareness | Comments Off on M-FILES radioshow: ‘Rest In Privacy’

Lukt het om in te breken in de website van Massa Media?

Die vraag stelde een TV-ploeg van RTV Utrecht mij:

Posted in hacking, website, website security | Comments Off on Lukt het om in te breken in de website van Massa Media?

Security risk analysis of address bar spoofing bug in Chrome and Opera

On June 30, 2015 security researcher David Leo publicly disclosed a vulnerability in Google Chrome on the full disclosure mailing list. Via this vulnerability it is possible to spoof the location of the address bar in the latest version of Chrome.

The team behind Chrome has been notified by the researcher of this issue via responsible disclosure. Google thought it wasn’t a serious issue and thus they haven’t patched it (yet?). Google classified the bug as a denial of service vulnerability. As a result, the security researcher decided to fully disclose all the details of the vulnerability, including a working exploit, in order to gain attention to the problem.

This week this vulnerability was broadly discussed within the security scene and there were a lot of different opinions and no clear threat analysis was made. I hope to add something to that discussion with my analysis. Continue reading

Posted in browser security, bug, phishing | Comments Off on Security risk analysis of address bar spoofing bug in Chrome and Opera

De wereld van hacking

Gisteren heb ik onderstaande presentatie gehouden op het Privacy & Security symposium van hogeschool Windesheim:

Posted in hacking, presentation | Comments Off on De wereld van hacking

Mitigations against critical universal cross-site scripting vulnerability in fully patched Internet Explorer 10 and 11

This week David Leo disclosed a critical universal cross-site scripting vulnerability in fully patched Microsoft Internet Explorer 10 and 11 (from now on called the UXSS leak). He notified Microsoft on October 13 last year, but Microsoft didn’t publish a patch for the problem, so he decided to go full public disclosure on the Nmap mailing list.

Every web site you visit with Internet Explorer version 10 and 11 can read the contents of cookies from other domain names that the user has stored in their web browser. An attacker can circumvent the same-origin policy via the UXSS leak. This is a primary and very important security measure in all browsers. It prevents web sites from reading each others data. And as of speaking, this protection is now completely broken in Internet Explorer 10 and 11. Continue reading

Posted in browser security, cross site scripting, security vulnerability, website security | 1 Comment

Cross-site scripting in millions of web sites

In August 2014 I found a severe cross-site scripting security vulnerability in the latest version (1.13.0) of the ‘jQuery Validation Plugin‘ during a security penetration test for a customer. This jQuery plugin which adds easy form validation functionality to a web site, is written by a core developer of the highly popular jQuery JavaScript framework.

As of speaking this vulnerability still exists and hasn’t been patched. Continue reading

Posted in cross site scripting, Google, PHP, responsible disclosure | 62 Comments

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 | Comments Off on Wat te doen tegen hard coded databasewachtwoorden in configuratiebestanden?

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 | Comments Off on Test voor vatbaarheid op afstand wissen van alle gegevens op een mobiele telefoon

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 | Comments Off on Security audits as an integral part of PHP application development

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 | Comments Off on Foutief gebruik van de term ‘kwetsbaarheden’

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 | Comments Off on Wat is een veilige aanpak voor downloadscripts?

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 | Comments Off on Noodzaak meldplicht datalekkage bedrijfsleven