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.

Jó tudni!

Vigyázat mélyvíz! Technikai részletek következnek, ha nem érdekelnek a programkódok vagy szerver konfiguráció, akkor olvasd el blogbejegyzésünket!

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.

Jó tudni!

  • A szervereket nem törték fel.
  • A hekker tárhely szolgáltatásokat tört fel úgy, hogy kihasználta az oda telepített program hibáit
  • A fentebbi leírás szándékosan nem tartalmaz konkrétumokat, nem hekker képzést szerettem volna tartani
  • A fentebbi módszer ellen a Tárhelypark szerverei már védettek, minden próbálkozásról naplóbejegyzés készül

 

9 Hozzászólás

  • Joschka Fischer
    Posted 2012. szept. 7. 15:19 0Likes

    Én mondjuk elvárnám, hogy a Softaculous scriptek ne nyissanak biztonsági rést a tárhelyemen…

  • DevDes
    Posted 2012. dec. 30. 10:49 0Likes

    Üdv,
    érdemes azért cp jelszót is most változtatni, mégha nem is joomla/wp oldalt üzemeltetek?

  • Trackback: Hekker támadás Joomla és Wordpress oldalak ellen | Tárhelypark Blog
  • törzsmókus
    Posted 2013. febr. 22. 17:00 0Likes

    softaculousnak nem szólt senki, hogy az upgrade-kor erre is figyeljen… nem írja át a drupal .htaccess fájlját, aztán vakarja az ember a fejét, mitől dob 500ast a frissítés után. persze error logból rájöttem, hogy ugyanaz a probléma, mint decemberben; de ezt minden frissítésnél el kell játszani majd? 🙁

  • törzsmókus
    Posted 2013. márc. 8. 09:17 0Likes

    és még mindig :-/

  • Péter
    Posted 2013. márc. 8. 10:58 0Likes
  • Péter
    Posted 2013. márc. 8. 11:00 0Likes

    Szia!

    Ha az oldalad nem törték fel, akkor nem kell változtatnod. A cpanel jelszavakhoz nem fértek hozzá, csak a tárhelyeken tárolt konfigurációs fájlokhoz, pl. configuration.php.

  • Tamás
    Posted 2014. júl. 4. 07:03 0Likes

    Szia Péter!

    Itt a cikkben a Joomla configuration.php helyes beállításaként 600-at írsz, kollégád egy másikban 440-et ír (http://help.tarhelypark.hu/tarhely/joomla-wordpress-biztonsag/.
    Melyik a jó?
    Másik kérdésem:
    FTP-n beállítom 440-re, de vissza ugrig 640-re a beállítás mentés után. A 600-at elfogadja. Ennek mi lehet az oka?

  • Péter
    Posted 2014. nov. 18. 11:25 0Likes

    Szia!

    Elnézést, ez a hozzászólás elkerülte eddig a figyelmem. Mind a két beállítás jó. A 440 eredménye, hogy a fájlt csak olvasni lehet, így senki, még a tulajdonosa sem tudja írni, a 600 azért enged írást. a lényeg, hogy a ‘nem azonosított’ felhasználók a fájlt nem írhatják és olvashatják egyik esetben sem. Ez a három számjegyből a jobb oldali. Részletes leírást a jogosultságokról itt találtam: http://hu.wikipedia.org/wiki/Chmod

    Az FTP szervert úgy állítottuk be, hogy javítsa a fájlok jogosultságait, ezért nem tudsz mindent beállítani vele. Mivel azonban a jogok nem csak FTP-vel állíthatók, ezért kell odafigyelni a kritikus fájlokra külön.

Ehhez nem lehet hozzászólni.

Kövess minket!