Miért fertőződik újra a WordPress oldal a tisztítás után?

Megtalálsz egy rosszindulatú fájlt a WordPress oldalon, eltávolítod, lefuttatsz egy malware scannert, frissíted a WordPresst és a bővítményeket, majd úgy tűnik, minden rendben van.

Néhány órával vagy nappal később viszont ugyanaz a fájl újra ott van. Visszatér az idegen oldalra történő átirányítás, ismét spam tartalom jelenik meg, vagy újabb fájlok módosulnak.

Ez érthetően frusztráló, de közben fontos diagnosztikai információ is.

Ha egy eltávolított probléma újra megjelenik, abból nem következik automatikusan, hogy az oldalt egy teljesen új támadás érte. Elképzelhető, hogy az eredeti kompromittálás valamelyik része maradt a rendszerben, egy bent maradt mechanizmus hozza létre újra a törölt elemet, vagy továbbra is használható az a hozzáférés vagy sérülékenység, amelyen keresztül módosítani lehet az oldalt.

Ilyenkor ezért nem az a legfontosabb kérdés, hogy mit kell megint törölni, hanem az, hogy miért tud újra létrejönni a probléma.

Mit jelent az, hogy újra megfertőződött a WordPress?

Az „újrafertőződés” kézenfekvő megfogalmazás, de technikailag több különböző helyzetet is jelenthet.

Lehetséges például, hogy:

• az eredeti fertőzést nem sikerült teljesen eltávolítani;
• maradt egy olyan kód vagy mechanizmus a rendszerben, amely képes újra létrehozni a törölt módosítást;
• ugyanazt a sérülékenységet ismét kihasználják;
• egy kompromittált hozzáférés továbbra is használható;
• egy fertőzött vagy nem bizonyítottan tiszta backupból került vissza a módosítás;
• vagy valóban egy új, az előzőtől különálló kompromittálás történt.

Az olyan bent maradó mechanizmust, amely a tisztítás után is lehetővé teszi a támadó számára a hozzáférés vagy egy nem kívánt módosítás fenntartását, gyakran perzisztenciának nevezik. A diagnosztika szempontjából azonban nem maga az elnevezés a fontos, hanem annak kiderítése, hogy maradt-e valami a rendszerben, ami újra létre tudja hozni a problémát.

Kívülről ezek akár nagyon hasonlóan is kinézhetnek.

Ha például ugyanaz a rosszindulatú JavaScript jelenik meg ismét egy oldalon, abból önmagában még nem tudjuk, hogy egy bent maradt kód írta vissza, valaki egy kompromittált hozzáféréssel ismét módosította az oldalt, vagy újra kihasználtak egy továbbra is meglévő sérülékenységet.

A visszatérő tünet tehát bizonyítja, hogy valamit még vizsgálni kell. A pontos okot viszont nem érdemes bizonyíték nélkül kijelenteni.

Miért térhet vissza a WordPress-fertőzés?

Csak a látható tünetet távolították el

Ez az egyik legfontosabb különbség egy visszatérő fertőzés megértésénél.

Tegyük fel, hogy találsz egy rosszindulatú JavaScript-részletet egy fájlban. Kitörlöd, az idegen oldalra történő átirányítás megszűnik, és a weboldal ismét normálisan működik.

Ez jó jel, de csak azt bizonyítja, hogy az adott módosítást eltávolítottad.

Azt nem bizonyítja, hogy a kompromittálás minden eleme megszűnt.

Ugyanez igaz lehet egy törölt rosszindulatú PHP-fájlra, spam tartalomra vagy redirectre is. A látogató számára ezek jelentik a problémát, ezért természetes, hogy elsőként ezeket vesszük észre. Biztonsági szempontból viszont ezek lehetnek csak egy nagyobb probléma látható következményei.

Ezért a „töröltem mindent, amit a scanner talált” és a „megszüntettem a kompromittálás minden releváns elemét” nem feltétlenül jelenti ugyanazt.

