SOHO HONEYPOT FEJLESZTÉSE OPENWRT KÖRNYEZETBEN

Budapesti Műszaki és Gazdaságtudományi Egyetem Villamosmérnöki és Informatikai Kar Távközlési és Médiainformatikai Tanszék

Kamarás Roland

SOHO HONEYPOT FEJLESZTÉSE OPENWRT KÖRNYEZETBEN

KONZULENS

Dr. Fehér Gábor 2 2011 BUDAPEST,

Tartalomjegyzék Tartalomjegyzék ............................................................................................................. 3 Összefoglaló ..................................................................................................................... 6 Abstract............................................................................................................................ 7 1. Bevezetés ...................................................................................................................... 8 1.1 A feladat indokoltsága ............................................................................................ 9 1.2 A feladat értelmezése.............................................................................................. 9 1.3 A feladat célja ......................................................................................................... 9 1.4 A szakdolgozat felépítése ..................................................................................... 10 2. Irodalmi áttekintés.................................................................................................... 11 2.1 A honeypotok típusainak áttekintése .................................................................... 11 2.2 Az automatikusan terjedő malwarek működése ................................................... 12 2.3 High-interaction honeypotok ................................................................................ 14 2.4 Az Argos high-interaction honeypot..................................................................... 16 2.5 Low-interaction honeypotok................................................................................. 17 2.6 A Nepenthes low-interaction honeypot ................................................................ 18 2.7 High- vs. low-interaction honeypotok .................................................................. 21 2.8 Honeypotok alkalmazása SOHO környezetben.................................................... 22 3. Tervezés ..................................................................................................................... 26 3.1 A honeypot funkcionális tervezése ....................................................................... 26 3.1.1 A programmal szemben támasztott követelmények ...................................... 26 3.1.2 A megvalósítandó funkciók összegzése felhasználói szempontból............... 27 3.2 Architekturális tervezés ........................................................................................ 28 3.3 Az alkalmazás objektummodellje......................................................................... 31 3.4 A választott sebezhetőségek ................................................................................. 37 3.5 Az exploitok működése ........................................................................................ 39 3.5.1 A stack ........................................................................................................... 39 3.5.2 Kódfuttatás buffer overflow eredményeként ................................................. 42 3.6 Vulnerability modulok működésének tervezése ................................................... 45 4. Implementálás ........................................................................................................... 47 4.1 A választott programozási nyelv........................................................................... 47 4.2 Az alkalmazás környezete..................................................................................... 47

4.3 Fordítás, telepítés, futtatás .................................................................................... 48 4.4 A telepített alkalmazás struktúrája, állományai .................................................... 51 4.5 A konfigurációs állomány..................................................................................... 53 4.6 A naplóállomány szerkezete ................................................................................. 53 4.7 A webes megjelenítő felület.................................................................................. 55 4.8 Dokumentációk ..................................................................................................... 56 5. Tesztelés, értékelés .................................................................................................... 57 5.1 Metasploit Framework .......................................................................................... 57 5.2 A tesztelés előkészítése, tesztkonfiguráció ........................................................... 57 5.3 A tesztelés kivitelezése ......................................................................................... 58 5.4 A tesztek eredménye, értékelése ........................................................................... 59 5.5 Egy példa támadásra és annak feldolgozására ...................................................... 60 6. Összefoglalás.............................................................................................................. 62 6.1 Eredmények .......................................................................................................... 62 6.2 Továbbfejlesztési lehetőségek .............................................................................. 62 Köszönetnyilvánítás ...................................................................................................... 63 Irodalomjegyzék............................................................................................................ 64 Rövidítésjegyzék............................................................................................................ 65

HALLGATÓI NYILATKOZAT

Alulírott Kamarás Roland, szigorló hallgató kijelentem, hogy ezt a szakdolgozatot meg nem engedett segítség nélkül, saját magam készítettem, csak a megadott forrásokat (szakirodalom, eszközök stb.) használtam fel. Minden olyan részt, melyet szó szerint, vagy azonos értelemben, de átfogalmazva más forrásból átvettem, egyértelműen, a forrás megadásával megjelöltem. Hozzájárulok, hogy a jelen munkám alapadatait (szerző(k), cím, angol és magyar nyelvű tartalmi kivonat, készítés éve, konzulens(ek) neve) a BME VIK nyilvánosan hozzáférhető elektronikus formában, a munka teljes szövegét pedig az egyetem belső hálózatán keresztül (vagy autentikált felhasználók számára) közzétegye. Kijelentem, hogy a benyújtott munka és annak elektronikus verziója megegyezik. Dékáni engedéllyel titkosított diplomatervek esetén a dolgozat szövege csak 3 év eltelte után válik hozzáférhetővé. Kelt: Budapest, 2011. 12. 06.

..................................................................... Kamarás Roland

Összefoglaló Napjaink gyors informatikai fejlődésének következtében egyre nagyobb hangsúlyt kap a számítógépes rendszerek védelme. Az internet rohamos terjedésének köszönhetően újabb és újabb alkalmazások jelennek meg. Az alkalmazások megjelenésével párhuzamosan jönnek létre azok hibáit kihasználó kis programok, az úgynevezett exploitok, valamint az exploitokat felhasználó kártékony alkalmazások, a malwarek. Az exploitok, illetve malwarek elleni védelemben hatékony megoldást jelenthetnek a honeypotok. A honeypotok olyan számítógépes rendszerek, melyeket azzal a céllal telepítenek, hogy támadások érjék, ezáltal részletes információval képesek szolgálni a támadásokat illetően. Ezen információk felhasználásával az éles rendszer biztonsága növelhető. A dolgozat elején a különböző típusú honeypot rendszerek felépítését és működését ismertetem, illetve összehasonlítom azokat, majd megvizsgálom SOHO környezetben való alkalmazhatóságukat. Ezt követően egy általam létrehozott, OpenWrt környezetben működő, alacsony interaktivitású (low-interaction) honeypot funkcionális és architekturális tervezését ismertetem. A tervezést követően implementálom a honeypotot, valamint a hozzá kapcsolódó kezelő-, megjelenítő felületet. Dolgozatomat a létrehozott rendszer Metasploit Framework behatolás tesztelő alkalmazás segítségével történő tesztelésével, ellenőrzésével zárom.

6

Abstract In our days computer system and network security has increasing importance due to the fast evolution of Information Technology Industry. Due to growth of the internet, there are more and more network applications are developed. In parallel with the issue of the applications, small programs (so-called exploits) and malicious applications that use exploits (so-called malwares) appear to exploit their flaws. In protection against malwares and exploits, honeypots can be an effective solution. Honeypots are computer systems that are installed for the purpose of capturing attacks and therefore they can serve detailed informations about the attack. With the use of these informations the security of the production system can be increased. In my thesis I review the different kinds of honeypot systems, including their architecture and operation and compare them, then I examine their applicability in a SOHO environment. After that I will present my low-interaction honeypot system reviewing the functional and architectural design of the honeypot and its implementation as well as the associated user interface. Finally I finish my thesis with testing of the system with Metasploit Framework penetration tester application.

7

1. Bevezetés Az informatikai biztonság kérdése napjainkban egyre nagyobb hangsúlyt kap a számítástechnika gyors fejlődése, az internet térhódítása következtében. A nagyiramú fejlődésnek köszönhetően folyamatosan jelennek meg újabb vállalatok, cégek, illetve magánszemélyek az interneten. Hatalmas sebességgel bővül a világhálón szabadon elérhető, ingyenes alkalmazások, szolgáltatások, illetve a korábbi desktop alkalmazások online változatainak száma. Ezzel párhuzamosan az alkalmazások hibáit kihasználó kis programok, az úgynevezett exploitok is gyorsan napvilágra kerülnek. Egy alkalmazásban (legyen az akár egy operációs rendszer, egy dokumentum megjelenítő, egy böngésző plugin stb.) lévő hiba nyilvánosságra kerülését követően gyakorlatilag néhány napon belül elkészül a hibát kihasználó exploit, majd ezt követően az exploitot felhasználó, automatikusan terjedő malwarek is. Éppen ezért nagyon fontos feladat az internetről érkező folyamatos támadásoknak kitett számítógépek védelme. A különböző biztonsági megoldások közül erre szolgálnak az úgynevezett honeypotok is. A honeypotok olyan monitorozott számítógépes erőforrások, melyeket arra találtak ki, hogy gyűjtsék a belső hálózatból vagy az internetről érkező támadásokat. Segítségükkel detektálhatjuk, illetve analizálhatjuk a hozzájuk érkező, illetve azokat elhagyó káros forgalmat. Másik fontos feladatuk pedig az olyan, még nem ismert sebezhetőségek (vulnerability) detektálása, amelyekre már létrehoztak exploitokat. Az olyan exploitokat, amelyek még nem ismert sebezhetőségeket használnak ki, röviden 0day (zero-day) exploitoknak nevezzük. Ezek a legveszélyesebbek, hiszen az általuk kihasznált hibákra még nem léteznek a biztonsági rést befoltozó patchek, frissítések. Ezek detektálása tehát kulcsfontosságú a hálózat és az azt alkotó számítógépek védelme szempontjából. Ugyanakkor a honeypotok képességei is korlátozottak. A honeypotok csak a támadások és azok eredményeként letöltött káros programok (malwarek) gyűjtésére, tárolására, a biztonsági rések, sebezhetőségek emulálására, illetve a kompromittáló forgalmak naplózására alkalmasak. Vagyis segítenek minket a támadások megértésében azzal, hogy a rendszer sebezhető pontjának tettetik magukat és így megpróbálják elhitetni a támadóval, például egy másik fertőzött számítógéppel, hogy ugyanolyan

8

potenciális célpontok, mint a valódi, éles környezetben üzemelő számítógépek, de az exploit által kihasznált biztonsági rés megtalálása a mi feladatunk. Szerencsére ma már erre is számos automatizált megoldás létezik, illetve jelenleg is intenzív kutatás folyik többek között a 0-day exploitok által kihasznált biztonsági sebezhetőségek automatikus felkutatásán. A közeljövőben valószínűleg ilyen jellegű alkalmazások is piacra kerülnek majd.

1.1 A feladat indokoltsága Az informatika fejlődése abba az irányba halad, hogy a közeljövőben otthonunk eszközei (mint például VoIP telefon, IP TV stb.) is az internet egy-egy végpontjai lesznek a már meglévő otthoni hálózat részeként. Ezen hálózatokkal szembeni biztonsági fenyegetést az internetről, valamint a belső hálózatból érkező támadások jelentenek. A lokális hálózatból érkező fenyegetést jelentheti például egy idegen laptop vagy mobil készülék belső hálózatba való beengedése. Ennek következtében az említett információs rendszerek védelmében kulcsfontosságú szempont a megelőzés, melynek hatékony eszközei lehetnek a honeypotok, ezért mindenképpen érdemes működésüket megérteni, foglalkozni velük.

1.2 A feladat értelmezése A szakdolgozat keretein belül a feladatom az volt, hogy tanulmányozzam a honeypotok típusait, az exploitok működésének folyamatát, majd a megszerzett ismereteket felhasználva tervezzek meg, implementáljak és teszteljek egy SOHO (Small Office/Home Office) környezetben (SOHO routeren) működő honeypot alkalmazást.

1.3 A feladat célja A feladat célja egy olyan SOHO honeypot alkalmazás fejlesztése, amely képes az internetről, valamint a belső hálózatból érkező meghatározott típusú támadások fogadására, alkalmas a támadások különböző paramétereinek rögzítésére, valamint az összegyűjtött információkat egy könnyen áttekinthető webes felületen jeleníti meg, amelyen keresztül lehetőség nyílik az alkalmazás konfigurálására is.

9

1.4 A szakdolgozat felépítése A szakdolgozat második fejezetében áttekintem a honeypot rendszerek két alapvető típusát, azok működését, tulajdonságait, majd ezen tulajdonságok mentén összehasonlítom azok előnyeit, illetve hátrányait. A fejezet hátramaradó részében megvizsgálom, hogy miként alkalmazhatók az ismertetett funkciók otthoni/irodai környezetben. A harmadik fejezetben a létrehozandó rendszer szerkezetét vázolom fel, illetve ismertetem a fejlesztés során meghozott fontos tervezői döntéseket, továbbá áttekintem a rendszer működéséhez nélkülözhetetlen járulékos ismereteket. A negyedik fejezetben a megvalósítás részleteit, míg az ötödik fejezetben a tesztelés kivitelezését és eredményeit írom le. A hatodik fejezetben kitérek a létrehozott rendszer továbbfejlesztési lehetőségeire.

10

2. Irodalmi áttekintés 2.1 A honeypotok típusainak áttekintése Ahogy a korábbi fejezetben már felvázoltam, a honeypotok az információs rendszerek védelmi feladatai közül a megelőzést szolgálják, azzal hogy monitorozzák az internetről, valamint a belső hálózatból érkező támadási kísérleteket. A honeypotok alapvetően tetszőleges operációs rendszer futtatására, illetve tetszőleges szolgáltatás emulálására alkalmasak. A honeypotokat sokféle szempont szerint lehet csoportosítani, az egyik legalapvetőbb csoportosítási szempont a támadóval való interakció szintjében tesz különbséget a rendszerek között. Ennek alapján megkülönböztethetünk alacsony interaktivitású (low-interaction) és magas interaktivitási szintű (high-interaction) honeypotokat. A high-interaction honeypotok [1] alapvetően egy teljes értékű rendszert szolgáltatnak a támadó felé, a támadó fél ugyanúgy tud kommunikálni a rendszerrel, mintha az egy éles rendszer volna. Ezek a rendszerek tipikusan egy fizikai gépen (host) lévő virtuális környezetben futnak (guest), mint például a Linuxos QEMU virtualizációs rendszer. Ilyen típusú honeypotra jó példa a holland Vrije Universiteit Amsterdam egyetem diákjai által fejlesztett Argos. Természetesen nemcsak virtuális, de fizikai honeypotok is léteznek. Ezek közvetlenül a fizikai gépen futnak, a hálózat részeként saját hálózati címmel (IP-címmel). Ezekkel ellentétben a low-interaction honeypotok [1] egy tényleges rendszernek csak néhány elemét emulálják, mint például a hálózati stacket vagy bizonyos sebezhető szolgáltatásokat. A high-interaction honeypotok tehát a megfelelő exploitok alkalmazásával lehetővé teszik a támadó számára, hogy az teljes körű hozzáférésre tegyen szert a virtualizált (esetleg fizikai) rendszeren és ezáltal a rendszer további hálózati támadásokat fedjen fel, valamint így a támadó szándékai is könnyebben meghatározhatók. A low-interaction honeypotok – mivel csak szolgáltatásokat emulálnak – nem teszik lehetővé a teljes rendszer feletti irányítás átvételét (hiszen ebben az esetben teljes értékű rendszer nem is létezik), vagyis korlátozottabb képességűek, mint high-interaction típusú társaik. Arra viszont alkalmasak, hogy segítségükkel képet kapjunk a hálózati betörési kísérletekről, illetve a különböző wormok (férgek) hálózati tevékenységéről. Ilyen jellegű honeypotra jó példa a The 11

