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.

Content Management Systeem staat open?
Wat mij al vrij snel opviel, is dat individuele webpagina’s in de map ‘/cms/’ werden opgeslagen:

2-v2

CMS staat voor Content Management Systeem – software waar teksten en afbeeldingen in een website mee beheerd kunnen worden. Het is vrij ongebruiktelijk voor websites om bestanden te tonen die in de map ‘/cms/’ staan, aangezien dit meestal de beheerinterface van de website is, en dus niet voor bezoekers bedoeld.

Benieuwd naar wat voor inhoud in deze map staat, heb ik de bestandsnaam uit het internetadres gehaald. Onverwachts zie ik een zoekformulier staan (nadat ‘/cms/’ automatisch doorverwijst naar ‘/cms/lijst.aspx’):

3-v2

Nieuwsgierig naar de uitkomst van het zoekformulier klik ik zonder iets in te vullen op de knop ‘Zoek nu’. Tot mijn grote verbazing zie ik een bijna eindeloze lijst met 2.364 bedrijfsnamen staan:

4-v2

Daar schik ik van. Meteen komt bij mij de gedachte op dat ik een meester oplichter ben tegen gekomen, die een wijd verbreid imperium van allerlei malafide bedrijfjes zou hebben opgezet. Snel klik ik op drie linkjes van één van deze bedrijven. Tot mijn verbazing zie ik compleet andere websites verschijnen onder dezelfde domeinnaam als dat van het bedrijf waar ik een auto van wou kopen:

5-v2

De websitesoftware bepaalt welke website wordt getoond op basis van een nummer in de adresbalk:

6-v2

Screenshot van de derde website:

7-v2

Ik kan u vertellen dat deze gewaarwording niet bevorderlijk is voor het vertrouwen in het bedrijf waar ik toch wel een grote aanschaf wil gaan doen. Gelukkig weet ik als websitebeveiliger beter en vermoed ik dat ik te maken heb met een massa websitebouwer die waarschijnlijk totaal niet bekend is met het onderwerp websitebeveiliging.

Zoekmachine optimalisatie: duplicate content penalties
Nog maar niet te spreken over het onderwerp zoekmachineoptimalisatie. Deze constructie van andere websites kunnen tonen onder andermans domeinnamen kan desastreus zijn voor een hoge positie in zoekmachines, wegens redundante inhoud op duizenden domeinnamen. Zoekmachines zijn allergisch voor dergelijke constructies van websites en kunnen daardoor behoorlijke straffen uitdelen. Enfin.

Databasebeveiliging op orde?
In het zoekformulier vul ik vervolgens een enkele quote in en druk wederom op de knop ‘Zoek nu’:

8-v2

Direct wordt een technische ASP.NET-foutmelding getoond, inclusief stacktrace. Deze melding is indicatief voor SQL-injectie – een ernstig databasebeveiligingslek.

9-v2

De foutmelding wijst niet direct op een SQL-injectielek, dus voer ik ter validatie het volgende onschuldige commando in: ‘ or ‘1’=’1. Zoals ik eigenlijk al verwacht had, wordt de complete lijst met bedrijfsnamen weer getoond:

10-v2

Het is mij nu vrij duidelijk dat een SQL-injectielek aanwezig is.

Het verbaasd me: mijn eerste paar pogingen zijn al direct raak. Mijn ervaring zegt me dat al deze 2.364 websites zo lek zijn als een mandje. Ter controle verander ik van een andere webpagina het internetadres, en voeg ik wederom een enkele quote toe bij een nummer:

11-v2

Nogmaals wordt een technische foutmelding weergegeven. Deze keer zie ik direct aan de foutmelding dat hoogst waarschijnlijk nog een SQL-injectielek aanwezig is.

Bij een andere pagina is het toevoegen van een enkele quote ook al raak: daar wordt wederom een technische foutmelding getoond:

12-v2

