WordPress driver en stor del af nettet, og det gør det værd at angribe i industriel skala. Men kernen bliver vedligeholdt af et seriøst hold og lappet hurtigt. Næsten hvert eneste indbrud kommer gennem noget, du selv har installeret ovenpå.
Den skelnen er hele sagen, og den ændrer, hvad du reelt bør gøre. "Hold WordPress opdateret" er et godt råd, der adresserer den mindste halvdel af problemet.
Hvor sårbarhederne er
En WordPress-installation er kernen plus et økosystem af plugins og temaer af helt usædvanlig størrelse, bygget af titusindvis af forskellige forfattere uden fælles gennemgang, uden en fælles sikkerhedsstandard og med vildt svingende grad af løbende opmærksomhed. Kernen er én kodebase med et sikkerhedshold. Resten er en forsyningskæde.
Det er derfor, tallene er så skæve: det overvældende flertal af offentliggjorte WordPress-sårbarheder ligger i plugins og temaer og ikke i kernen. Ikke fordi plugin-forfattere er sjuskede, men fordi der er så mange af dem, og de fleste er enkeltpersoner, der vedligeholder noget gratis.
De fire situationer, der reelt giver problemer
1. Det plugin, ingen opdaterer, fordi ingen bruger det
Et installeret, men deaktiveret plugin har stadig filer på disken. Afhængigt af sårbarheden kan det være nok — nogle huller kan nås, uden at pluginnet er aktivt, fordi en PHP-fil, der ligger i plugin-mappen, kan hentes direkte over nettet og bliver udført, uanset om WordPress nogensinde har indlæst den. Mere almindeligt er det, at et plugin, der blev installeret for år siden til en formular eller en billedkarrusel, stadig er aktivt, stadig bliver indlæst ved hver forespørgsel, og ikke er blevet opdateret, fordi ingen husker, det er der.
Den praktiske instruktion: slet det, du ikke bruger. Ikke deaktivér — slet.
2. Det plugin, der blev fjernet fra kataloget
Det er den, de færreste site-ejere har hørt om, og den farligste.
Når der bliver fundet en alvorlig, ulappet sårbarhed i et plugin, kan WordPress.org lukke det — det forsvinder fra kataloget og kan ikke installeres af nye. Det, der ikke sker, er nogen som helst ændring på de titusindvis af sites, der allerede kører det. Der kommer ingen opdatering. Plugins bliver lukket af flere forskellige grunde — en urettet sikkerhedsindberetning, et brud på retningslinjerne, et licensproblem, undertiden forfatterens eget ønske — og virkningen for dig er den samme i dem alle: der bliver ikke sendt noget ud til de sites, der allerede kører det. Dit kontrolpanel viser ingen besked. Pluginnet bliver bare ved med at virke, permanent sårbart, mens dets sårbarhed er offentligt dokumenteret.
Du får det ikke at vide fra WordPress. Du får det at vide ved at holde det, du kører, op mod det, der er offentliggjort om det.
3. Det piratkopierede tema
Et kommercielt tema eller plugin, du har fået gratis et andet sted end hos leverandøren, er den enkeltvis mest pålidelige måde at blive kompromitteret på — for ændringen er hele formålet med distributionen. Det er en ren omkostningsbeslutning truffet for år siden, som ingen har taget op igen.
4. Det eksponerede login
WordPress' loginside ligger på en forudsigelig adresse og bliver angrebet vedvarende og i flæng — hvert eneste WordPress-site på internettet modtager automatiske loginforsøg, uanset størrelse og trafik. To-faktor-login på hver eneste administratorkonto betyder mere her end noget plugin, du kunne installere, og det koster ingenting.
xmlrpc.php fortjener en bemærkning: dens system.multicall-metode pakker mange loginforsøg ind i én enkelt HTTP-forespørgsel, så en angriber kan prøve hundredvis af adgangskoder pr. forespørgsel og glide under enhver begrænsning, der tæller forespørgsler. Er der ikke noget, du bruger, som har brug for den — og det har de fleste moderne sites ikke — så slå den fra.
Hvad en angriber faktisk gør
Det er værd at gøre klart, at det ikke er målrettet. Ingen har valgt dit site. Automatiske værktøjer scanner enorme dele af internettet, aflæser, hvad der kører, og prøver kendte angreb mod de versioner, de finder. Hele processen er ubemandet.
To ting følger af det. For det første beskytter "vi er for små til at være et mål" ikke, for der er ingen målretning. For det andet er vinduet mellem, at en sårbarhed bliver offentliggjort, og at den bliver udnyttet i stor skala, kort — ofte dage. Det relevante spørgsmål er ikke, om du på et tidspunkt får opdateret, men om du ville vide det inden for det vindue.
Og udbyttet er som regel ikke dine data. Et kompromitteret WordPress-site bliver oftere brugt til at hoste phishing-sider, indsætte spam-links i dine sider til fordel for en andens placering i søgeresultaterne, eller levere malware til dine besøgende. Det betyder, at skaden lander på dit omdømme og din synlighed i søgninger, før du overhovedet opdager, at noget er galt.
Hvad man rent faktisk gør
- Slet hvert plugin og tema, du ikke bruger. Den mest virkningsfulde enkelthandling, fordi den fjerner risiko i stedet for at administrere den.
- Slå automatiske opdateringer til for kernen og for de plugins, du stoler på. Argumentet imod er, at én af dem kan gå i stykker. Hold det op mod alternativet, som er en uges eksponering, mens du finder tid til at kigge.
- To-faktor-login på hver eneste administratorkonto. Uden undtagelser, også udvikleren, der satte sitet op for tre år siden og stadig har adgang.
- Gennemgå, hvem der har administratorrettigheder. Gamle bureauer, tidligere medarbejdere, en konsulent, der lavede én opgave. Hver af dem er et levende login.
- Hold det, du kører, op mod det, der er offentliggjort om det — gentagne gange. Det er den del, der ikke kan gøres én gang, for svaret ændrer sig, uden at dit site gør.
- Sørg for, at dine backups kan gendannes og ikke ligger på samme server. Utestede backups er en plan, ikke en sikring. Og en backup-fil efterladt i web-roden er sin egen eksponering.
En ærlig bemærkning om scanning
En ekstern scanner kan opremse de plugins og temaer, et WordPress-site henter, med versioner, hvor de er synlige, og matche dem mod offentliggjorte sårbarheder. Det er reelt nyttigt, og det er sådan, du finder det lukkede plugin ovenfor.
Men dækningen af plugin-sårbarheder i de almindelige sårbarhedsdatabaser er tyndere end for udbredt serversoftware — plugin-økosystemet er stort, fragmenteret og dårligt indekseret af de nationale databaser. Så et rent resultat på plugins er svagere dokumentation end et rent resultat på din webserver, og enhver, der siger noget andet, sælger noget. Behandl plugin-hygiejne — slet det, du ikke bruger, opdatér det, du beholder — som den primære kontrol, og scanning som dét, der fanger, hvad hygiejnen ikke tog. Mekanismen bag er værd at forstå, hvis du overhovedet skal læse scanner-output: derfor giver sårbarhedsscannere falske positive forklarer, hvorfor tynde og dårligt indekserede advarselsdata giver både falske alarmer og falske rene resultater.
Er WordPress sikkert?
WordPress-kernen bliver vedligeholdt af et seriøst sikkerhedshold og lappet hurtigt, så kernen er sjældent det svage punkt. Det overvældende flertal af offentliggjorte WordPress-sårbarheder ligger i plugins og temaer, som er bygget af titusindvis af forskellige forfattere uden fælles gennemgang og med svingende grad af løbende opmærksomhed. I praksis er det forkert stillet at spørge, om WordPress er sikkert — svaret afhænger næsten udelukkende af, hvad du har installeret ovenpå.
Hvad sker der, når et WordPress-plugin bliver fjernet fra kataloget?
Et lukket plugin forsvinder fra WordPress.org og kan ikke installeres af nye, men der sker ingenting på de sites, der allerede kører det. Der kommer ingen opdatering: plugins bliver lukket af flere forskellige grunde, og i dem alle bliver der ikke sendt noget ud til de sites, der allerede kører det. Dit kontrolpanel viser ingen besked, og pluginnet bliver ved med at virke, permanent sårbart, mens dets sårbarhed er offentligt dokumenteret. Du opdager det kun ved at holde det, du kører, op mod det, der er offentliggjort om det.
Skal jeg slette eller bare deaktivere ubrugte WordPress-plugins?
Slet ubrugte WordPress-plugins i stedet for at deaktivere dem. Et deaktiveret plugin har stadig sine filer på disken, og afhængigt af sårbarheden kan det være nok til, at det kan udnyttes. At slette fjerner risikoen i stedet for at administrere den, og det gør det til den enkeltvis mest virkningsfulde ting, de fleste site-ejere kan gøre — mere virkningsfuldt end noget sikkerhedsplugin, de kunne installere i stedet.
Hvorfor skulle nogen angribe mit lille WordPress-site?
Ingen har valgt dit site — og det er netop pointen. Automatiske værktøjer scanner enorme dele af internettet, aflæser, hvad der kører, og prøver kendte angreb mod de versioner, de finder, helt ubemandet — så det beskytter ikke at være lille, for der er ingen målretning. Udbyttet er som regel heller ikke dine data: kompromitterede sites bliver typisk brugt til at hoste phishing-sider, indsætte spam-links til fordel for en andens placering i søgeresultaterne eller levere malware til dine besøgende, og det betyder, at skaden først lander på dit omdømme og din synlighed i søgninger.
Hvor VulnControl passer ind
VulnControl finder udefra ud af, hvilken software dit site reelt kører — WordPress-kernen, de plugins og temaer det henter med versioner, hvor de er synlige, webserveren og JavaScript-bibliotekerne — og matcher hver enkelt mod en natligt opdateret sårbarhedsdatabase, med markering af alt, der er bekræftet under aktivt angreb. Det finder også de tilstødende eksponeringer, der følger med et site, som har levet længe: et admin-panel, der kan nås alle steder fra, en databaseport, der står åben, en backup-fil, der stadig ligger i web-roden.
Det er ærligt om den begrænsning, der er beskrevet ovenfor: dækningen af plugin-sårbarheder er tyndere end dækningen af kernen, og en version, det ikke kan fastslå, bliver meldt som ubekræftet og ikke som ren.