GASTON DIABLO - Hacker támadása után

Security-all

Sziasztok,

a Debian 7.8-as szerveremet "GASTON DIABLO" Hacker csapat által támadás érte. Ami site-ot megtámadtak, azon egy Drupal futott.
Először onnan vettem észre, hogy sok hibás e-mail cím érkezik az egyik domain nevemről.
Utána megnéztem az oldalamat és láttam, hogy támadás érte (ki lett cserélve az oldal).
Azóta az index.html-t kicseréltem és a szervert is újra indítottam, de a levél küldözgetés nem állt le. Továbbá a serverem nagyon be van lassulva, alig tudom elérni. HTOP-ot futatam rajta, de semmi rendkívüli terhelést nem láttam. A ps aux -nál lehetett látni, hogy a postfix több helyen fut. Leállítása után egy kicsit gyorsult a rendszer.
Kérdésem, hogy ilyenkor mit lehet tenni, hogyan lehet megszüntetni a levél küldözgetést? Mit kell mindenképpen ellenőrizni?

Köszi!

Kalmi

  • 4338 megtekintés

( kalmarr | 2015. 04. 26., v – 17:06 )

Ami hibám fennmaradt a levél küldözgetés a Debian serveremen. Letöröltem azt a könyvtárat amit feltörtek, de a levél küldés megmaradt, azaz itt már szerintem a Debian server törése lesz a valószínűsíthető. Kérdésem, hogy ezt hol lehetne kikapcsolni letiltani? Mit támadhattak meg?

Kalmi

közel sem biztos.
először is ellenőrzöd, hogy a netstat és fuser korrupt-e. ha nem, akkor megmondják, mi az ami küldi a levelet. Simán lehet, hogy a www-data (apache) user távolról indított el valami shellscript szerű dolgot, ami küldi a levelet - vagy letöltötte a programot, ami küldi a levelet.

Vagy csak a queue ban van még egy rakat levél, de újak már nem is jönnek, csak a kézbesítés alatt lévők miatt lassú a szerver (nagy az io)

postqueue -p mutatja a queue ban lévő leveleket, ha ez mondjuk 10-20e levél, akkor gyanús, hogy ez van.

Töröld az egész queuet, vagy valamilyen szabály alapján amit kell. Pl. így:

postqueue -p|grep -B 1 xyzemailpeldaul|cut -f 1 --delimiter ' '|cut -f 1 --delimiter '*'|postsuper -d -

abban az esetben, ha a Te MTA-dat használják. (nyilván első körben megoldja egy olyan védelem az MTA-n, hogy n*5levél/perc valami burst értékkel megtámogatva - a normál üzemvitelt simán elviszi)

Ha feltöltenek egy scriptet, ami letölt egy interpreter alapú (mondjuk perl/php/python/shell) nyelven írt spamküldő programot, hát, kereshetsz egy ideig (főleg ha a netstat felül van írva)...

( dotnetlinux | 2015. 04. 26., v – 17:23 )

Több postfix példány van, amiket ps-ax-szel látsz? Azokat töröld le.

Továbbá, amíg nem lesz pontos a felderítés:
- postfix csomag eltávolítása
- tűzfal kimenő levelek tiltása
- atop-ban (htop helyett) jobban látszanak a nagy/túlterheléses kiugrások.

Levél küldéshez elég egy shell script, nem kell postfix.
Azt kell kideríteni ps aux-al, logokból, netstat-al esetleg, hogy mi küldi a levelet.
Érdemes esetleg kilőni az apacheot és megnézni akkor is jönnek-e...
---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

( gelei v | 2015. 04. 26., v – 17:57 )

De miért üzemeltet szervert, aki nem ért hozzá? Véletlenül se vedd bántásnak, hiszen én sem értek hozzá (de nem is üzemeltetek szervert).

Be kell vágni az egészet egy szolgáltatóhoz*, és a megtakarított időben/pénzen pedig el lehet menni nyaralni. ;)

* egy normálishoz, aki ért hozzá, mert nyilván olyan is van elég sok, aki nem - akkor pedig ott vagy, ahol elindultál

Nem szeretnék megbántani senkit, de nekem is ez jutott az eszembe, hogy wtf?
Ezek elég alap üzemeltetési dolgok, ha ennyire nem megy, hagyni kell valóban szerintem is.

---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

Hobbi szinten üzemeltetem a servert és szeretném megtanulni a működését, működtetését. Most törték fel először a szerveremet ezért kérek segítséget...