Ik weet wel genoeg zo. In een paar minuten tijd heb ik via enkele speldenprikken en zonder inzet van gespecialiseerde professionele websitebeveiligingstools die ik in mijn dagelijkse werkzaamheden gebruik, zeer ernstige beveiligingslekken gevonden in het websiteframework dat op het eerste gezicht op 2.364 websites gebruikt wordt. De lekken die ik op eenvoudige wijze gevonden heb zijn hoogst waarschijnlijk nog maar het topje van de ijsberg, daar ik er amper moeite in gestoken heb om ze te vinden. En eigenlijk niet eens bewust ook.

Impact van het lek: complete database uitlezen
Als verantwoord beveiligingsonderzoeker ben ik niet verder gedaan. Een kwaadwillend persoon zou eenvoudig de database gekopieerd kunnen hebben via software zoals SQLmap. Tevens kan de database aangepast worden, waardoor eventueel fraudescenario’s ontstaan.

Volgens de website van de leverancier van het framework zit onder andere de volgende functionaliteit in het systeem:

Untitled-1

Behalve de bedrijfsadministratie als inkoop en verkoop, bevat dit systeem waar duizenden bedrijven op draaien, ook grote hoeveelheden klantgegevens die nodig zijn om offertes en facturen op te stellen.

Zo maar wat fraudescenario’s
Kan mij voorstellen dat criminelen graag willen weten wie de eigenaar is van bepaalde dure auto’s en waar deze auto’s staan. Erg handige informatie als je auto’s wilt stelen of rijke mensen wilt opzoeken om bij in te breken of af te persen. Je kan ook alle autobezitters een op naam gestelde acceptgiro sturen waarin een parkeer- of snelheidsboete mee betaald moet worden. Zullen toch altijd nog aardig wat mensen intrappen.

Responsible disclosure op 3 oktober 2012
Snel neem ik contact op met het bedrijf dat dit massa websiteframework gebouwd heeft, want ik denk dat ze wel graag zouden willen weten dat hun software behoorlijk lek is. Op 3 oktober 2012 bel ik hier naar toe (met een niet afgeschermd telefoonnummer). Ik krijg een medewerker aan de lijn.

Heb mezelf netjes aan deze medewerker voorgesteld en hem voorzichtig globaal gemeld zonder enige details te geven – dat de beveiliging van de websites die zijn bedrijf voor haar klanten ontwikkelt, totaal niet op orde is. Ik meld hem dat ik graag hierover nader met één van de websitebouwers zou willen praten om de problemen verder toe te lichten. Vol goede hoop zette hij mij in de wacht. Na 10 seconden kreeg ik hem wederom aan de lijn en toen melde hij mij resoluut:

“Bedankt voor je melding. Onze bouwers gaan ermee aan de slag.”

Direct daarna verbrak hij de telefoonverbinding zonder mijn reactie af te wachten. Ik was met stomheid geslagen. Heb al vele malen ongevraagd per toeval gevonden beveiligingslekken gemeld aan bedrijven, maar dit had ik nog nooit meegemaakt. Kreeg geen kans om ook maar iets te zeggen, laat staan te vertellen waar precies de beveiligingslekken zaten.

Door dit soort reacties ben ik steeds meer geneigd om terloops gevonden beveiligingslekken niet meer te melden.

Status zomer 2013: niks opgelost
Na dit telefoongesprek heb ik de zaak laten rusten. Tot de zomer van 2013 toen ik met een collega pentester sprak over het feit dat beveiligingslekken vaak niet worden opgelost, ondanks het feit dat een onafhankelijk persoon belangenloos het uit eigen initiatief meldt aan een bedrijf. Toen we hierover spraken herinnerde ik mij weer deze casus. Was toch wel benieuwd of het bedrijf inmiddels de problemen had opgelost. Niets bleek minder waar. Er was niets aan de situatie veranderd: het websiteframework was nog steeds zo lek als oorspronkelijk geconstateerd.

Poging 2: Brenno de Winter inschakelen
Toen besloot ik maar contact op te nemen met journalist Brenno de Winter; de specialist als het gaat om bedrijven zo ver te krijgen om – eventueel via de media – hun beveiliging wel op orde te krijgen.

