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"
Nem volt selinux bekapcsolva mi? :D
Amugy ezek szerint millio modon megtortenhetett.
https://books.google.hu/books?id=9469BwAAQBAJ&pg=PP1&dq=web+security+a+…
nem. :(
Röviden: miért van jogosultsága a PHP-nak fájlokat írni a wwwroot alá?
Mert amúgy nem megy a wordpress-en az update button. :P
Azt kultúráltan úgy intézik, hogy update előtt egy script tűzfalon tilt minden forgalmat egy adott IP kivételével, majd átállítja a jogosultságokat. Update után pedig fordítva.
Miért nem eleve csak whitelist-elt IP-k 80-as és 443 portjai érhetőek el?
?
Jó de, hogy cseréli le a wordpress a saját állományait, ha nem tud írni oda ahol van? ;)
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.
Ha a wwwroot alatt a DocumentRoot mappáját érted, akkor kell, hogy tudjon azon kívül írni a php. A php által írt logok például ezen kívül kerülnek létrehozásra.
A DocumentRoot-ba pedig az assets funkciók és a médiafeltöltések miatt kell tudnia írni.
Milyen PHP verzió? Ha ősrégi lehet ez.
5.3.2
(Valamivel kevesebb az 5.6.23-nál, ami most az aktuális.)
(Az aktuális a 7.0)
meg a másik is, és vélhetően NT azért írta azt, mert az még közelebb is van verzióban, mint a 7-es ági php.
Ha ilyen egyszerű lenne: Current Stable PHP 5.6.23 & Current Stable PHP 7.0.8, http://php.net/supported-versions.php
Hmm....
É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?
Ezt olvasgasd át, és próbáld végig:
http://www.justanotherhacker.com/projects/htshells/index.html
Illetve rögtön egy kérdés: amikor file feltöltés történik, az miért történhet olyan könyvtárba, amit aztán direktbe be enged
hivatkozni? (ezért tudnak php fileokat feltölteni és végrehajtani, illetve .htaccess file-okat feltölteni és végrehajtani)
A médiafeltöltések miatt nem korlátozható, hogy publikus területre ne lehessen feltölteni.
Azt viszont tudod korlatozni, hogy a feltoltes konyvtarba irt PHP fajlok vegrehajthatoak legyenek.
--
Pásztor János
Sole Proprietor @ Opsbears
Development Lead @ IXOLIT
Refaktor Magazin
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ő.
Természetesen nem telnet protokollon keresztül, hanem weben keresztül, csak a hacker script is telnetnek nevezi magát. Igazából csak tetszőleges parancsot tudott lefuttatni, ami azért eléggé telnet szerű.
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!
+1 az apparmorra
Nem WP. Most egy Joomla olda volt utoljára, de előtte egy egyedi készítésű oldalt törtek fel. Nekem szerver szinten kell tudnom megállítani, függetlenül a konkrét PHP kódtól.
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
+1
+1
exec('ln -s valami /valami');
Bocs, kimaradt, hogy a szerveroldali parancsfuttatás tiltva.
Mondjuk az ilyen problémákra nem lenne jó valamilyen verziókövetős filerendszer?
Ez költői kérdés, vagy van ilyen fájlrendszer? Ha igen, érdekelne, és az is, mennyire terheli ez a tárterületet?
Volt régen olyan, hogy wayback, vagy nilfs, illetve mintha a zfs-nek is lenne ilyen változata. Nem tudom,
hogy milyen gyakran változik az ügyfelek könyvtára, de ha jórészt php fileok vannak, és adatbázisba írnak,
akkor lehet, hogy valami ilyen megoldás jó lenne.
'milyen eszközöket használhattak még?'
Pl.: úgy tűnik a kliensről került fel.
Teljes körű ssh hozzáférés nincs. A logok alapján PHP kérelmek zajlottak végig, azokon keresztül hatolt be.
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