Apache symlink hack WordPress és Joomla ellen

Megírtuk már a blogunkban, hogy egyik szerverünkön több Joomla és WordPress alapú oldalt is feltört egy (vagy több hekker). De hogyan történhetett ez? Hogy lehetséges, hogy hozzáfértek az oldalak jelszavaihoz, és megváltoztatták a template fájlokat? A teljes történet megértéséhez kezdjük egy kis háttérinformációval.

A korlátlan tárhelynek ára van

Szolgáltatásainkkal szeretnénk megrendelőinket maximálisan kiszolgálni, ezért a tárhely szolgáltatásaink kidolgozásakor úgy döntöttünk, hogy a lehető legkevesebb akadályt gördítjük a fejlesztők elé, és mindent engedélyezünk a szerver konfigurációs fájlokban. Azt nagyon gyorsan az indulás után beláttuk, hogy nem működőképes a dolog. A rengeteg biztonsági rés és az okos hekker toolok pillanatok alatt kiszúrják az ilyen szervereket. Így a beállításokat folyamatosan optimalizáljuk, hogy a nyílt forráskódú platformok könnyedén telepíthetők legyenek, és általában mindenkinek megfeleljenek a szerverek, de biztonságosak maradjanak. Számos programot, toolt és tűzfalat használunk, hogy kiderüljenek a biztonsági rések, és megfogjuk az esetleges illegális tevékenységet.

Mire gondoltunk először?

Természetesen arra, hogy a feltörést az oldalakon keresztül követték el, és minden feltört oldalban van valami közös, például, hogy régi verziók, vagy egy sebezhető plugin vagy template van rájuk telepítve.

Ez a feltételezés részben igaz volt. Rengeteg megrendelőnk használ 2009-es Joomlát vagy  a hekker iskola első napján kötelező oktatási anyagként szereplő timthumb.php-t. Ez úton is felhívom mindenki figyelmét a folyamatos frissítésre, amiben segít az adminisztrátori felületen levő telepítő azzal is, hogy figyelmeztetést küld az új verziókról!

Sajnos azonban észrevettük, hogy ez nem minden oldalra igaz. Tehát az oldalakat úgy törték fel, fértek hozzá a jelszavakhoz és deface-elték, hogy voltak köztük friss telepítések is.

A felhasználók jogai a szerveren

Egyik biztonsági megoldás például, hogy a szervereken levő PHP programok minden esetben az operációs rendszerben létrehozott felhasználó nevében futnak. Tehát mindenkinek a szerveren van saját valódi felhasználója, és ezek a felhasználók nem férnek  hozzá a másik felhasználók könyvtáraihoz, mert a PHP-t futtató kód ezt megakadályozza. Tehát a domainA felhasználó nem tudja futtatni a /home/domainB könyvtárban levő dolgokat, csak a /home/domainA-t.

DomainA egyáltalán nem férhet hozzá a DomainB könyvtárában levő wp-config.php (wordpress) vagy configuration.php (Joomla) fájlokhoz, mert a PHP futtató ezt megakadályozza.

Apache symlink trükk

Ahhoz, hogy hozzáférjünk a szerveren a felhasználók WordPress és Joomla jelszavaihoz, először fel kell törni egy régebbi rendszert, hogy hozzáférésünk legyen egy tárhelyhez. Erre tökéletesen megfelel például egy 2009-es Joomla, aminek a könyvtárait telipakolhatjuk a saját fájljainkkal, és utána futtathatjuk is azokat. (A feltörés pontos módját azt hiszem érthető okoknál fogva nem írom le.)

Tehát már tudunk mindenféle PHP parancsot futtatni a szerveren, de csak domainA felhasználó nevében, és nem férünk hozzá domainB felhasználó fájljaihoz, mert a PHP futtató ezt megakadályozza.

Azonban ha az egyik kis okos programunkkal készítünk egy symlinket domainB felhasználó könyvtárára, és .htaccess fájlban azt mondjuk, hogy a PHP fájlokat ne a PHP futtató hajtsa végre, hanem az Apache web szerver kezelje a PHP kiterjesztésű fájlokat szövegfájlként, domainB könyvtárából olvasni tudjuk a PHP fájlokat abban az esetben ha azok jogosultságai ezt lehetővé teszik, például az adatbázis hozzáféréseket tartalmazó konfigurációs fájlokat.

Ha már megvannak ezek a jelszavak, akkor az adatbázisokban könnyedén módosíthatjuk az admin jelszavakat, és mindent amit csak akarunk. Aztán az admin jelszóval bejelentkezve a felületre Joomla és WordPress esetében is lehetőségünk van a téma megváltoztatására, így könnyedén módosíthatjuk azt.

Megoldás symlink feltörés ellen

Első körben az Apache szervereket beállítottuk, hogy ne kövessék a szimbolikus linkeket, szigorítva az első részben írt „korlátlanságon”. Ezt az Options beállítás teszi lehetővé. Ettől a beállítástól a Joomla oldalak kiakadtak, számomra érthetetlen oknál fogva a Joomlának szüksége van a szimbolikus linkekre. Szóval gyorsan visszaállítottuk az eredeti beállítást.

Szerencsére van megoldás, mégpedig szintén az Options beállításnál a SymLinksIfOwnerMatch. Ez akkor teszi lehetővé a szimbolikus linkek követését, ha annak tulajdonosa egyezik a programot futtató felhasználóval. Így más könyvtárába nem lát bele az Apache processz.

Mit tehet a tárhely tulajdonos

A fentebbinél egyszerűbb megoldás, ha mindenki odafigyel rá, hogy a szenzitív fájlok ne legyen olvashatók az egész világnak. Tehát mindenképp be kell állítani a konfigurációs fájlok jogosultságát 600-ra, hiszen pl. 644 azt jelenti, hogy a fájl bárki, például a szerver többi felhasználója számára is olvasható. Ezt a beállítást most egy szkripttel el is végeztünk az oldalakon, de természetesen egy új telepítésnél mindenkinek magának kell beállítania.

Természetesen azoknak a fájloknak a jogait melyeket a böngésző felhasználók láthatnak (például index.php vagy képek) nem szabad átállítani, csakúgy mint a publikus mappa jogait, mert az oldal elérhetetlenné válik.