Sikeres harc egy rafinált hacker ellen

Submitted by bnorbi on

2014. március 4-én arra ébredtünk, hogy a WorkPoint szerveren lévő, általunk kezelt weboldalak egy része hackertámadás áldozatává vált. Az érintett szájtoknál a megjelenő oldalt, valaki oda nem illő és valószínűleg ártalmas külső lapra mutató szolgáltatással helyettesítette.
A rendszerben volt egy általam ismert biztonsági rés, melyet már előzőleg ki kellett volna javítanom, csak időhiány miatt tolódott ennek meglépése.  Minden jel arra utalt, hogy itt jöhetett be egy emberi intelligenciát nem használó robot, amely bejuttatta hozzánk az ártalmas, kezdőoldalakat lecserélő kódot [rootkit]. Azt a nagy hibát követtem el, hogy nem győződtem meg arról, hogy valóban így történt-e, hanem gyorsan eltávolítottam a bekerült ártalmas kódrészleteket és megszüntettem a fent említett biztonsági rést. Naponta 500 és 1000 támadás ér minket, így hiába fejlődünk, a nagy számok törvénye miatt előbb-utóbb sikere lehet egy ilyennek.
Igen ám, de délutánra újra jelentkezett ez az eset és hogy az általunk nyújtott szolgáltatások működjenek, felvettem a harcot: részletesebben elkezdtem nyomozni. Nyilvánvalóvá vált, hogy előzőleg nem a megfelelő lyukat foltoztam be. Ezalatt egyre intenzívebb lett a támadás és egyszercsak változott a bejuttatott kód és annak elhelyezése. Ekkor vált világossá, hogy itt bizony közvetlen intelligencia áll az eset mögött, hiszen olyan dolgok történtek, amelyet jelenlegi technológia alkalmazásával csakis ember tud végrehajtani. (Vagy kvantumszámítógép, de ennek az esélyét teljesen kizárhatjuk)

A küzdelem késő délután érkezett a csúcspontjára, amikorra a lyukak foltozgatása közben a támadó aktívan jelen volt a szerveren és újabb és újabb lyukakat készített. Bíztam benne, hogy elegendő nyomot hagy maga után, amiből egyértelműen kiderül, hogyan került ide, mit akar és milyen tudásszinten áll.

Majd elhallgatott minden..

A szolgáltatást lekapcsoltam. Pontosabban letiltottam minden rajtunk kívüli számára mindennemű elérést és megindult a nyomkeresés. Eddigre már 20 óra telt el az első incidens óta és midösszesen annyit tudtunk, hogy biztosan a web irányából jött [80-as port]. Azaz ha működnek a weboldalak, akkor kapjuk a támadást.
Hosszú órákon való keresgélések után csak annyi volt világos, hogy az elhelyezett ártalmas fájlok [rootkit] futtatását a belső szerverről intézte valahogy, így ennek semmi nyoma nem maradt a naplókban. Vakon tapogatóztunk.

Majd 1-2 (alvással töltött) órával később, újabb szakértők bevonásával a bejutási pontra való koncentrálással kiderült, hogy egy holland ip címről telepítettek sikeresen egy nálunk csak rendszergazdai felhatalmazással telepíthető oldalt. Így végre 5-én kora délután elmondhattuk: viszonylag biztosak lehetünk abban, hogyan érkezett először a támadás.


Amit eddig is tudtunk:

A.) cPanel rendszert használunk, ahol létezik egy fő-domain és minden egyes hozzáadott további domaint úgy tart nyilván a rendszer, hogy a fő-domainnak létrehoz egy al-domaint. (Pl. fő-domain: "cpanel.net" esetén ha hozzáadjuk a "drupal.org" -ot, akkor kvázi mellékesen létrejön egy "drupal.cpanel.net" is)
Ez az al-domain, aminek semmi szerepe nincs a mindennapos életben, a fájlrendszerben ugyanoda mutat, ahová a hozzáadott domain, de nem látszódik kívülről [nem szerepel a DNS-ben]. Viszont kisebb munkával és emberi logikával lehet ilyen al-domaint találni és ezzel kérést intézni a szerverhez [pl. hosts fájl].

B.) Egy weboldal lekérdezésnél a cPanel [pontosabban apache] dönti el, hogy a kért weboldal a fájlrendszerben hol is található és így irányítja a megfelelő drupal mappára. A drupalt u.n. multisite-ban használjuk. Eszerint további döntés születik, hogy azon belül pontosan melyik weboldalt kell megjeleníteni.
Amikor olyan kérés jön be, amihez nincs hozzá tartozó pontos domain, akkor automatikusan a "default" mappára irányít át, ami multisite esetén általában üres szokott lenni.

C.) A cPanel valami oknál fogva egy bizonyos fontos modult [PDO] akkor enged telepíteni, ha az hoz magával egy u.n. SQLite -ot. (ami általában teljesen felesleges, de megjelenik)
Ez a szolgáltatás annyit tesz, hogy nem szükséges igazi adatbázis, hanem egyszerűbb környezetben is lehet weboldalt használni.

D) Az elmúlt időkben a drupal rendszer általánosabb lett azzal, hogy támogatja ezt az SQLite -ot.


A támadás lépései:

1. lépés: Találni egy olyan al-domaint, ami drupal fájlrendszerre mutat, s így annak a default-ja szolgálja ki.

2. lépés: (a hekkelés) A default-ba elindítani egy drupal telepítést SQLite -ot használva és hamis [POST] adatok bejuttatásával rávenni, hogy fogadja el őt mint hiteles telepítő.

3. lépés: Van egy telepített (ugyan korlátozott jogú) weboldala, ahol ő az admin, így képes [PHP eval] kódokat futtatni, továbbá a fájlrendszerre írni.

4. lépés: Megfelelő kód hívása az oldalon belül, ami elhelyez egy kártékony futtatható állományt [rootkit] a fájlrendszerben.

5. lépés: Hogy nyomtalanok maradjunk, oldalon belülről hívni ezt a futtatható állományt, amely képes fájlokat létrehozni, módosítani, törölni, hozzáférési jogokat korlátozottan módosítani.

6. lépés: Rendszer adminisztrátori jogok átvétele a megfelelő eszközök használatával [stack overflow].
(Többszöri próbálkozás után sem nem történt meg.)


Megoldás:
A rendszert visszaállítottam március 1-i időpontra, amikor még semmi jelét nem találtuk a behatolásnak. Aztán ahol az adatokat teljesen tisztának találtam, ott a lehető legfrissebb állapotra hoztam. A behatolási pontot 3 szinten javítottam, majd az összes kompromittálódott jelszót lecseréltem és végre 5-én délután újra indulhatott a szolgáltatás.

Megállapítás:
Egy nagyon felkészült és ravasz támadóval álltunk szemben, aki nagyon furfangosan viselkedett. A rendszer piciny részeiből egyre nagyobb és nagyobb jogot tudott magának szerezni. A globális probléma ellen az védett meg minket, hogy a támadó bejutása ellenére állítható, hogy a szerverbiztonsági védelme sokrétű: fel van készítve arra, hogy a szerzett jogosultágokon túl külső belépő ne juthasson. Így a támadó csak és kizárólag a weboldalakat kiszolgáló fájlokhoz tudott hozzáférni.
Azt, hogy ki lehetett a támadó, nem tudjuk, hiszen az eddigi tapasztalatok alapján biztosan jól eltakarította maga mögött a nyomokat. Így nem is érdemes felkutatást kezdeni.
Kérdés: miért töltött el ennyi értékes időt azzal, hogy minket piszkálgatott? Mit akarhatott vajon elérni?

Bánfi Norbert