Maradt rosszindulatú kód vagy más módosítás az oldalon

Egy kompromittált WordPress oldal nem feltétlenül egyetlen rosszindulatú fájlból áll.

Módosítás kerülhet többek között:

• WordPress core fájlokba;
• a wp-config.php fájlba;
• bővítményekbe;
• sablonokba;
• mu-pluginokba;
• a wp-content más részeibe;
• az uploads könyvtárba;
• a WordPress gyökérkönyvtárában található más, nem core fájlokba;
• vagy más, az alkalmazás számára elérhető fájlokba.

A vizsgálatot ezért nem érdemes automatikusan a pluginokra és a sablonokra korlátozni. Egy olyan fájl is releváns lehet, amely nem része a WordPress core-nak, mégis ugyanabban a környezetben található és az alkalmazás vagy a webszerver számára elérhető.

Ha ezek közül csak az egyik komponenst találod meg és távolítod el, egy másik bent maradt komponens később ismét létrehozhatja a látható problémát.

Ez az oka annak is, hogy egyetlen gyanús fájl megtalálása után nem érdemes automatikusan azt feltételezni, hogy maga a fájl volt a kompromittálás teljes oka.

Lehet, hogy csak az egyik következménye volt.

Az adatbázisban maradt nem kívánt módosítás

A WordPress-fertőzéseknél könnyű kizárólag a fájlokra koncentrálni, pedig a weboldal működésének jelentős része az adatbázisban tárolt adatoktól függ.

Egy kompromittálás során bekerülhet például:

• injektált HTML vagy JavaScript;
• spam tartalom;
• módosított beállítás;
• plugin vagy sablon konfigurációjába írt nem kívánt érték;
• jogosulatlan felhasználóhoz kapcsolódó adat.

Ennek fontos következménye van: egy kizárólag fájlokat ellenőrző scanner negatív eredménye önmagában nem bizonyítja, hogy az egész WordPress oldal tiszta.

Ha a tünet forrása az adatbázisban maradt, a fájlok ismételt átvizsgálása nem feltétlenül fogja megtalálni.

Megmaradt egy jogosulatlan vagy kompromittált adminisztrátori fiók

Ha valaki továbbra is rendelkezik használható adminisztrátori hozzáféréssel, akkor a fájlok megtisztítása önmagában nem zárja le az incidenst.

A probléma nem feltétlenül egy újonnan létrehozott, feltűnő nevű adminisztrátor. Egy már létező fiók hozzáférési adatai is kompromittálódhattak.

Ezért érdemes megvizsgálni, hogy mely WordPress-felhasználók rendelkeznek magas jogosultsággal, szükség van-e ezekre a fiókokra, és van-e köztük olyan, amelynek eredete vagy használata nem tisztázott.

Egy kompromittált fióknál nem feltétlenül elég kizárólag a jelszó megváltoztatására gondolni. A WordPress külön kezeli a bejelentkezett felhasználói munkameneteket, és lehetőséget ad azok visszavonására is. Emiatt az aktív munkamenetek felülvizsgálata és szükség esetén megszüntetése is része lehet a hozzáférés kezelésének. A „megváltoztattam a jelszót” és a „minden korábbi hozzáférési lehetőséget megszüntettem” nem feltétlenül ugyanaz az állítás.

Komolyabb kompromittálásnál ugyanakkor nem érdemes kizárólag arra hagyatkozni, amit a WordPress adminisztráció felhasználói listájában látsz. A vizsgálatnak azt kell tisztáznia, hogy ki és milyen módon képes jelenleg módosítani a rendszert.

Egy WordPressen kívüli hozzáférés továbbra is kompromittált

A WordPress admin csak egyetlen hozzáférési pont.

Egy weboldalhoz a környezettől függően más módokon is hozzá lehet férni. Ilyen lehet például:

• a hosting fiók;
• SFTP vagy FTP;
• SSH;
• adatbázis-hozzáférés;
• deployment rendszer;
• más kapcsolódó technikai fiók;
• olyan e-mail-fiók, amely jelszó-visszaállításhoz használható.

A felülvizsgálatnál a programozott WordPress-hozzáférésekről sem érdemes megfeledkezni. A WordPress Application Passwords például felhasználói fiókhoz kapcsolódó, külön visszavonható hitelesítési adatokat biztosít programozott hozzáféréshez, többek között API-t használó alkalmazások és integrációk számára. Használatuk önmagában nem biztonsági probléma. Ha viszont egy ilyen hitelesítési adat kompromittálódhatott és továbbra is érvényes, akkor ugyanúgy figyelembe kell venni a hozzáférések felülvizsgálatánál, mint más credentialöket.

Ugyanez vonatkozik a REST API-hoz vagy más ténylegesen használt integrációhoz tartozó hitelesítési adatokra is. Nem az API jelenléte a gyanús, hanem az a kérdés, hogy milyen alkalmazások férhetnek hozzá az oldalhoz, milyen jogosultsággal, és ezek a hozzáférések továbbra is megbízhatók-e.

Ha ezek közül valamelyik kompromittált marad, a WordPress adminisztrátori jelszó megváltoztatása önmagában kevés.

A WordPress hivatalos hardening dokumentációja is külön kezeli többek között a jelszavakat, az FTP/SFTP kapcsolatokat, az adatbázis biztonságát, a fájljogosultságokat, a mentéseket, a naplózást és a monitoringot. Ez jól mutatja, hogy egy WordPress oldal biztonsága nem kizárólag a /wp-admin belépési oldal körül dől el.

A weboldalt kezelő számítógép vagy mentett hozzáférés is érintett lehet

Ezt nem érdemes minden visszatérő fertőzés automatikus okának tekinteni, de lehetséges támadási irányként számolni kell vele.

Érintett lehet például:

• böngészőben tárolt hozzáférés;
• FTP/SFTP kliensben mentett hitelesítési adat;
• fejlesztői gépen tárolt credential;
• ellopott session vagy más hitelesítési adat.

Ha egy ilyen hozzáférés továbbra is használható, a szerveroldali tisztítás nem feltétlenül szünteti meg a problémát.

Ezért visszatérő kompromittálásnál nemcsak azt érdemes megkérdezni, hogy mi található a szerveren, hanem azt is, hogy milyen eszközökről és milyen hitelesítési adatokkal férnek hozzá a rendszerhez.

Ha reális lehetőségként felmerül, hogy az adminisztrációra vagy fejlesztésre használt számítógép is kompromittálódott, ezt a hozzáférések cseréjénél is figyelembe kell venni. Ha minden jelszót és más hitelesítési adatot ugyanabból a potenciálisan érintett környezetből cserélünk le, miközben maga az eszköz továbbra sem tekinthető megbízhatónak, a credentialcsere önmagában nem feltétlenül oldja meg a problémát.

Ez nem jelenti azt, hogy egy visszatérő WordPress-fertőzés mögött automatikusan a weboldalt kezelő számítógépet kell keresni. Ez egy lehetséges vizsgálati irány, amely akkor válik különösen relevánssá, ha más körülmény is utal rá.

Sérülékeny vagy problémás plugin, sablon vagy más komponens maradt a rendszerben

A malware eltávolítása és a kompromittálást lehetővé tevő probléma megszüntetése két külön feladat.

Ha egy kihasználható komponens továbbra is elérhető, akkor hiába távolítod el a korábbi támadás következményeit, ugyanazon vagy hasonló belépési lehetőségen keresztül ismét módosíthatják az oldalt.

Ez nem jelenti azt, hogy minden WordPress-fertőzést egy plugin okoz.

