We plaatsen een cookie voor Google Analytics om onze website te verbeteren

Met een cookie kun je advertenties personaliseren. Wij hanteren echter de strikte regels van de Autoriteit Persoonsgegevens. Surfgedrag houden we niet bij en we achtervolgen je ook niet met reclame.

Lek in WP Super Cache, opgelost!

Het was weer raak, onlangs heeft Sucuri een lek gevonden in de zeer populaire WordPress-plugin WP Super Cache. Eerder schreven Tweakers en ISPam er al over dat mogelijk miljoenen WordPress-installaties kwetsbaar zouden zijn. Zelfs de FBI waarschuwde voor het lek, omdat hackers van IS de kwetsbaarheden actief zouden misbruiken voor hun (criminele) doeleinden.

Lek in WP Super Cache: beveiligingslek in je website

Volop commotie dus, maar wat moet je ermee? Als je zelf een WordPress-website hebt en je hebt WP Super Cache geïnstalleerd, dan kun je inderdaad ook kwetsbaar zijn. Maar wat betekent dat precies, heeft dat gevolgen en wat kun je eraan doen? Als eindgebruiker wil je natuurlijk weten of je slachtoffer bent geworden en hoe je zo snel mogelijk je website veilig kunt stellen voor dit lek. Om wat meer inzicht te geven en deze vragen te beantwoorden, ga ik in dit artikel uitleggen, hoe we het bij Antagonist aanpakken.

Allereerst, geen paniek!

Bij Antagonist wordt je website constant gecontroleerd op beveiligingslekken. Mochten we er eentje vinden, dan dichten we dat automatisch. Uiteraard krijg je daarvan bericht. Deze service is gratis en bieden we aan al onze klanten. Misbruik moeten we zoveel mogelijk proberen te voorkomen en daar dragen we graag ons steentje aan bij! We gebruiken hiervoor de software van onze partner Patchman.

Lek in WP Super Cache: geen paniek!

Het is natuurlijk slecht nieuws dat er een dergelijk groot lek in WP Super Cache is gevonden en dat kwaadwillenden dit misbruiken. Het goede nieuws is echter dat Patchman dit dus voor je oplost! Zo kunnen we proactief al onze klanten beschermen tegen de gevolgen van het lek. Het wordt immers gedicht, alvorens hackers de kans krijgen er iets mee te doen.

Pleister op de wonden

Het is belangrijk om te weten dat het dichten van het lek geen gevolgen heeft voor de werking van je website. Patchman pakt enkel het lek zelf aan. Zodoende wordt het stukje kwetsbare code opgezocht en uitgeschakeld, waardoor het lek niet meer misbruikt kan worden. Je website kan hier geen hinder van ondervinden en blijft op dezelfde wijze functioneren als voorheen.

Er wordt dus geen update uitgevoerd, want dat zou de werking van je website wél kunnen beïnvloeden. Ook worden er geen wijzigingen in jouw code of content gedaan. Er wordt dus als het ware alleen een pleister (patch) op de zere plek (kwetsbare code) geplakt, zodat je er geen last meer van hebt. Het is overigens ook mogelijk om zelf de resultaten van het patchen terug te vinden. Een technische uitleg hierover vind je verderop in dit artikel.

Alles komt goed

Dus nogmaals, geen paniek! Mocht het onverhoopt toch misgaan, dan zijn er gelukkig nog andere manieren om je website te herstellen. We kunnen je daarbij tevens ondersteuning bieden. Een handig artikel over wat je kunt doen tegen malware en misbruik, heeft mijn collega Wouter eerder geschreven.

Lek in WP Super Cache: Sitedokter, de nieuwe dienst van Antagonist

Om uit te leggen hoe wij, dankzij Patchman, zorgen dat onze klanten beschermd zijn, is het belangrijk om eerst de ontwikkelprocessen te snappen. Voor de technisch onderlegden onder ons, zal dit wel bekend zijn. Zodoende kunnen zij het volgende deel overslaan en verder lezen vanaf ‘Het lek patchen’.

Een lek in WP Super Cache?

Je hoort wel vaker dat ergens een lek in zit, maar wat zijn die lekken nou precies? Dit is een complex en uitgebreid onderwerp, maar het grootste deel van de lekken komt door onvoldoende validatie op invoer. Aangezien veel klanten met PHP werken, zal ik hieronder een voorbeeldje geven.

<?php
$username = $_POST['username'];
$password = hash("sha256", $_POST['password']);
$query = "SELECT * FROM users WHERE username='{$username}' AND password='{$password}'";
// Verdere code

