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?
- 3312 megtekintés
Hozzászólások
php.ini -ből a disable_functions= részt kérnénk
// Happy debugging, suckers
#define true (rand() > 10)
- A hozzászóláshoz be kell jelentkezni
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"
- A hozzászóláshoz be kell jelentkezni
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+…
- A hozzászóláshoz be kell jelentkezni
nem. :(
- A hozzászóláshoz be kell jelentkezni
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á?
- A hozzászóláshoz be kell jelentkezni
Mert amúgy nem megy a wordpress-en az update button. :P
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Miért nem eleve csak whitelist-elt IP-k 80-as és 443 portjai érhetőek el?
- A hozzászóláshoz be kell jelentkezni
?
- A hozzászóláshoz be kell jelentkezni
Jó de, hogy cseréli le a wordpress a saját állományait, ha nem tud írni oda ahol van? ;)
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Milyen PHP verzió? Ha ősrégi lehet ez.
- A hozzászóláshoz be kell jelentkezni
5.3.2
- A hozzászóláshoz be kell jelentkezni
(Valamivel kevesebb az 5.6.23-nál, ami most az aktuális.)
- A hozzászóláshoz be kell jelentkezni
(Az aktuális a 7.0)
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Ha ilyen egyszerű lenne: Current Stable PHP 5.6.23 & Current Stable PHP 7.0.8, http://php.net/supported-versions.php
- A hozzászóláshoz be kell jelentkezni
Hmm....
- A hozzászóláshoz be kell jelentkezni
É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?
- A hozzászóláshoz be kell jelentkezni
Ezt olvasgasd át, és próbáld végig:
http://www.justanotherhacker.com/projects/htshells/index.html
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
A médiafeltöltések miatt nem korlátozható, hogy publikus területre ne lehessen feltölteni.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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ő.
- A hozzászóláshoz be kell jelentkezni
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ű.
- A hozzászóláshoz be kell jelentkezni
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!
- A hozzászóláshoz be kell jelentkezni
+1 az apparmorra
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
exec('ln -s valami /valami');
- A hozzászóláshoz be kell jelentkezni
Bocs, kimaradt, hogy a szerveroldali parancsfuttatás tiltva.
- A hozzászóláshoz be kell jelentkezni
Mondjuk az ilyen problémákra nem lenne jó valamilyen verziókövetős filerendszer?
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
'milyen eszközöket használhattak még?'
Pl.: úgy tűnik a kliensről került fel.
- A hozzászóláshoz be kell jelentkezni
Teljes körű ssh hozzáférés nincs. A logok alapján PHP kérelmek zajlottak végig, azokon keresztül hatolt be.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni