WordPress RSS plugin cache felülbírálása

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:

add_filter( ‘wp_feed_cache_transient_lifetime’, create_function(‘$a’, ‘return 600;’) );

Forrás: https://stackoverflow.com/questions/22504076/how-can-i-stop-wordpress-from-returning-a-cached-rss-feed

 

2018.02.11. 18:22 - legyes

WordPress érdekesség, avagy miért nem jó ötlet fröccsöntött rendszereket használni

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.

  1. 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
  2. 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
  3. 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.wordpress_hack2
    find . -name "*.php" -exec grep -H "eval" {} \; | more

    wordpress_hack

 

Update #1:

Közben találtam még egy finomságot:

wordpress_hack3

 

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 :(
Egy kis Joomla hack. Az 1. sor: assets(), a 2. base64_decode() és már ott is az eval 🙁

Kis olvasnivaló: https://www.exploit-db.com/exploits/17602/ és https://forums.digitalpoint.com/threads/wp-hack.2734636/ és https://jordankueh.com/2014/wordpress-remote-code-execution-base64_decode/ és https://jordankueh.com/2014/wordpress-remote-code-execution-base64_decode/ és http://msurowiecki.pl/index.php/inne/106-wordpress-under-attack-april-2013-tips-to-remove-spyware

2016.03.26. 17:38 - legyes