Het is hier goed te zien dat er geen validatie plaatsvindt op de username die rechtstreeks in de query terecht komt. Dat betekent dat als iemand als gebruikersnaam Robert' OR '1' = '1 invult, de aanvaller kan inloggen als Robert zonder een wachtwoord in te voeren. Dit type aanval heet ook wel een SQL-injection.

Lek in WP Super Cache: XKCD

Een vergelijkbare aanval is XSS (Cross Site Scripting). Daarbij kan de aanvaller zelf content in de pagina zetten en wordt dit bij een nietsvermoedende bezoeker uitgevoerd. Het lek in WP Super Cache valt ook in deze categorie, zoals Sucuri ook uitlegt. De oplossing is dan ook zorgen dat er geen kwaadaardige code in de invoer zit.

Jij bent vaak niet het doelwit

Verder is het goed om te weten dat veel aanvallers het niet specifiek op jou of op je website hebben gemunt. Kwaadwillenden zoeken simpelweg naar kwetsbare plekken die ze kunnen gebruiken. Als je site een lek bevat, dan kan deze worden geïnfecteerd. Je site wordt dan een plek, waarvandaan aanvallen op andere doelwitten worden uitgevoerd.

Je kunt het zien als België in de Eerste Wereldoorlog. Ook zij waren geen doel op zich, maar lagen op de route naar Frankrijk. Voor Duitsland en Frankrijk was het daarom handig om hun grondgebied te gebruiken voor oorlogvoering.

Hackers kunnen mogelijke doelwitten vinden doormiddel van bijvoorbeeld het zoeken op slimme termen in Google. Vanuit de resultaten proberen ze vervolgens gewoon of er een lek is dat misbruikt kan worden. Uiteraard gaat dit geheel automatisch. Daarom is het ook belangrijk dat jij of je webhoster de beveiliging automatiseert.

In den beginne…

Tijd voor een stukje uitleg over development.

Bij het beschrijven, hoe een softwareproject ongeveer werkt, ga ik uit van een enkel project en zullen concepten als afhankelijkheden buiten beschouwing worden gelaten. In de basis is een project niets meer dan een verzameling van bestanden die gewoon op je harde schijf staan. Zodra je het wil delen, dan kun je bijvoorbeeld alles e-mailen, op een gedeelde netwerkmap zetten of recenter iets als Dropbox gebruiken. Al in de jaren ’70 kwam men erachter dat dit niet zo handig was, dus kwamen er versiebeheersystemen.

Hoewel er verschillende manieren zijn om een versiebeheersysteem te ontwerpen (bijvoorbeeld centraal of decentraal, enkel bestand of meerdere), doen ze in de basis allemaal hetzelfde: een historisch overzicht geven van één of meer bestanden. Een wijziging wordt vaak een revisie, commit of patch genoemd.

Lek in WP Super Cache: code quality

Bij de meeste systemen moet je expliciet een revisie maken, maar systemen zoals Google Docs doen dit automatisch voor je. Voordeel van expliciet, is dat je heel goed kunt bepalen wat er wel en wat juist niet in de revisie zit. Later zullen we zien waarom dit belangrijk is en dus juist een enorme meerwaarde biedt. In situaties waar dat niet van belang is, volstaan automatische revisies. Simpelweg omdat het makkelijk is en je het dan niet zult vergeten.

Dat je in een versiebeheersysteem geen broncode hoeft te stoppen, bewijst france.code-civil, een project dat de Franse wetten opslaat. Veel wetten zijn eigenlijk aanpassingen op bestaande wetten en dat zie je.

Release the Kraken!

Een release is vaak niet veel meer dan een specifieke revisie pakken en die een nummertje geven. Hoe je dat nummertje bepaalt, mag je zelf weten, maar er zijn standaarden. Vaak speelt backwards compatibility of achterwaardse compatibiliteit een grote rol, maar anderen zijn gebaseerd op tijd. Een backwards compatible change is niets meer dan dat je niets verandert aan de bestaande functionaliteit. Een voorbeeld hiervan is een extra knop in een menu toevoegen. De betekenis van een knop in een menu veranderen is een backwards incompatible change.

Semantic Versioning is een standaard die veel wordt gevolgd. Hier wordt alles in het MAJOR.MINOR.PATCH-formaat geschreven. Je verhoogt MAJOR als je backwards incompatible changes maakt. MINOR wordt gebruikt bij nieuwe functionaliteit die backwards compatible is. PATCH wordt enkel verhoogd bij backwards compatible bug fixes. Zo hoor je een zonder probleem te kunnen updaten van 1.4.0 naar 1.4.4, maar van 1.4.0 naar 2.0.0 kan vervelender zijn.

