Hvad du gør den dag, en sårbarhed i et WordPress-plugin bliver offentliggjort

Der bliver offentliggjort en ny sårbarhed i et WordPress-plugin næsten hver dag. De fleste kræver ikke andet end den næste almindelige opdatering. Nogle få kræver handling i dag: dem, der aktivt bliver udnyttet, dem, der ikke kræver login, eller dem, der sidder i et plugin, du kører på dusinvis af kundesites. Denne guide er en rutine for den dag: hvordan du hurtigt afgør, om et hul betyder noget for dig, hvordan du finder hvert ramt site, og hvad du gør efter opdateringen.

Trin 1: afgør på fem minutter, om det haster

Læs selve advarslen (Patchstack, Wordfence eller WPScan), ikke kun overskriften. Fire spørgsmål afgør, hvor hurtigt du handler:

• Bliver det udnyttet? En advarsel, der nævner observerede angreb, ryger øverst på din dag.
• Kræver det login? Et hul, som en anonym besøgende kan bruge, er langt farligere end et, der kræver en administratorkonto.
• Hvad kan en angriber gøre? Upload af filer, kørsel af kode eller oprettelse af administratorkonti er værre end en reflekteret XSS, der kræver et klik.
• Hvor mange af dine sites kører det? Ét site er en opgave; fyrre sites er et projekt med en deadline.

Er svaret på de to første spørgsmål ja, så behandl det som hastende: ramte sites i dag, ikke ved næste vedligeholdelsesrunde.

Trin 2: find hvert ramt site

Du har brug for to oplysninger pr. site: er pluginet installeret (aktivt eller ej), og hvilken version kører det. Inaktive plugins tæller med. Den sårbare kode ligger stadig på serveren og kan ofte stadig nås direkte.

Med WP-CLI tager det sekunder pr. site:

wp plugin list --name=ninja-forms --fields=name,status,version

Uden WP-CLI kan du se under Plugins i wp-admin eller versionen i pluginets readme.txt. Skriv resultatet i én liste: site, installeret ja eller nej, version, rettet version. Den liste er din tjekliste resten af dagen og bagefter din dokumentation over for kunden.

Trin 3: opdater de ramte sites, de mest udsatte først

Start med de sites, der betyder mest, hvis de bliver ramt: webshops, sites med mange formularer eller brugerkonti og sites med meget trafik. Sørg før hver opdatering for, at der findes en nylig backup, som du faktisk kan gendanne.

Sikkerhedsopdateringer er som regel små, men ikke altid. Nogle udviklere leverer rettelsen i en større udgivelse med andre ændringer. Er den rettede version et stort spring, eller håndterer pluginet formularer eller checkout, så test den først på en kopi af sitet, når du kan, og tjek de vigtigste sider bagefter.

Kan du ikke opdatere i dag, for eksempel fordi rettelsen ikke er udkommet endnu, eller opdateringen ødelægger noget, så mindsk risikoen i stedet: deaktiver pluginet, hvis sitet kan klare sig uden det en dag, eller bloker det sårbare endpoint i din firewall, hvis advarslen nævner det. Fortæl kunden, hvad du gjorde og hvorfor.

Trin 4: test det, pluginet bruges til

En opdatering, der lykkes, er ikke det samme som et site, der virker. Test efter opdateringen det, pluginet er til for. Ved et formularplugin sender du en rigtig testindsendelse og tjekker, at e-mailen kommer frem. Ved et shopplugin laver du en testordre helt til betaling. En formular, der stille holder op med at sende, kan koste en kunde en uges henvendelser, før nogen opdager det.

Trin 5: tjek, om sitet allerede er blevet ramt

Opdateringen lukker hullet. Den fjerner ikke noget, en angriber har efterladt før. Blev hullet udnyttet, før du patchede, så tjek hvert ramt site for:

• administratorkonti, du ikke genkender;
• PHP-filer i uploads-mappen, som kun bør indeholde medier;
• nyligt ændrede filer i plugins og temaer, som du ikke har opdateret;
• ukendte planlagte opgaver eller omdirigeringer, du ikke har sat op.

Finder du tegn på et indbrud, så gendan en backup fra før angrebsperioden, opdater med det samme, og skift alle adgangskoder og sikkerhedsnøglerne i wp-config.php. Det er ikke nok kun at patche.

Trin 6: fortæl kunden det, kort

Kunder læser sjældent sikkerhedsnyheder, men de lægger mærke til, når deres bureau var på forkant. En kort besked er nok: hvad problemet var, om deres site var ramt eller ej, hvad du gjorde og hvornår. Det gør usynligt arbejde til synlig værdi, og det hører også med i din næste vedligeholdelsesrapport.

Gør det hurtigere næste gang

• Hold en liste over, hvilke plugins der kører på hvilke sites, så trin 2 tager minutter.
• Følg én eller to kilder til advarsler, ikke ti.
• Sørg for, at hvert site har en backup, som du faktisk har gendannet én gang.
• Aftal på forhånd med kunderne, at hastende sikkerhedsopdateringer sker uden for den normale plan.

Sådan håndterer Verploy sårbarheder i plugins

Verploy viser kendte sårbarheder i plugins og temaer på hvert tilsluttet site, så du med det samme ser, hvilke sites der er ramt. Hver opdatering bliver tjekket, og de risikable testes først på en kopi, inklusive formularer og checkout. Natlige backups kommer med en gendannelsestest, og hvis et site går i stykker efter at være gået live, ruller Verploy det tilbage. Mere om overvågning af WordPress-sårbarheder.