De flesta WordPress-sajter tar sig ingen in i genom någon smart, skräddarsydd attack. De tar sig in genom en brist i ett plugin eller tema som avslöjades veckor tidigare, åtgärdades av utvecklaren och helt enkelt aldrig uppdaterades på sajten. Att ligga steget före handlar mindre om hjältedåd och mer om en rutin: att veta var sårbarheter tillkännages, att ha en backup innan du rör något, och att applicera fixen snabbt när den väl finns. Det här är en tidlös guide till den rutinen, och till hur en managed leverantör kortar tiden mellan att en fix publiceras och att den är live på din sajt.
Hur en plugin-sårbarhet blir en attack
Livscykeln ser oftast likadan ut, och att förstå den är vad som gör försvaret självklart. En forskare hittar en brist i ett plugin eller tema, ofta i kod som hanterar indata: ett formulär, en uppladdning, en API-endpoint. Bristen rapporteras privat till utvecklaren, som skriver en fix och släpper en ny version. Sårbarheten avslöjas sedan offentligt, ofta genom en samordnad rapport, så att sajtägare vet att de behöver uppdatera. Det avslöjandet är ett tveeggat ögonblick: det säger till försvararna att patcha, och det säger till angriparna exakt vad de ska leta efter.
Sedan följer en kapplöpning. Automatiska verktyg skannar webben efter sajter som fortfarande kör den sårbara versionen, eftersom avslöjandet i praktiken har publicerat en karta. Sajter som uppdaterar snabbt försvinner från den kartan. Sajter som inte gör det hittas och utnyttjas i stor skala, för samma skript kan pröva tusentals mål. Den obekväma sanningen är att offentligt avslöjande, som finns för att skydda dig, också startar en klocka. De sajter som förlorar är nästan aldrig de som valdes ut för vilka de är. Det är de som fortfarande var exponerade när skanningen började.
Ett historiskt exempel, så att tidslinjen blir konkret
Ett väldokumenterat, historiskt fall gör mönstret gripbart. I slutet av januari 2017 släppte WordPress version 4.7.2, som åtgärdade en sårbarhet för innehållsinjektion i REST-API:t som påverkade versionerna 4.7.0 och 4.7.1. Bristen lät en oautentiserad användare ändra innehållet i inlägg. WordPress säkerhetsteam höll medvetet tillbaka detaljerna i ungefär en vecka efter att fixen släppts, för att ge sajter tid att uppdatera, och avslöjade dem sedan. När detaljerna väl var offentliga drabbade defacement-kampanjer opatchade sajter inom några dagar och ändrade sidor på ett stort antal installationer. Allt som behövdes för att vara säker, den patchade versionen, fanns tillgängligt innan utnyttjandevågen började. De sajter som drabbades var de som ännu inte hade applicerat en uppdatering som redan fanns.
Vi använder detta enbart som en tydligt historisk illustration, löst för flera år sedan, för att visa riskens form. Det är ingen aktuell varning. Verkliga, aktuella varningar bör alltid komma från verifierade sårbarhetsflöden, som vi går igenom härnäst, snarare än ur minnet eller ett blogginlägg.
Var sårbarheter faktiskt tillkännages
Du behöver inte hitta sårbarheter själv. Du behöver bevaka platserna som publicerar dem, och det finns en handfull tillförlitliga källor för WordPress-ekosystemet:
- Patchstack. Underhåller en sårbarhetsdatabas för WordPress-plugins och -teman och samordnar avslöjanden med utvecklare. Det är ett praktiskt sätt att följa vad som rapporterats och åtgärdats bland de plugins du kör.
- WPScan. Driver en etablerad sårbarhetsdatabas för WordPress (historiskt känd som WPVulnDB) och en skanner som stämmer av en sajts plugins, teman och kärna mot kända problem. Användbart både som flöde och som granskningsverktyg.
- WordPress.org säkerhetsteam. Publicerar säkerhetsreleaser för kärnan och de release-anteckningar som följer med. Kärnuppdateringar är den baslinje alla bör bevaka.
- Ändringsloggar för plugins och teman. Utvecklarna själva noterar säkerhetsfixar i sina release-anteckningar. För de plugins som betyder mest för din sajt är ändringsloggen en direkt signal.
Poängen med att bevaka dessa är inte att bli säkerhetsanalytiker. Det är att veta, inom ungefär ett dygn, när något du kör behöver uppdateras, så att du agerar på fixen medan fönstret fortfarande är smalt.
Rutinen som håller dig steget före
Bevakning hjälper bara om den leder till ett säkert, upprepbart svar. Rutinen som faktiskt håller sajter steget före sårbarheter är inte komplicerad, men den måste göras konsekvent snarare än när någon råkar komma ihåg:
- Håll en inventering. Vet vilka plugins och teman du kör och vilka versioner, för du kan inte patcha det du glömt att du installerat.
- Ta backup innan du uppdaterar. En färsk backup gör en dålig uppdatering till en snabb återställning i stället för en incident.
- Applicera säkerhetsfixar snabbt. Vanliga säkerhetsreleaser är oftast säkra att applicera direkt, och det är i fördröjningen risken sitter.
- Kontrollera sajten efter uppdateringen. Ladda sidorna, kassan och formulären, så att en trasig uppdatering fångas av dig och inte rapporteras av en besökare.
- Ta bort det du inte använder. Varje inaktiverat men installerat plugin är fortfarande kod på disken och fortfarande en möjlig ingång. Radera det.
Försvaret mot plugin-sårbarheter är sällan en produkt. Det är disciplinen att ta backup före en uppdatering och patcha snabbt efter ett avslöjande, gjort tillförlitligt nog att det faktiskt sker.
Var Celestio passar in
Det är här hosting och underhåll slutar vara skilda saker. På vår managed plattform är rutinen ovan en del av hur plattformen körs, snarare än en veckopåminnelse du måste hedra. Backuper körs på schema och sparas, så att en återställningspunkt finns före varje ändring. Uppdateringar hanteras med en kontroll efteråt, så att säkerhetsreleaser appliceras snabbt och sajten ses över när de är gjorda. Och när ett avslöjande landar som kräver ett mänskligt beslut, ett större versionshopp som kan ändra beteende, finns ingenjörer tillgängliga att göra den bedömningen i stället för att lämna den till en obevakad automatisk uppdatering.
Värdet ligger i fönstret. Glappet mellan att en fix publiceras och att den är live på din sajt är precis den period angriparna räknar med. Att korta det fönstret, tillförlitligt och för varje sajt, är det mesta av vad managed uppdateringar och bevakning är till för. Det är inget löfte om att inget någonsin kommer att ha en sårbarhet, för allt får det till slut. Det är ett löfte om att fixen appliceras medan den fortfarande spelar roll.
Om en sårbarhet redan har använts mot dig är det ett annat och mer brådskande jobb. Vår tjänst för malware-sanering är för sajter som redan är komprometterade: att hitta vad som tagit sig in, ta bort det och täppa till hålet så att det inte helt enkelt händer igen. För alla andra är målet med den här guiden att göra det samtalet onödigt genom att hålla dig på den säkra sidan av avslöjandeklockan.