Honeynet Project által fejlesztett Nepenthes, illetve annak rokonai, mint például a Dionaea vagy az Amun honeypotok. A honeypotok mellett az internetről érkező támadásokat is két nagy csoportra lehet osztani. Az egyik csoportba tartoznak a kevésbé intelligens támadások, amelyekért tipikusan az exploitokat felhasználó automatikusan terjedő malwarek a felelősek. A malwarek feladata tipikusan abból áll, hogy az exploitot felhasználva egy, már kompromittált számítógépről kihasználják más számítógépek biztonsági sebezhetőségeit és ráveszik a célpontot arra, hogy egy meghatározott helyről (például a támadás során harmadik félként jelenlévő fertőzött gépről) töltse le és futtassa is magát a célpontot megfertőző binárist. Az így letöltött bináris pedig maga a malware, amely ily módon képes terjedni a rendszerek között újabb és újabb gépeket megfertőzve. A malwarek tevékenységét is tehát két részre lehetne osztani. Egyrészt biztosítják a hálózatban történő terjedésüket, másrészt valamilyen járulékos (és általában káros) tevékenységet is kifejtenek az áldozat gépén. Ez lehet például egy hátsó-ajtó (backdoor) nyitása, amelyen keresztül a malwaret készítő személy hozzá tud férni a megtámadott számítógéphez. Vagyis a támadások másik típusáért (az „intelligens” támadásokért) a biztonsági rések kihasználásához értő személyek (hackerek) felelősek. Ők vagy a maguk által írt programokkal (illetve sok esetben már meglévő alkalmazásokkal) veszik rá a számítógépet, hogy tegye lehetővé számukra a távoli hozzáférést (a számítógép feletti teljes kontrollal), vagy a malwarek által nyitott hátsó-ajtókat használják ki. A malwarek által megtámadott számítógépek, amelyek akár a Föld egymástól távoli pontjain is elhelyezkedhetnek, egy hálózatot alkothatnak, ezt botnetnek nevezzük. Egy botnet hatalmas értéket képviselhet a támadó kezében, hiszen a támadó a botnet részeként üzemelő zombie gépek hátsó-ajtóit kihasználva utasíthatja valamilyen tevékenységre azokat. Például egy nagyobb botnet segítségével akár maradandó károkat okozó DDoS (Distributed Denial of Service) jellegű támadást is lehet kivitelezni valamely vállalat számítógépes rendszere, internetes szolgáltatásai ellen.

2.2 Az automatikusan terjedő malwarek működése Az előzőekben ismertetett honeypot típusok alapvetően az automatikusan terjedő malwarek ellen használhatók. Az automatikusan terjedő malwarek működésének ciklusát az 1. ábra szemlélteti.

12

1. ábra - Automatikusan terjedő malwarek működése

Egy adott alkalmazásban lévő hiba nyilvánosságra kerülését követően néhány napon belül elkészül a hibát kihasználó exploit [1], majd általában több – ezt az exploitot felhasználó – automatikusan terjedő malware jön létre egymástól függetlenül. Ezt a folyamatot szemlélteti az ábra felső része. Ezt követően a létrehozott malware a környezetében sebezhető célpontokat kezd el keresni. Ha egy célpontot sikeresen azonosított, akkor megkísérli végrehajtani rajta az exploitot. Egy, a számítógép valamely szolgáltatásában rejlő biztonsági hiba, akár egy hálózati protokoll alkalmazás hibája például úgy használható ki, hogy a támadó malware az áldozatnak szándékosan hibás kéréseket vagy hibás csomagokat küld. A hibás kérések/csomagok feldolgozása során az áldozat gépen a biztonsági hiba következtében valamilyen rendellenes esemény, viselkedés következik be. Ez nagyon gyakran az adott szolgáltatás folyamatának részét képező valamely buffer túlcsordulását vagy alulírását jelenti (buffer over- vagy underflow), amelynek eredményeként érzékeny memóriaterületek írhatók felül és ennek következtében a hálózati alkalmazás olyan memória területet címez meg, ahol a támadó a buffer over- vagy undeflownak 13

köszönhetően elhelyezett káros kódja található, ezzel pedig a folyamat futásába képes a támadó beleavatkozni. Az így elhelyezett futtatható kódot shellkódnak nevezzük. A shellkód elnevezés onnan ered, hogy a támadó által elhelyezett kód leggyakrabban egy parancsértelmezőt (shellt) indít el és a parancsértelmezőn keresztül történik a további műveletek végrehajtása. A shellkódok, illetve exploitok működését egy későbbi fejezetben részletesen ismertetem. Ahogy a fenti ábrán is olvasható az imént említett folyamatot nevezhetjük exploitálásnak. Nyilvánvaló módon az exploitálás csak akkor lehet sikeres, ha a célpont gép a felhasznált exploit által érintett biztonsági hibát tartalmazta. Ebből következően a malwarek csak az esetek kis részében járnak sikerrel, de mivel kellően sok gépet próbálnak megtámadni, ezek között mindig előfordulnak majd olyanok, amelyek esetében sikeresek lesznek. A támadást végző malwarek tipikusan a „fire-and-forget” elvet követik, vagyis nem törődnek a szándékosan hibás csomagokra adott célponttól érkező válasszal, ha az adott gép nem volt támadható, akkor egy következőnél próbálkoznak. Azért sem törődnek a visszaküldött válaszokkal (ugyan az lehet, hogy olyan információt hordozna, amellyel egy másik típusú támadás sikeresen kivitelezhető lenne), mivel a válaszok nagyon különbözőek lehetnek, platformtól, operációs rendszertől, annak verziójától, nyelvi változattól vagy service packtól függően, illetve így a malwarek is egyszerűbbek lehetnek. Az exploitálás eredményeként tehát kódfuttatásra nyílik lehetőség az áldozat gépen. A futtatandó kód általában a támadást végző malware futtatható állományának a letöltésére irányul. A kódfuttatás eredményeként az áldozat gép letölti a binárist vagy a támadó gépről vagy valamely más hálózaton elérhető erőforrásról. Miután letöltődött a malware, a célpont elkezdi azt futtatni, aminek következtében fertőzötté válik és a malware az eddig ismertetett ciklust kezdi elölről immár az új gépen is. Mindezek mellett a malware általában valamilyen káros tevékenységet is kifejt az áldozat gépen, amely gyakran egy backdoor nyitását jelenti. Ezen a backdooron keresztül a malware tulajdonosa hozzáférést szerezhet az adott számítógéphez.

2.3 High-interaction honeypotok A high-interaction honeypotok egy teljes rendszert tesznek ki a hálózatból érkező támadásoknak. Ez azt jelenti, hogy nem egy különálló szolgáltatást, funkcionalitást emulálnak, hanem egy valós rendszert biztosítanak az azon futó alkalmazásokkal, szolgáltatásokkal, így a támadó teljes mértékben átveheti az irányítást 14

a rendszer felett. Ennek köszönhetően többet megtudhatunk a támadó céljairól, az általa alkalmazott

eszközökről,

eljárásokról,

mélyebben

megismerhetjük

a

támadás

folyamatát. A high-interaction honeypotok tetszőleges operációs rendszert futtathatnak, leggyakrabban azonban a Windows operációs rendszer valamelyik verzióját, ugyanis a Windowsos környezetben a leggyakoribbak az ilyen jellegű támadások. A high-interaction honeypotok lehetnek fizikai vagy virtuális gépek. Fizikai gép használata esetén célszerű erre a célra dedikált eszközt biztosítani, hiszen ebben az esetben a támadó nem fér hozzá a rendszeren tárolt esetlegesen érzékeny adatainkhoz. Ilyen rendszer lehet például egy szeparált gépen futó patch nélküli Windows 2000 vagy XP operációs rendszer, amely gyakorlatilag néhány perc alatt kompromittálható. A virtuális honeypotok egy fizikai gépen futó virtualizált környezetben futnak. A legelterjedtebb megoldások a VMware, User-Mode Linux (UML), illetve a QEMU rendszerekkel megvalósított megoldások. A magas interaktivitási szintű honeypotok fizikailag hagyományos számítógépes rendszerek, lehetnek szerver számítógépek, PC-k (Personal Computer), routerek, switchek. Általában a rendeltetésszerű feladatukat nem látják el a hálózatban, aktív felhasználóik sincsenek, így az alapvető háttérfolyamatokat, szolgáltatásokat leszámítva nem hoznak létre újabb processzeket (folyamatokat), nem generálnak további hálózati forgalmat. Ebből következően minden egyéb forgalmat, illetve a honeypotokkal folytatott interakciót gyanúsnak kell tekinteni és lehetséges káros tevékenységként kell kezelni. Az

ilyen

high-interaction

rendszerek

tehát

mentesek

a

tévedésektől,

vakriasztásoktól és ez az egyik legfontosabb előnyük a behatolás detektáló rendszerekkel (IDS, Intrusion Detection System) szemben. További előnyük, hogy láthatóvá válik, miként deríti fel a célpontokat a támadó, illetve milyen technikákat használ annak érdekében, hogy új információkat szerezzen az áldozatról. Részletes képet kaphatunk a rendszer támadásának folyamatáról, illetve, hogy pontosan milyen exploitokat használ a támadó fél. Ebből következően a másik nagy előnye a highinteraction rendszereknek, hogy olyan sebezhetőségeket is képesek felfedni, amelyekre még nincsenek biztonsági javítások (0-day exploitok). Végezetül nyomon követhetővé válik a támadó honeypoton végzett tevékenysége. További érv a magas interakció szintű rendszerek mellet a könnyű telepíthetőség. Használhatunk fizikai vagy virtuális gépet, esetleg egy fizikai gépen több egymással párhuzamos virtuális honeypotot különböző konfigurációval. További 15

lehetőség az előkonfigurált honeypotok használata, melyek esetében csak némi finomhangolásra van szükség a futtatás előtt. A virtuális honeypotok további jellemzője a könnyű karbantarthatóság. Ezeknél ugyanis, ha támadás történt, könnyen eltárolható az operációs rendszer aktuális állapota későbbi elemzés céljából és egy korábban elmentett, jól definiált operációs rendszer állapot (pillanatkép, snapshot) tölthető vissza. A virtuális honeypotok használata ráadásul kevésbé kockázatos, mivel ekkor kisebb a valószínűsége annak, hogy a támadó kárt tesz a tényleges gépben, amelyen a virtuális rendszer fut. A korábban említett WMware, illetve UML rendszerek virtuális gépek telepítésére, kezelésére alkalmasak. A velük megvalósított különböző típusú (különböző platformú, különböző operációs rendszert futtató) high-interaction honeypotokat (legyenek azok akár egyetlen fizikai eszközön) virtuális hálózatba lehet szervezni, ezt honeynetnek nevezzük. A QEMU virtualizációs megoldásra épülő Argos honeypotról a következő alfejezetben még szó esik. Mindezen előnyök mellett természetesen hátrányokkal is rendelkeznek a magas interaktivitású rendszerek, a támadó ugyanis elérheti, hogy azok más gépeket kezdjenek el támadni az interneten, ez pedig jogi és etikai problémákat vet fel. Másik hátrányuk, hogy a támadó képes lehet különbséget tenni a virtuális és valós gépek között és így megtörténhet az, hogy a támadó egy próbálkozás alkalmával felismeri a gyanús környezetet és felhagy a honeypot további támadásával, vagy a korábbitól eltérő módszerekkel próbálkozik annak érdekében, hogy „becsapja” a honeypotot. Végezetül az ilyen jellegű rendszerek egy támadás esetén tipikusan memory dumpot készítenek, vagyis elmentik a rendszer memóriájának aktuális állapotát, de az abban rejlő információk kinyerésére már nem alkalmasak, így azt nekünk kell analizálnunk. Sajnos erre a feladatra jelenleg is kevés eszköz áll rendelkezésre és jelenleg is intenzív kutatás zajlik az említett területen.

2.4 Az Argos high-interaction honeypot Az Argos honeypot [1] fizikai gépen futó virtuális környezetben működik. Alapját a már említett QEMU virtualizációs rendszer jelenti. A QEMU egy nyílt forráskódú processzor emulátor program, amely segítségével Linux rendszeren futtatási környezet emulálására nyílik lehetőség, amely egy kernel modul hozzáadásával közvetlenül a processzoron (kernel módban) képes az emulációt végezni úgynevezett dynamic translation technikát használva. 16

Az Argos tehát e felett működik és monitorozza az emulált rendszer hálózati tevékenységét. Erre úgynevezett dinamikus fertőzés analízis (dynamic taint analysis) technikát használ, vagyis első lépésként az összes hálózatból érkező forgalmat megjelöli. Az így megjelölt forgalmat ezt követően végigköveti a memóriában és ha azt észleli, hogy a korábban megjelölt forgalom részét képező valamely adatot arra használtak, hogy azzal befolyásolják a végrehajtás folyamatát, vagyis a támadó beavatkozott a rendszer futásába, akkor az Argos ezt detektálja és generál a támadásról egy memória lenyomatot. Ez arról tartalmaz információt, hogy mi okozta a program működésének normálistól való eltérését és ebből a támadás során végrehajtott műveletekre lehet következtetni. Az Argos által detektált esemény leggyakrabban egy buffer overflow következtében kialakuló memória terület átírás, amely lehet például egy JMP (jump), vagyis ugró utasítás beszúrása a támadó által elhelyezett kódra. Ezt elsősorban speciálisan formázott bájtsorozatok célpontnak való küldésével éri el a támadó. Fontos megjegyezni, hogy az Argos nem a memória területek átírásakor, hanem ezen területek használatakor detektálja a támadást. Az ismertetett megoldás legnagyobb előnye az, hogy úgy vagyunk képesek támadásokat detektálni, illetve azokat felderíteni, hogy nem rendelkezünk azokról semmiféle előzetes információval. Ez nem teljesül a low-interaction honeypotokra.

2.5 Low-interaction honeypotok A low-interaction honeypotokra számos megoldás létezik, fontos jellemzőjük a könnyű telepíthetőség és karbantarthatóság, nem igényelnek számottevő erőforrást. Az informatikai biztonság terén kevésbé jártas személy is könnyen létrehozhat egy akár több száz low-interaction honeypotból álló hálózatot. Egy alacsony interaktivitású honeypot csak korlátozott hozzáférést képes biztosítani egy adott operációs rendszerhez, ugyanis nem egy komplett rendszert emulál, hanem csak annak néhány szolgáltatását. Emiatt a tulajdonságuk miatt nem alkalmasak 0-day exploitok felderítésére. Ehelyett viszont hatékonyan használhatók a már ismert exploitok detektálására, illetve annak mérésére, hogy a rendszert milyen gyakran érik külső támadások. Az „alacsony interaktivitású” jelző tehát azt jelenti, hogy a honeypot egy bizonyos fokig megpróbálja a támadót félrevezetni, de az nem jelent teljes értékű rendszert. A

