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.

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 priviligerte kontoer.
9. Kjøre en fullstendig skadevareskanning.
10. Sette opp løpende sikkerhetsovervåking.

Poenget med denne rekkefølgen er ikke bare å gjenopprette miljøet, men å 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 som jobber sammen, ikke bare ett av dem alene.

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.