Feltört weboldal, de hogyan?

Egy ügyfelünk weboldalát feltörték, de sajnos nem tudok rájönni, hogyan. Saját PHP kódot futtatva olyan symlinket hoztak létre, ami kimutat az open_basedir korlátozásból.A környezet egy egy LAMP szerver, mpm_itk apache modullal.
Minden domain saját userrel rendelkezik, és saját elkülönített mappába vannak az adataik.
A PHP open_basedir korlátozás erre a mappára van állítva. A PHP modul módban fut.
A betörés alkalmával feljuttattak a feltört tárterületre egy 'insta!l.php' fájlt, majd ennek segítségével további fájlokat. Ezt a fájlt később törölték, így a tartalmát nem ismerem.

A PHP symlink parancsa nem tud az open_basedir korlátozáson kívülre symlinket létrehozni. Akkor hogyan lehetséges egy ilyen symlink létrehozása ilyen korlátok mellett?

A feltörés alkalmával csak ilyen PHP eszközöket használtak, és úgy tűnik, a létező PHP korlátozások meg is fogták a tevékenységet, tehát nem valószínű, hogy a rendszert is feltörték volna. A tevékenység egy részének a naplói is megvannak, és azok is azt mutatják, hogy csak php eszközöket használtak.

- Tudja valaki, hogyan lehet PHP alól (modul módban) olyan symlinket létehozni, ami kimtat a basedir korlátozásból?
- Ismeri valaki ennek az 'insta!l.php' fájlnak a tartalmát? Netán meg tudja velem osztani, hogy tudjam, milyen eszközöket használhattak még?

Hozzászólások

php.ini -ből a disable_functions= részt kérnénk

// Happy debugging, suckers
#define true (rand() > 10)

Elnézést, ez kimaradt:

disable_functions = "apache_child_terminate,apache_setenv,define_syslog_variables,dl,escapeshellarg,escapeshellcmd,exec,highlight_file,ini_alter,ini_restore,openlog,passthru,popen,pclose,posix_getpwnam,posix_getpwuid,posix_kill,posix_mkfifo,posix_setpgid,posix_setgid,posix_setsid,posix_setuid,proc_close,proc_get_status,proc_nice,proc_open,proc_terminate,shell_exec,show_source,syslog,system,virtual"

Egy ügyfelünk weboldalát feltörték, de sajnos nem tudok rájönni, hogyan. Saját PHP kódot futtatva olyan symlinket hoztak létre, ami kimutat az open_basedir korlátozásból.

Röviden: miért van jogosultsága a PHP-nak fájlokat írni a wwwroot alá?

Ezt teszi lehetővé a script.

Amikor fut a wp, akkor a jogai alapban root:www-data és 640/750. Frissítés előtt lefuttatod a script-et, ami először tűzfalon szűri a 80/443 portot a te IP-d kivételével, majd a pl. a tulajt átbillenti www-data:www-data-ra, vagy a jogokat nyeszteti.
Ezután lefut a frissítés, majd ugyanezt visszacsinálja, esetleg még a kóbor jogosultságokat is helyreteszi (ne legyen már 777 könyvtár valahol, vagy ilyesmi), aztán visszaállítja az eredeti fw szabályt.

Érdekes ez az exploit.
A biztonság kedvéért a symlink is a tiltott függvények listájába került, de ennek ellenére újra betörtek, de legalább így már több nyom maradt:
Feltöltöttek egy .htaccess fájlt, amiben AddType és AddHandler segítségével beállították, hogy perl cgi scriptként fusson egy feltöltött cgi.sa fájl. Ezzel pedig egy távoli telnetet hoztak létre.
Az apache AllowOverride FileInfo engedélyezi a .htaccess-ben az AddType és AddHandler használatát. Ugyanez engedélyezi a mor_rewrite használatát is, emiatt szükséges.
Az Options -ExecCgi paraméterrel blokkoltam ugyan az ilyen cgi-s betörési lehetőséget, de úgy érzem, ez messze nem teljes megoldás!
Tudja valaki, hogyan lehetne tiltani az AddType és AddHandler használatát úgy, hogy a mod_rewrite használható maradjon?

Távoli telnetet? Javaslom, hogy úgy konfiguráld a tűzfalat a szerveren, hogy kifele csak egy whitelist-en levő IP-k irányába (és portokra) tudjon csak kommunikálni (tehát például wordpress update-hez csak az ehhez szükséges weboldalak 80-as portjára mehessen ki). Iptables + ipset kombó ilyenkor jól jöhet: az ipset-tel létrehozol egy ip tartomány set-et (pl: out_http), amibe egy időzített szkripttel bedobálod az adott domain-hez tartozó IP címeket. A set engedélyezéséhez egyetlen iptables szabály elegendő.

ha ugyis tudod hogy ez egy WP, akkor a mod_rewrite mokat tedd be az apache configba, htaccess tiltasa.
jah es apparmor module van apachehoz, azzal szepen minden hostot be lehet "zarni", nem tokeletes megoldas, de ez is egy vedelmi vonal a tobbivel egyutt (tuzfal, stb)

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Tok mindegy. Ha a fenti 5.3-as PHP verzio figyel a szervereden es open_basedir-re alapul a biztonsagod, akkor komoly problemaid vannak. Az ITK javit rajta valamennyit, de mivel nincs chroot, AppArmor, stb. es a PHP verziod ismert remote exploitokkal rendelkezik, a benne futo szoftver szinte mindegy. Egy mersekelten ugyes tamado barmikor tud azon a gepen shellt inditani, a WP vagy Joomla maximum segit, ha nincs frissitve.

Nagyon leegyszerusitve: neked olyan biztonsagi megoldasokra vannak szukseged, amik a PHP-n KIVUL vannak hogy megvedjen a PHP sajat bugjaival szemben, kulonosen ha ilyen osregi verziot vagy kenytelen futtatni. A PHP-n BELULI vedelem csak akkor hasznal valamit, ha rendszeresen frissitesz, es akkor is csak modjaval.

--
Pásztor János
Sole Proprietor @ Opsbears
Development Lead @ IXOLIT
Refaktor Magazin

Mondjuk az ilyen problémákra nem lenne jó valamilyen verziókövetős filerendszer?

FYI az open_basedir koncepcionálisan hibás, és ez több helyen dokumentálva is van. Ha normális biztonságot akarsz, akkor AppArmorral korlátozd be a PHP-t (ha ilyet lehet az ITK-ban), vagy állj át PHP-FPM + chroot kombóra.

--
Pásztor János
Sole Proprietor @ Opsbears
Development Lead @ IXOLIT
Refaktor Magazin