low-interaction

honeypotok

tipikusan

csak

az

emulált

hálózati

szolgáltatásokhoz feltétlenül szükséges internet protokollokat implementálják, úgy, mint a hálózati rétegben elhelyezkedő IP (Internet Protocol) vagy a transzport rétegben 17

található TCP (Transmission Control Protocol), illetve UDP (User Datagram Protocol) protokollokat. Gyakori még az alkalmazás szintű protokollok megvalósítása, mint a HTTP (Hypertext Transfer Protocol) vagy az FTP (File Transfer Protocol) protokollok. Az alacsony interaktivitású honeypotok kisebb kockázatot jelentenek egy éles rendszerben, mint high-interaction típusú társaik, mivel a támadó nem tud betörni ezekbe a rendszerekbe. Másfelől ez a tulajdonság jelenti a hátrányukat is, mert egy sikeres exploitálás alkalmával nem képesek például egy root shellt kiszolgálni a támadónak. A low-interaction honeypotok koncepcióját érdemes egy konkrét honeypot megoldáson keresztül áttekinteni, amelyre alkalmas például a Nepenthes.

2.6 A Nepenthes low-interaction honeypot A Nepenthes honeypot felépítését hivatott mutatni a 2. ábra:

2. ábra - A Nepenthes honeypot felépítése [1]

Ahogy a fenti ábrán látható, a Nepenthes [1] és általánosságban a többi lowinteraction honeypot moduláris felépítésű. Az egyes modulok a támadás folyamatának különböző fázisaihoz tartoznak és a támadás feldolgozási láncának megfelelő sorrendben kapcsolódnak egymáshoz. Amikor egy támadó, például egy automatikusan terjedő malware megpróbálja a honeypot által emulált sebezhetőséget kihasználni, akkor a Nepenthes ugyanúgy reagál, mintha az egy valós rendszer lenne. A támadó malware a sebezhetőség kihasználásához szükséges exploit mellett tartalmaz egy úgynevezett payloadot, vagyis magyarul hasznos terhet. Ez a payload határozza meg, hogy a sikeres támadást követően a kódfuttatás során milyen tevékenység hajtódjon végre a célponton. A Nepenthes és általánossában a low18

interaction honeypotok esetében a payloadok futtatására nincs lehetőség, mivel nem valódi rendszerek (futtatáskor nyilván azonnal fény derülne a payload szándékára), az egyetlen lehetőségük, hogy megpróbálják „kitalálni” a payloadból a támadó szándékát, amely leggyakrabban egy bináris letöltését jelenti. A malware által tartalmazott payload tipikusan kódolva van, hogy az ne legyen észrevehető a tűzfalak, antivírus szoftverek, illetve behatolás detektáló rendszerek által és így beengedjék a káros forgalmat a belső hálózatba, illetve az áldozat gépére. A leggyakoribb és legegyszerűbb kódolási módszer az úgynevezett XOR-kódolás. Ez annyiból áll, hogy a payloadnak (esetleg az exploit egy részének is) minden egyes bájtját „össze XOR-ozzuk” (Exclusive OR, kizáró VAGY művelet) egy általában véletlenszerűen generált kulccsal (encoding key). A kulcs hossza 32 bites rendszereken általában 4 bájt, míg 64 bites rendszereken 8 bájt, mivel így éppen elférnek a processzor adott regiszterében. Az XOR-kódoláson kívül még számos kódolási mechanizmus létezik, amelyek architektúránként is különböznek. Vannak például olyanok is, melyek úgy kódolják a payloadot, hogy az csak nagybetűs vagy csak kisbetűs ASCII (American Standard Code for Information Interchange) karaktereket tartalmazzon. Egy közös jellemzőjük azonban van, mégpedig hogy a „null” karaktert (ASCII kódja hexadecimálisan:

0x00)

mindegyik

kódoló

eliminálja,

mivel

a

támadandó

alkalmazásban található string feldolgozó műveletek „elronthatják” a payloadot. Ez amiatt lehetséges, mert a stringek végét a „null” karakter jelöli. Ezen felül természetesen más tiltott karakterek is lehetnek, amelyeket kiszűr az alkalmazás, ezt a malware kódolójának figyelembe kell vennie. Miután az áldozat gépén lehetővé vált a kódfuttatás az exploit által, az első lépés az exploitban korábban elhelyezett kulcs segítségével dekódolni a payloadot, így az már végrehajthatóvá válik. A dekódolás műveletét is természetesen tartalmazza az exploit. Ezt követően lefut a payload által tartalmazott művelet a célponton, amely így végrehatja a malware által meghatározott műveleteket. Visszatérve a Nepentheshez az ábrán látható, hogy az tartalmaz egy fő modult, ez a honeypot magja (Nepenthes Core modul). Ez a modul felelős a hálózati interfész kezeléséért, a hálózati portok lefoglalásáért (a példán TCP portok vannak felsorolva), illetve ezeken keresztül fogadja a hálózatból érkező csomagokat. Ezeken kívül a fő modul felelős a többi modul működésének összehangolásáért is. A központi rész úgy szerez tudomást a többi modulról, hogy azok regisztrálják magukat a Nepenthes Core modulban. 19

A moduloknak a következő típusait különböztethetjük meg: •

vulnerability - sebezhetőséget emuláló modulok,

•

shellcode parsing - shellkód értelmező, elemző modulok,

•

fetch - letöltésért felelős modulok,

•

submission - a letöltött malwarek tárolásáért felelős modulok, illetve

•

logging - naplózó modulok.

A korábbi ábrán jól látható, hogy a Nepenthes által kezelt portokon beérkező forgalmat a honeypot magja a vulnerability (sebezhetőségi) modulok felé továbbítja (vuln-* nevű modulok). Ezek felelősek a hálózati szolgáltatások sebezhetőségeinek emulálásáért. Ebből is jól látszik, hogy ahelyett, hogy egy teljes értékű rendszert valósítanánk meg, annak csak a támadás szempontjából szükséges részeit emuláljuk. Ezek a modulok valósítják meg a támadóval való kommunikációt és olyan viselkedést tanúsítanak kifelé, mintha egy valós rendszertől érkezett volna a válasz. Itt látszik a low-interaction honeypotok egy másik nagy előnye is, vagyis, hogy tetszőleges szolgáltatások sebezhetőségeit tudjuk összegyűjteni egy alkalmazásban (akár különböző operációs rendszerekét is), ahogy a vulnerability modulok is számos, egymástól gyökeresen eltérő szolgáltatás sebezhetőségeit valósítják meg. Ha valamely vulnerability modulnál sikeres volt a támadási kísérlet, akkor a modul a támadó által az üzenetében elhelyezett payloadot (shellkódot) a shellcode parsing elnevezésű modulok felé továbbítja (shellcode-* kezdetű modulok). A payload elnevezés alapvetően az exploit lényegi részét jelenti, de mivel ez leggyakrabban egy shellkódot tartalmaz, ezért nevezhetjük egyszerűen shellkódnak is. Ezek a modulok analizálják a támadó által küldött, egyelőre még kódolt shellkódot és megpróbálják „kitalálni” annak szándékát. Ezt a feladatot tipikusan reguláris kifejezéssel történő mintaillesztéssel végzik. Előbb a mintaillesztéssel meghatározzák az alkalmazott kódolót, majd az ahhoz tartozó dekóderrel – felhasználva a modul által a payloadból kicsomagolt kulcsot – dekódolják a shellkódot. Ezt követően szintén mintaillesztéssel (patternek használatával) próbálják meg kinyerni a shellkód által tartalmazott műveleteket. Ilyenkor gyakran alkalmazott rendszerhívásokra keresnek rá, mint például a CreateProcess() függvény, amely – mint a nevéből is kiderül – egy új folyamatot hoz létre a rendszerben. A low-interaction honeypotok ezen kívül tipikusan alkalmasak URL-ek (Uniform Resource Locator) detektálására is. Bináris letöltése esetén miután az adott

20

URL-t sikerült „kicsomagolni” a kódból és ezzel meghatározni a bináris helyét, a Nepenthes letölti a futtatható állományt a megadott helyről, esetleg a támadó kódjában szereplő autentikációs információkat (mint felhasználónév, jelszó) felhasználva a megadott protokoll segítségével, majd eltárolja azt például a helyi fájlrendszerben, egy adatbázisban, vagy feltölti egy víruskereső cég analizáló alkalmazása számára egy webes interfészen keresztül. Az URL alapján történő letöltésre a fetch (vagy download) modulok hivatottak. Ezek különböző protokollokat használhatnak, úgy, mint a HTTP, az FTP, a TFTP (Trivial File Transfer Protocol) vagy egyéb malware-specifikus protokollok. A sikeresen letöltött malware eltárolásáról is gondoskodni kell, erre szolgálnak az ábrán is látható submission (submit-* elnevezésű) modulok. A Nepenthes a feldolgozás és letöltés során a támadó által használt Windows shell parancsokat a beépített shell emulátorával képes értelmezni. Ez a shell természetesen nem egyenértékű egy valós rendszer parancssori bemenetével. Mivel egy fájl letöltésének legegyszerűbb módja az, hogy a malware előbb létrehoz egy ideiglenes parancsállományt, majd azt futtatja, ezért a Nepenthes a shell mellett virtuális fájlrendszert is létrehoz és támogatja a batch fájlok (kötegelt állományok) létrehozását és futtatását is. A Nepenthes és más low-interaction honeypotok képesek logolni a sikeres és sikertelen támadási kísérleteket egyaránt. A logolás is történhet egy helyi fájlba vagy adatbázisba, küldhet e-mailben értesítést a támadásról stb. Fontos, hogy a Nepenthes csak eltárolja a letöltött binárist, de nem futtatja le azt. Így a malware nem tud kárt okozni a rendszerben, igaz Linuxos környezetben nem is lenne képes a működésre. A Nepenthes esetében az úgynevezett logging modulok végzik a detektált támadási kísérletek részleteinek naplózását. Az ábrán az ehhez tartozó modulok a „logdownload”, illetve „log-surfnet” elnevezésű modulok. Az ábrán egyéb komponensek is láthatók, amelyek további funkciók megvalósításáért felelősek, mint például a DNS (Domain Name System) névfeloldás.

2.7 High- vs. low-interaction honeypotok Az 1. táblázat az eddig ismertetett két fő honeypot típust hasonlítja össze néhány meghatározó tulajdonság mentén.

21

Támadóval való interakció szintje Emuláció szintje A támadó átveheti-e a rendszer fölötti irányítást

High-interaction

Low-interaction

honeypotok

honeypotok

magas

alacsony

komplett rendszer

sebezhető szolgáltatások

átveheti

nem képes átvenni

alkalmasak

nem alkalmasak

mentesek a

előfordulhatnak téves

vakriasztásoktól

riasztások

általában könnyű

általában könnyű

0-day exploitok detektálására alkalmasak-e Téves riasztások Telepítés/karbantartás

nagyobb, mint a lowErőforrásigény

interaction honeypotok

alacsony

esetében Skálázhatóság Információ kinyerése a támadásról

gyengén skálázhatók

jól skálázhatók

általában nem automatikus, emberi

automatikus

erőforrást igényel 1. táblázat - High- és low-interaction honeypotok összehasonlítása

2.8 Honeypotok alkalmazása SOHO környezetben A SOHO rövidítés az angol Small Office/Home Office kifejezésből származik, amely magyarul kisebb irodai/otthoni számítógépes hálózatot, környezetet jelent. A SOHO környezet alatt alapvetően olyan hálózatot érthetünk, amelyben néhány hálózati eszköz, tipikusan néhány PC, notebook, hálózati nyomtató, valamint esetleg smartphone vagy VoIP (Voice over IP) készülék kapcsolódik egy központi routerhez, amely router jelenti egyben az első védelmi vonalat is a belső hálózat felé. Tipikusan az otthoni hálózat, illetve a néhány főt számláló kisvállalkozások hálózatai tekinthetők SOHO-nak, mely hálózatok jellemzően alacsony költségű, kis teljesítményű eszközökből épülnek fel.

22

Ebből következően SOHO környezetben a kis erőforrásigényű low-interaction honeypotok alkalmazhatók hatékonyan. Mielőtt azonban a SOHO honeypot megoldásra kitérnék, a 3. ábrán egy lehetséges irodai/otthoni hálózatot vázolok fel.

3. ábra - Egy lehetséges SOHO hálózat

Ahogy az ábrán is látható, az internetről érkező támadások ellen az első védelmi vonalat a router tűzfala jelenti. Természetesen a tűzfal sem tud minden támadási kísérletet kiszűrni, ezért előfordulhat, hogy bizonyos malwarek átjutnak rajta a belső hálózatba, illetve maga a tűzfal is lehet célpont például abban az esetben, ha a router, az access point és a tűzfal egy eszközön van megvalósítva. Az említett malwarek ellen a hálózati eszközök tűzfalmegoldásai, illetve antivírus szoftverei nyújthatnak még védelmet. Annak érdekében azonban, hogy képet kapjunk a lokális hálózatba bejutó, illetve a már hálózatban lévő malwarek, wormok tevékenységéről, érdemes lehet a honeypot megoldás alkalmazása. Irodai/otthoni környezetben is alkalmazhatunk magas, illetve alacsony interaktivitású honeypotokat. High-interaction honeypot alkalmazásakor fizikai, illetve virtuális gép használata esetén is mindenképpen célszerű dedikált gépet használni erre a célra, mivel egyrészt egy sikeres támadás alkalmával a támadó nem fér hozzá a személyes adatainkhoz, másrészt a high-interaction rendszerek nagyobb erőforrásigénye miatt ekkor nem kell számolnunk az eszközök válaszidejének csökkenésével. 23

Mint ahogy azt már említettem, a low-interaction honeypotok használata hatékonyabb lehet a high-interaction honeypotokénál, ha az alacsony erőforrás szükségletet tekintjük elsődleges szempontnak. Ebből adódóan alacsony interaktivitású honeypotokat telepíthetünk routerekre, PC-re, notebookra stb. Mivel irodai/otthoni környezetben a legelterjedtebb rendszerek a Windows rendszer különböző verzió, ezért fontos, hogy ezeknek a rendszereknek az ismert sebezhetőségeit emuláljuk. Függetlenül attól, hogy milyen megoldást használunk, SOHO környezetben annak a következő feltételeknek kell eleget tennie: •

olcsó hardware eszközökön is hatékonyan működjön,

•

tegye biztonságosabbá az internethasználatot, elsősorban a monitorozás és megelőzés terén,

•

legyen

egyszerű,

könnyen

telepíthető,

használható,

könnyen

konfigurálható, karbantartható, illetve •

ne zavarja az internethasználatot.

