- Door
- Jeroen Mulder
- geplaatst op
- 18 maart 2014 08:13 uur
Eigenlijk is het te banaal voor woorden. Al sinds 2007 is in WordPress een ‘feature’ bekend waarmee het echt kinderlijk eenvoudig is om DDoS-aanvallen op te zetten, waarbij WordPress-sites elkaar gebruiken om daarmee een doelwit te bombarderen. Begin deze week publiceerde Sucuri.net een blog waarin werd uitgelegd hoe je met een simpel stukje code 162.000 WordPress-sites succesvol een DDoS-aanval uitvoert. Dat weten we dan. En nu? Wat als je als hoster honderden, tot misschien duizenden WordPress-sites host voor klanten? Moet je iets met een bericht over een dergelijk risico in een CMS?
De truc is echt eenvoudig. Per default staat pingback aan in WordPress, via XMLRPC. Dit wordt gebruikt voor diverse functionaliteiten, met name voor mobiele toegang tot de sites. Het is direct het grootste ‘lek’ – let wel: goed beschouwd is hier geen sprake van een lek. WordPress gebruikt de functionaliteit bewust – in de populaire content managementsoftware. Hackers gebruikten het lek om meer dan 162.000 WordPress-sites met elkaar te laten communiceren en gezamenlijk een doelwit onder schot te nemen in een DDoS-aanval. De pingback-verzoeken die op het doelwit werden afgevuurd, hadden telkens andere URL’s. De doelsite moest daarom telkens een nieuwe pagina laden om een verzoek vanuit de aanvallers te beantwoorden. Een stukje code. En een bijna niet te achterhalen DDoS-bron.
DDoS groeit in populariteit. Vooral NTP-amplification is een veel gebruikte techniek: hierbij wordt een IP-adres van een doelwit vervalst. Vanaf dat adres wordt een verzoek naar een NTP-server gestuurd. Die server stuurt daarop een antwoord terug, maar dan naar het doelwit en flink ‘versterkt’. Er zijn op de markt diverse DDoS-toolkits verkrijgbaar waarmee ook dit bijzonder eenvoudig is om uit te voeren. En zo lijkt er maar geen einde te komen aan de manieren waarop een DDoS kan worden opgezet. En wat doen de hosters?
In het geval van deWordPress-hack: het is eenvoudig om te achterhalen of sites worden misbruikt. In de blog van Sucuri wordt keurig uitgelegd hoe je dit kunt achterhalen en kunt voorkomen. Het wordt echt tijd dat de hostingbranche zelf echt eens heel serieus leert omgaan met security. Daarbij hebben we het niet over de grote, professionele bedrijven die regelmatig audits laten uitvoeren op hun security, maar vooral om de kleine hosters die ergens in een datacenter een paar servers hebben draaien en die tot de nok volstouwen met websites, waar ze nauwelijks nog naar omkijken. Ook die partijen hebben een plicht om security op een hoog niveau te waarborgen.
Security is een maatschappelijke plicht. Misschien vindt een klant van zo’n hoster het niet erg als een site niet beschikbaar is, maar die site vormt wellicht wel een schakel in een botnet-ketting van waaruit DDoS-aanvallen worden uitgevoerd. Sterker: het verdient zo langzamerhand misschien wel sterke aanbeveling om hosters verplicht te onderwerpen aan een jaarlijkse security-audit om zo het kaf van het koren te scheiden. Hosters – ook kleine hosters en zolderkamerbedrijven – moeten zich gaan realiseren welke verantwoordelijkheid zij hebben om hun klanten en die van collega’s te vrijwaren van ellende die internetcriminaliteit met zich meebrengt. Dat is niet alleen een zaak van de ‘grote jongens’. Niet meer.