Előre is köszönöm a segítségeket!

U.i.
Egy-két dologhoz már alapszinten értek, ezért kifejtenétek bővebben, hogy mire gondoltok itt "Ezek elég alap üzemeltetési dolgok, ha ennyire nem megy, hagyni kell valóban szerintem is."
Mik az alap dolgok ilyen esetben a server kikapcsolásán, vagy újra telepítésén kívül? Ha ennyire alap, akkor talán sikerülhet nekem is ;)

Szerintem az alap, hogy kiderítsd hogy mi okozza a dolgot, és legalább tanulj belőle, esetleg megtisztítsd a rendszert.
tcpdump, netstat, ps, lsof így hirtelen ami ehhez kellene neked szerintem.. :)
---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

( ncc1701 | 2015. 04. 26., v – 18:11 )

Ilyenkor a teendők:
-szerver távoli publikus elérését lelőni
-rájönni, hogyan törték fel
-megoldást keresni
-utolsó jó imageből visszatenni a virtuális gépet (remélem, nem fizikai a feltört gép, mert akkor lehet rohangálni)
-megoldást applikálni
-elérhetővé tenni
-reménykedni :)

+1

megtört gépet nem megjavítani próbáljuk, hanem töröljük és újratesszük.

Törlés előtt persze lehet vizsgálódni (ha érdekli az embert vagy ha el szeretné kerülni az újabb törést), és újratesszük az lehet mentésből vagy alap telepítésből.

+1
Általában valahová betolnak egy php oldalt, amit távolról hívogatnak egy egész botnet hálóról, akár másodpercenként más-más ip-ről, és amikor lefut, egy email kimegy.
Az ilyen feltörések _zömében_ nem profin mennek, az esetek többségében egy jól paraméterezett find megmondja, hogy mik az új/módosult fájlok, a tettes egy mezei less/vi/mcedit/stb. segítségével megtalálható/ellenőrizhető.
Persze, ha egyedi fejlesztésű az oldal, akkor molyolni kell vele. Ha joomla/drupal/wp/stb, akkor konfig elment, ugyanaz a patchlevel feltesz, konfig vissza, kiegészítők vissza, biztonsági beállítások újraellenőrzése/javítása, majd upgrade-upgrade-upgrade. Ha a cms biztonsági hibáját szúrták ki, akkor főleg.
_Mindig_ a legfrissebb verzió legyen fenn a cms-ből.
--
PtY - www.onlinedemo.hu, www.westeros.hu

Hát igen, van benne valami. Ahogyan nézegetem egyre jobban látom, hogy nem pusztán egy oldal került feltörésre, hanem maga a serverem.
Először talán a Drupal-t törték fel, arra tettek egy oldalt. Utána a serverre telepítettek, valamit, mert hiába töröltem le a usert, postafiókokat, a teljes feltört oldalt, ugyan úgy küldi a leveleket, azaz mélyebbre kelet tenni valamit.
A serveremen, amúgy egy I-MSCP rendszer fut, amit szintén újra frissítettem, de semmi nem változott mennek tovább ki a levelek.
A Postfixet is purge-al un-instáltam, de elvileg nem itt lehet a hiba, mert ezt csak használja valami.

Parancsokkal nézegetem a servert, de lehet "béna vagyok", de nem szúrok ki semmi érdekes. Amit megfigyeltem, hogy a levél küldője minden esetben webmester@server.hu, esetleg ezt meg lehetne valahogy keresni, hogy hol lehet ez a mail cím?

Olyan kérdésem lenne, hogy valahogy lehetne figyelni a kimenő levelek forgalmát és ha elér egy mennyiséget, akkor kapjak riasztást? Nem ilyen menedzselő szoftverre gondolnék, hanem valami egyszerűbb programra. Ezzel a SPAM-elő feltörést ki lehetne kerülni...., vagy gyorsabban észre vehetném.

( Frantique v | 2015. 04. 28., k – 12:21 )

A következő lépéseket mindenképpen csináld végig:

1. CGI futtatás off, exec, shell, stb. függvények tiltása. (pl.
disable_functions =exec,passthru,shell_exec,system,proc_open,popen,curl_exec,curl_multi_exec,parse_ini_file,show_source)
2. PHP-ban mail logolás be: php.ini-be: mail.log = /var/log/php-mail.log (legalább látod, hol és ki küldözget bármit is)
3. Amíg meg nem találod, hol a baj, chattr +i minden php fájlra.
4. minden cron átnézése, pl.:
for user in $(cut -f1 -d: /etc/passwd); do echo "START: $user"; crontab -u $user -l; echo "END: $user"; done
5. rkhunter és társai ráeresztése a rendszerre.

Bónusz: Ha van lehetőség, vesd össze a szerveren futó szkriptek hashsumját az érintetlen fájlokéval (fejlesztőnél pl.), a továbbiakban ez lehet egy monitorozási pont is.

És a legfontosabb: ha tanulni akarsz, keress egy mentort, aki nem leereszkedő, viszont akar és szeret oktatni.
--
Coding for fun. ;)

Esetleg még egy maldet-et javasolnék, a jövőben pedig ITK MPM modult. Utóbbi anniyban lehet csak hasznos, hogy ha az egyik oldalt felvágják, akkor csökkenhet az esélye annak, hogy a többit is végignyalják, mivel külön userrel fut. Persze ez sem garancia mindenre.

( _Franko_ v | 2015. 04. 28., k – 15:48 )

Felhúzol egy új szervert és átmigrálsz egyenként a szolgáltatásokat a legjobb tudásod szerint, aztán oda irányítasz mindent, a régit meg bezúzod.

Az újat frissen tartod, nem teszel fel rá ismeretlen forrásból semmit, csak csomagból és/vagy megbízható weboldalról. Amit kézzel teszel fel, azt is frissen tartod, ahogy minden mást. Nem állítgatsz át semmit, amiről nem tudod, hogy mit okoz.

Ha újra feltörik, akkor felírod magadnak, hogy nem értesz hozzá és más hobbi után nézel.

( athila v | 2015. 04. 28., k – 21:09 )

Csak nekem bántja a szememet magyar szövegkörnyezetben a "server" szó?
trolling off.

( Dacr (nem ellenőrzött) | 2015. 04. 28., k – 21:18 )

Azt meg szabad tudni, milyen verziójú drupal volt és milyen kiegészítők voltak rajta? Így tudni lehetne, hoyg mit használtak ki, miben volt a sérülékenység, stb. Nem mellesleg másnak is hasznos infó lehetne.

Sziasztok,

egy segítséget kaptam a egyik fórumozótól. Ezt köszönöm neki itt is!

Amit megállapítottunk, hogy csak a Drupal oldalt törték fel a szervert nem. A Drupal és feltöltöttek egy PHP szkriptet:

#cat access.log |grep POST

---
http://pastebin.com/qR0VuapQ
---

Ami elindította a SPAM-lést.

A lassúság és az oldal törlés utáni levélküldés pedig, azért volt mert (nem tudtam), hogy ellenőrizni kellene a "postqueue" -t.

#postqueue -p

Így ebben lehettek még a ki nem küldött levelek, amik szép lassan kimentek....

Drupallal kapcsolatban megnézem a mentést, hogy melyik verzió volt, de elvileg mindegy, mivel mindenkinek ajánlom a teljes frissítést!

Kalmi

Nem mindegy. Mert ha egy olyan sebezhetőség van, ami a frissben sincs javítva, akkor megette a fene a frissítést is, holnapután ugyanúgy beköszönnek. Azért nem árt ezt kideríteni, hogy aztán esetleg le is tudd jelenteni a drupal fejlesztők felé, ha a hiba a frissben is fennáll.

nem kötözködni akarok, de ha spammelésről van szó, akkor pont oda rakják fel a sz*rjukat ahová sikerül.
Pont a jelentéktelen szerveren futó jelentéktelen site van kevésbé védve.

Elmesélem a folyamatot:
van valami ismert sebezhetőség.
nekiállnak guglival vagy saját scanner scripttel keresni olyan site-okat amik az adott verziót futtatják. fut a scan pár napig, majd a megtalált site-okra megpróbálják feltenni a sz*rjukat, ami jó eséllyel sikerül is.
Értsd: nem meghekkelik az adott site-ot, hanem ismert sebezhetőséget (pl távoli script végrehajtás) keresnek és alkalmaznak.

"Értsd: nem meghekkelik az adott site-ot, hanem ismert sebezhetőséget (pl távoli script végrehajtás) keresnek és alkalmaznak."

Tudom, tele van az összes webszerverem logja azzal, hogy konkrét verziókat keresnek PhpMyAdmin/PhpLdapAdmin/Drupal/Joomla/stb vonalon, hogy aztán specifikus támadást tudjanak indítani a nem frissített site ellen.