A vizsgálat során a WordPress core, a bővítmények, a sablonok és a környező infrastruktúra állapotát együtt kell értékelni. Nem érdemes előre kiválasztani a bűnöst csak azért, mert egy adott ok gyakori vagy kézenfekvőnek tűnik.

Fertőzött vagy nem bizonyítottan tiszta backup került visszaállításra

A backup fontos része a helyreállításnak, de van egy gyakori félreértés:

egy régebbi backup nem automatikusan tiszta backup.

Tegyük fel, hogy augusztus 10-én észleled a fertőzést, és van egy augusztus 5-i mentésed. Ettől még nem tudod biztosan, hogy augusztus 5-én az oldal tiszta volt. Elképzelhető, hogy a kompromittálás már korábban megtörtént, csak még nem vetted észre.

Az sem tesz egy mentést automatikusan megbízhatóvá, hogy egy automatikus backup rendszer készítette. A mentőrendszer azt az állapotot menti el, amely az adott időpontban létezett. Ha abban már jelen volt egy nem kívánt módosítás, az is bekerülhetett a mentésbe.

A WordPress hardening dokumentációja is olyan mentési stratégiát ír le, amely több időpontból őriz teljes állapotokat. Ennek egyik előnye éppen az, hogy egy később észlelt kompromittálásnál lehet esély kompromittálás előtti állapothoz visszanyúlni.

A backup visszaállítása tehát nem automatikusan egyenlő a fertőzés megszüntetésével. Először azt kell eldönteni, mennyire bízhatunk az adott mentésben.

Miért nem elég frissíteni a WordPresst és a bővítményeket?

A frissítés és a tisztítás két külön problémát kezelhet.

Vegyünk egy leegyszerűsített folyamatot:

1. Van egy sérülékeny komponens a weboldalon.
2. Ezen keresztül megtörténik a kompromittálás.
3. A támadás során nem kívánt módosítás kerül a rendszerbe.
4. Ezután frissíted az eredetileg sérülékeny komponenst.

A frissítés megszüntetheti azt a konkrét sérülékenységet, amelyen keresztül a kompromittálás történt. A korábban létrehozott rosszindulatú fájlt, adatbázis-módosítást vagy jogosulatlan hozzáférést viszont nem feltétlenül távolítja el.

Fordítva ugyanez a probléma.

Ha kitörlöd a malware-t, de változatlanul elérhető marad az a támadási lehetőség, amelyen keresztül bekerült, akkor az oldal ismét kompromittálható.

Ezért a két feladatot külön érdemes kezelni:

Mi került a rendszerbe?

és

Mi tette lehetővé, hogy bekerüljön?

Egyik kérdés megválaszolása sem helyettesíti automatikusan a másikat.

Hogyan deríthető ki, miért tér vissza a fertőzés?

Visszatérő problémánál sokszor nem egy újabb általános malware scan adja a legtöbb információt. Először érdemes pontosan megfigyelni, mi változik, mikor változik és milyen módon változik.

Nézd meg, pontosan mi jelenik meg újra

Nem mindegy, hogy minden alkalommal pontosan ugyanaz történik-e.

Például:

• ugyanaz a fájl jön létre ugyanazon az útvonalon;
• ugyanazon a helyen jelenik meg újra, de más tartalommal;
• mindig más fájl módosul;
• ugyanaz az átirányítás tér vissza;
• új adminisztrátor jelenik meg;
• új spam bejegyzések vagy oldalak keletkeznek.

Ezek önmagukban még nem mondják meg biztosan a kiváltó okot, de segítenek leszűkíteni a vizsgálatot.

Ha például egy konkrét fájl újra létrejön, akkor már nemcsak azt tudjuk, hogy „megint vírusos az oldal”. Van egy pontosan megfigyelhető változásunk, amelynek meg lehet vizsgálni az idejét, tartalmát és környezetét.

Hasonlítsd össze a fájlok változásait