A honeypotok monitorozási funkciója szempontjából fontos kérdés, hogy hol helyezzük el azokat a belső hálózatban [1]. Egyik lehetőségként elhelyezhetjük azokat a tűzfallal védett környezeten belül. Ebben az esetben, ha a honeypot támadásokat észlel, akkor az tipikusan arra utal, hogy a hálózaton belül valamely gép már megfertőződött valamilyen automatikusan terjedő malware-rel, másrészt arra is utalhat, hogy egy támadónak sikerült bejutnia a lokális hálózatunkba. Másik lehetőség a honeypotok elhelyezésére, hogy ha közvetlenül az internetre kapcsoljuk azokat, kikerülve ezzel a tűzfalakat, illetve egyéb biztonsági megoldásokat. Ebben az esetben az internetről a routerünkhöz érkező valamennyi támadást detektálhatunk, mivel ezeket az ISP-k (Internet Service Provider), vagyis az internetszolgáltatók általában nem szűrik. Harmadik lehetőségként pedig kialakíthatunk a belső hálózatban úgynevezett DMZ-t (Demilitarized Zone, demarkációs zóna), melyen belül helyezzük el a honeypotot. A DMZ olyan fizikai vagy logikai alhálózat, amely egy plusz biztonsági réteget nyújt a megbízhatatlan közeg, vagyis az internet, illetve a megbízható helyi hálózat között. A forgalmat a DMZ-be, illetve a védendő alhálózatba a router tűzfala irányítja. Ezen megoldás esetében a tűzfalon túljutó, a DMZ-t célzó káros forgalmakat tudjuk rögzíteni. A megoldás igazi előnye az, hogy védi a hálózat többi részét abban az esetben, ha valakinek sikerül behatolnia, mivel a védendő alhálózat a DMZ-től

24

elkülönítve, például külön VLAN (Virtual Local Area Network) tartományban van megvalósítva. Ugyancsak DMZ-be célszerű helyezni a high-interaction honeypotokat, ha például 0-day exploitokat akarunk detektálni, illetve azok ellen akarjuk hálózatunkat védeni. Végül honeypotokból álló hálózatot (honeynetet) is kialakíthatunk a demarkációs zónában, ha a sokrétű védelem is cél. SOHO honeypotra jó példa a korábban részletesebben is ismertetett Nepenthes SOHO routeren, OpenWrt környezetben való alkalmazása [2]. Ebben az esetben egy beágyazott

eszközökre,

minimális

erőforrás-használatra

optimalizált

verzióját

használhatjuk a Nepenthesnek (az említett platformhoz rendelkezésre áll telepíthető verzió). Az OpenWrt platformról a 4. fejezetben még szó esik. Másik példa lehet az általam a szakdolgozat részeként fejlesztett low-interaction honeypot, melynek tervezését mutatom be a következő fejezetben.

25

3. Tervezés 3.1 A honeypot funkcionális tervezése 3.1.1 A programmal szemben támasztott követelmények Mint minden szoftver, úgy a következőkben bemutatandó honeypot alkalmazás készítése is a felhasználói igényekből, követelményekből indul ki. A korábbi fejezetekben megfogalmazott low-interaction honeypot funkciók ellátása, vagyis a hálózat monitorozása, illetve az automatikusan terjedő malwarek támadásainak gyűjtése az elsődleges célja a programnak. Az alkalmazással szemben elvárás, hogy egyszerűen telepíthető, konfigurálható és futtatható legyen. Képes legyen meghatározott típusú támadások fogadására, azok különböző paramétereinek rögzítésére. Felhasználói szempontból fontos kritérium, hogy az összegyűjtött információkat könnyen értelmezhető, áttekinthető struktúrában jelenítse meg, ugyanakkor lehetőség nyíljon az információk hatékony gépi feldolgozására is. Ezt kielégítendő, tartalmazzon egy kötött szerkezetű naplóállományt, illetve a naplóállományban lévő információkat felhasználóbarátan megjelenítő, kevésbé kötött struktúrájú kezelői felületet, amelyen keresztül a konfigurációs feladatok ellátására is lehetőség nyílik. Ennek érdekében a kezelői felület webes formában kerüljön megjelenítésre, mivel az információk megtekintéséhez ekkor csak egy böngészőre van szükség. További fontos szempont, hogy a webes felület az információkat alapesetben aggregáltan, összesítve jellemezze, ugyanakkor a részletes adatok kinyerésére is biztosítson lehetőséget. Fejlesztői szempontból követelmény, hogy hatékonyan továbbfejleszthető legyen, adjon lehetőséget a kibővítésére, lehessen a detektálható exploitok, malwarek körét egyszerűen bővíteni. Ezeket a feltételeket szem előtt tartva tehát legyen moduláris felépítésű, tulajdonképpen micro-framework (mikro-keretrendszer) jellegű alkalmazás. Mivel SOHO honeypotról van szó, ezért a lokális hálózat első védelmi vonalát jelentő routeren fusson, figyelembe véve a beágyazott rendszer által támasztott erőforrás, illetve teljesítmény korlátokat (processzor, memória, illetve háttértár korlátok). A kiválasztott, emulálandó sebezhetőségekkel kapcsolatban lényeges szempont, hogy azok Windows jellegű biztonsági hibákhoz kapcsolódjanak. Mivel az alkalmazásnak alapvetően nem sokrétű védelem biztosítás a célja, ezért a hangsúly

26

inkább arra helyeződik, hogy a program változatos legyen a detektálható támadások szempontjából. A tesztelést illetően fontos kritérium, hogy az emulált sebezhetőségek tesztelhetők legyenek a Metasploit Framework alkalmazás segítségével, vagyis az tartalmazzon kész exploitokat a kiválasztott sebezhetőségekhez. Mindezt összegezve tehát a honeypotnak a következő funkciókkal kell rendelkeznie: •

konfigurálhatóság konfigurációs állományon és webes interfészen keresztül,

•

a konfigurált portok figyelése támadás szempontjából,

•

exploitok detektálása és az azokhoz kapcsolódó sebezhetőségek emulálása,

•

az exploit eredményeként letöltendő malware naplózása (letöltés nem történik a szűkös háttértár kapacitásból adódóan),

•

a támadás körülményeinek naplózása,

•

valamint a naplóállomány webes felületen történő kiszolgálása, aggregálása táblázatok, illetve grafikonok formájában.

3.1.2 A megvalósítandó funkciók összegzése felhasználói szempontból A követelmények alapján a 4. ábrán látható use-case diagramot rajzoltam fel magamnak.

4. ábra - A honeypot alkalmazás use-case diagramja

Látható,

hogy

a

felhasználó

a

honeypot

által

gyűjtött

információk

megtekintésére tudja használni a programot. Az információkat mind a webes felületen, 27

mind a honeypot által generált nyers log (napló) állományból lekérdezheti. Ezen kívül konfigurálhatja a honeypotot, ezt a konfigurációs állomány módosításával vagy a webes felületen lévő megfelelő szekció használatával tudja elérni.

3.2 Architekturális tervezés A honeypot alkalmazás felépítését, illetve a rétegek egymáshoz való viszonyát szemlélteti az 5. ábra.

5. ábra - A honeypot alkalmazás felépítése és a rétegek kapcsolata

Mint ahogy az ábrán is látható, a honeypot réteges felépítésű, a legalsó réteget maga a hardware, vagyis a SOHO router jelenti. E fölött helyezkedik el az OpenWrt platform, amely a routeren futó Linux alapú, beágyazott eszközökhöz készült operációs rendszer. Továbbá itt helyezkednek el az alkalmazáshoz felhasznált C/C++ nyelvű programkönyvtárak. A következő rétegben található maga a low-interaction honeypot alkalmazás. Mint az a képen is látható, a honeypot tartalmaz egy fő modult (központi modult), illetve a sebezhetőségek megvalósításához, emulálásához szükséges további sebezhetőségi (vulnerability) modulokat. A központi modul feladata az alkalmazás elindítása, inicializálása, illetve a konfigurációs állományban található beállításoknak megfelelő vulnerability modulok betöltése a szintén a konfigurációs állományban megadott portokra. Tehát a megfelelő

28

hálózati portok lefoglalása is a központi modul felelőssége. Ha valamely modul betöltése során probléma lépne fel, akkor a hibát a fő modul kezeli. A rendszer igazi célját, vagyis a támadások detektálását a vulnerability modulok végzik. Minden kiválasztott sebezhetőséghez pontosan egy sebezhetőségi modul tartozik. A kiválasztott sebezhetőségekről részletesebb információkat egy későbbi alfejezetben közlök. Mint ahogy a fenti ábrából is kiderül, az általam létrehozott honeypot jelenleg 7 sebezhetőségi modult tartalmaz. Ezeket később tetszőlegesen lehet bővíteni további modulokkal. A vulnerability modulok első körben hallgatják a hozzájuk rendelt portot, figyelik az azon érkező forgalmakat. Minden beérkező kapcsolatot, illetve forgalmat rögzítenek, majd megvizsgálják, hogy az megfelel-e az általuk detektálható exploit mintájának. Ha az általuk detektálható exploitnak megfelelő mintájú támadás érkezik, akkor a sebezhetőségi modul elkezd olyan üzeneteket küldeni a támadó felé, melyeket egy éles sebezhető rendszer is küldene válaszul. Miután a támadó fél elküldte a payloadot, a modul lezárja vele a kapcsolatot és vizsgálat alá veszi a hasznos terhet. Ekkor még kiderülhet, hogy valójában nem exploit volt a beérkező forgalom, ebben az esetben a modul befejezi a payload vizsgálatát. Ha megerősítést nyer, hogy a forgalom exploitot tartalmazott, akkor a payload dekódolása, majd sikeres dekódolás esetén az így kapott shellkód értelmezése történik (valójában sikertelen dekódolás esetén is megpróbálja értelmezni a payloadot, hátha az kódolatlanul érkezett). A modul minden információt rögzít, amelyet sikerült kinyernie a payloadból. Az exploitok működésének és a modulok általi lekezelésének részletes lépéseit a későbbi alfejezetekben ismertetem, majd a tesztelés során egy konkrét példán keresztül bemutatom az adott modul által a támadásról rögzített információkat. Végül a legfelső rétegben a felhasználók felé megjelenített webes felületet láthatjuk. A webes megjelenítő felület a honeypot által generált log állományt dolgozza fel és jeleníti meg táblázatos, illetve grafikonos formában. A felületen lehetőség nyílik megtekinteni a létrehozott naplóállományt is, valamint konfigurálni a honeypotot. A program részletesebb architekturális tervét (a webes felület nélkül) a 6. ábra tartalmazza.

29

6. ábra - A honeypot architekturális felépítése részletesebben

Ha a fenti ábrát összehasonlítjuk a Nepenthes felépítését bemutató 2. ábrával, akkor sok hasonlóságot fedezhetünk fel. Ez nem véletlen, hiszen mindkét alkalmazás low-interaction típusú honeypot. Itt is van központi modul, illetve vulnerability modulok. A 2. ábrán látható shellkód modulok itt a dekóder és shellkód feldolgozó modulok „uniójának” felelnek meg. Az általam készített honeypot szemben a Nepenthessel nem tartalmaz sem letöltésért felelős (fetch), sem a letöltött fájlok tárolásáért felelős (submission) modulokat. Ezekre ugyanis nem volt szükség, hiszen a már említett szűkös háttértár kapacitásból adódóan a routeren futó honeypot nem tölt le semmit az internetről, hanem csak logolja azt. Természetesen itt is megtalálható a naplózást végző modul (logger). A fenti ábrán láthatjuk a már korábban is említett sebezhetőségi modulokat. Az 5. és 6. ábrán látható vulnerability modulokon kívül a honeypot tartalmaz még két további példa modult is (Vuln_Example_Tcp, Vuln_Example_Udp). Ezeknek csak annyi a szerepe, hogy egy sablont biztosítanak a további vulnerability modulok egyszerűbb létrehozásához, illetve mivel minimális működést is produkálnak (az első konkrétan egy rendkívül egyszerű webszerver, a második pedig egy időszerver), így segítségükkel ellenőrizhető a honeypot működése. Az említett példamodulok naplózást nem végeznek.

30

Az előbbi ábrán már láthatók az általam írt dekóder és shellkód értelmező modulok is. A képen a felső két dekóder 32, illetve 64 bites XOR dekódolást valósít meg. Az utolsó dekóderre csak azért van szükség, hogy ha a payload nem az előbbi két dekódernek megfelelő kódolóval volt kódolva, akkor a payloadot dekódolás nélkül, nyers formában is megvizsgálhassuk. A shellkód értelmezők közül az első a fájl letöltést és futtatást végző shellkódok detektálására, míg a második a shellel történő parancsvégrehajtás detektálására használható. A honeypot alkalmazása

összetettségéből

nélkülözhetetlen.

A

adódóan következő

az

objektum-orientált

alfejezetben

tehát

a

szemlélet program

objektummodelljét mutatom be, amelyen láthatóvá válnak az architekturális nézetben még rejtett építőelemek.

3.3 Az alkalmazás objektummodellje Az

objektum-orientált

szemléletnek

megfelelően

a

honeypot

minden

komponensét egy-egy osztály hivatott megvalósítani. Az alkalmazás statikus osztálydiagramja az UML (Unified Modeling Language) leíró nyelvvel megvalósítva a 7.1., 7.2., 7.3. és 7.4. ábrákon látható (az ábrák egymás folytatásai). Az ábrákon megfigyelhető a honeypotot alkotó osztályok szerkezete, valamint az osztályok egymással való kapcsolata, viszonyaik.

31

7.1. ábra - Az alkalmazás statikus osztálydiagramja

32

7.2. ábra - Az alkalmazás statikus osztálydiagramja

33

7.3. ábra - Az alkalmazás statikus osztálydiagramja

34

7.4. ábra - Az alkalmazás statikus osztálydiagramja

A fenti ábrákon látható osztályok feladatait az alábbi táblázatban foglalom össze, az osztályok attribútumainak és metódusainak részletes leírását a szakdolgozat mellékleteként csatolt webes formátumú dokumentumban ismertetem.

Osztálynév ApplicationListener

Leírás Az

alkalmazási

réteg

osztályainak közös ősosztálya.

35

kommunikációs

Értelmezi ConfigReader

a

konfigurációs

állományt

és

visszaadja a betölthető modulok nevét és portját egy ConfigRecord objektumban.

ConfigRecord

A betölthető modul nevét és portját tartalmazza. Dekóder osztály, amely valójában nem végez

Decoder_Generic_None

dekódolást. Abban az esetben van rá szükség, ha nem ismerhető fel a payload kódolója, mert ekkor nyers formában is megvizsgálhatjuk azt.

Decoder_Module

A dekóder modulok közös interfészét írja le.

Decoder_Module_Container

Dekóder modulokat tárol.

Decoder_x64_XOR_8byte

8 bájtos kulcsú XOR dekóder modul.

Decoder_x86_XOR_DWord

4 bájtos kulcsú XOR dekóder modul.

FTPSocketHandler

FTP kapcsolatot kezelő modul.

HTTPSocketHandler

