Életveszélyes WordPress SEO spamek, amik kinyírhatják a helyezéseidet

Néha eltűnödöm azon, hogy inkább kapálni kéne menni, és jó messzire elkerülni minden, informatikával kapcsolatos dolgot.

Szóval igen, megint sikerült bekapni egy ultrajó kis fertőzést az egyik WordPress alapú blogomon – olyat, amivel simán ki lehet nyírni egy honlap organikus keresőforgalmát. Bár WP-t emlegetek, tartok tőle, hogy ezek a típusú hackek minden népszerűbb CMS-re – Joomla, Drupal pl. – működnek.

Mit is csinálnak ezek genyaságok?

Láthatatlan linkekkel rakják tele az oldaladat, a legtöbb esetben Viagra, Cialis, és hasonló barátságos kulcsszavakkal linkelnek mindenféle spamoldalra. És nem szívbajosak, 50-100 db. szemét linket gond nélkül beszúrnak.

Az a kisebbik gond, hogy ezzel szépen elfolyatják a lapok PageRankjeit. A nagyobbik gond az, hogy rossz szomszédságba keveredsz, hiszen a Te lapod fog spam oldalakra linkelni, ami büntetést von maga után. Ráadásul olyan illegális SEO technikákat használsz, amik önmagukban is büntetést vonnak maguk után – lekerülsz a Google találati oldalairól.

Az elmúlt években kétféle technikába futottam bele WordPress alapú oldalon, amik ezt okozták: van egy egyszerűbb és egy jóval veszélyesebb, nehezebben felderíthető változat.

A láthatatlan footer linktár

Ez az egyszerűbb, a támadó átírja a template-ed könyvtárában található footer.php filet. Sajnos akkor is képes erre, ha amúgy a template fileokra nincsen írási jog. Erről egyébként már írtam korábban is, a módszer azóta sem változott. Amellett, hogy érdemes rendszeresen utánaolvasgatni annak, hogyan lehet a WP-t biztonságosabbá tenni, illetve meg is fogadni a tanácsokat, van még egy lehetőség ennek kivédésére: a wp-includes/general-template.php file átírása. Konkrétan rá kell keresni ebben a fileban a footer.php kifejezésre, és azt átírni akarmicsoda.php-ra – ekkor a template saját könyvtárában NEM a footer.php-ből akarja előállítani a blog footerét, hanem az akarmicsoda.php-ből (nyilván ehhez a footer.php-t át kell nevezni). A WordPress frissítésekor általában újra bele kell nyúlni a general-template.php-ba, viszont a footer.php hiányában a támadó nem tudja átírni a footert.

Ezt a típusú átírást könnyű lebuktatni – napi szinten ránézve az oldal forráskódjára azonnal kiszúrható, ha kedves barátaink láthatatlan linkeket szúrtak be, elég rákeresni a legnépszerűbb spam kulcsszavakra, mint a viagra, vagy esetleg a display:none kifejezésre.

Cloaking hack

Nah, ez a veszélyesebb, mert simán a HTML kódod napi ellenőrzésével nem fogod tudni kiszűrni a dolgot. Egyrészt, a spammerek is rájöttek, hogy a footerlink már nem menő, a Google szemében alig-alig ér valamit a dolog, ellenben a valós tartalomban elhelyezett linkekkel. Plusz a footeres hacket a fentiek alapján baromi könnyű kiszúrni, és megtenni a megfelelő lépéseket.

Ennek eredményeképp létrejött egy sokkal gonoszabb metódus, aminek ráadásul több alfaja is van.

A lényege, hogy nem pusztán láthatatlan linkeket, hanem viszonylag nagyobb terjedelmű, linkekkel telepakolt szöveget rak be, és nem a footerbe, hanem a content részbe, általában a blogpostok elé. Ráadásul a HTML kódot megtekintve nem is látod ezt a szöveget – ugyanis a szintén büntetést maga után vonó cloacking módszerével él. Azaz, ez a tartalom mindenki elől rejtve marad, felhasználó és tulajdonos előtt is – csak és kizárólag a Google botot eteti vele. A kiszúráshoz az sem elég, ha az ember a böngészőjét átállítja, hogy user agentnek Googlebotot adjon – mert nem user agent alapján dönt a hack, hanem a Google IP címeire szűrve mutatja a szemetét.

