Meldingen: Mogelijk DDOS op WordPress websites via niet bestaande images

Beste Lezers,

Gisteren 13 april heeft ons team “onderop deze nieuwsbrief partijen benoemd” een zwakte binnen WordPress gevonden, deze zwakte is minstens bij een van onze klanten op grote schaal misbruikt. Ik beschrijf deze zwakte in een “hopelijk” zo goed mogelijke uitleg.

Het zijn hits op niet bestaande images.
Bijvoorbeeld op
/android-touch-icon-192x192.png
/apple-touch-icon-180x180.png
/favicon-touch-96x96.png
/apple-touch-icon-152x152.png
/favicon-touch-32x32.png
/apple-touch-icon-144x144.png
/favicon-touch-16x16.png
/apple-touch-icon-120x120.png
/apple-touch-icon-114x114.png

Op het eerste gezicht voor een systeembeheerder als deze aanroepingen gedaan worden, lijken deze op legitieme urls, een systeembeheerder bouwt zelf geen websites, en ziet dan diverse IPv4 en IPv6 adressen voorbij komen, die de websites bezoeken via o.a. in Apache en of Nginx acces logs, deze vallen helemaal niet op als een website, zoals een publicatie-website die een geschiedenis heeft gehad met veel bezoekers, met name na het plaatsen van een bekende Blog en /of publicatie via diverse media.

Wat daarmee gebeurde was:
De ongeldige hits probeerde WordPress op te starten om een 404 pagina te genereren, dat kon de server niet aan. Het is wel een zwakte van WordPress om in zo'n situatie zo'n zware belasting te veroorzaken, dat is de basis van de DOS aanval. De hits komen vanaf verschillende ip-adressen, daardoor denken wij dat er een botnet gebruikt wordt. Die zijn vaak goedkoop te huur voor dit soort aanvallen, omdat urls niet bestaan doet WordPress een algehele search op de index naar de url / image en daarna geeft deze een 404 terug, doe je dit nou 1 of 10 keren, dat is geen probleem, maar wanneer je dat doet met bijvoorbeeld een paar duizend keren tegelijk, dan trekt Apache Php onderuit en Php wederom weer SQL onderuit door de hoge server-load.

De geldige urls moeten zijn /
manifest.json /android-icon-192x192.png
/apple-icon-180x180.png
/favicon-96x96.png
/apple-icon-152x152.png
/favicon-32x32.png
/apple-icon-144x144.png
/favicon-16x16.png
/15932 /apple-icon-114x114.png

De fix die hiervoor gemaakt is, is een actie die op de htaccess uitgevoerd moet worden om direct de gehele search in de gehele index direct te stoppen RewriteEngine On RewriteCond %{REQUEST_FILENAME} !-f RewriteRule \.(jpg|jpeg|png|gif|ico|swf|bmp)$ - [nocase,redirect=403,last]

Het stukje code: "RewriteEngine On"
Hebben de meeste wel instaan, het gaat dus om de onderstaande twee regels, daarmee zeg je feitelijk als een image niet bestaat ga dan direct naar 403 ipv 1st de gehele index afzoeken en dan pas een 404 afgeven,

Nu heb ik van een paar klanten een kritiek gehoord “wat gebeurd er nu met onze SEO?” Mijn antwoord als systeembeheerder is: “het gaat om niet bestaande pages die je wegstuurt naar 403 maar puur de niet bestaande url/images. U als klant bent niet verplicht om de actie uit te voeren, u heeft daar zelf de vrije keuze in, echter zodra wij een server-overload binnenkrijgen en zien bovenstaande acties gebeuren, dan zal ons security-team daar wel op aansturen om de overlast op de server/s en netwerk zsm te beperken dan wel stoppen.

De samenwerkende partijen die hun tweede Paasdag hiervoor opgeofferd hebben:


Menno Zweistra van Atis Software, https://atissoftware.com/
Michael Michel van Online Marketing Amsterdam https://www.online-marketing.amsterdam
Maurice de Hond van View/Ture B.V.
De website waar deze actie op gebeurd was is https://www.maurice.nl
Vservs BV Team.