De meest voorkomende WordPress-kwetsbaarheden (en hoe je die van jou vindt)

WordPress draait een groot deel van het web, wat het een geliefd doelwit maakt voor aanvallers die geautomatiseerde scans uitvoeren. Het goede nieuws: de meeste inbraken zijn geen slimme, op maat gemaakte hacks. Ze berusten op dezelfde handvol fouten die steeds weer opduiken. Als je de meest voorkomende WordPress-kwetsbaarheden begrijpt, weet je al waar het grootste deel van je risico zit, en kun je het oplossen voordat iemand anders het vindt.

Deze gids loopt in gewone taal door de problemen die het vaakst voorkomen op echte sites. Geen doemdenken, en er wordt niet aangenomen dat je developer bent. We benoemen elke zwakke plek, leggen uit waarom die ontstaat, en wijzen je dan op een eenvoudige manier om je eigen site te controleren.

Waarom WordPress-sites doelwit worden

Het helpt om te weten dat dit bijna nooit persoonlijk is. Aanvallers kiezen jouw site niet met de hand uit. Ze draaien geautomatiseerde tools die duizenden domeinen per uur doorzoeken, op zoek naar bekende zwakke plekken met gepubliceerde oplossingen. Zodra een kwetsbaarheid publiek bekend wordt, kan misbruik binnen uren of dagen beginnen, niet weken.

WordPress zelf is redelijk veilig. Het risico zit vrijwel altijd in wat erbovenop wordt toegevoegd: plugins, thema's, configuratiekeuzes en inloggegevens. Daar gaan we onze tijd aan besteden.

Verouderde plugins en thema's

Dit is de grootste risicobron op de meeste WordPress-sites. Elke plugin en elk thema is code die door iemand anders is geschreven, en zoals alle software bevat die code soms beveiligingslekken. Wanneer een lek wordt ontdekt, brengt de ontwikkelaar meestal een patch uit via een update. Het lek wordt vervolgens publiek gedocumenteerd als een CVE, een gestandaardiseerd record van een bekende kwetsbaarheid.

Dit is het probleem. Zodra een CVE wordt gepubliceerd, zijn de details openbaar, en dat betekent dat aanvallers precies weten waar ze naar moeten zoeken. Elke site die nog de oude, ongepatchte versie draait, is nu een makkelijk doelwit. Verouderde software draaien is als een raam onvergrendeld laten nadat de lokale krant heeft afgedrukt welk raam het was.

De oplossing is onopvallend, maar effectief: houd plugins, thema's en WordPress-core up-to-date. Het probleem is dat updates soms een live site kunnen breken, dus het loont om te leren hoe je plugins veilig bijwerkt in plaats van op "alles updaten" te klikken en te hopen op het beste. Het is ook de moeite waard om na te gaan of de plugins die je gebruikt sowieso veilig en goed onderhouden zijn, want een verlaten plugin krijgt nooit meer een patch.

Nulled (illegale) thema's en plugins

"Nulled" software is een betaalde plugin of thema die is gekraakt en gratis wordt verspreid, met de licentiecontroles verwijderd. Het is verleidelijk, zeker met een krap budget, maar het is een van de ergste risico's die je op je site kunt binnenhalen.

De reden is simpel. Wie de software kraakte, had volledige toegang tot de code, en er is geen reden om aan te nemen dat diegene alleen de licentiecontrole heeft verwijderd. Nulled-pakketten bevatten vaak verborgen backdoors, spaminjectors of ingebakken malware. Je draait niet alleen onondersteunde software, je draait software die een vreemde bewust heeft aangepast voordat hij die gratis aan je gaf.

Er is geen veilige manier om nulled plugins of thema's te gebruiken. De enige oplossing is ze te verwijderen en te vervangen door legitieme versies van een vertrouwde bron.

Zwakke inloggegevens en blootgestelde loginpunten

Veel sites worden helemaal niet gehackt via een slimme code-exploit. Er wordt gewoon op ingelogd. Als een adminaccount een zwak of hergebruikt wachtwoord heeft, kunnen aanvallers dat raden met geautomatiseerde "brute force"-pogingen die duizenden combinaties proberen.

Een paar veelvoorkomende zwakke plekken in deze categorie:

• Zwakke of hergebruikte wachtwoorden, vooral op adminaccounts. Gebruik lange, unieke wachtwoorden en een wachtwoordmanager.

• De standaardgebruikersnaam admin, die aanvallers de helft van de login cadeau geeft. Gebruik in plaats daarvan een unieke gebruikersnaam.

• Geen tweefactorauthenticatie (2FA), een van de meest effectieve losse beschermingsmaatregelen die je kunt toevoegen.

• Misbruik van XML-RPC. XML-RPC is een oudere WordPress-functie waarmee externe apps met je site kunnen communiceren. Het kan worden misbruikt om brute-force-aanvallen te versterken of voor denial-of-service. Heb je het niet nodig, dan wordt het vaak uitgeschakeld of beperkt.