Ha rendelkezésre áll korábbi ismert állapot, verziókövetés vagy megfelelő mentés, érdemes összehasonlítani, pontosan mi változott.

Hasznos információ lehet:

• a fájlok módosítási ideje;
• a fájlok tartalmának változása;
• checksumok;
• verziókövetési előzmények;
• ismert tiszta állapottól való eltérések.

A fájl módosítási ideje diagnosztikai támpont lehet, de önmagában nem bizonyítja, hogy pontosan akkor történt a kompromittálás vagy a jogosulatlan módosítás. Az időbélyeg legitim műveletek, például frissítés, deployment, restore, fájlmásolás vagy más adminisztratív művelet miatt is változhat. Érdemes ezért egy bizonyítékdarabként kezelni, és más információkkal együtt értelmezni.

A WP-CLI a WordPress core fájljait a WordPress.org által biztosított checksumokkal tudja összehasonlítani:

wp core verify-checksums

A hivatalos WP-CLI dokumentáció szerint a parancs az aktuális WordPress-verzió fájljait hasonlítja össze a WordPress.org checksumjaival.

A WordPress.org-ról származó bővítményeknél hasonló ellenőrzés használható:

wp plugin verify-checksums --all

A WP-CLI dokumentációja szerint ez a telepített pluginok fájljait ellenőrzi a WordPress.org checksumjai alapján.

Ezek hasznos eszközök, de nem teljes malware-vizsgálatok. A WordPress saját fejlesztői cikke is felhívja a figyelmet arra, hogy sikeres core checksum-ellenőrzés mellett is lehetnek más rosszindulatú változások, és a WordPress.org-on kívülről származó egyedi vagy prémium bővítményekhez sem feltétlenül érhető el ilyen checksum.

Ellenőrizd a felhasználókat és a hozzáféréseket

A kérdés itt ne csak az legyen, hogy:

„Van-e ismeretlen WordPress admin?”

Érdemes tágabban feltenni:

Ki és milyen módon képes jelenleg módosítani ezt a rendszert?

A környezettől függően vizsgálandó lehet:

• WordPress adminisztrátori hozzáférés;
• aktív WordPress munkamenetek;
• használatban lévő Application Passwords és más programozott hozzáférések;
• hosting fiók;
• SFTP/FTP;
• SSH;
• adatbázis-hozzáférés;
• deployment rendszer;
• kapcsolódó e-mail-fiókok;
• más releváns technikai hozzáférések.

Ha egy kompromittált hozzáférés a tisztítás után is érvényes maradt, azon keresztül ismét módosítható az oldal. Ezért a felülvizsgálatnál nemcsak a jelszavakra, hanem az aktív munkamenetekre és a külön visszavonható alkalmazás-hozzáférésekre is érdemes gondolni.

Vizsgáld meg az adatbázist is

Ha a fájlok rendben lévőnek tűnnek, attól még nem érdemes kizárni az adatbázist.

Meg kell nézni, hogy a visszatérő tünet kapcsolódhat-e adatbázisban tárolt tartalomhoz vagy konfigurációhoz. Ez különösen fontos lehet például injektált tartalom, módosított beállítás vagy jogosulatlan felhasználói adat esetén.

Nem az a cél, hogy minden táblát találomra átnézz. A tünetből érdemes kiindulni, és azt megvizsgálni, milyen adat lehet kapcsolatban vele.

Használd fel a rendelkezésre álló naplókat

A naplók sokat segíthetnek abban, hogy egy fájl módosításának vagy egy jogosulatlan műveletnek a környezetét megértsd.

A rendelkezésre álló infrastruktúrától függően hasznos lehet például:

• webszerver access log;
• error log;
• hosting security log;
• autentikációs napló;
• más releváns alkalmazás- vagy rendszerlog.

Ha tudod, hogy egy fájl kedden 14:32 körül módosult, érdemes megnézni, milyen események történtek az adott időszakban.

A log azonban nem időgép.

Előfordulhat, hogy nincs megfelelő naplózás, túl rövid a megőrzési idő, a releváns esemény már kiesett, vagy az adott log egyszerűen nem tartalmazza azt az információt, amelyre szükség lenne.

A naplókból ezért bizonyítékot és támpontot lehet keresni, de nem érdemes azt ígérni, hogy minden incidens teljes története rekonstruálható belőlük.

A visszatérés időzítése is adhat információt

Nem mindegy, hogy a probléma a tisztítás után azonnal, néhány órával később vagy csak napok múlva jelenik meg ismét.

Érdemes feljegyezni például:

• mikor fejeződött be a tisztítás;
• mikor volt még biztosan megfelelő az oldal;
• mikor észlelted először az új változást;
• történt-e közben frissítés, belépés, deployment vagy más adminisztratív művelet;
• van-e felismerhető ismétlődés.

Az időzítés segíthet abban, hogy merre érdemes tovább vizsgálódni.

Ha például egy módosítás rendszeresen visszatér, érdemes lehet automatizált vagy ütemezett folyamatokat is megvizsgálni. Ha egy adott adminisztratív művelet után jelenik meg, annak környezete lehet érdekes.

Ebből viszont nem szabad túl gyors következtetést levonni.

Az, hogy valami tíz perccel a tisztítás után visszatért, önmagában nem bizonyítja, hogy cron feladat okozta. Az időzítés diagnosztikai támpont, nem automatikus root cause.

Automatizált folyamatok és ütemezett feladatok

WordPressben és a szerverkörnyezetben is működhetnek automatizált folyamatok.

Ilyen lehet például:

• WP-Cron;
• rendszer cron;
• deploymenthez kapcsolódó automatizmus;
• más ütemezett folyamat.

A WordPressben a WP-Cron az ütemezett események kezelésére szolgáló rendszer, a WP-CLI pedig külön parancsokat biztosít a WP-Cron események és ütemezések vizsgálatához és kezeléséhez.

Egy ütemezett feladat létezése természetesen még nem jelent fertőzést. A WordPress és a bővítmények teljesen legitim feladatokra is használnak automatizált folyamatokat.

Visszatérő jogosulatlan módosításnál viszont érdemes ellenőrizni, hogy van-e olyan automatizmus, amely kapcsolatban lehet a változással.

A kérdés ugyanaz, mint a fájloknál: nem az a cél, hogy minden ismeretlennek tűnő elemet töröljünk, hanem hogy megértsük, mi fut, miért fut, és mit módosít.

Mi van, ha nem állapítható meg biztosan a fertőzés eredeti oka?

Ez reális helyzet.

Egy incidens után nem mindig lehet bizonyítani:

• pontosan mikor történt az első kompromittálás;
• melyik sérülékenységet használták;
• melyik hozzáférés került először illetéktelen kézbe;
• milyen sorrendben történtek a módosítások;
• pontosan mit csinált a támadó.

Különösen nehéz a helyzet, ha az esemény óta sok idő telt el, nincs megfelelő naplózás, vagy a releváns logok már nem érhetők el.

Ilyenkor veszélyes lenne csak azért kijelölni egy root cause-t, mert valamelyik magyarázat valószínűnek tűnik.

Ha az eredeti belépési pont nem bizonyítható, akkor a reálisan szóba jövő lehetőségeket kell kezelni. Ez jelentheti a releváns hozzáférések cseréjét és felülvizsgálatát, a problémás komponensek kezelését, az ismert jogosulatlan módosítások eltávolítását, valamint a rendszer további megfigyelését.

A cél ilyenkor nem egy jól hangzó történet rekonstruálása, hanem annak elérése, hogy a jelenlegi rendszerben ne maradjon ismert vagy reálisan feltételezhető út a jogosulatlan módosítások folytatására.

Honnan tudható, hogy most már valóban megszűnt az újrafertőződés?

Nincs egyetlen olyan malware scanner vagy egyszeri ellenőrzés, amely minden helyzetben matematikai bizonyossággal kijelenti, hogy az oldal mostantól biztosan nem fertőződhet vissza.

A bizalom több ellenőrzés eredményéből áll össze.

Jó jel, ha:

• az ismert rosszindulatú vagy jogosulatlan módosítások eltűntek;
• a releváns hozzáféréseket felülvizsgálták és szükség esetén lecserélték vagy visszavonták;
• az ismert sérülékenységeket lezárták;
• a releváns fájlokat és konfigurációkat ellenőrizték;
• az adatbázis is része volt a vizsgálatnak;
• a gyanús automatizált folyamatokat ellenőrizték;
• a rendszer a tisztítás után is megfigyelés alatt marad;
• és nem jelennek meg újabb jogosulatlan változások.

Az, hogy egy bizonyos ideig nem jelenik meg újabb tünet, önmagában még nem bizonyítja, hogy a probléma véglegesen megszűnt. Nem érdemes abból kiindulni, hogy ha néhány napig nem történt látható változás, akkor az oldal biztosan tiszta.

A monitoring akkor ad erősebb megerősítést, ha előtte a feltárt vagy reálisan szóba jövő problémákat is kezelték. Vagyis nem önmagában a tünetmentes időszak a bizonyíték, hanem az, hogy az ismert módosításokat eltávolították, a releváns hozzáféréseket és sérülékenységeket kezelték, a lehetséges mechanizmusokat ellenőrizték, majd ezt követően a megfigyelés sem mutat újabb jogosulatlan változást.

A monitoring ezért nem csak általános biztonsági extra. Visszatérő fertőzés után diagnosztikai szerepe is van.

Ha tudod, milyen fájlokat, hozzáféréseket vagy más változásokat kell figyelni, egy újabb módosításról pontosabb információt szerezhetsz, mint abból, hogy néhány nappal később ismét lefuttatsz egy scannert.

A WordPress hivatalos hardening útmutatója is külön biztonsági területként kezeli a loggingot és a monitoringot.

Mit tegyél, ha a WordPress újra és újra megfertőződik?

Ilyenkor érdemes a gondolkodási sorrendet megváltoztatni:

1. Ne csak az újra megjelenő tünetet töröld.
2. Határozd meg pontosan, mi tér vissza.
3. Vizsgáld meg, hogy a rendszer más részein maradt-e kapcsolódó módosítás.
4. Ellenőrizd a WordPressen belüli és kívüli hozzáféréseket.
5. Vizsgáld meg a lehetséges visszafertőződési mechanizmusokat, köztük az automatizált folyamatokat és a nem tiszta mentéseket.
6. Kezeld a feltárt vagy reálisan szóba jövő belépési lehetőségeket.
7. Figyeld a rendszert a tisztítás után is.

Ez nem helyettesíti magát a helyreállítási folyamatot. Ha az oldal jelenleg kompromittált, a konkrét teendőkről részletesebben a Feltörték a WordPress oldalam: mit tegyek? cikkben írok.

A visszatérő fertőzés vizsgálatánál viszont már nem elég azt megállapítani, hogy „megint van malware”. A lényeg annak megértése, hogyan kerülhetett vissza.

WordPress vírusirtás visszatérő fertőzésnél

Visszatérő fertőzésnél nem az a cél, hogy újra lefusson ugyanaz a scanner, majd ismét kitöröljük ugyanazt a fájlt.

Meg kell próbálni meghatározni:

• pontosan mi tér vissza;
• mi hozhatja létre újra;
• a rendszer mely részei érintettek;
• milyen hozzáférések maradhattak használhatók;
• milyen sérülékenység vagy más támadási lehetőség maradhatott nyitva;
• és hogyan ellenőrizhető a tisztítás után, hogy történik-e újabb jogosulatlan módosítás.