Ennek lebuktatására egyetlen egy biztos módszert tudok: egy Google Webmaster Tools regisztrációt. Valamint napi ellenőrzést. Amikor a főoldalon a legfontosabb kulcsszavak listájában viagra, cialis és hasonló szavakat látsz, akkor már érdemes parázni, hogy feltörték a lapodat. A gyanút minden kétséget kizáróan a Diagnosztika menüpont alatt található Megtekintés Googlebotként opció igazolhatja vagy cáfolhatja – ekkor ugyanis pontosan azt a HTML kódot fogod látni, amit a Google is lát.

Ha sikerült bekapni egy ilyen fertőzést, akkor sajnos ennek elhárítása sokkal nagyobb macera, mint a fenti footeres móka, ugyanis ennek a metódusnak létezik több alfaja is.

Elképzelhető, hogy valamelyik népszerűbb plugin biztonsági rését használják ki – pl. Facebook like gombok eléggé népszerűek minden blogon.

De a core WordPress fileok is felülírásra kerülhettek.

Egy igen kifinomult metódus pedig azt csinálja, hogy egy random plugin könyvtárba írja bele magát, valamint az adatbázishoz is hozzáír pár sort a wp_options táblában. Ráadásul, ha hihetünk a linkelt postnak, nem érinti az összes lapot – hanem csak azokat, amik a legtöbb keresőforgalmat kapják. Mint írja, egyébként ezek a lapok kapták a legtöbb PPC bevételt is a fertőzés ideje alatt – értelemszerűen a legjobban spamelt kulcsszavak jó bevételt is hoznak. Hasonló tapasztalatom nekem is volt egyébként: iszonyatos mértékben megszaporodtak a Viagra hirdetések az AdSense helyeken, ami utólag visszanézve egy újabb figyelmeztető jel.

Ktamás adta az ötletet, hogy a letöltött mentést az Ultraedit keresőfunkciójával nézzem át, eval-ra és base64-re keressek vele – ezzel sikerült találni néhány gyanús plugint, amit gyorsan le is töröltem, majd a Webmaster Toolsban csekkolva a probléma meg is szűnt. Ezzel a metódussal az a probléma, hogy teljesen normális wp-fileokban is vannak evalok és base64-ek. Esetleges megoldás lehet az, hogy az ember egyenként kikapcsolgatja a plugineket, és minden egyes alkalommal ellenőrzi az oldalt a Webmaster Toolsban.

A legtisztább megoldás továbbra is a fileok teljes lecserélése: egy “tiszta” WordPress, valamint pluginek és template-ek letöltése, és a szerveren található fileok felülírása. Emellett az adatbázis ellenőrzése, különös tekintettel a wp_options táblára nézve: egy keresés az rss% kifejezésre a PHPmyadminban előhozhat egy olyan találatot, ahol a mező értéke egy kódolt javascript – lásd egy hasonlóan rosszul járt illető bejegyzését. Valamint az ilyen spammerek felkutatása és felnégyelése a CNN élő egyenes adásában.

És ha ezzel megvagyunk, akkor végigmenni a beállításokon, az FTP-n és mindenen, hogy tényleg eléggé biztonságos-e a WordPressünk. Ha ezzel is megvagyunk, akkor keressünk egy spammert, és vessük máglyára a CNN élő egyenes adásában.

Ekkor nem maradt más hátra, mint rendszeresen ellenőrizni az oldalunkat a Google Webmaster Toolsban (a GWT a barátod, látogasd rendszeresen!), és rendszeresen update-elni az összes plugint és persze magát a WordPresst is. A biztonsági frissítéseket ünnepeljük egy spammer kerékbetörésével, élő egyenes adásban a CNN-en. És juszt se megyek kapálni, maradok az online marketingnél.

No related posts.

5 Responses to “Életveszélyes WordPress SEO spamek, amik kinyírhatják a helyezéseidet”

1. Szabó Gábor szerint:

   2011. február 14. hétfő 12:01-kor

   Én ezt is szoktam használni linkellenőrzésre: http://home.snafu.de/tilman/xenulink.html
   Főleg nagyobb oldalaknál hasznos.