HTTP kapcsolatot kezelő modul.

Listener

A hálózati kommunikációt biztosító osztályok közös interfészét írja le. Naplózást végez, segítségével minden modul kötött

formátumban

osztálydiagramon Logger

logolhat.

nincsenek

A

feltüntetve

fenti az

osztály metódusai azok nagy száma miatt, illetve azért, mert mindegyik gyakorlatilag csak a kapott szöveg megfelelő formátumban történő kiírását végzi. Shellkód értelmező modul. A fájl letöltést és

ShellcodeParser_DownloadExec

futtatást

végző

shellkódok

detektálására

alkalmas. Shellkód értelmező modul. A shellel történő ShellcodeParser_Exec

parancsvégrehajtást

végző

shellkódok

detektálására alkalmas. ShellcodeParser_Module

A shellkód értelmező modulok közös interfészét írja le.

ShellcodeParser_Module_Container Shellkód értelmező modulokat tárol. TcpTransportListener

TCP kapcsolatokat kezelő osztály.

36

A szállítási réteg kommunikációs osztályainak

TransportListener

közös ősosztálya.

UdpTransportListener

UDP kapcsolatokat kezelő osztály. Sebezhetőséget

Vuln_* (vulnerability modulok)

emuláló

modulok.

A

sebezhetőségekről részletesebb információval a következő alfejezet szolgál. Példa modul, nagyon egyszerű webszervert

Vuln_Example_Tcp

valósít meg. Példa modul, nagyon egyszerű időszervert

Vuln_Example_Udp

valósít meg. A vulnerability modulok közös interfészét írja

Vuln_Module

le.

Vuln_Module_Regex

Reguláris kifejezés feldolgozó osztály.

Vuln_Module_Thread

Szálkezelő osztály a többszálú vulnerability modulok számára. A honeypot központi modulja, a további

WrtHoney

modulok betöltéséért felelős. 2. táblázat - Az alkalmazás osztályainak leírása

3.4 A választott sebezhetőségek A következő leírásban a honeypothoz választott sebezhetőségeket, illetve az azokhoz kapcsolódó publikus exploitokat [3] foglalom össze. A sebezhetőségek kiválasztásánál az elsődleges cél azok változatossága volt. Minden sebezhetőség Windows rendszert vagy azon futó alkalmazást érint. Exploit neve: ms02_039_slammer Vulnerability modul neve: Vuln_Mssql Sebezhetőség leírása: Buffer túlcsordulás kódfuttatást tesz lehetővé a Microsoft SQL Server 2000 alkalmazásban. Hibajegy: MSB MS02-039 Közzététel időpontja: 2002. július 24.

37

Exploit neve: mysql_yassl_hello Vulnerability modul neve: Vuln_Mysql_Yassl Sebezhetőség leírása: Buffer túlcsordulás a yaSSL nevű SSL (Secure Socket Layer) programkönyvtárban a MySQL alkalmazással használva távoli kódfuttatást tesz lehetővé. Hibajegy: CVE-2008-0226 Közzététel időpontja: 2008. január 4. Exploit neve: aim_triton_cseq Vulnerability modul neve: Vuln_Sip Sebezhetőség leírása: Buffer túlcsordulás az AIM (AOL Instant Messenger) Triton alkalmazásban távoli kódfuttatást tesz lehetővé. Hibajegy: CVE-2006-3524 Közzététel időpontja: 2006. július 10. Exploit neve: xlink_nfsd Vulnerability modul neve: Vuln_Xlink_Nfsd Sebezhetőség leírása: Buffer túlcsordulás az XLink Omni-NFS (Network File System) szerverben távoli kódfuttatást tesz lehetővé. Hibajegy: CVE-2006-5780 Közzététel időpontja: 2006. november 6. Exploit neve: sasser_ftpd_port Vulnerability modul neve: Vuln_Sasser_Ftpd Sebezhetőség leírása: A Windows XP-s Sasser worm FTP „szolgáltatásában” (FTP szerver komponensében) lévő hiba a stack túlírását, ezzel pedig kód futtatását teszi lehetővé. Hibajegy: OSVDB-6197 Közzététel időpontja: 2004. május 10. Exploit neve: cesarftp_mkd Vulnerability modul neve: Vuln_Cesarftp Sebezhetőség leírása: Buffer túlcsordulás a CesarFTP szerveralkalmazásban alkalmazás összeomlást, illetve távoli kódfuttatást tesz lehetővé.

38

Hibajegy: CVE-2006-2961 Közzététel időpontja: 2006. június 12. Exploit neve: ms03_051_fp30reg_chunked Vulnerability modul neve: Vuln_ms03_051_fp30reg Sebezhetőség leírása: Buffer túlcsordulás a Microsoft FrontPage Server Extensions alkalmazásban kódfuttatást tesz lehetővé. Hibajegy: MSB MS03-051 Közzététel időpontja: 2003. november 11. Látható, hogy a fenti exploitok mindegyike buffer túlcsorduláson alapuló technikát használ, ezért a következő fejezetben ennek ismertetésével folytatom.

3.5 Az exploitok működése Ahogy az előbb említettem, a fenti leírásban található exploitok mindegyike a buffer túlcsordításon alapul, ezzel lehetővé téve a kódfuttatást. A túlírt bufferek mindegyik esetben a stacken találhatók. Az alkalmazások hibáinak kihasználása során a stacken allokált bufferek túlírása a leggyakoribb exploitálási technika. Természetesen ezen kívül még számos kódfuttatást lehetővé tevő eljárás létezik, ezek azonban kevésbé gyakoriak. A buffer túlcsordításos technika előnye az, hogy viszonylag egyszerűen, rövid idő alatt lehet ilyen módszerrel exploitokat létrehozni. A honeypot vulnerability moduljai működésének megtervezéséhez mindenképpen szükséges az említett exploit működés ismerete, ezért most ennek ismertetésére kerül sor.

3.5.1 A stack A stack, vagy más néven verem memória egy futtatás alatt álló program, vagyis egy processz memóriájának része. A processz memóriájának további részei az úgynevezett text és a data terület [4]. A text terület az a memória rész, ahol a programkód, illetve egyéb csak olvasható adatok helyezkednek el, a data terület pedig az a rész, ahol inicializált, illetve inicializálatlan adatokat tárolunk, mint például a globális változók. A text és data területekkel a továbbiakban nem foglalkozunk. A stack LIFO (Last In First Out) szervezésű memóriaterület, vagyis mindig az utoljára „betett” adat lesz a verem tetején, így az érhető el először. Két alapvető művelet tartozik a veremhez, ezek a PUSH, illetve POP műveletek. A PUSH művelet egy elemet 39

tesz a stack tetejére, ezáltal növelve annak méretét, a POP művelet pedig kiveszi a legfelső elemet a stackből, így annak mérete csökken. A memóriának ezen a részén a függvények paramétereit és lokális változóit, valamint bizonyos processzor regiszterek tartalmát tároljuk ideiglenesen. A stack általános felépítését [5] mutatja a 8. ábra.

8. ábra - A stack általános felépítése

A fenti ábrán látható, hogy egy programban egy függvény meghívásakor előbb a függvény paramétere(i) kerül(nek) be a stackbe (feltéve, hogy a függvénynek van paramétere). Mivel egy függvény hívásakor a program végrehajtása általában a text terület korábbitól eltérő részén folytatódik, ezért szükség van a text terület aktuális címének eltárolására, ahova majd vissza kell térni a függvény befejeztével. A text terület aktuális címét (vagyis az aktuálisan végrehajtandó utasítás címét) tartalmazza az EIP processzor regiszter. Ezt a visszatérési címet tehát le kell menteni a stackre még a függvény hívása előtt. A stacken megkülönböztethetünk stack frame-eket. Egy stack frame azokat az adatokat jelenti, amiket egy függvény hívása során beteszünk a stackbe, majd a függvény visszatérésekor kiveszünk onnan. A stack frame-ekhez tartozik egy úgynevezett frame pointer, amit az EBP regiszter tárol. Ez a frame pointer általában a függvény lokális változói által lefoglalt memóriaterület kezdetére mutat a stackben.

40

Mivel egy új függvény hívásakor az EBP értéke megváltozik, ezért azt a függvény futásának elején le kell menteni a stackbe, így az EBP egyel korábbi értéke később visszaállítható. Miután a régi EBP értéket lementette az új függvény, annak tartalma frissítésre kerül az új függvény lokális változóinak kezdetére. Ezek szintén láthatók a fenti képen. Innentől kezdve az új függvény végrehajtása során az EBP értéke nem változik. Az ábrán tulajdonképpen az „új” függvényként emlegetett függvény stack frame-je látható, az őt meghívó („régi”) függvény stack frame-je pedig ehhez hasonló és az „új” függvény paraméterei alatt helyezkedne el. Végül az EBP mentett értéke fölött (ettől már különbözik az aktuális értéke) helyezkednek el a függvény lokális változói, amelyeket buffereknek is nevezhetünk. A stack tetejének címét az ESP regiszterben tároljuk. Összefoglalva tehát az említett 3 regiszter (Intel processzorok esetén) a következőket tartalmazza [6]: •

EIP (Instruction Pointer): A futó program aktuális utasításának címét tartalmazza, függvény hívásakor az EIP utolsó értéke lementésre kerül a stackbe, mint visszatérési cím.

•

EBP (Base Pointer vagy Frame Pointer): A meghívott függvény lokális változóinak kezdetére mutat. Azért van rá szükség, mert a függvény lokális változóinak címzésénél így mindig csak az EBP-hez képesti eltolást (offsetet) kell megadni. Régi értéke mentésre kerül új függvény hívása esetén, új értéke pedig az új függvény lokális változói címének eleje.

•

ESP (Stack Pointer): Mindig a stack tetejére mutat. A PUSH művelet csökkenti az értékét, míg a POP művelet növeli azt. (Ez azért van így, mert a stackben az adatok elhelyezése a memória címek szerint csökkenő sorrendben történik.)

Ahhoz, hogy a stack működése még érthetőbb legyen, érdemes egy konkrét példát is megnézni. Ehhez tekintsük az alábbi rendkívül egyszerű C nyelvű példaprogramot: void function(int a, int b) { char buffer2[4]; }

41

int main(int argc, char * argv[]) { char buffer1[4]; function(1, 2); return 0; }

A „function” elnevezésű függvény visszatérése előtt a stack a 9. ábrán látható módon fog felépülni [5].

9. ábra - A stack felépítése a példaprogram esetén

Az előbbi ábrán jól megfigyelhető a már korábban is említett „régi”, illetve „új” függvények stack frame-je. A stack frame-ek tehát az esetleges paraméterekből, a visszatérési címből, a frame pointer mentett értékéből, illetve a bufferekből állnak. Az ábrán továbbá láthatók a példakódban szereplő paraméterek listái, illetve a függvények lokális változói. A képen még az is látható, hogy a később meghívott függvény mentett EBP értéke ténylegesen a korábbi EBP értéket tartalmazza, illetve, hogy az érték mentését követően került sor az EBP frissítésére, amely az akkori ESP értéket kapta meg. A később meghívott függvény bufferének (buffer2) megtörtént a memória lefoglalása, így az ESP értéke a buffer „tetejére” mutat (stack teteje), ugyanakkor az EBP értéke nem változott.

3.5.2 Kódfuttatás buffer overflow eredményeként Ahhoz, hogy egy alkalmazás biztonsági hibáját kihasználva rá tudjuk venni az áldozat gépet, hogy egy általunk megírt kódot futtasson le, két dolog szükséges:

42

egyrészt el kell valahogyan helyezni a futtatható kódot a memóriában, másrészt rá kell venni a hibás programot, hogy ezen a kódrészleten folytassa a futását. A memóriát, ahol a kódot elhelyezzük, jelen esetben a stack jelenti. Ahhoz pedig, hogy az alkalmazás ezt le is futassa (hiszen normális működés esetén a futó kód a text területen van, a stacken nem történik utasítás végrehajtás), az aktuális függvényhez tartozó visszatérési címet kell átírni úgy, hogy az az általunk elhelyezett kódra mutasson. A buffer túlcsordulást kihasználó exploitok általánosságban így működnek [6]. Az aktuális függvény visszatérési címének átírásához tehát csak annyi szükséges, hogy az egyik lokális bufferét (ez fölötte helyezkedik el a veremben) írjuk túl annyi bájttal, hogy az így stackbe írt adat „érje el” a visszatérési címet. Ekkor természetesen az EBP mentett értékét is biztosan felülírjuk. A buffer túlírás általában azért lehetséges, mert a programban valahol nem történik meg a bemeneti adat hosszának ellenőrzése, korlátozása. Ilyen hibára jó példa az strcpy() (karakterlánc másoló) függvény alkalmazása előzetes hossz ellenőrzés nélkül, ugyanis az említett függvény ilyet nem végez. Ezek alapján tehát az exploitok által a bufferbe írt adat egyrészt tartalmazza a futtatandó kódot (vagyis a shellkódot). A shellkód azonban nem biztos, hogy kitölti egymaga a rendelkezésre álló buffert, ezért a bufferben lévő maradék helyet kitöltik valamilyen értelmetlen adattal (például csupa „A” karakterrel). Így már megtelítik a buffert, minden további beírt adat már a bufferen kívülre esik. Ez után jön az a tartalom, ami felülírja a mentett EBP értéket. Ez Intel x86 architektúrájú rendszereknél 4 bájtot jelent. Ezt a 4 bájtot is tipikusan értelmetlen adattal tölti fel az exploit. Ezzel végül elérik a visszatérési címet, amely az említett rendszerek esetén szintén 4 bájt hosszúságú. Ebből következően az exploit által memóriába írt tartalom következő 4 bájtja egy olyan cím lesz, amely a korábban elhelyezett shellkódra mutat. Mivel sokszor nehéz pontosan a shellkód elejére mutatni (ez pedig nélkülözhetetlen, különben nem a kívánt művelet hajtódik végre), ezért annak elejére még tipikusan NOP utasításokat (No Operation) helyeznek el, mely utasítások nem tesznek semmit, csak processzoridőt használnak. Így elég csak körülbelül a NOP utasítások sorozatának közepére mutatni. A NOP utasítások sorozata könnyen detektálható a behatolás detektáló rendszerek által, ezért a NOP-ok eliminálására számos összetettebb megoldás is létezik, illetve az ismertetettnél bonyolultabb exploit működés is elképzelhető. Az exploit shellkódja tipikusan a már említett CreateProcess() rendszerhívást futtatja Windows rendszereken, amelynek segítségével leggyakrabban egy shell 43

folyamat kerül elindításra. Ez a shell folyamat pedig valamilyen hálózati protokollt alkalmazva letölti, majd elindítja a malwaret. Az exploit által memóriába írt adat összefoglalva tehát a következőképpen néz ki: [NOP utasítások + shellkód + buffer maradék helyét kitöltő értelmetlen adat] [EBP-t felülíró értelmetlen adat] [visszatérési címet felülíró valamely korábbi NOP utasítás címe]. A visszatérési cím x86 rendszerekben little-endian bájtsorrendben van tárolva, vagyis a cím végére kerülnek a kisebb helyértékű bitek. Az így kialakuló verem tartalmat [6] igyekszik szemléltetni a 10. ábra.

