Sziasztok,
Egy egyszerűnek és átlagosnak mondható Debian 6 (Apache 2.2, PHP 5.3, MySQL 5.1 - open_basedir szigorítva a saját htdocs, /tmp és /var/tmp mappákra) kiszolgálónkon a weboldalak felén a "Hacked by Mahabad Cíber Army" található, egyszerűen az index.php|html|htm -et cserélték le. A szervert heti szinten frissítjük APT-vel (gyári Debian US mirror-ok), gyakorlatilag minden mindig a legfrissebb. A feltört lapok közt vannak Joomla-k, Drupal-ok, CMS Made Simple-k, egyedi fejlesztésű lapok, és ami végképp érdekes, egyszerű HTML oldalak is.
A fájlok dátuma mindenütt Január 30, 15:28-15:30.
FTP logokban semmi, debian log-okban semmi, az apache log-okban pedig csak GET -ek vannak az adott időpontban és közvetlenül előtte. Természetesen az oldalak gazdái is teljesen különböznek, nem is ismerik egymást. Van valakinek ötlete?
Köszi
Hozzászólások
Ha már a /tmp-hez hozzáfér bármelyik VirtualHost, akkor elég az egyiken feltölteni valami okosságot és nagy az esély rá, hogy máshova is eltudja juttatni. Kérdéses, hogy milyen PHP biztonsági beállítások voltak, amik esetleg lehetővé tettek ilyesmit.
+1 Milyen verziójú CMS-ek, van-e olyan site, ahol saját php bug^Wkódkupac futkorászik...
Sajnos vannak köztük régiek is. A webmester nem én vagyok.
Akkor őt (is) rúgd se&&be. De nagyon.
Úgy érted sa&boxba?
"az apache log-okban pedig csak GET -ek vannak"
Az pont eleg. :)
Egymast tudjak ezek irni?
Mármint a virtual-host -ok tudják-e írni egymást?
Biztos nem, ez kizáró ok! :)
"Igen, minden www-data userrel fut."
Azért nem találsz az ftp logokban semmit, mert nem ftp-n töltötte fel a fájlokat.
Minden egy linux (www-data) alatt fut?
POST-okat nem találtál az apache logokban? Ne csak közvetlenül előtte keress.
Tűzfal van a gépen vagy a gép előtt?
Feltölthetett valamit korábban, ami pl nyitott egy portot kifelé és azon keresztül tolta be a többit. Keress furcsa futó processzt. (Már nem biztos, hogy megtalálod, de hátha.)
Lehet apache, php, joomla, drupal, stb hiba is akár, melyen keresztül bejutott. Keress a friss sebezhetőségek között is.
Linuxscripting
Igen, minden www-data userrel fut.
PHP default beállításokkal megy, csak az upload és post limit van módosítva, ill. minden "veszélyes" függvény tiltva van (pl. exec, shell_exec stb.).
Suhosin -al telepített a PHP. A gépen van tűzfal, arno-iptables-firewall, csak a szükséges portok vannak nyitva.
Furcsán futó processzt sem látok, csak ami tényleg szükséges.
Keresgéltem egy csomót, de max listákat találtam több ezer feltört weboldallal.
Köszi
Kifelé is csak a szükséges forgalmat lehet indítani?
Szerintem ne csodálkozz, ez teljesen normális. Joomla, WordPress stb mind saját magát telepíti www-data userrel. Ha minden felhasználód virtualhostjain www-data userrel megy a php, akkor elég egyetlen ismert hiba bárhol és ez lesz az eredmény.
Ezért szokás úgy belőni a szervert, hogy a php mindig a megadott user nevében fusson mondjuk fastcgi-vel. Tehát pl. pistike user pistike felhasználóval jön scp-n, csak /home/pistike mappában tud írni, ideális esetben még chrootolva is van oda. Itt vannak a virtualhostjai és a php scriptjei a saját php processzeivel mennek pistike userként. Ezek a php folyamatok tehát /home/pistike mappán kívül nem tudnak írni sehova, ergó más user scriptjeit nem tudják megfertőzni.
Persze, ha pistike valamelyik virtualhostján nem frissíti mondjuk a joomlát, akkor simán feltörhetik a többi virtualhostját is, de ez így csak pistike hibája és csak a saját dolgai sérülnek a saját hibájából.
A te esetedben viszont a szerver rendszergazdája felel, ő volt hanyag azzal, hogy hagyta www-data userrel menni a php-t minden usernek. Ha ebből kára is származott valakinek, szerintem nem kell csodálkozni, ha perelni fog és meg is nyeri. Persze ez azért szerződésfüggő.
Amit csinálni lehet ilyenkor:
Összeraksz egy normális rendszert, aztán a mentésekből visszaállítod a törés előtti állapotot, most már jól beállított jogosultságokkal.
"Igen, minden www-data userrel fut."
Es milyen jogosultsag kell az index.php lecserelesehez?
Joomlából tonna számra törik ezeket. Lehet, hogy onnan indul ki az egész?
Telefonrol irok, bocsanat a tomondatokert...
Ha van tartalek geped oda rakd fel a tores elotti mentest kicsit szigoritott kornyezetben, ha nincs, be kell vallalj par ora kiesest.
Amivel en szoktam kezdeni:
- apache home /dev/null
- apache shell /bin/false
- php-ban minden futtatassal kapcsolatos dolog letilt
- a /tmp es a /var/tmp noexec,nodev-re mountolva (minimum)
- itk vagy suexec-cel elszeparalni a user:group vonalat virthostonkent
- minden olyan mappara, ahova ftp, vagy apache hozzaferhet az auditd- rainditani a letrehozas, torles, atnevezes muveletek logolasara
- valamilyen MAC apparmor, tomoyo, selinux,... apace/ftp-re izgatasa
- a felhasznalok csak virtualis userek legyenek
- logokat lehetoleg egy masik gepre is kuldeni
- csak olyan programok fussanak, amik a szolgaltatasokkal szigoruan osszefuggenek (mast ne is telepits)
- iptables-szel lehetoleg logoltass minden new statuszu kapcsolatot
- rakj fel valami dinamikus tuzfalat (fal2ban) amivel a fobb logokat tudod figyeltetni
- apache ne mondja meg az os/szoftver infokat
- kapcsolj ki minden nem kello modult az apache-ban
- kapcsold ki a directory browsing-ot az apache-ban
- .htaccess hasznalata, engedese rizikos, ha lehet, tiltsd
- php ne logoljon semmit a bongeszobe, csak fajlba
- php basedir megadas
- ha nagyon durvulni akarsz: modsecurity
- fajlrendszer jogokkal, ACL-ekkel beallitani, hogy a user mas adatat ne lassa
Most ennyi jutott eszembe.
sub
----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"
--> YouTube csatornám
+1
sub
+1
+1
én is én is...
--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
.
+1
+1
--
Ingyenes Ubuntu One tárhely:
https://one.ubuntu.com/referrals/referee/170278/
+1
+1
Meg egy
Nahát milyen népszerű lett ez a komment. :-)
\o\ |o| /o/
+1
--
"'The time has come,' the Walrus said"
Csak egy kérdés - lehet butaság: ha különböző user:group-al akarom futtatni az egyes virtual hostokat, akkor a felhasználónak és csoportnak valójában létezni kell nem? Tehát nem lehet virtuális usert használni...
Érdekes kérdéskör az, hogy egy user mitől virtual és mikortól nem az.
Én ha tehetem pam-nss-mysql alapon oldom meg a dolgom, mert view-kal bármely programnak emészthetővé tudom tenni az adatokat. (Van akinek LDAP jön be.)
Onnantól, hogy a user:group feloldható nincs nagy különbség a hagyományos local user:group között, de valamit valamiért. (Persze shell nincs, pam rendszer szintű home-ot a /dev/null-ra kiválóan rá lehet állítani és az ftp-nek meg lehet kamuzni egy ftphome-ot, amibe ftp-n belépve fel lehet tölteni a kívánt anyagot és az uid:gid is rendben lesz. Ez csak view írás kérdése.)
Persze a leírtakból nem minden kötelező, de ha nagyjából érted a dolgokat, valamennyi segítséget ad. Az az elvem, hogy minden kis nehezítés a támadónak nekem jó, mert inkább keres magának egy kevésbé macerás vasat erőlködni. :) Ezeket meg egyszer kell csak beállítani.
szerk:
De azt azért tartsd észben, hogy a leírtak egyike sem véd meg (talán modsecure, Zorp) a rosszul megírt CMS-ek bugjainak kihasználásától. Persze a rendszerhez, más adatokhoz nem, vagy nagyon nehezen férnek hozzá, de az adott CMS egy pillanat alatt szétcsaphatják, ha úgy hozza a sors.
ha SuExec, akkor igen
ha minden vhostot egy kulon apacson akarsz futtatni a user neveben, es a kulso labrol beproxyzod, akkor is.
t
Miért? Ha az nss/nscd válaszol valami számmal az uid:gid lekérdezésre, akkor miért kell fizikai user:group?
+1
--------------------------------
ALKOHOLISTA: Az, aki ugyanannyit iszik, mint mi, csak nem szimpatikus.
+1
+1
Miféle ftp progit használsz? Ott sok a sérülékenység. Nem feltétlenül ott jöttek be, de nagy az esélye. Érdemes kézzel végignézni a /proc ban futó dolgokat, ha kell pid-enként. Fél óra kézzel végigszaladni.
A hiba jellege joomla-ra utal. Akkor viszont nem sok mindent fogsz találni. Script kiddie-k kedvenc játékszere... pl a Törökök naddon szeretik.
A /dev alatt is lehet pl új könyvtár szerkezet, és oda is be lehet bújni.
kieg:
Rákerestem. Ugyan nézd már meg, mit is ír ki a feltört site? Ui olyanokat is találtam, amik el is mondják, h mi volt a sebezhetőség. pl SQL-injection
Ha már többször felmerült, hogy a Joomla lesz a bűnös. Én sem rajongok érte, de tudnátok mondani egy érzésből valamit, hogy e három CMS közül melyiket törik meg gyakrabban? Magyarán tényleg a Joomla ennyire notórius?
Igen. Joomlára kilóra vannak exploitok. Ezek kihasználása akkor gáz, ha emberi hülyeséggel párosul (pl. nincs letíltva az user regisztráció). 2012 nyár óta van egy biztonsági rés amivel nagyon sok Joomlát felnyomtak, idegenek fájlokat töltöttek fel a Joomlán keresztül. Onnan IRC és SPAM botokat futtattak. A host gépen nagy CPU terhelést és spamlistára kerülést okozva.
Mellé ment
Ez egy általános Joomla törés volt, amin keresztül továbbmentek.
Leginkább az 1.5 sorozatot szokták így nyomni, gondolom van rá valami scriptjük. Ha a szerver nincs megfelelően belőve, akkor ezen keresztül már tovább tudnak menni.
Ok, hogy open_basedir be van love, de milyen apache modulok vannak engedelyezve meg (pl. cgi modul engedelyezve van) ?
Tipikusan az szokott lenni, hogy cgi is be van kapcsolva es hat ...
1. tiszta forrásból linux újratelepítés
2. biztonságos környezet kialakítása... kiindulásnak Lavian által írt lista és az alábbi link alatt található infók jó alapot nyújtanak...
http://hup.hu/node/111976
3. korábbi tárhely tartalmak megtisztítása, majd átmásolása az új szerverre
Jó munkát!
Olyat láttam, Jomla bugot kihasználva feltolt egy php-t, azt meghívva, komplett web-es filemanager, file editor, shell-t és crack toolt elért weben. Következő lépésnél egy (vagy sok) meglévő php elejébe berakja a kódot úgy, hogy egyetlen megfelelő get-es paraméterrel hívva az adott linket a saját cucca indul el, különben az eredeti oldal fut. Így a méret és dátumváltozáson kívül fel sem tűnik, tűzfal nem fogja meg, apache logban a get paraméter tűnhet fel. Openbasedir-en nem ment át szerencsére, igaz nem volt közös tmp könyvtár. De innen is elkezdhet csomó rosszaságot csinálni, a spam bot-tól kezdve..
sub
Lehet kirakom a php-t valamelyik nap egy ures vps-re par napig, lathassa innen, aki kivancsi. Okulasnak szerintem eleg jo, illetve akar sajat szervert tesztelni is.
Már előttem is írták, vélhetően az egyik CMS-edet törték meg, és minden bizonnyal azt, amelyikről kideríthető pusztán egy böngésző meg némi plugin segítségével, hogy milyen verziójú CMS fut rajta. Ennek tudatában meg már a Google is megsúgja, hogy hogyan kell feltörni.
Elég, ha egy olyan szövegmező van pl. ami a form elküldése után visszaírja a beírt értéket a html kódba, és nincs védve escape/unescape-pel.
Így 'rávehető' a kód, hogy ha pl. php kódot írunk a szövegmezőbe (körültekintően persze), akkor az a form elküldésével lefut. Pl. létrehoz egy fájlt valahol a weblap könyvtárstruktúrájában, amit aztán már csak hívogatni kell távolról pl. a www.torottoldal.hu/hack.php
Innentől kezdve 5 perc alatt zombi hálózatba kapcsolható a szervered. Az igazán szép az, ha ki sem írja, hogy hacked, csak minden alkalommal, ha valaki látogat, lefut a kód.
Ha ez a Te szervered, akkor nézd meg a CMS verziókat. Ha nem a legújabb alverzió, vagy olyan verzió, ami már nem supported (pl. joomla 1.x), akkor a vserver Apache alatt a2dissite, és lehet jelezni a tulajnak, hogy upgrade, vagy kuka - mivel a többi ügyfeledet veszélyezteti. Az egyéni PHP oldalakat (poisoning szempontból ezek a veszélyesebbek) meg auditálj vagy auditáltass valami szagértővel, és ha gázos, az eljárás UA.
--
PtY - www.onlinedemo.hu
Egyébként halkan jelezném trey-nek, hogy telnettel lekérdezhető módon ezt árulja el magáról a HUP.HU:
Ha valaki törni akar, ebből az infóból már elég jól meg tud élni...
Ezek ellen véd...
--
PtY - www.onlinedemo.hu
tmp mappa/user elszeparálása + suexec + nss-pgsql/mysql (ha már adatbázisban vannak az userek) + php.ini/user open_basedir disable_functions stb....
Joomla meg readonlyban kell futtatni, ha már a tulaja noob ;))
+ smtp szervert is nézd meg ha van, mert valószínűleg tonnaszám küldi a spemet a géped
sub