Feltört weboldal javítása: három eset az elmúlt hónapokból

Az elmúlt hónapokban három feltört WordPress oldalt takarítottam ki. Az egyik egy webshop, a másik egy cég bemutatkozó oldala, a harmadik egy egészségügyi szolgáltatóé. Az ügyfelek nevét nem írom le, a részleteket igen, mert egy feltört weboldal javítása sokkal több munka annál, mint ami kívülről látszik, és a hibák ismétlődnek.

1. Webshop: egy külsős munkatárs ellopott jelszavai

Ami történt: a webshoppal dolgozó külsős marketinges gépén egy kártevő ellopta a böngészőben mentett jelszavakat. Köztük volt a webshop admin-jelszava és a tárhely jelszava is. Két nappal később a támadó bejelentkezett.

Három nap alatt ezt csinálta:

• a WordPress beépített sablonszerkesztőjével egy hátsó ajtót írt a téma egyik fájljába
• egy bővítménnyel adminisztrátori jogot adott két régóta nem használt vásárlói fióknak
• a WordPress saját jQuery-fájlját egy 1,2 MB-os, összezavart kódra cserélte, ami minden látogatónál lefutott, a pénztárban is
• végül egy hamis „Cloudflare-ellenőrzés" oldalt tett ki, amely arra kérte a látogatót, hogy másoljon be és futtasson egy parancsot a saját gépén

A naplók szerint megnézte a felhasználók és a rendelések listáját is, ezért ezt adatvédelmi incidensként kellett kezelni. A GDPR szerint ilyenkor 72 óra van arra, hogy a cég eldöntse, bejelenti-e a hatóságnak.

Amit javítottam: a WordPress magját újra letöltöttem, és fájlonként összevetettem a hivatalos ellenőrzőösszegekkel. A jQuery-fájlnak új verziójelölést adtam, mert a látogatók böngészője a gyorsítótárból még napokig a fertőzött példányt tölthette volna be. Visszaállítottam a két vásárlói fiók jogait, töröltem a támadó bővítményeit és a külsős fiókját, mindenkit kiléptettem, és lecseréltem a WordPress titkos kulcsait (salt). Letiltottam a beépített fájlszerkesztőt. Minden admin és boltkezelő új jelszót kapott, és kötelező lett a kétlépcsős azonosítás. A webshophoz kötött szolgáltatások kulcsait (számlázó, hírlevél, levélküldés) is cseréltük.

A tanulság: a külsős munkatárs még aznap reggel maga is takarított, de csak a téma hátsó ajtaját és a hamis ellenőrző oldalt vette ki. A lecserélt jQuery és a két új admin bent maradt. Egy részleges takarítás után az oldal tisztának látszik, közben a támadó bármikor visszajöhet.

2. Céges oldal: évekig rejtőző kártevő, ami csak a Google-nek mutatta magát

Ami történt: a cég oldala a látogatóknak rendben volt. A Google viszont szerencsejáték-spamet látott rajta, 17 MB-nyi oldalt idegen nyelvű kulcsszavakkal. Ezt cloakingnak hívják: a kártevő megnézi, ki kéri az oldalt, és a keresőrobotnak mást ad, mint az embernek.

Amikor elkezdtem visszafejteni, kiderült:

• az oldalnak két példánya volt két szerveren. A fertőzést egy korábbi költözéskor az oldallal együtt átvitték az új tárhelyre.
• az első nyomok 2023-ból valók. A WordPresst akkor újratelepítették, de a régi mappák (közel ezer PHP-fájl) bent maradtak mellette.
• 2024-től egy kódrészlet-bővítményen keresztül hetente új kódrészlet került az oldalba. Ez végezte az átirányítást és a spamet.
• a bővítmények között 14 hamis galéria-bővítmény volt, véletlenszerű nevekkel. Mindegyik a hivatalos bővítmény pontos másolata volt, plusz egy fájl, ami a hátsó ajtó. Az egyik a levelezés naplóját próbálta olvasni, vagyis e-mail-jelszavakat gyűjtött.
• 2026 januárjában kilencszer lépett be valaki az egyetlen admin fiókkal, váltakozó külföldi IP-címekről. A jelszó tehát kiszivárgott.

Ugyanez a felhasználónév és jelszó a cég testvéroldalán is működött. Ott 17 fertőzött fájlt találtam a webgyökérben, betöltőket, adathalász oldalt és kártevő-letöltéseket.

Amit javítottam: mindent lementettem a szerveren kívülre, mielőtt bármihez nyúltam. A testvéroldalról eltávolítottam a 17 fájlt. A fertőzött oldalon leállítottam a WordPresst, és a webgyökérben letiltottam a PHP futtatását, így ott most semmilyen kód nem tud lefutni, amíg az oldal tisztán újra nem épül.

A tanulság: az újratelepítés nem takarítás, ha a régi fájlok bent maradnak. A cloakingot pedig a tulajdonos soha nem veszi észre, mert ő az ember-változatot látja. Ezt csak úgy lehet kiszűrni, ha valaki rendszeresen a keresőrobot szemével is lekéri az oldalt.

3. Egészségügyi szolgáltató: amikor nem lehet kitakarítani

Ami történt: a kártevő a tárhelyfiók szintjén terjedt, és négy WordPress telepítést fertőzött meg ugyanazon a fiókon. Két takarítás után is percek alatt visszaírta magát.

Amit csináltam: itt a takarítás helyett a tiszta újraépítést választottuk egy új szerveren. A régi szerverről egyetlen fájlt sem vittem át. A témát és a bővítményeket hivatalos forrásból telepítettem újra, az adatbázist pedig kézzel szűrtem.

Az adatbázisban 20 spambejegyzést találtam (felnőtt tartalmú affiliate-linkekkel), egy ismeretlen felhasználó nevén, pár perc alatt tömegesen létrehozva. Ezt a kártevő-szűrés nem fogta ki, mert ezek közönséges bejegyzések voltak. A tárhely vírusellenőrzője közben további álcázott bővítménymappákat talált időbélyeges nevekkel, és egy hamis wp-config.php-t.

A tanulság: a tárhely naplói csak öt nappal a fertőzés utánról voltak meg, így a belépési pont soha nem derül ki pontosan. A tárhelyszolgáltató tapasztalata szerint a leggyakoribb út az elavult bővítmény vagy a kalóz („nulled") prémium téma. Ezek egy részébe szándékosan tesznek hátsó ajtót.

Mi a közös a három esetben?

• Három esetből kettőnél jelszóval jöttek be. Az egyiknél egy külsős böngészőjéből lopták el, a másiknál évekig ugyanaz a jelszó volt két oldalon.
• A támadók sokáig bent maradtak. Napokig, hónapokig, az egyik esetben évekig, mert senki nem nézte rendszeresen, mi változik az oldalon.
• A részleges takarítás nem elég. Egy feltört weboldal javítása a jelszavak cseréjét, a munkamenetek kiléptetését, a titkos kulcsok cseréjét és minden idegen fájl eltávolítását jelenti, az adatbázisban is. Néha az újraépítés a gyorsabb út.

Amit ezekből bevezettem az általam karbantartott oldalakon: minden munkatárs saját fiókot kap, csak a szükséges jogokkal, és a munka végén törlöm. Az adminoknak kötelező a kétlépcsős azonosítás. A beépített fájlszerkesztő ki van kapcsolva. A feltöltési mappában nem futhat PHP.

Ha az oldaladat valaki más készítette, és nem tudod, ki fér hozzá, a weboldal-átvétel első lépése pontosan ennek a feltérképezése. Ha pedig már gyanús jeleket látsz, írj nekem.