WordPress Multisite kompromittert: slik undersøkte og gjenopprettet vi nettverket

Kunden driftet et WordPress Multisite-nettverk, med flere bedriftsnettsteder administrert fra én enkelt WordPress-installasjon. Det oppsettet samler oppdateringer og administrasjon på ett sted, men det har en bakside: alt som påvirker kjerneinstallasjonen, kan nå hvert eneste nettsted i nettverket samtidig. Det som kom inn som en rutinemessig melding om ødelagte sider og manglende stilark, ble i løpet av få timer til en full sikkerhets- og infrastrukturundersøkelse.

Kort om oppdraget

• Oppsett: WordPress Multisite med flere bedriftsnettsteder i én installasjon, med felles kjernefiler, plugins, temaer og brukeradministrasjon
• Symptom: Ødelagte oppsett, stilark og skript som ikke lastet, og upålitelig ytelse og funksjonalitet på flere av nettstedene
• Funn: Uautoriserte omdirigeringsregler i .htaccess, en endret index.php med kjennetegn på SEO-cloaking, og sterkt obfuskert PHP-skadevare
• Utfall: Rotårsakene fastslått og en gjenopprettingsplan i ti steg for hele nettverket

Oppsettet

Siden alle nettstedene kjørte fra én WordPress Multisite-installasjon, delte de kjernefiler, plugins, temaer og brukeradministrasjon, samtidig som de beholdt sine egne konfigurasjoner og sitt eget innhold. Kunden fortalte oss at flere nettsteder oppførte seg uventet. Noen sider så ødelagte ut, stilark manglet, og ytelsen og funksjonaliteten generelt hadde blitt upålitelig. Den delte arkitekturen gjorde at vi ikke kunne se på ett enkelt nettsted isolert. Vi måtte undersøke både den delte infrastrukturen og de individuelle nettstedskonfigurasjonene.

Utfordringen

Da vi startet vurderingen, var flere varseltegn synlige med en gang:

• Flere nettsteder viste ødelagte oppsett.
• CSS- og JavaScript-ressurser lastet ikke inn riktig.
• Nettleserkonsollen logget en rekke feil.
• Enkelte sider oppførte seg annerledes enn forventet.
• PHP-advarsler og kompatibilitetsproblemer dukket opp i hele miljøet.

Med alt kjørende på en delt Multisite-installasjon betydde det å finne rotårsaken at vi måtte jobbe metodisk gjennom infrastrukturen, i stedet for å lappe symptomer på ett nettsted om gangen.

Innledende undersøkelse

Gjennomgang av serverkonfigurasjonen

Vi startet med serverkonfigurasjonen og rutingen av nettstedene. Under den gjennomgangen fant vi uautoriserte omdirigeringsregler inne i nettstedets .htaccess-fil. Reglene hadde ingen legitim forretningsmessig hensikt, og at de var der i det hele tatt, pekte mot et kompromittert miljø. Å finne omdirigeringslogikk som ingen hadde lagt inn med vilje, flyttet dette umiddelbart fra en feilsøkingsjobb til en sikkerhetshendelse.

Inspeksjon av WordPress-kjernefiler

Deretter sjekket vi integriteten til sentrale WordPress-kjernefiler. Et av de første funnene var at nettstedets index.php var blitt endret. I stedet for den standard WordPress-oppstarten inneholdt filen ekstra egendefinert logikk skrevet for å profilere besøkende og selektivt vise forskjellig innhold. Den oppførselen er en kjent signatur for SEO-cloaking og skadevare. Uautorisert kode plassert inne i en kjernefil bekreftet at installasjonen ikke lenger kunne stoles på uten grundigere analyse.

Analyse av mistenkelige PHP-filer

Videre graving avdekket sterkt obfuskert PHP. Koden bar de vanlige kjennetegnene på skadevare:

• Kodede strenger
• Dynamisk funksjonskjøring
• Skjult rutinglogikk
• Deteksjon av besøkende
• Rutiner for ekstern kommunikasjon
• Målretting mot søkemotorer

Graden av obfuskering fortalte sin egen historie. Koden var skrevet for å unngå oppdagelse og gjøre manuell analyse så vanskelig som mulig.