10. ábra - Az exploit által kialakított stack tartalom

Amennyiben az előbbi ábrán látható stack frame-hez tartozó függvény visszatér, akkor a program végrehajtása a már módosított visszatérési címen folytatódik, vagyis valamelyik NOP utasításon. A NOP utasításokon a program „végiglépeget”, majd a vezérlés végül a shellkódra kerül, amely így elvégzi a malware által meghatározott tevékenységet. Mint

azt

láttuk,

a sebezhetőséget

tartalmazó

hálózati

szolgáltatások,

alkalmazások valamely bufferének túlcsordítását speciálisan összeállított üzenetekkel lehet elérni. Ez azonban sokszor önmagában nem elég, hiszen elképzelhető, hogy az alkalmazás a kezdeti állapotában nem sérülékeny. Ezért, ha egy állapotgépként fogjuk fel azt, akkor az exploitnak még a speciálisan összeállított üzenet előtt el kell vinnie az alkalmazást

annak

sebezhető

állapotába.

Ez

általában

egy

megfelelő

üzenetszekvenciával érhető el, amely jól definiált szakaszokból (stage) tevődik össze. A magasabb szintű programnyelvek megjelenésével együtt alakult ki a kivételkezelés lehetősége is a programokban. Egy másik jellegzetes típusú exploit az úgynevezett SEH (Structured Exception Handling) alapú exploit [7], amely esetében a 44

kivételkezelő struktúrák kerülnek felülírásra, ezzel elérve a shellkód futtatását. Ilyen technikán alapul a korábban már ismertetett „aim_triton_cseq” elnevezésű exploit.

3.6 Vulnerability modulok működésének tervezése A honeypot alkalmazás vulnerability moduljai működésének dinamikus modellje látható a 11. ábrán szereplő UML szekvencia diagramon.

11. ábra - Vulnerability modulok működésének dinamikus modellje

Ahogy az ábrán is látható, a vulnerability modulok működésüket az „emulateVulnerability” metódus meghívásának hatására kezdik meg (természetesen előzetesen a honeypot központi modul már létrehozta azokat), ez minden „Vuln_Module” interfészt implementáló modulra igaz. Ebben a metódusban

45

inicializálást követően egy végtelen ciklus indul el, amelyben a modul fogadja a hálózatból érkező üzeneteket. Miután a modul fogadta az üzenetet, azt egy bufferben tárolja, majd meghívja a „getPayloadFromExploit” metódusát, amelynek átadja a buffert. (A metódusok paramétereit csak a külső objektumok metódusainak hívása esetén tüntettem fel.) A „getPayloadFromExploit” nevű metódusban a modul egy reguláris kifejezésre illeszti a buffer tartalmát, mely reguláris kifejezés a modul által detektálható exploitokra illeszkedik. Ebből adódóan, ha a buffer tartalma illeszkedik a reguláris kifejezésre, akkor a kapott üzenet exploitot tartalmaz. Ha ez igaz („[regexMatch() == 0]”), akkor egyrészt kicsomagoljuk a payloadot az exploitból, másrészt meghívjuk a modul „decodePayload” metódusát, ellenkező esetben a feldolgozás befejeződik. A „decodePayload” metódus elsőként ellenőrzi, hogy felismerhető-e valamelyik kódoló mintája a kapott payloadban („[check() >= 0]”), és ha igen, akkor inicializálást követően meghívja a megfelelő dekódoló „decode” metódusát, amelynek átadja a buffer tartalmát, vagyis a payloadot. A dekódoló („Decoder_Module” interfészt valósítja meg) megpróbálja dekódolni a kapott tartalmat, majd visszaadja az eredményt egy „tempPayload” nevű bájt tömbben. Ez a „tempPayload” bájt tömb kerül átadásra a vulnerability modul „parseShellcode” nevű metódusának. Ebben a metódusban valamennyi shellkód értelmezővel megpróbáljuk kinyerni a payloadból a lényegi részt, vagyis azt a tartalmat, ami a végrehajtandó káros tevékenységre utal (URL, shell parancs). Ehhez a shellkód értelmezőknek (ezek a „ShellcodeParser_Module” interfészt implementálják) a „getUsefulContent” metódusát hívja meg a sebezhetőségi modul a korábban említett „tempPayload” paraméterrel. Ha a shellkód feldolgozó modul talált valamit, akkor azt logolja, illetve lehetőség nyílik ennek a tartalomnak a metódus általi visszaadására is, ez azonban opcionális. Ez az opcionális érték látható a fenti ábrán „usefulContent” néven. A dekóderek, illetve shellkód feldolgozó modulok konténer objektumokba vannak helyezve az egyszerű felhasználás érdekében, ez a fenti ábrán nincs jelölve. Az említett működés mellett a vulnerability modulok, a dekóderek és a shellkód feldolgozók is minden lépést naplóznak.

46

4. Implementálás 4.1 A választott programozási nyelv A honeypot alkalmazás implementálásához választott programozási nyelv a C/C++ nyelv volt. Mivel az alkalmazás a hálózati rétegben működik, ezért ennél alacsonyabb szintű nyelvre, hardware programozásra nem volt szükség. Az ennél magasabb szintű nyelvek, azok nagyobb erőforrás-szükséglete miatt nem jöhettek számításba. Mivel a honeypot tervezése során az objektum-orientált paradigmát használtam fel, ezért az implementáció során egy objektum-alapú rendszert kellett megvalósítani. Ehhez olyan nyelvre volt szükség, amely nyelvi szinten támogatja az objektum-orientált programozást, erre volt alkalmas a C++ nyelv. Ugyanakkor a felhasznált könyvtári függvények C-s változatát használtam, mivel ez a honeypot környezetét jelentő OpenWrt rendszerben már kezdetben rendelkezésre állt. A program webes megjelenítő felületének dinamikus részét PHP („PHP: Hypertext Preprocessor”) nyelven hoztam létre, a megjelenítést a HTML (HyperText Markup Language) leíró nyelv biztosítja minimális CSS (Cascading Style Sheets) használattal az oldal stílusának kialakítása végett. A webes felület automatikus generálását a naplóállományból a bash (BourneAgain SHell) parancssori script nyelvvel oldottam meg.

4.2 Az alkalmazás környezete Az implementált honeypotot egy Asus WL-500g Premium típusú routeren működtettem, amelyen előre telepített OpenWrt operációs rendszer futott. Az OpenWrt egy beágyazott eszközökhöz kifejlesztett Linux disztribúció [8], amely alacsony erőforrású környezetekre (tipikusan routerekre) lett optimalizálva. Az OpenWrt rendszer lényege, hogy egy statikus firmware létrehozása helyett egy szabadon konfigurálható szolgáltatásokkal,

platformot illetve

biztosít,

amely

alkalmazásokkal.

tetszőlegesen Segítségével

bővíthető

testreszabott

további működés

valósítható meg. A rendszer gyártófüggetlen, vagyis minden olyan eszközön képes futni, amely támogatja azt. Az OpenWrt fejlesztői szempontból egy frameworkkel egyenértékű, amelyre tetszőleges alkalmazás fejleszthető anélkül, hogy egy komplett firmwaret kellene létrehozni. 47

Az OpenWrt-re történő fejlesztés alapját a buildroot környezet jelenti. A buildroot környezet ahhoz szükséges, hogy különböző beágyazott rendszerekre (melyek különböző architektúrára és CPU-ra épülnek) tudjunk egyszerűen alkalmazásokat létrehozni. Ehhez a buildroot környezet olyan funkciókat valósít meg, mint például a keresztfordítás (cross-compilation) vagy a root fájlrendszer. Az OpenWrt legfrissebb kiadása a szakdolgozat írása idején a 10.03-as, Backfire kódnevű verzió volt. Ez a változat futott az általam használt routeren is. A honeypot fejlesztéséhez az említett buildroot környezetet alkalmazó SDK-t (Software Development Kit) használtam fel, amely szabadon letölthető az OpenWrt oldaláról (downloads.openwrt.org) kiadástól, verziótól és architektúrától függően. Az SDK-t használva csupán egy makefile megfelelő összeállítására van szükség, melynek segítségével a létrehozott alkalmazás a routerre automatikusan lefordítható [9]. A honeypot routerre történő telepítésének lépéseire a következő alfejezetben térek ki. Az általam használt SDK a brcm-2.4 router architektúrára készült változat volt, mivel ez kompatibilis az Asus router architektúrájával. Mivel a programok fordítása a fejlesztői gépen történik, ami esetemben egy x86-64-es architektúrájú rendszert jelentett, ehhez pedig nem állt rendelkezésre a szakdolgozat írás időpontjában az OpenWrt Backfire kiadáshoz SDK, ezért az azzal visszafelé kompatibilis egyel korábbi kiadás (8.09.2, Kamikaze) SDK-ját használtam. Az alkalmazás webes felületét a routerre telepített uHTTPd webszerver program szolgálja ki. A webes felületen megjelenő grafikonokat az RRDtool adatbázis alkalmazás hozza létre [10]. Az RRDtool elnevezés az angol round robin database kifejezésből származik és ahogy a neve is mutatja, egy olyan körkörös adatbázist jelent, amelybe ha új adatok kerülnek, akkor azok régieket szorítanak ki, vagyis az adatbázis mérete nem változik az időben. Az RRDtool időfüggő adatok tárolására, hatékony lekérdezésére és vizualizálására lett kitalálva. Nyílt forrású rendszer, mely rendelkezésre áll az OpenWrt platformra is, ahol parancssorból futtatható.

4.3 Fordítás, telepítés, futtatás A honeypot alkalmazás Linux rendszeren való fordításához első lépésként ki kell csomagolni a szakdolgozat mellékleteként szereplő WrtHoney.zip tömörített állományt. Ezt követően le kell töltenünk az OpenWrt oldaláról a keresztfordításhoz szükséges SDK-t, ez esetemben a http://downloads.openwrt.org/kamikaze/8.09.2/brcm48

2.4/OpenWrt-SDK-brcm-2.4-for-Linux-x86_64.tar.bz2 címen elérhető állomány volt. Ezt a fájlt is ki kell csomagolnunk, majd az így kapott könyvtárba belépve a package alkönyvtárba kell bemásolnunk a korábban kicsomagolt WrtHoney katalógust. Ezt követően az SDK főkönyvtárában ki kell adnunk a make parancsot, amely elvégzi az automatikus fordítást és létrehozza a telepítéshez szükséges csomagot. A csomag egy fájlként tartalmazza az alkalmazás összes komponensét, amelyet majd az OpenWrt csomagkezelő programjával egyszerűen telepíthetünk. A csomagkezelés a Linux-alapú rendszerek egyik lényeges funkcionalitása, amely segítségével gyakorlatilag egy parancsot kiadva tudunk alkalmazásokat telepíteni, legyenek azok a lokális gépen vagy az interneten. A csomagkezelők a csomagokat

felhasználva

általában

előkonfigurált

és

fordított

alkalmazásokat

installálnak. Az elkészült csomagot (WrtHoney_1.0_mipsel.ipk) a főkönyvtárból indulva a bin/packages/mipsel könyvtár tartalmazza. Innen már csak át kell másolnunk a fájlt a routerre, majd telepíthetjük is azt. A routerre bejelentkezve a telepítéshez a következő parancsot kell kiadnunk a csomag könyvtárában: opkg install WrtHoney_1.0_mipsel.ipk

Ezzel az alkalmazás települ alapesetben a /opt/wrthoney könyvtárba. Hasonlóan egyszerűen távolíthatjuk el az alkalmazást a routerről a következő parancsot kiadva: opkg remove WrtHoney

Az alkalmazás sikeres futtatásához szükségünk lesz a következő csomagokra is, amelyeket szintén telepítenünk kell – mint a honeypot függőségeit – abban az esetben, ha még nem állnak rendelkezésre a routeren (verzióban lehet eltérés): libstdcpp_4.3.3+cs-42_brcm47xx.ipk libpthread_0.9.30.1-42_brcm47xx.ipk

Ezen felül a /etc/opkg.conf konfigurációs állományban el kell helyeznünk az alábbi sorokat architekturális problémák miatt: arch all 1 arch mipsel 200 arch brcm47xx 10

Miután települt a program és rendelkezünk a szükséges függőségekkel, be kell lépnünk annak könyvtárába, amely alapértelmezetten a /opt/wrthoney könyvtár. A futtatáshoz (háttérben, daemonként futtatáshoz) itt kell kiadnunk a ./wrthoney.sh 49

start

parancsot. A honeypotot újraindítani a ./wrthoney.sh restart, leállítani pedig a

./wrthoney.sh

stop

paranccsal lehet. A honeypot naplóállományát tetszőleges

mélységig a ./wrthoney.sh displaylog paranccsal lehet. A telepítő csomag ugyan tartalmazza a webes megjelenítő felület létrehozásához szükséges állományokat és azokat installálja is, de fontos, hogy nem tud minden szükséges függőséget telepíteni, ezért az alábbiakban részletezett feladatokat nekünk kell „kézzel” elvégezni. A webes felülethez rendelkeznünk kell az uHTTPd nevű webszerver alkalmazással, valamint a grafikonok létrehozásához az RRDtool programmal. Ezek hiányában azokat telepíteni kell, amely valószínűleg további függőségeket is telepít a routerünkön. Az uHTTPd-nek használható például a 7-es verziója, az RRDtool-nak pedig az rrdtool_1.2.30-1_brcm47xx.ipk nevű csomagja. Mivel a honeypot a webes felületet csak meghatározott időközönként frissíti a naplóállomány alapján az úgynevezett cron ütemezővel, ezért erre is szükségünk van. A cron ütemező konfigurációs fájljában (crontab) a következő sort kell elhelyeznünk: */1 * * * * (cd /opt/wrthoney; ./infopagegenerator.sh)

Ennek hatására a cron 1 percenként fogja frissíteni a webes felületet. Érdemes lehet egy másik sort is elhelyezni az említett állományban, amely a következő: */1 * * * * (cd /opt/wrthoney; ./wrthoney.sh condrestart)

Erre azért lehet szükség, mert sajnos a honeypot által használt, reguláris kifejezéseket feldolgozó C-s függvények hibát tartalmaznak és ebből adódóan memóriaszivárgás lép fel, vagyis a honeypot egyre több memóriát használ fel, ez pedig egy SOHO router esetében hamar gondot okozhat. A problémát kiküszöbölendő, a fenti sor 1 percenként lefuttatja a ./wrthoney.sh condrestart parancsot, amely lekérdezi a honeypot által aktuálisan felhasznált memória méretét és ha az elér egy küszöböt, akkor automatikusan újraindítja a honeypotot. A korábban már említett és a webes felülethez szükséges PHP interpretert is installálnunk kell, például az alábbi csomagok telepíthetők (ezeknek további függőségei lehetnek): php5_5.3.1-3_brcm47xx.ipk php5-cgi_5.3.1-3_brcm47xx.ipk php5-fastcgi_5.3.1-3_brcm47xx.ipk