2. Tommey szerint:

   2011. február 14. hétfő 18:53-kor

   Sziasztok!

   Az említett megoldásokkal kapcsolatban az a probléma, hogy ehhez emberi beavatkozás kell és ha több 10-100-1000 WP-vel dolgozol, akkor egy idő után az egész napod rá fog menni az ellenőrzésre.

   Amik eszembe jutottak:
   - a blogot saját gépen fejleszteném, a fájlokat mindig itt frissíteném újabb verzióra, így mindig meg lenne a tiszta verzió, amit bármikor fel lehet tölteni a helyére
   - a feltöltés után csinálnék minden fájlból csinálnék egy sha1 hash-t, a végén összefűzném és ebből is csinálnék egy sha1 hash-t, így meg lenne az ellenőrző kód, amit akár óránként lehetne vizsgálni ugyanezzel az algoritmussal, mindig kiszámolni a hash-eket, abból a közöst és ha az nem egyezik a feltöltéskorival, akkor gáz van
   - az adatbázis már problémásabb, de azt is lehet dumpolni, így 1 darab szövegként megkaphatjuk az egészet és a nem változó táblákat ugyanúgy hash-ellenőrzést használva lehetne ellenőrizni, a dinamikus táblákban pedig lehet a javascriptet vadászni vagy ami még előfordulhat
   - adatbázist egyébként is javasolt legalább naponta menteni, ha pedig úgyis meg van a mentés, akkor: könnyű visszaállítani, lehet benne keresni

   Nekünk más CMS-nél jött elő ilyen probléma, azt FTP-t törték fel, illetve lehet, hogy a szervert is, de a szolgáltató nem kötötte az orrunkra:
   - erős jelszót kell használni, lehetőleg random karakterek és jó hosszút, pl. KeePass nevű program segít
   - a php fájlokba kerültek be plusz html tartalmak, ez ellen lehet egy kis trükköt csinálni: egyszerűen le kell hagyni a záró php tagot vagy ha nem php-val végződik, akkor tenni kell a végére egy nyitó php tagot, ha ez után kerül be html/javascript kód, akkor a php értelmező hibát fog rá dobni – ekkor az oldal ugyan nem fog megjelenni, de a gonosz tartalom sem (persze ezt általánosságban megcsinálni macera, de egy footer.php-t elég módosítani, ha tudjuk, hogy oda várható)

   Üdv,
   Tommey
3. Nu7ec szerint:

   2011. február 15. kedd 12:19-kor

   Csak megerősítésként írom, én is találkoztam már joomla alapú oldalnál is a footer linktáras változattal.

   Az oldal tulajdonosa megkeresett, hogy újabban csak vánszorognak a webhely oldalai.
   Nem is csodáltam 1300-1500KByte-os letöltési méretnél.
   Ebből 1100 volt csak a html szerkezet, több ezer potencianövelő linkkel a láblécben.

   Megoldást azért nem tudok írni, mert a hiba felderítése után a kijavítására nem kaptam megbízást, az oldal azóta is ugyanúgy áll.
   Bár a f.név – jelszó páros erejéből következtetve gyanítom hol lehetett a
   gyenge pont.

   Üdv,
   Schumacher Zsolt
4. Linkekről | SeSam.hu szerint:

   2011. február 24. csütörtök 13:37-kor

   [...] Merras/Jun írt egy roppant érdekes cikket olyan hackekről, amikor a támadók a WordPress kódba helyeznek el nemkívánt linkgyűjteményt, nem mellesleg kinyírva ezzel az oldal keresőkben elért helyezését. [...]
5. Andrea szerint:

   2011. február 24. csütörtök 16:52-kor

   Én úgy jártam,hogy egyik tárhelyemen az összes wp alapú oldal bekapott ilyet. A linkek kizárólag a bejegyzésekbe kerültek be.
   Ami érdekes, hogy a wp szerkesztőjében a bejegyzésből hiába vettem ki, az adatbázisban megmaradt. Csak az adatbázisban átírással tudtam kipucolni azon a 3 oldalon ahol kellett, a többihez szerencsére volt aktuális sql mentés a gépemen. 2-3 órát így is szívtam vele…
   Tanulság, nem árt időnként egy sql mentést a gépünkre pakolni