Ha ehhez segítségre van szükséged, a WordPress vírusirtás szolgáltatás keretében ebben is tudok segíteni.

Gyakori kérdések

Miért jön vissza a WordPress vírus törlés után?

Azért, mert a törölt elem lehetett csak a kompromittálás egyik része vagy látható tünete. Maradhatott más rosszindulatú módosítás, továbbra is használható hozzáférés, sérülékeny komponens vagy olyan mechanizmus, amely újra létrehozza a problémát.

A visszatérés önmagában nem bizonyítja, hogy teljesen új támadás történt.

Lehet fertőzött a biztonsági mentésem is?

Igen. Ha a mentés a kompromittálás után készült, már tartalmazhatja annak valamelyik elemét.

A nehézség az, hogy az első észlelés időpontja nem feltétlenül egyezik meg a kompromittálás időpontjával. Ha nem tudod, mikor történt az eredeti behatolás, pusztán a backup dátuma alapján nem mindig dönthető el biztosan, melyik az utolsó tiszta mentés.

Elég minden plugint és a WordPresst frissíteni?

Nem feltétlenül.

A frissítés lezárhat egy ismert sérülékenységet, de nem automatikusan távolítja el azokat a jogosulatlan módosításokat, amelyek a frissítés előtt már bekerültek a rendszerbe.

Fordítva is igaz: a malware eltávolítása nem elég, ha a kompromittálást lehetővé tevő probléma továbbra is jelen van.

Visszatérhet a fertőzés egy kompromittált admin fiók miatt?

Igen, ez az egyik lehetséges ok.

Ha egy jogosulatlan vagy kompromittált adminisztrátori hozzáférés továbbra is használható, azon keresztül ismét módosítható az oldal. Egy ilyen fióknál az aktív munkamenetek és más kapcsolódó hozzáférések kezelése is releváns lehet, nem csak a jelszó megváltoztatása.

Ez azonban csak egy lehetséges magyarázat, ezért visszatérő fertőzésnél a többi hozzáférési pontot és technikai lehetőséget is érdemes vizsgálni.

Miért jelenik meg újra ugyanaz a rosszindulatú fájl?

Lehetséges, hogy egy másik bent maradt kód vagy automatizált folyamat újra létrehozza. Az is elképzelhető, hogy egy továbbra is használható hozzáférésen vagy sérülékenységen keresztül kerül vissza.

Az, hogy ugyanaz a fájl jelenik meg újra, fontos diagnosztikai információ, de a pontos mechanizmust külön vizsgálattal kell meghatározni.

Mit jelent, ha mindig más fájlban jelenik meg a fertőzés?

Ez arra utalhat, hogy nem egyetlen izolált fájl jelenti a teljes problémát.

Önmagában azonban nem bizonyítja, hogy milyen mechanizmus áll mögötte. Érdemes összehasonlítani az érintett fájlokat, a módosítások időpontját és a rendelkezésre álló naplókat, majd ezek alapján keresni a kapcsolatot a változások között.

Honnan lehet tudni, hogy valóban megszűnt az újrafertőződés?

Egyetlen negatív malware scan ehhez nem feltétlenül elegendő, és önmagában az sem bizonyítja a probléma végleges megszűnését, ha egy ideig nem jelenik meg újabb látható tünet.

Nagyobb bizalom akkor alakulhat ki, ha az ismert jogosulatlan módosításokat eltávolították, a releváns hozzáféréseket és sérülékenységeket kezelték, a fájlrendszer mellett az adatbázist és a kapcsolódó mechanizmusokat is ellenőrizték, majd a rendszer megfigyelése során sem jelenik meg újabb jogosulatlan változás.

A cél nem az, hogy újra és újra megtaláljuk és töröljük ugyanazt a tünetet. Azt kell kideríteni, mi teszi lehetővé, hogy a probléma újra létrejöjjön.