50

Amennyiben a PHP interpreter nem érhető el a /usr/bin/php útvonalon és néven, akkor szükséges az említett állománnyal azonos helyű és nevű szimbolikus link létrehozása a tényleges interpreterre. A webes felület a /www és a /www/cgi-bin katalógusok alá kerül generálásra, ahhoz azonban, hogy a PHP interpreter működjön ezeken az állományokon, szükséges a következő sor a /etc/php.ini fájlban: cgi.force_redirect = 0

Végezetül a /www könyvtárnak tartalmaznia kell egy megfelelő index.html fájlt, ami elvégzi a böngésző átirányítását a honeypot megjelenítő felületére. Ez a honeypot csomag részeként telepítésre kerül. Ezt követően a webes felület rendelkezésre áll, alapértelmezésben, ha közvetlenül csatlakozunk a routerhez, akkor a böngészőbe a 192.168.1.1 címet írva megjelenik a webes felület.

4.4 A telepített alkalmazás struktúrája, állományai A routerre telepített honeypot fájlstruktúráját mutatja a 12. ábra.

12. ábra - A routerre telepített honeypot fájlstruktúrája

51

A fenti fájlstruktúra két fő eleme a /opt/wrthoney könyvtár, ahol a honeypot megjelenítő felület nélküli része helyezkedik el, valamint a /www könyvtár, ahol a webes felület elemei találhatók. A /opt/wrthoney katalógusban helyezkedik el a WrtHoney nevű bináris, amely a honeypot központi modulja, ennek object (tárgykódú) fájlja a WrtHoney.o állomány. A configs könyvtárban helyezkedik el a konfigurációs állomány, ez a wrthconfig.cfg nevet viseli. A konfigurációs állomány felépítését a következő fejezetben mutatom be. A counter fájl csak egy számlálót valósít meg, melyet az infopagegenerator.sh parancsállomány hoz létre. Az említett parancsállomány felelős a webes felület generálásáért a naplóállományból. A naplóállomány alapján, amely a logs könyvtárban található és a wrthoney.log nevet kapta, a /www/cgi-bin katalógusban lévő infopage.php és logreader.php állományokat hozza létre. Ezen felül az RRDtool adatbázis programot használva, feltölti annak tábláit a naplóállomány alapján. Az adatbázis táblái az rrddatabases könyvtárban látható .rrd kiterjesztésű fájlok. Az első az exploitokat számolja és átlagolja időben, a második a bejövő forgalmat számlálja, a harmadik a naplózott malwareket, míg a negyedik a kimenő forgalmat számolja. A bejövő és kimenő forgalom a honeypot által fogadott és generált hálózati forgalomra vonatkozik. Az infopagegenerator.sh parancsállomány ezeket az adattáblákat frissíti dinamikusan a cron ütemező segítségével. A cron percenként hívja meg a parancsállományt, amely lefut és így új bejegyzéseket helyez a táblákba a log fájl utolsó változása alapján. Ezen felül a parancsállomány a folyamatosan frissülő táblákból szintén az RRDtool programmal a táblákban lévő adatsoroknak megfelelő grafikonokat hoz létre. Ezek a grafikonok láthatók a /www katalógusban, melyek .png kiterjesztésű képfájlok és kölcsönösen megfeleltethetők a tábláknak. Természetesen ezek is perceként újragenerálódnak a cronnak köszönhetően. A /opt/wrthoney/vulns könyvtár alatt láthatók a vulnerability modulok, amelyek .so kiterjesztésű, úgynevezett shared object állományok. Ezek dinamikusan betölthetők a központi modul futása során. Végül a wrthoney.sh állománnyal lehet a honeypotot elindítani, leállítani stb., ahogy erről a korábbi fejezetben már szó volt. A webes felület létrehozásáért felelős fájlok a /www könyvtárban vannak elhelyezve. A /www/cgi-bin katalógusban az infopage.php a webes felület főoldalát tartalmazza, a logreader.php pedig a kiválasztott vulnerability modul teljes (nyers) logját írja ki formázottan. Ezeket tehát a korábban említett parancsállomány generálja.

52

A /www könyvár alatt lévő index.html fájl telepítéskor jön létre és betöltésekor átirányítja a böngészőt az infopage.php oldalra. Ez tartalmazza a grafikonokat is. Az oldalakat az uHTTPd webszerver szolgálja ki, amely a PHP interpreterrel dolgoztatja fel a .php állományokat.

4.5 A konfigurációs állomány A konfigurációs állomány egy bejegyzésére példa az alábbi sor: +

Vuln_Example_Tcp

8080

Ahogy látható, a konfigurációs állományban minden sor 3 oszlopot tartalmaz, amelyeket tabulátorok választanak el. A sor elején szerepelhet a „#” komment karakter, amely érvényteleníti a sort feldolgozási szempontból. Az első oszlopban szerepelhet a „+”, illetve „-” jel. Az elsővel bekapcsoljuk, a másodikkal pedig kikapcsoljuk a vulnerability modul használatát. A következő oszlop tartalmazza a betöltendő sebezhetőségi modul nevét, a harmadik oszlop pedig a hozzárendelt port számát.

4.6 A naplóállomány szerkezete A honeypot által generált naplóállomány időbélyeggel ellátott bejegyzésekből tevődik össze. Minden egyes sor tartalmazza a bejegyzés keletkezési idejét, valamint magát a bejegyzést. A 13. ábrán látható egy részlet a naplóállományból.

13. ábra - Részlet a naplóállományból

Az ábrán látható sorok a honeypot indulásakor keletkeztek. Előbb a központi modul logolja az indulását, majd sorra a betöltött modulok logolják, hogy melyik porthoz lettek hozzárendelve, illetve, hogy a betöltésük sikeres volt-e vagy sem. Ezt követően minden egyes vulnerability modul naplózza a róla elérhető információkat, úgy, mint a modul neve, készítője, a modul verziója, a modulhoz tartozó sebezhetőség neve, leírása, hibakódja, valamint közzétételének dátuma. Minden egyes modulnál detektált támadási kísérlet úgynevezett szekciókból épül fel. Egy szekció egy támadási kísérlet egy feldolgozási lépésének felel meg, mint például a dekódolás vagy a shellkód értelmezés. Ennek megfelelően a szekciókban jól láthatók az adott támadáshoz tartozó honeypothoz bejövő, illetve kimenő üzenetek,

53

valamint a feldolgozás egyes szakaszai során a támadásból kinyert információk. Minden egyes támadás feldolgozása egymástól el van különítve egy megfelelő nyitó és záró sorral. Ezek az alábbi alakúak: Nyitó sor: Záró sor: <End :: Vuln_Mssql :: 1435> Mivel egy támadási kísérlet a kapcsolatfelvétellel kezdődik, ezért a támadás logjának elején található egy bejövő kapcsolatkérést rögzítő szekció. Ilyen látható a 14. ábrán:

14. ábra - Kapcsolatkérés rögzítése a naplóállományban

Az ábrán jól látható a kérést intéző gép IP-címe (192.168.1.213), valamint portja (36614). Ezt követően a következő szekciót a beérkező üzenet logolása jelenti. Ez a szekció rögzíti a fogadott üzenet hosszát, valamint magát az üzenetet bájtonként hexadecimális formátumban (hexdump). Abban az esetben, ha a vulnerability modul küld választ, akkor az is rögzítésre kerül szintén hossz/hexdump párban. Ha

FTP

protokollal

történik

a

kapcsolatfelvétel,

akkor

a

megadott

felhasználónév, valamint az esetleges jelszó is rögzítésre kerül. Ezen felül az FTP szekció tartalmazza a fogadott FTP parancsot, valamint a parancs argumentumaként átadott tartalmat és annak hosszát. Miután a vulnerability modul rendelkezik a támadó által küldött üzenettel, megkezdődik feldolgozásának rögzítése. Először logolásra kerül a detektált exploit (amennyiben az üzenet exploitot tartalmazott), ennek szekciója is látható a 15. ábrán.

15. ábra - Exploit feldolgozásának naplózása

Az exploit detektálásának szekciójában látható a detektált exploit neve, az exploitban használt visszatérési cím, valamint annak a rendszernek a típusa, amelyre a 54

támadás irányult. Rögtön ez alatt látható még a dekódolás szakasza is, ahol megnézhetjük, hogy a honeypot milyen dekódereket próbált végig, illetve melyik járt közülük sikerrel. Végül a kép alján lévő szekcióban láthatjuk a sikeres dekódert, valamint a dekódoláshoz alkalmazott kulcsot hexadecimális formában. A dekódolást követő shellkód értelmezéshez kapcsolódó bejegyzések vannak a 16. ábrán.

16. ábra - Részlet a shellkód feldolgozásának logjából

A felső sor azt mutatja, hogy a 0. próbálkozás történik a káros tartalom kinyerésére a shellkódból. A modul erre több kísérletet is tesz, hiszen nem ismeri, hogy a kódoló kulcs hogyan volt eltolva a shellkódhoz képest a kódoláskor, így ez a dekódoláskor nem egyértelmű. Ennek érdekében pontosan N számú próbálkozást kell végeznie, ahol N a kulcs hossza bájtban. A fenti ábrán egy sikeres próbálkozás látható, ahol rögzítésre kerül a shellkód típusa (itt: Download Exec), a káros tartalom (jelen esetben az URL), a shellkód hossza, majd a hexdumpja. Amennyiben egyik próbálkozás sem járt sikerrel, úgy csak a nyers shellkódot és hosszát rögzíti a honeypot. Mind a központi modul, mind a vulnerability modulok ugyanazt a közös naplóállományt használják.

4.7 A webes megjelenítő felület A webes megjelenítő felület a 17. ábrán láthatóhoz hasonló táblázatokból épül fel.

17. ábra - Példa a webes felületen megjelenő táblázatra

Ezen a táblázaton például a detektált exploit típusok láthatók, mellettük az utolsó detektálás időpontjával, valamint a detektálások számával. A táblázatok a következő információkat tartalmazzák:

55

•

Vulnerability modulok listája, portszámmal, státusszal

•

Általános információk a vulnerability modulokról

•

Dekóder modulok listája

•

Shellkód feldolgozó modulok listája

•

Összes, illetve támadásnak nyilvánított kapcsolatok száma

•

Az egyes portokra érkező kapcsolatok száma

•

Támadók száma, IP-cím szerint csoportosítva az utolsó detektálás idejével

•

Exploitok száma, típus szerint csoportosítva az utolsó detektálás idejével

•

Sikeres dekódolások száma, dekóderenként csoportosítva, az utolsó sikeres dekódolás idejével

•

Shellkód feldolgozások száma az előbbivel megegyező formában

•

Exploit, illetve malware lista a detektálás időbélyegével

•

HTTP és FTP kapcsolatok száma

Ezen kívül megtekinthető minden modul nyers logja, a naplóállományban rögzített formátumban. A táblázatok mellett rendelkezésre áll egy konfigurációszerkesztő, ahol a 4.5-ös fejezetben ismertetett adatokat lehet megadni (illetve akár törölni) egy egyszerű webes űrlapon keresztül, illetve azokat – szintén táblázatos formában – meg lehet tekinteni. A felületen megjelenő 4 grafikon mindegyike átlagot számol 2 perces felbontással, 1 napos időablakkal. A felületen balról jobbra haladva az első a honeypot átlagos input forgalmát, a második az átlagos output forgalmat számolja byte/sec mértékegységben. A harmadik a detektált exploitokat exploit/sec, míg az utolsó a detektált malwareket malware/sec mértékegységben.

4.8 Dokumentációk A honeypot felhasználói dokumentációjaként használható a teljes 4. fejezet, amelyben külön telepítési útmutatóként használható a 4.3-as alfejezet. Fejlesztői dokumentációként felhasználható a 3. fejezetben ismertetett objektum orientált modell, valamint a vulnerability modulok működése tervezésének szakasza. Ezen kívül fejlesztői dokumentációként még rendelkezésre áll a programhoz mellékelt Doxygennel generált webes leírás, amely a Dokumentáció/html/index.html fájlon keresztül tekinthető meg. A mélyebb megértést a forráskódban elhelyezett megjegyzések segítik.

56

5. Tesztelés, értékelés 5.1 Metasploit Framework A Metasploit Framework [11] egy nyílt forrású, az internetről szabadon letölthető behatolás tesztelő keretrendszer, amelyet informatikai biztonsági szakértők fejlesztenek. A rendszert még 2003-ban HD Moore – közismert biztonsági szakértő – hozta létre a Metasploit Project részeként, abból a célból, hogy segítségével gyorsan és egyszerűen lehessen új exploitokat létrehozni és fejleszteni. A keretrendszer kezdetben Perl nyelven íródott, majd később az egész Ruby nyelven újra lett írva. Az eszköz segítségével a kisebb otthoni környezetektől kezdve egészen a nagyvállalati rendszerekig lehetőség nyílik azok sebezhetőségeinek tesztelésére és ezen keresztül azok biztonsági réseinek befoltozására. A keretrendszer számos segédeszközt (tool) bocsát a felhasználó rendelkezésére, amely jelentősen megkönnyíti a rendszerrel végzett munkát. A Ruby nyelven írt exploitok a framework moduljait képezik, amelyekben további modulok felhasználására nyílik lehetőség, úgy mint a kódolók, a NOP generátorok vagy az előre definiált payloadok.

5.2 A tesztelés előkészítése, tesztkonfiguráció A teszteléshez egy Debian operációs rendszert futtató számítógépet használtam, amelyen előzőleg már telepítettem a Metasploit Framework-öt. Ez a rendszer, ahogy említettem, számos kisebb alkalmazásból épül fel, nekem csak az msfconsole nevű alkalmazásra volt szükségem. A másik eszközt maga a SOHO router (Asus WL-500g Premium) jelentette, melyen installáltam az általam fejlesztett low-interaction honeypotot, majd miután a konfigurációs állományában beállítottam az elkészült 7 vulnerability modult, elindítottam azt. A PC-t közvetlenül csatlakoztattam a router egyik LAN (Local Area Network) portjába, a router más eszközzel vagy az internettel nem volt összekapcsolva. A PC a routeren futó DHCP (Dynamic Host Configuration Protocol) szervertől a 192.168.1.213 címet kapta. A router a szokásos 192.168.1.1 címen volt elérhető. A tesztelést akkor tekintem sikeresnek, ha az msfconsole-ban beállított – következő fejezetben

ismertetett – támadást jellemző paraméterek pontosan 57

megjelennek a honeypot naplóállományában, valamint a webes megjelenítő felületen, illetve a Metasploit is sikeresnek ítéli a támadást.