Deze oplossingen zijn meestal gratis en kosten minuten, wat een goede omgang met inloggegevens een van de meest waardevolle dingen maakt die je kunt doen.

Ontbrekende of verkeerd geconfigureerde SSL

Als je site laadt via http:// in plaats van https://, reist data tussen je bezoekers en je server in platte tekst, inclusief logingegevens. SSL (de technologie achter HTTPS) versleutelt dat verkeer en bewijst dat je site is wat hij beweert te zijn.

Naast het beveiligingsrisico schaden SSL-problemen je ook op zichtbare manieren. Browsers tonen een "Niet veilig"-waarschuwing die bezoekers afschrikt, en zoekmachines behandelen HTTPS als rankingfactor. Certificaten verlopen ook, en een verlopen certificaat kan een site van de ene op de andere dag kapot of offline laten lijken.

Algemene verkeerde configuratie

Verkeerde configuratie is een brede categorie, maar komt neer op instellingen die stilletjes een deur openlaten staan. Een paar voorbeelden die vaak voorkomen:

• Het tonen van mapinhoud staat aan, zodat iedereen je mappen kan doorbladeren en kan zien wat er is geïnstalleerd.

• Debugmodus staat aan op een productiesite, wat bestandspaden en andere interne details kan lekken.

• Blootgestelde gevoelige bestanden, zoals back-ups of configuratiebestanden die in een openbare map staan.

• Te ruime bestandsrechten, waardoor één gecompromitteerd onderdeel een ander kan beïnvloeden.

• Verouderde serversoftware, waaronder oude PHP-versies die geen beveiligingsupdates meer krijgen.

Niets hiervan is exotisch. Het is het digitale equivalent van de reservesleutel onder de deurmat leggen. De meeste zijn makkelijk op te lossen zodra je weet dat ze er zijn, en precies daarom is controleren zo belangrijk.

XSS en SQL-injectie (op hoofdlijnen)

Twee technische kwetsbaarheidstypen komen voortdurend terug in WordPress-CVE's, en je zult hun namen vaak zien. Je hoeft ze niet zelf te kunnen misbruiken, maar het helpt om te weten wat ze betekenen.

Cross-site scripting (XSS) gebeurt wanneer een site niet-vertrouwde invoer als code laat draaien in de browser van een bezoeker. Een aanvaller kan dit gebruiken om sessies te kapen, gebruikers om te leiden of pagina's te bekladden. Het is meestal terug te voeren op een plugin of thema dat de invoer die het accepteert niet goed opschoont.

SQL-injectie (SQLi) gebeurt wanneer niet-vertrouwde invoer de database bereikt op een manier waardoor een aanvaller zijn eigen databasecommando's kan uitvoeren. Dat kan betekenen dat je gegevens, inclusief gebruikersaccounts, worden gelezen, gewijzigd of verwijderd. Ook hier ligt de oorzaak vrijwel altijd bij een plugin of thema dat invoer verkeerd verwerkt.

De praktische conclusie is voor beide hetzelfde. Er wordt niet van je verwacht dat je code regel voor regel controleert. Deze lekken zitten in de plugins en thema's die je installeert, en daarom pakt up-to-date houden en verwijderen wat je niet nodig hebt het grootste deel van de blootstelling aan.

Een snel denkmodel

Onthoud vooral dit: het meeste WordPress-risico is bekend risico. Het komt uit gepubliceerde kwetsbaarheden in add-on-software, zwakke inloggegevens en een paar verkeerd geconfigureerde instellingen. Dat is oprecht bemoedigend, want bekende problemen hebben bekende oplossingen. Je jaagt niet op onzichtbare, nieuwe aanvallen. Je sluit deuren die al gedocumenteerd zijn.

Het moeilijke is niet het oplossen van deze problemen. Het moeilijke is weten welke er vandaag op jouw specifieke site van toepassing zijn.

Zo vind je jouw kwetsbaarheden

Je zou elke plugin, elk thema, elke instelling en elk certificaat met de hand kunnen doorlopen. Of je laat een scanner de eerste ronde voor je doen.

Catcher24 controleert je WordPress-site van buitenaf, hetzelfde uitzichtpunt dat een aanvaller heeft. Het is agentless, wat betekent dat je niets op je server installeert en geen plugin toevoegt die dingen vertraagt. Je voert je adres in en het zoekt naar bekende kwetsbaarheden (de gepubliceerde CVE's in je software), verlopen of verkeerd geconfigureerde SSL-certificaten en DNS-problemen, en laat je vervolgens in gewone taal zien wat het heeft gevonden.

Een paar eerlijke kanttekeningen, zodat je weet waar het wel en niet bij helpt. Catcher24 vindt problemen, het blokkeert geen live aanvallen en het ruimt geen infectie op. Een firewall en een malwarescanner zijn nog steeds de moeite waard om ernaast te draaien, want die doen ander werk. Zie Catcher24 als de regelmatige check-up die je vertelt wat je moet oplossen, voordat een probleem een incident wordt.