Mindössze azt kétlem, hogy ismeretlen (vagyis a legfrissebb Drupal esetén is létező) sebezhetőséget használnak ki egy jelentéktelen site-on.

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Hhh... szóval találsz egy _új_ Drupal sebezhetőséget, ami az _összes_ Drupal-t érinti, bármelyik és bármilyen friss legyen is, erre nekiállsz és jelentéktelen szervereken kezded kihasználni a hibát spam küldésére, amit tulajdonképpen pillanatok alatt észrevesznek? Ahelyett, hogy keresnél jelentősebb és információ dúsabb Drupal oldalakat és onnan adatokat lopnál titokban, minimális beavatkozással, mert minél tovább tudod kihasználni a hibát, annál jobb? Ez életszerű?

"ha egy olyan sebezhetőség van, ami a frissben sincs javítva"

Erre reagáltam. Legalább olvasd el a szálat.

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

És a támadó helyében komolyan kockáztatnád egy értékes sebezhetőség idő előtti felfedezését azzal, hogy szimplán spam küldésre használod (=aprópénz), amikor sokkal értékesebb dolgokra is jó lehet (=hitelkártya adatok)?

Hány olyan Drupal sebezhetőséget láttál már eddig a saját szervereiden támadók által kihasználva, ami nem ismert sebezhetőség volt (=Drupal frissítés bezárta a lyukat)?

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

"Mekkora az esélye annak, hogy hasznos adatot találsz?"

Mindegyik Drupal-t érintő nem ismert, nem javítható sebezhetőséggel?

Elég nagy, ha tudod, hogy melyik oldal Drupal, mint például a https://www.whitehouse.gov is Drupal... :)

Ennyire nincs arányérzéketek?

Van egy minden Drupal-t nyitó sebezhetőség a kezetekben, most találtátok, senki nem ismeri, és akkor Ti tényleg elkezdenétek jelentéktelen oldalakon robotokkal spam-et küldeni, vagyis azt kockáztatni, hogy ezzel felfedezik a sebezhetőséget és javítják, vagy például körülnéznétek a fehér ház weboldalán belülről és próbáltok minimális profilt mutatni, hogy minél később fedezzék fel a hibát és javítsák a Drupal-ban?

"Ez a lényeg."

Ismert, publikált és javított sebezhetőségre teljesen igaz, amit írsz, ott célzottan keresik a frissítetlen kiszolgálókat. A hangsúly itt a _nem ismert_ és ezért _nem javított_ sebezhetőségen van.

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

A Drupal könyvtárában szerepelő CHANGELOG.txt szerint Drupal 7.31-es Drupal volt az áldozat. Mondjuk nem tudom, hogy a későbbi frissítéseknél ezt javították-e, mivel "ijedtemben" töröltem a teljes usert (IMSCP rendszernél a Customer). Így repültek a log-ok is. Legközelebb ezt a hibát sem követem el (lementem majd azt is).

Javaslat mindenkinek a frissítés!

Ez valóban nem mai darab. Simán kihasználhatták az arzenálból bármelyik sérülékenységet, még azt is, amit 7.35-ben javítottak (azok közt volt olyan, ami az egész 7-es és 6-os sorozatot is érintette, szóval jó pár verzión keresztül nyitott volt).

Igen, ezek nem gondolkodnak. Csak pörög a szemük előtt a SPAM SPAM SPAM szócska. :) Jellemzően nem az spammel, aki Drupal bugot talál, hanem valamilyen forrásból eljutott egy bug/sechole hozzá és puff nekiáll azt nyomatni, sőt lehet hogy még a scriptet is csak minimálisan módosítják. Én ezt már többször jellemeztem a szőnyegbombázás hasonlattal, de másnak is volt itt már hasonló jellegűje.

a mod_security egy apache modul, amivel különböző dolgokat tudsz ellenőrizni és tiltani.
pl túl hosszú url (buffer overflow) támadás, adott string-ek kiszűrése get/post adatátadásban (pl include http://)
(mint írták lentebb a hozzá tartozó url-t)

a reverse proxy pedig olyan proxy, ami a browser és megnézni kívánt oldal között van (mint a proxy általában :-)
itt is lehetőséged van szűrések biztosítására
(pl csak a Te ipcímedről engedélyezett olyan url regexp hogy include http://)