Help me, feltörtek egy csomó website-ot?!

Linux-security

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

  • 11416 megtekintés

( djpety v | 2013. 02. 01., p – 20:24 )

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.

( eax | 2013. 02. 01., p – 20:42 )

"az apache log-okban pedig csak GET -ek vannak"

Az pont eleg. :)
Egymast tudjak ezek irni?

( siposg | 2013. 02. 01., p – 20:45 )

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

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.

( Proci85 v | 2013. 02. 01., p – 20:51 )

Joomlából tonna számra törik ezeket. Lehet, hogy onnan indul ki az egész?

( lavian v | 2013. 02. 01., p – 23:12 )

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.

É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.

( kojot | 2013. 02. 02., szo – 00:16 )

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

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.

( Dacr (nem ellenőrzött) | 2013. 02. 02., szo – 07:55 )

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.

( Ar0n v | 2013. 02. 02., szo – 07:58 )

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 ...

( hg2ebh | 2013. 02. 02., szo – 15:13 )

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!

( Skuzzy | 2013. 09. 18., sze – 08:45 )

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..

( PtY | 2013. 09. 18., sze – 09:33 )

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:

Server: Apache/2.2.11 (FreeBSD) PHP/5.2.9 with Suhosin-Patch
X-Powered-By: PHP/5.2.9

Ha valaki törni akar, ebből az infóból már elég jól meg tud élni...

ServerTokens Prod
ServerSignature Off
TraceEnable Off

expose_php = off

Ezek ellen véd...
--
PtY - www.onlinedemo.hu

( pepelopez | 2013. 09. 18., sze – 10:14 )

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