Vurdering av WordPress Multisite

Deretter gikk vi gjennom selve Multisite-arkitekturen. Flere nettsteder kjørte fra én installasjon, noe som betydde at de delte:

• WordPress-kjernefiler
• Plugins
• Temaer
• Brukeradministrasjon

Hvert nettsted hadde sin egen konfigurasjon og sitt eget innhold, men det delte laget var den egentlige bekymringen. Enhver kompromittering som berørte de delte ressursene, kunne nå hvert nettsted i nettverket, så det var avgjørende å forstå strukturen før vi anbefalte noen løsning.

Analyse av nettleserkonsollen

For å forstå den ødelagte frontend-en jobbet vi oss gjennom loggene i nettleserkonsollen. Flere problemer skilte seg ut.

Manglende ressurser

Flere CSS- og JavaScript-filer returnerte 404-feil, noe som forklarte hvorfor enkelte nettsteder så ustilte ut eller bare var halvveis gjengitt.

Problemer med blandet innhold

Noen ressurser forsøkte å laste over HTTP mens nettstedene selv kjørte over HTTPS. Moderne nettlesere blokkerer slike usikre forespørsler, så stilark, fonter og skript lot rett og slett være å laste.

Feil ved hastighetsbegrensning

Konsollen viste også 429-svar, som betyr at noen forespørsler ble blokkert av hastighetsbegrensning eller sikkerhetsrestriksjoner. Det sendte oss videre til å se på sikkerhetsverktøyene, brannmurreglene og beskyttelsen på plugin-nivå som kunne være involvert.

Gjennomgang av PHP-kompatibilitet

Mens vi var inne i miljøet, fant vi også en rekke PHP-kompatibilitetsadvarsler. Flere plugins og temakomponenter ga varsler om utdaterte funksjoner under nyere PHP-versjoner. Disse var ikke årsaken til kompromitteringen, men de bidro til ustabilitet og gjorde feilsøkingen vanskeligere enn nødvendig. Vår anbefaling var å gjennomgå plugin-kompatibiliteten og validere PHP-versjonen mot resten av programvarestakken.

Viktige funn

Undersøkelsen avdekket flere uavhengige problemer på tvers av miljøet.

Sikkerhet

• Uautoriserte omdirigeringsregler
• Endrede WordPress-kjernefiler
• SEO-cloaking-oppførsel
• Obfuskert PHP-skadevare
• Indikatorer på uautorisert tilgang

Infrastruktur

• Kompleksitet i Multisite-konfigurasjonen
• Delte ressurser som påvirker flere nettsteder
• Manglende frontend-ressurser
• Konfigurasjonsproblemer med blandet innhold

Kompatibilitet

• Utdatert PHP-funksjonalitet
• Bekymringer rundt temakompatibilitet
• Kompatibilitetsadvarsler for plugin-rammeverk

Ytelse og pålitelighet

• Feil ved innlasting av ressurser
• Sikkerhetsblokkeringer i nettleseren
• Svar med hastighetsbegrensning
• Problemer med frontend-gjengivelse

Gjenopprettingsstrategi

Med et klart bilde satte vi sammen en strukturert gjenopprettingsplan:

1. Fjerne de skadelige omdirigeringsreglene.
2. Erstatte de kompromitterte WordPress-kjernefilene.
3. Fjerne uautoriserte PHP-filer og bakdører.
4. Verifisere integriteten til Multisite-konfigurasjonen.
5. Revidere temaer og plugins.
6. Rette opp problemene med HTTPS og blandet innhold.
7. Gjennomgå innstillingene for brannmur og sikkerhetsplugin.
8. Tilbakestille påloggingsdetaljer for privilegerte kontoer.
9. Kjøre en fullstendig skadevareskanning.
10. Sette opp løpende sikkerhetsovervåking.

Rekkefølgen skal både gjenopprette miljøet og herde det, slik at det samme ikke skjer igjen.

Resultat

Undersøkelsen fastslo rotårsakene bak kundens nettstedsproblemer og avdekket bevis på en bredere kompromittering på tvers av WordPress-miljøet. Ved å jobbe metodisk gjennom serverkonfigurasjonen, kjernefilene, Multisite-arkitekturen, konsoll-loggene og sikkerhetsindikatorene etablerte vi en klar gjenopprettingsvei og et sett konkrete anbefalinger for å gjenopprette nettverket trygt. Det var en god påminnelse om at komplekse nettstedsproblemer ofte krever WordPress-kunnskap, sikkerhetsanalyse og infrastrukturfeilsøking på én gang.

Viktig lærdom

WordPress Multisite er kraftig, men det krever nøye oppmerksomhet på sikkerhet og vedlikehold. Når en kompromittering rammer delte ressurser, sprer skaden seg på tvers av hvert nettsted samtidig. En strukturert undersøkelse var det som lot oss finne de skjulte problemene, avdekke de skadelige endringene og legge opp en vei tilbake til et sikkert og pålitelig miljø. Hvis et WordPress-nettsted oppfører seg merkelig, viser sikkerhetsadvarsler eller gjengir ødelagte oppsett, er en grundig teknisk undersøkelse vanligvis den raskeste måten å finne det egentlige problemet på før det gjør mer skade.

Hvis Multisite-nettverket ditt viser de samme tegnene

Ødelagte oppsett og manglende stilark kan ha helt ufarlige årsaker, som én feil mappetillatelse. Det som gjorde denne jobben til en sikkerhetshendelse, var kode ingen hadde lagt inn med vilje. Disse sjekkene hjelper deg å skille de to i ditt eget nettverk.

• Sammenlign kjernen med den offisielle utgivelsen. Et nettverk er en samling nettsteder som deler de samme kjernefilene, så én sjekk dekker alle nettstedene. Har du SSH-tilgang, sammenligner WP-CLI-kommandoen wp core verify-checksums de installerte filene med sjekksummene fra WordPress.org og varsler om hver fil som ikke stemmer. Det er slik en endret index.php avslører seg. Med --include-root varsler den også om filer og mapper i rotmappen som ikke hører til WordPress.
• Sjekk pluginene på samme måte. wp plugin verify-checksums --all gjør det samme for alle pluginene, mot sjekksummene fra WordPress.org. Premiumplugins og kommersielle temaer publiserer ingen sjekksummer, så de må gjennomgås strukturelt, slik vi gjorde i saken der sikkerhetspluginen hadde oversett tre bakdører.
• Les .htaccess-filen linje for linje. Når et nettverk settes opp, legges omskrivingsreglene i .htaccess-filen i samme mappe som wp-config.php, ifølge WordPress sin egen veiledning om å opprette et nettverk. Med én installasjon står den filen foran hvert eneste nettsted. Finner du en omdirigeringsregel ingen kan gjøre rede for, må du finne ut hvordan den kom dit. Å slette den og gå videre er ikke nok.
• Behandle Super Admin-kontoer som nøkler til alle nettstedene. I et nettverk er det bare Super Admin som kan installere og oppdatere plugins og temaer, og WordPress beskriver rollen som tilgang til nettverksadministrasjonen og alle andre funksjoner. Nye passord for privilegerte kontoer står i gjenopprettingsplanen over, og de kommer etter at de skadelige filene er fjernet, så en aktiv bakdør ikke gir angriperen de nye passordene.
• Skriv ned hva nettleserkonsollen sier før du endrer noe. Her fortalte 404 på stilark og skript, blokkert blandet innhold og 429-svar hver sin del av historien.

---

Oppfører Multisite-nettverket ditt seg rart?

Et nettverk trenger en annen type undersøkelse enn et enkelt nettsted, fordi bevisene er delt, og det samme er risikoen. Med WordPress-sikkerhet tar vi kompromitteringer på servernivå og i multi-site fra 17 990 kr eks. mva, med kartlegging av infeksjonen på tvers av nettstedene i installasjonen. Gjelder det ett enkelt nettsted, starter oppryddingen fra 3 990 kr. Vurderingen er gratis, du får fast pris skriftlig før vi starter, og vi bekrefter henvendelsen innen 1 time i arbeidstiden. Fortell oss hva du ser, så tar vi det derfra.