A WordPress beépített RSS kliens widgettel rendelkezik, de néha kicsit megbolondul benne a gyorsítótárazás. A cache idejének felülbírálásához a functions.php -hez ( Megjelenés – Szerkesztő – Sablon funkciók functions.php ) kell hozzáadni a következőt:
A minap a segítségem kérték, mert egy szerver spammelt, letiltották és azonosítani kellett a baj forrását. Kiderült, hogy feltörtek rajta egy WordPress blogot, és ezzel elég nagy bajt okoztak, ugyanis a WordPress PHP-ja hozzáfért egyéb könyvtárakhoz is, amiben más PHP oldalak futottak.
Első alkalommal valószínűleg egy kép plugin hibát kihasználva base64-ben kódolva feljutott pár PHP fájl. Általában a szokásos dolgokra voltak kihegyezve:
teljes adatbázis leképezés, amihez a WordPress felhasználója hozzáfér
teljes könyvtárstruktúra leképezés, amihez a WordPress-t futtató PHP hozzáfér
Következő lépésben elrejtett véletlenszerű könyvtárakban PHP fájlokat, amik több funkciót láttak el:
önmagukat terjesztették, mint file proxy
spam leveleket küldtek
webproxy-t hoztak létre
egyéb vicces dolgokat “telepítettek” egykattintásos szolgáltatókon hostolt címekről
A legviccesebb lépése pedig az volt, hogy létező (lehetőleg index.php) PHP fájlok első sorába is elhelyezte magát a 11900. oszloptól! A fájlokba belenézve semmi érdekes nincs. De a grep mégis kidobja, hogy ott van benne az eval, sőt magát a kódot is. Nano-ban vagy mceditben az eval-hoz is ugrik, de belenézve nem látni.
Mi a tanulság? Ha már fröccsöntött motorokat (WordPress, Joomla, Drupal, …) használunk, frissítsünk, amilyen gyakran csak lehet. Igen, ez is WordPress 🙂
Közel 4 óra volt kibelezni a különféle vicces dolgokat művelő PHP-kat a mappákból és még biztosan találni ezt-azt 🙁
Ui.: Most komolyan, mit nem lehet azon érteni, hogy NE HASZNÁLJ eval()-t, soha, semmiben. De főleg abban nem, ami felhasználó által bevihető inputból származik.
Update #2:
Egy kis Joomla hack. Az 1. sor: assets(), a 2. base64_decode() és már ott is az eval 🙁