Voorbeelden van tijdgebaseerde versies zijn Ubuntu die JAAR.MAAND pakt (bijvoorbeeld 15.04 voor april 2015) of tzdata die JaarLetter pakt (bijvoorbeeld 2015b voor de 2e release in 2015). Voor het overzicht laat ik het beheren van meerdere versies tegelijk in een versiebeheersysteem buiten beschouwing laten, maar dit wordt typisch met branches en tags gedaan.

Het lek in WP Super Cache patchen

Hier zal ik beginnen vanuit een generiek oogpunt en daarna kijken hoe Patchman dit voor je kan doen. Om een lek te patchen, zullen we diverse stappen moeten uitvoeren. Zo moet je eerst weten of je überhaupt vatbaar bent voor een lek. Traditioneel gezien weet een applicatiebeheerder precies wat er draait. Hij krijgt van de leverancier door, wanneer er lekken bekend zijn en wat er aan gedaan moet worden. Vaak is dat een patch installeren.

Helaas is het in de praktijk niet zo mooi. Zo draaien veel mensen en bedrijven op verouderde software die door de leverancier niet meer wordt ondersteund. Denk aan Amsterdam die extra betaalt om Windows XP te blijven gebruiken. Ook is soms het advies om te updaten naar de nieuwste versie, terwijl dat niet kan doordat er ergens een incompatibiliteit zit. Ook kan het zijn dat er een lang migratietraject is, waarbij je medewerkers nog moet trainen. In de tussentijd wil je echter niet vatbaar zijn.

Met open source software kun je het vaak zelf oplossen. Met het eerder genoemde lek gaan we kijken hoe we dat zouden kunnen doen. Let op dat dit een voorbeeld is en je over het algemeen gewoon wilt updaten naar de laatste versie!

Lek in WP Super Cache: plugin

We beginnen bij het versiebeheersysteem van WP Super Cache. Als we daar in de geschiedenis gaan zoeken, vinden we commit 3e6b128. Deze twee regels lossen het veiligheidslek op door inhoud te ‘escapen’. Nu is het een kwestie van het juiste bestand vinden en te zorgen dat daar de regels toegevoegd worden.

Eerder beschreef ik dat je zorgvuldig wil zijn in wat je revisies bevatten en hier heeft de auteur dat perfect gedaan door slechts één wijziging te doen: het lek dichten. Te vaak zie je dat mensen in een revisie ongerelateerde wijzigingen meenemen en dat maakt het backporten veel complexer.

Wat ik net heel kort heb beschreven, is eigenlijk ook een van de taken die Patchman automatisch doet: via tooling bestanden met lekken vinden en daar een patch op toepassen, zodat alleen het lek er uitgehaald wordt. Zo kan er dus niets aan de werking van een website veranderen.

Meedoen?

Ik hoop dat je, aan de hand van het lek in WP Super Cache, dit kijkje in de keuken van ontwikkelaars interessant vond. Uiteraard is het slechts een begin van wat Development allemaal nog meer doet. Uit persoonlijke ervaring weet ik dat het erg lastig is om exact uit te leggen wat ik developers nou precies doen. Het is immers een complex technisch werkje. Laat staan dat je van alle klanten kunt verwachten dat ze dit soort taken zelf doen.

Omdat het wel erg belangrijk en nodig is, werken wij er hard aan om dit soort moeilijke zaken zoveel mogelijk voor onze klanten te doen. Vind je dit echter ook interessant en beheers jij de juiste skills, kom dan soliciteren! We kunnen alle hulp goed gebruiken!

Bekijk vacatures →

P.S. Wil je op de hoogte blijven van alle artikelen, updates, tips en trucs die verschijnen op ons blog? Dat kan! Via RSS, per e-mail, het liken op Facebook, het +1’en op Google+ of het volgen op Twitter.

Deel dit blog
Ewoud Kohl van Wijngaarden
Ewoud Kohl van Wijngaarden

Ewoud versterkt sinds 2014 het development-team. Naast ontwikkelen is systeembeheren ook een iets te serieuze hobby geworden. Je mag Ewoud dus gerust als techneut omschrijven, mede door zijn passie open source.

Artikelen: 7

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *

Sterren Webhosting: 5 sterren uit 5.830 reviews

60.000+ webhostingpakketten actief
Bij de beste webhosters in MT1000 en Emerce 100