5.3 A tesztelés kivitelezése A tesztelés alapját jelentő támadáshoz az msfconsole-ban csak annyi a teendőnk, hogy beállítjuk a megfelelő paramétereket egy parancssoros felületen keresztül [12]. Első lépésként ki kell választanunk a megfelelő exploitot. A rendelkezésre álló exploitokat a show exploits paranccsal listázhatjuk ki, amely egy rövid leírással is szolgál minden egyes exploithoz. Ezek közül egyet a use <exploit neve> paranccsal választhatunk ki. Itt természetesen az egyes tesztesetek során azokat az exploitokat választottam ki, amelyek detektálására képesek voltak a vulnerability modulok. Az említett teszteseteket a következő fejezetben sorolom fel. Adott exploitról részletesebb információt az info <exploit neve> paranccsal kaphatunk. Miután kiválasztottuk az exploitot, a második lépést a célpont kiválasztása jelenti. Egy exploit több, különböző verziójú rendszert is támogathat, ezeket a show targets

paranccsal listázhatjuk ki. Minden egyes célpont egy sorszámot kap (0-tól

kezdve), amennyiben az aktuálisat meg szeretnénk változtatni, úgy a set target <sorszám>

parancsot használhatjuk.

A harmadik lépést a payload kiválasztása jelenti. Az exploithoz felhasználható payloadokat a show payloads paranccsal kaphatjuk meg mellettük egy rövid leírással. A payloadokról részletesebb információt az előzővel megegyező módon, az info <payload neve> neve>

parancs szolgáltat. A megfelelő payloadot a set PAYLOAD <payload

paranccsal lehet kiválasztani. A kiválasztott célpontokat, valamint payloadokat a

tesztesetek leírása szintén tartalmazza. A következő lépés a kiválasztott exploit és payload beállításainak megadása. Az opciók egy része exploit, illetve payload specifikus, a fontosabb opciókat a show options,

míg az összeset a show advanced options paranccsal kaphatjuk meg. Minden

tesztesetnél alapvetően csak két exploit paramétert kellett beállítanom, ezek az RHOST és RPORT opciók voltak. Értelemszerűen az RHOST-nak a 192.168.1.1 értéket, míg az RPORT-nak a tesztesethez tartozó vulnerability modul port számát állítottam be. Az ehhez használt parancsok a set RHOST 192.168.1.1 és a set RPORT <portszám> parancsok voltak. A payload beállításánál annak típusától függően az URL-t vagy a futtatandó shell parancsot kellett paraméterként megadnom. Ezeket a set URL és set CMD <shell parancs>

parancsokkal adtam meg. 58

Ezek után még meg kell határozni az alkalmazandó kódolót is. A rendelkezésre álló kódolókat a show encoders paranccsal kapjuk meg. A kódolók közül csak kettőt használtam, egy 4 és egy 8 bájtos XOR kódolót. A használni kívánt kódolót a set encoder paranccsal

lehet beállítani.

A támadás előtti utolsó lépést a check parancs futtatása jelenti, amely nem végez exploitálást, csak megpróbálja eldönteni, hogy a megadott célpont sebezhető-e vagy sem. Ezt a műveletet nem minden exploit támogatja és az eredménye sem mindig megbízható. A támadást az exploit paranccsal indíthatjuk el. A támadás folyamatáról és eredményéről rövid szöveges üzeneteket kapunk az msfconsole ablakában. A tesztelés során tehát az ismertetett beállítási folyamatot jártam végig minden egyes tesztesetre, majd összevetettem a beállított paramétereket a honeypot log fájl tartalmával és a megjelenítő felülettel.

5.4 A tesztek eredménye, értékelése A 3. táblázat az elvégzett teszteseteket és azok eredményét tartalmazza. Vuln. modul neve

Vuln_Mssql

Vuln_Mysql_Yassl

Vuln_Mysql_Yassl

Exploit neve

ms02_039_ slammer

mysql_yassl_ hello

mysql_yassl_ hello

Cél rendszer MSSQL 2000

x64/xor

/ MSDE <= SP2 MySQL

x86/call4_

5.0.45community-nt

aim_triton_cseq

x64/xor

5.1.22-rccommunity

1.0.4 Universal

Vuln_Xlink_Nfsd

Vuln_Sasser_Ftpd

Vuln_Cesarftp

dword_xor

MySQL

AIM Triton Vuln_Sip

Kódoló

exec

download_ exec

dword_xor

exec

2000 SP4

dword_xor

sasser_ftpd_

Windows XP

x86/call4_

port

SP0/SP1

dword_xor

Windows

x86/call4_

2000 Pro SP4

dword_xor

59

exec

download_

x86/call4_

cesarftp_mkd

download_

x86/call4_

Windows

xlink_nfsd

Payload

Teszteset sikeressége

Sikeres

Sikeres

Sikeres

Sikeres

exec

Sikeres

exec

Sikeres

exec

Sikeres

Vuln. modul neve

Exploit neve

Vuln_Cesarftp

cesarftp_mkd

Vuln_Cesarftp

cesarftp_mkd

Vuln_ms03_051_

ms03_051_

fp30reg

fp30reg_chunked

Cél rendszer

Kódoló

Windows XP

x86/call4_

SP2/SP3

dword_xor

Windows

x86/call4_

2003 SP1

dword_xor

Windows

x86/call4_

2000 SP0-

dword_xor

SP3

Payload

Teszteset sikeressége

exec

Sikeres

exec

Sikeres

exec

Sikeres

3. táblázat - Az elvégzett tesztesetek és azok eredménye

Ahogy a fenti táblázatból látszik, minden elvégzett teszt sikeresnek bizonyult, vagyis a fenti paraméterek kivétel nélkül megjelentek a log fájlban és a megjelenítő felületen is. A tesztelést összegezve elmondható, hogy a honeypot funkcionálisan helyesen működik. A tesztelés lezárásaként az utolsó alfejezetben egy konkrét támadási példán keresztül is bemutatom a támadás folyamatát, valamint annak feldolgozását a honeypot oldalon.

5.5 Egy példa támadásra és annak feldolgozására A következő példában az előbbi fejezet táblázatának 4. sorában szereplő tesztesetet mutatom be. Az msfconsole alkalmazás elindítását követően elsőként kiválasztjuk az aim_triton_cseq nevű exploitot a következő paranccsal: use exploit/windows/sip/aim_triton_cseq

Ezt követően a show targets parancs eredményéből láthatjuk, hogy csak egyetlen cél rendszerünk van (AIM Triton 1.0.4 Universal), amely egyben az alapértelmezett is, ezért itt nincs mit átállítani. Ezek után be kell állítanunk a payloadot, ehhez az alábbi parancs használható: set PAYLOAD windows/download_exec

A show options parancs eredményéből látszik, hogy az RHOST, RPORT és URL paraméterek értékét kell beállítanunk. Az RHOST értékét az alábbi paranccsal a 192.168.1.1-es címre állítjuk: set RHOST 192.168.1.1

Az RPORT értékét az alapértelmezett 5161-en hagyhatjuk (persze a honeypot konfigurációs állományában is ennek kell beállítva lenni). 60

Az URL paraméter értéket például a következőre lehet állítani (természetesen a fájl nem létezik, csak példa): set URL http://localhost/mw.exe

Be kell állítanunk még a kódolót: set encoder x86/call4_dword_xor

A fentieket elvégezve már csak ki kell adnunk az exploit parancsot és végrehajtódik az exploitálás. Ennek következtében a 3.6-os fejezetben bemutatott szekvencia diagramnak megfelelő működés zajlik le a Vuln_Sip nevű vulnerability modulban, melynek eredményeként a 18. ábrán látható sorokat kapjuk a naplóállományban:

18. ábra - A Vuln_Sip modul logjának egy részlete

A fenti ábrán látható, hogy az érintett sebezhetőségi modul ugyanazokat a paramétereket rögzítette, amiket előzőleg beállítottunk az msfconsole-ban. Végül a 19. ábrán látható a webes felületnek egy részlete a támadást követően.

19. ábra - A Vuln_Sip modul által detektált exploit a webes felületen

A webes felület ezen részletén is látható a tesztelt modul által detektált exploit, a cél rendszer, valamint a payload típusa és a beállított URL, mindezek pedig a teszt sikerességét igazolják.

61

6. Összefoglalás 6.1 Eredmények Szakdolgozatomban áttekintettem a honeypotok alapvető típusait, azok tulajdonságait, szerkezetét és működését, majd összehasonlítottam azokat előnyök és hátrányok

szempontjából.

Ismertettem

a

SOHO

környezet

által

támasztott

követelményeket és a honeypotok SOHO környezetbe való integrálhatóságának lehetőségeit. Terveztem egy SOHO honeypotot, amely figyelembe veszi a környezet elvárásait, valamint hatékonyan továbbfejleszthető, implementáltam azt a hozzá kapcsolódó elemző felülettel, majd sikeresen teszteltem az így létrehozott rendszert egy közismert behatolás tesztelő alkalmazással.

6.2 Továbbfejlesztési lehetőségek Az egyik legalapvetőbb továbbfejlesztési lehetőség a honeypot új vulnerability modulokkal való bővítése. Ehhez szorosan kapcsolódik a sebezhetőségi modulok által felhasznált dekóderek, valamint shellkód feldolgozó modulok körének kiterjesztése és ezáltal a detektálható és elemezhető exploitok számának növelése. További lehetőség a továbbfejlesztésre új, elsősorban alkalmazás szintű protokollok implementálása és ezzel a honeypot támadó által elérhető funkcionalitásának bővítése. Ezen kívül a már meglévő protokollkezelők (HTTP, FTP) kiterjesztése is szükséges lehet, mivel azok csak a megvalósított vulnerability modulokhoz feltétlenül szükséges működést biztosítják. Jelenleg a rendszer a naplózás során egy közös naplóállományt használ, azonban a logolás párhuzamosítása csak a bejegyzések, valamint a 4.6-os fejezetben említett szekciók szintjén van megoldva. Ebből következően egy vulnerability modulnál egy támadás teljes feldolgozásának naplózása nem párhuzamos, vagyis az átlapolódhat egy másik sebezhetőségi modul hasonló bejegyzéseivel (ez ritkán fordul elő, ha valós környezetben használjuk a honeypotot). Ezen hiányosság kiküszöbölésére nyújthat megoldást az elosztott naplózás, vagyis az a lehetőség, amely során az egyes modulok saját naplóállományba logolnak a közös helyett.

62

Köszönetnyilvánítás Köszönettel tartozom konzulensemnek, Dr. Fehér Gábornak az Önálló laboratórium c. tárgy, valamint a szakdolgozat írás során nyújtott segítségéért, amely a szakmai fejlődésemhez nagymértékben hozzájárult.

63

Irodalomjegyzék [1] Niels Provos, Thorsten Holz: Virtual Honeypots: From Botnet Tracking to Intrusion Detection, Kiadó: Addison Wesley Professional, 2007, ISBN-10: 0-321-33632-1, ISBN-13: 978-0-321-33632-3, Fejezetek: 2.1, 2.4, 3.1, 6.2 [2] UK Honeynet Project, Nepenthes futtatása az OpenWrt beágyazott platformon: http://www.ukhoneynet.org/research/building-nepenthes-on-the-openwrt-embeddedplatform/ (2011. december) [3] Metasploit Project, Exploit modulok leírása: http://metasploit.com/modules/ (2011. december) [4] Révay Gergely: Weboldalak automatikus biztonsági tesztelése (diplomamunka), 2009, Fejezetek: 2.4.2, 2.4.3, 30-32. oldal [5] Citizendium, A stack frame ismertetése: http://en.citizendium.org/wiki/Stack_frame (2011. december) [6] James C. Foster, Vitaly Osipov, Nish Bhalla, Niels Heinen: Buffer Overflow Attacks – Detect, Exploit, Prevent, Kiadó: Syngress Publishing, Inc., 2005, ISBN: 1-932266-67-4, 161-189. oldal (Stack Overflows c. fejezet) [7] Joel Scambray, Stuart McClure: Hacking Exposed Windows: Microsoft Windows Security Secrets and Solutions, Third Edition, Kiadó: The McGraw-Hill Companies, 2008, ISBN: 0-07-149426-X, 392-394. oldal (SafeSEH c. fejezet) [8] Paul Asadoorian, Larry Pesce: Linksys WRT54G Ultimate Hacking – „A Rosetta Stone for the WRT54G”, Kiadó: Syngress Publishing, Inc., Elsevier, Inc., 2007, ISBN: 978-159749-166-2, 69-76. oldal (OpenWrt c. fejezet) [9] GitHub, Keresztfordítás az OpenWrt platformra SDK (Software Development Kit) használatával: https://github.com/airplug/airplug/wiki/Cross-compiling-for-OpenWRT (2011. december) [10]

Lambert M. Surhone, Mariam T. Tennoe, Susan F. Henssonow: RRDtool –

Time Series, Bandwidth (computing), Temperature, Kiadó: Betascript Publishing, 2010, ISBN: 6131997659 [11]

Metasploit Project, A Metasploit Framework keretrendszer ismertetése:

http://metasploit.com/about/ (2011. december) [12]

David Maynor, K. K. Mookhey, Jacopo Cervini, Fairuzan Roslan, Kevin

Beaver: Metasploit Toolkit for Penetration Testing, Exploit Development, and Vulnerability Research, Kiadó: Syngress Publishing, Inc., Elsevier, Inc., 2007, ISBN13: 978-1-59749-074-0, 37-45. oldal (Msfconsole c. fejezet)

64

Rövidítésjegyzék AIM:

AOL Instant Messenger

ASCII:

American Standard Code for Information Interchange

BASH:

Bourne-Again SHell

CVE:

Common Vulnerabilities and Exposures

CSS:

Cascading Style Sheets

DDoS:

Distributed Denial of Service

DHCP:

Dynamic Host Configuration Protocol

DMZ:

Demilitarized Zone

DNS:

Domain Name System

EBP:

Extended Base Pointer

EIP:

Extended Instruction Pointer

ESP:

Extended Stack Pointer

FTP:

File Transfer Protocol

HTML:

HyperText Markup Language

HTTP:

Hypertext Transfer Protocol

IDS:

Intrusion Detection System

IP:

Internet Protocol

ISP:

Internet Service Provider

LAN:

Local Area Network

LIFO:

Last In First Out

MSB:

Microsoft Security Bulletin

NFS:

Network File System

OSVDB:

The Open Source Vulnerability Database

PC:

Personal Computer

PHP:

PHP: Hypertext Preprocessor

SDK:

Software Development Kit

SEH:

Structured Exception Handling

SOHO:

Small Office/Home Office

SQL:

Structured Query Language

SSL:

Secure Socket Layer

65

TCP:

Transmission Control Protocol

TFTP:

Trivial File Transfer Protocol

UDP:

User Datagram Protocol

UML:

Unified Modeling Language

UML:

User-Mode Linux

URL:

Uniform Resource Locator

VLAN:

Virtual Local Area Network

VoIP:

Voice over IP

66