Status herfst 2014: eindelijk opgelost
Dat heeft geholpen, want ik zie zojuist dat de door mij gevonden lekken inmiddels zijn gedicht. Hopelijk hebben ze een volledige beveiligingstest laten uitvoeren door een gespecialiseerd bedrijf en hun klanten geïnformeerd over dit lek. De persoonsgegevens die in de websites opgeslagen zitten zijn in gevaar gebracht en mogelijk zelfs ingezien door een hacker die wel kwaadwillend was.

Wet Bescherming Persoonsgegevens
Al deze duizenden bedrijven en zeker het bedrijf wat dit systeem ontwikkeld heeft voldoen niet aan de Wet Bescherming Persoonsgegevens. Artikel 13 van deze wet stelt namelijk:

[..] De verantwoordelijke legt passende technische en organisatorische maatregelen ten uitvoer om persoonsgegevens te beveiligen tegen verlies of tegen enige vorm van onrechtmatige verwerking. Deze maatregelen garanderen, rekening houdend met de stand van de techniek en de kosten van de tenuitvoerlegging, een passend beveiligingsniveau gelet op de risico’s die de verwerking en de aard van te beschermen gegevens met zich meebrengen. [..]

Dat de software van de leverancier een beveiligingslek heeft is tot daar aan toe. Maar door het niet reageren op een responsible disclosure voldoe je mijn inziens dus ook niet aan het nemen van passende organisatorische maatregelen.

Artikel 14 vrijwaart de duizenden bedrijven ook niet voor de nalatigheid van hun softwarelevernacier (hieronder te lezen als “een bewerker”):

[..] Indien de verantwoordelijke persoonsgegevens te zijnen behoeve laat verwerken door een bewerker, draagt hij zorg dat deze voldoende waarborgen biedt ten aanzien van de technische en organisatorische beveiligingsmaatregelen met betrekking tot de te verrichten verwerkingen. De verantwoordelijke ziet toe op de naleving van die maatregelen. [..]

Het College Bescherming Persoonsgegevens – wat de toezichthoudende autoriteit van deze wet is – kan bestuursdwang toepassen of een bestuurlijke boete opleggen bij al deze bedrijven. Ze hebben geluk dat dit college niet op de hoogte is van de beveiligingsproblemen.

Overigens ligt er op dit moment een wetsvoorstel voor een datalekmeldplicht voor bedrijven die wordt behandeld. De ministerraad is al akkoord.

Nietszeggende beveiligingsstatements
Het is overigens opvallend, en dat kom ik heel vaak tegen, dat bedrijven op hun website melden dat de beveiliging op orde is en dus dat de bezoekers zich op dat gebied nergens zorgen over hoeven te maken. Zo staat in het privacybeleid op de website van de aanbieder van dit websiteframework vermeld:

[..] Wij hebben de nodige veiligheidsmaatregelen ingevoerd om het verlies, het onrechtmatig gebruik of de wijziging te voorkomen van informatie die wij ontvangen op onze site. [..]

Dit soort statements zonder in te gaan op details zijn niets betekenend. Sinds eind jaren negentig dat ik mij al met hacking bezig hou, kom ik dergelijke statements continu tegen. Ook bij bedrijven waar ik in mijn werk beveiligingstesten bij uitvoer. Constateer dan ook dat er bijna nooit onderbouwing voor dergelijke statements is. Dit soort statements zijn daarom ook in de meeste gevallen een vorm van security theater.

Tot slot
Ben blij dat de door mij gevonden lekken inmiddels gedicht zijn, en hoop dat de betreffende softwareleverancier de beveiliging van hun software nu wel serieus neemt. Met dit verhaal hoop ik andere bedrijven meer bewust te maken dat IT-beveiliging niet vanzelfsprekend is en dat heel veel bedrijven over dit onderwerp nog een hoop te leren hebben. Hoop ook dat responsible disclosures serieuzer genomen gaan worden. We hebben als samenleving nog een lange weg te gaan op dit gebied.

Referenties naar dit onderzoek:

  1. Security.nl: “Lek in duizenden Nederlandse bedrijfssites na 2 jaar gedicht”
  2. ICTrecht.nl: Column van Brenno de Winter (PDF, pagina 10 en 11)

About Sijmen Ruwhof

Freelance IT Security Consultant / Ethical Hacker
This entry was posted in responsible disclosure, search engine optimization, security vulnerability, website security. Bookmark the permalink.

15 Responses to 2.364 Nederlandse bedrijfswebsites met ernstige beveiligingslekken

  1. Joko says:

    Goed en informatief artikel. Leerzaam ook. Dank je!

  2. Security.nl says:

    Nieuwswebsite security.nl:

      “Lek in duizenden Nederlandse bedrijfssites na 2 jaar gedicht”
      zondag 9 november 2014, 15:17 door Redactie, 8 reacties

      Een ernstig beveiligingslek in het contentmanagementsysteem (CMS) dat duizenden bedrijven voor hun website gebruiken is na twee jaar eindelijk gedicht, zo claimt de beveiligingsonderzoeker die het probleem ontdekte. Onderzoeker Sijmen Ruwhof wilde in oktober 2012 een nieuwe auto kopen.

      Hij keek daarbij ook naar de website om te controleren of het geen malafide aanbieder was. De website van de autodealer bleek individuele webpagina’s in de map ‘/cms/’ op te slaan. In deze map stond een lijst met ruim 2300 bedrijfsnamen van allemaal bedrijven die voor hun website hetzelfde CMS gebruiken. Verder onderzoek van Ruwhof wees uit dat het CMS kwetsbaar was voor SQL Injection, waardoor een aanvaller direct met de database van de websites kon communiceren en bijvoorbeeld gevoelige gegevens zou kunnen stelen.

      Melding
      Op 3 oktober 2012 belde Ruwhof de ontwikkelaar van het CMS en kreeg een medewerker aan de lijn die hem bedankte voor het melden van het lek, hoewel de onderzoeker nog geen details had kunnen delen. Direct nadat de medewerker hem had bedankt werd echter de verbinding verbroken. “Ik was met stomheid geslagen. Heb al vele malen ongevraagd per toeval gevonden beveiligingslekken gemeld aan bedrijven, maar dit had ik nog nooit meegemaakt. Kreeg geen kans om ook maar iets te zeggen, laat staan te vertellen waar precies de beveiligingslekken zaten”, aldus Ruwhof.

      In de zomer van 2013 wilde de onderzoeker kijken of het lek was verholpen, maar dat bleek nog steeds aanwezig te zijn. Uiteindelijk benaderde Ruwhof IT-journalist Brenno de Winter om te kijken of het probleem zo verholpen kon worden. Nu twee jaar later zijn de gevonden kwetsbaarheden eindelijk gepatcht. Hoewel Ruwhof verbolgen is over de reactie van de leverancier is hij blij dat het probleem is opgelost. “Ik hoop dat de betreffende softwareleverancier de beveiliging van hun software nu wel serieus neemt”, besluit hij.

  3. Bram says:

    Ik kan er zo 376 vinden op google;
    https://www.google.nl/#q= [verwijderd door moderator]

  4. Michael van Griensven (via LinkedIn) says:

    Leuk om te lezen!

  5. Peter Hazenberg (via Facebook) says:

    *ahum*, 2364 in een? Als het een nederlandse websitebouwer is, dan moet het nog en best grote geweest zijn ook. Behoorlijk pijnlijk… Nouja, het bevestigt mijn opmerking “De meeste ICT-systemen hangen van ellende aan elkaar (ongeacht of je nu kijkt bij overheid of bedrijfsleven)”. Helaas.

    • Vind het ook behoorlijk indrukwekkend dat zoveel websites op één systeem draaien. Dat bedrijf heeft behoorlijk aan de weg getimmerd. Zo zie je maar weer dat het niet iets technisch hoogstaands hoeft te zijn om in de ICT succesvol te zijn.

  6. Jos Heijmans (via LinkedIn) says:

    Interessant! Ik zag inderdaad je naam voorbij komen op security.nl.

Leave a Reply

Your email address will not be published.