Pék Gábor. Új eljárások kártékony kódok detekciójára és új támadások hardver virtualizáció ellen. Ph.D. Tézisfüzet. Konzulens: Buttyán Levente, Ph.D.

Átírás

1 Budapesti M szaki és Gazdaságtudományi Egyetem Hálózati Rendszeek és Szolgáltatások Tanszék Új eljáások kátékony kódok detekciójáa és új támadások hadve vitualizáció ellen Ph.D. Tézisfüzet Pék Gábo Konzulens: Buttyán Levente, Ph.D. Budapest 2015

2 1. Bevezetés A disszetációmban két poblémateülettel foglalkozom: (i) ismeetlen kátékony kódok detekciója és (ii) új támadások vizsgálata hadve vitualizáció ellen. Ebb l adódóan a disszetáció két észe bontható. Az els észben el szö, egy új memóia foenics eszközt javaslok Membane néven, melynek célja a kód injekciós támadások detektálása. Ahelyett, hogy a kódinjekció tényét detektálnám, a Windows opeációs endszeben jelentkez laptábla eseményváltozásokat vizsgálom meg nagy alapossággal. Mivel a laptábla-események által okozott anomáliáka fókuszálok, széles spektumban lehet detektálni különböz típusú injekciós eljáásokat. Az eedmények Windows XP opeációs endsze esetén 91-98%-os pontosságot mutatnak, míg Windows 7 endszeeknél még a legzajosabb folyamatok esetén is (pl.: exploe.exe) 75-86% a detekciós pontosság. Az eljáásomnak köszönhet en lehetséges ilyen típusú ejt zköd kátékony kódokat detektálni, még ha célzott támadásból vett kampányól is van szó. Ezt követ en egy új endsze-monitoozó eszközt javaslok, amely automatikus malwae detekciót tesz lehet vé éles gépek esetén. A megközelítésem a moden CPU-kban eléhet hadveel támogatott vitualizációs eljáást használja ki, illetve azt a tényt, hogy ezáltal lehet ség van egy hypevisot telepíteni a futó opeációs endsze alá anélkül, hogy le kéne a gépet állítani, vagy úja kéne azt indítani. Ez a hypeviso magasabb pivilégium szinten fut, mint az opeációs endsze maga. Ennek köszönhet en a endszet tanszpaensebben lehet meggyelni, mint más módszeekkel. Ebb l a célból javaslok továbbá egy új endsze-monitoozó eljáást, melyet a tanszpaencia és az elemzési ganulaitás mentén lehet nomhangolni. A disszetáció második észében ávilágítok a VM-ekhez kapcsolódó fenyegetéseke és védelmi megoldásoka azáltal, hogy a közvetlen eszközcsatolással kapcsolatos támadások széles skáláját tevezem meg, implementálom le és kategoizálom. Ezeket a támadásokat sok különböz VMM konguációval teszteltem, hogy kideítsem a tényleges hatásukat. A vizsgálataink megmutatták, hogy a futtatott támadások egy jó észe tulajdonképpen hatástalan a mai VMM beállítások mellett. Kifejlesztettem azonban egy automatikus eszközt, amit PTFuzz-nak neveztem el, hogy hadve szint, VMM-hez kapcsolódó poblémákat fedezzek fel. A PTFuzz segítségével számos váatlan hadve viselkedést, továbbá egy Intel platfomhoz köthet komoly séülékenységet találtam, mely engeteg Intel chipsete és ezáltal gépe hatással van a mai napig. Ez a séülékenység minden olyan nem pivilegizált vituális gépet éint, mely közvetlen eszközcsatolással endelkezik minden létez hadvees biztonsági védelem mellett. Egy támadó a séülékenység segítségével hosztoldali inteupt-ot vagy hadve hibát tud geneálni megsétve ezáltal az elvát izolációs m ködést. Ez el bbi elméleti szinten tényleges vitualizációs kitöést is lehet vé tehet, míg a második a hoszt szoftve (pl.: VMM) teljes leállását idézheti el. Hiszem, hogy a tanulmányom segít a felh szolgáltatóknak és kutatóknak jobban megéteni a jelenlegi achitektúa kolátait, hogy biztonságos hadve vitualizációs platfomot hozzanak léte és felkészüljenek jöv beli támadásoka. Ugyanakko a biztonsági szakét k nagy métékben támaszkodnak a különböz vitualizációs technikáka, hogy sandboxing könyezeteket hozzanak léte, melyek valamilyen szint izolációt biztosítanak a hoszt és az analizált kód között. Azonban ezek nagy észét nagyon könny detektálni és kikeülni. A hadveel támogatott vitualizáció bevezetése (Intel VT és AMD-V) lehet vé tette az újsze, vendégkönyezeten kívüli kátékony kód analízis platfomok létehozását. Ezek magas tanszpaenciát biztosítanak, és vendég opeációs endszeen kívül helyezkednek el teljes métékben, így hatástalanítva a hagyományos memóia-szint ellen z eljáásokat. Ezen analizátook továbbá megoldják a pontatlan endsze emulációból, vendég könyezeten belüli id zítésb l és a pivilegizált m veletek használatából adódó hiányosságokat. Az utolsó bekezdésben ezét egy új megközelítést mutatok be, amely lehet vé teszi a hadveel támogatott vitualizációs könyezetek és a vendég könyezeten kívüli analízis keetendszeek 1

3 detektálását. Az elképzelésem demonstálása céljából, egy alkalmazás keetendszet implementáltam nethe néven, mely képes detektálni az Ethe nev, vendég könyezeten kívüli analízis endszet. 2

4 2. Új eedmények 2.1. Új módszeek malwae fet zések detekciójáa THESES 1:. Egy újsze memóia foensics technikát és egy hozzá tatozó eszközt (Membane) javaslok, mely lap események analízise alapján detektál ismeetlen kód injekciós támadásokat Windows futtató könyezetekben. Az utóbbi évek célzott támadásai megmutatták, hogy még a legfejletebb endszeeket is kompomittálni lehet. Ezen célzott támadások némelyike kinomult behatolási technikákat[cer14], némelyike pedig elég egysze megoldásokat [Ali14] alkalmaznak. Ezen kátékony támadások tipikusan kompomittálási lépések soozatát végzi el a célendsze ellen. Miután sikeült hozzáféést szeetniük a célendszehez, ezen malwae kódok számos egyéb m veletet hajtanak vége, hogy elfedjék a nyomokat és észevétlenek maadjanak. Tehát, minél hosszabb ideig képes egy malwae a célendszeben tatózkodni, annál több infomációt képes ott összegy jteni. Gyakan ezen támadások évekig jelen vannak a célendszeben és a támadók jelent s bizalmas infomációhoz fének hozzá ahogy koábbi jelentések is mutatták [Man13]. Éssze feltételezés, hogy ezen hosszú élet támadások jelent s nyomokat hagynak maguk mögött, mégis számos példa azt mutatja, hogy a mai opeációs endszeek komplexitása és gazdag eszközkészlete hatalmas teet biztosít a támadók számáa. Kód injekció az egyik kulcstechnika, melyet a malwae-ek használnak a pezisztencia eléése céljából. Kód injekcióól beszélünk, amiko a malwae hozzáad vagy elvesz funkcionalitást meglév kódból, azét hogy új szoftvekomponenseket tudjon futtatni. Ez minden különösebb nehézség nélkül lehetséges, hiszen a Windows opeációs endsze számos megoldást nyújt (pl.: legitim API hívások, egisztációs adatbázis bejegyzések segítségével) ehhez. Tehát, a kód injekció sokszo a jótékony pogamokban lév feltételek használja ki. Ezét használják tehát a kód injekciót az olyan kívánt m ködések elééséhez, mint a detekció kikeülése vagy a folyamat szint kolátozások feloldása. Jelent s e feszítéseket tettek pont ezét a memóia és lemez foensics technikák kifejlesztésée, melyek olyan endszeszint anomáliák detekciójáa használhatóak, melyeket malwae-ek okoznak [IM07]. A legnagyobb pobléma a mostani memóia foensics technikákkal kapcsolatban az az, hogy csak azon memóiacímeket vizsgálják, melyek aktív használatban voltak az OS memóiakép készítéseko. Tehát fontos infomációk veszhetnek el az injekcióval kapcsolatban, ha a malwae vagy ennek egy észe inaktív volt a pillanatkép készítéseko. Továbbá, a Windows gazdag funkciótáa lehet vé teszi a behatolók számáa, hogy egyedi kód injekciós technikákat fejlesszenek ki, ahogy azt a Flame esetén is láttuk. Ezen kinomult technikák a hagyományos szignatúa alapú detekciós eljáásokat könnyen kikeülik ugyanis. Tehát a Windows memóiakezelésének mély ismeete egy ígéetes út lehet kátékony kódinjekciós támadások detekciójáa, akko amiko má a fet zés bekövetkezett a célfolyamatokban. Pontosan ezét vizsgálom meg nagy alapossággal a Windows memóia kezelésének világát, és endszeezem a legfontosabb lapozási eseményeket, melyek majd felhasználok a kés bbiekben kátékony viselkedések detekciójáa. A következ kben az általalam javasolt Membane nev anomália és foensics eszköz tevezését és implementációját mutatom be, mely a népsze memóia foensics keetendszee, a Volatilitye épül. Membane a lap események számosságát vizsgálja els soban. Ez a megközelítés jelent sen különbözik létez megoldásoktól, mivel itt az anomális detekcióján van a fókusz és nem pedig a kód injekció tényének detekcióján. 3

5 1. táblázat. Általános és célzott kód injekciós malwae-ek detektálása exploe.exe-ben a WinXP és Win7_1 könyezeteken a különböz hálózati beállítások mentén. Az eedmények kiétékeléséhez K = 5-ös keesztvalidáció lett használva. Fontos megjegyezni, hogy a tesztadathalmazban lév célzott támadások csak Win7_1 alatt lettek kiétékelve. Általános mintákból álló keesztvalidációs adathalmaz Intenet VM ACC % TPR % FPR % no WinXP Win7_ yes WinXP Win7_ Általános keesztvalidációs adathalmaz egyéb alkalmazások indítása nélkül no Win7_ no Az általános és célzott támadásokból álló tesztadathalmaz WinXP Win7_ THESIS 1.1:. Egy újsze memóia foensics technikát javaslok egy Membane nev eszközzel együtt, mely széles köben képes kódinjekciós technikákat detektálni. Az eedményeim azt mutatják, hogy Mebane képes aká 86-98%-os pontossággal detektálni Windows platfomon még a legzajosabb célfolyamatok esetén is, mint például az exploe.exe A Membane pontos kiétékeléséhez nagy számosságú tesztet kellett végehajtani, két hálózati konguáció mentén: (i) nincs Intenet kapcsolat engedélyezve, (ii) valós Intenet kapcsolat engedélyezett egy gondosan beállított biztonsági háziend mentén követve Rossow et al. [RDG + 12] ajánlásait. Engedélyezett Intenet kapcsolat esetén NAT-olva volt a fogalom a következ háziend mentén: a) az ismet C&C TCP potok ki lettek engedve, mint például a HTTP, HTTPs, DNS vagy IRC, b) minden más TCP pot át lett iányítva egy Intenet szimuláto felé (pl: SMTP potok melyeket nem egisztált be az IANA), melyet az InetSim nev alkalmazás biztosított, c) ezen felül az analizált VM-eken a hálózati fogalom átájának kolátozását kellett bevezetni a DoS támadások megel zése édekében. A 194 általános kód injekto malwae közül 128 minta célozta meg az exploe.exe-t, mely ezáltal a legnépsze bb célpontot jelenti. Ebb l adódik az is, hogy a véletlen-ed alapú osztályozó algoitmus is ezekkel a mintákkal dolgozik. A kiétékelés háom észb l áll: (i) a kód injektook kiétékelése K-szoos keesztvalidációval tötént el telepített VM-eken, melyeken legitim alkalmazások is futaottak (ii) ugyanaz, mint az el z eset, de nem lett semmilyen legitim alkalmazás telepítve és elindítva, (iii) a legjobban teljesít véletlen ed osztályozó kiválasztásával a csak tesztelése szánt adathalmaz mintái is ki lettek étékelve. Ez a csak tesztelése szánt adathalmaz tatalmazott általános és célzott mintákat is. Az (i) és (ii) esetben, Windows XP (WinXP) és Windows 7 (Win7_1) könyezetek lettek megfet zve mindkét hálózati konguáció mellett. Miután a snapshotokat a Membane analizálta, az osztályotó algoitmus keült futtatása kátékony injekciók detektálása céljából. Az 1 táblázat összegzi az eedményeket és mege sít néhány kulcsfontosságú meggyelésemben. A futó folyamatok megnövelik bizonyos endszefolyamatokban a zajt. Ez a meggyelés alacsonyabb detekciós átában nyilvánul meg, amint az (i) és (ii) esetek mutatják Win7_1 alatt. A

6 következ meggyelésem, hogy a futtató könyezet szintén hatással van a detekciós pontossága, amint a TPR is mutatja Win7_1 és WinXP konguációk esetén. Míg a detekciós áta egészen jó Windows XP esetén, az eedmények osszabbak a Windows 7-es pillanatképeknél az exploe.exe-ben megnövekedett lap események miatt. A detekciós átát azonban lehet növelni a legitim folyamatok megállításával, mellyel az exploe.exe-t is tehementesítjük. Ezt a detekciós növekedést az 1 táblázat mutatja, amint a TPR 75.92%- l 86%-a mozdul el. THESIS 1.2:. Megmutatom, hogy a detekciós pontosságot befolyásolja a célfolyamat, a futtatókönyezet és a vizsgált endszeen futó tiszta folyamatok is. Minden méésemet valós endszeeken végeztem szimuláció használata nélkül. Ezen felül demonstálom, hogy a megközelítésem független a használt injekciós technikától, tehát széles köben képes detektálni injekciós technikákat. Ezen felül, megmutatom, hogy mostani célzott támadásokat is képes detektálni a módszeem. Azét, hogy az ígéetes osztályozási szempontokat kiétékeljem, összehasonlítom a tiszta és fet zött osztályozási vektook mediánját, melyet egy adott p P folyamata nézek meg, ahol P jelenti az összes folyamatot, ami egy adott endszeen (pl.: WinXP, Win7_1) fut. Ez a megközelítés deniálni tudja, hogy a futtatókönyezet és a vizsgált folyamat hogyan befolyásolja a detekciós pontosságot. Egészen konkétan, deniálom a µ (G (f) p, M (f) p p ) µ(m p (f) ) ) = µ(g(f) képletet, mint medián aányt egy adott p P folyamata, ahol f F osztályozási szempont kiválaszt egy lapbejegyzés típust, amit helyeállított Membane. Mivel limitált számú pillanatképpel dolgoztam, így a medián statisztikát használom a váható éték helyett. A kátékony számosságok egy adott f osztályozási szemponta, p folyamata és n daab pillanatképe az M p (f) = (m (f) p 1, m (f) p 2,..., m (f) p n ) összefüggéssel deniálom, míg a tiszta számosságot a G (f) p = (g p (f) 1, g p (f) 2,..., g p (f) n ) képlet jelöli. A következ kben nemég felfedezett célzott támadásokat étékeltem ki a Win7_1-es könyezeten. Ezen minták mindegyike az exploe.exe-be injektál és a Snake, Shale, Epic, Tulae és Flame családokból számaznak. Fontos megjegyezni, hogy az el bbi 4 család az Uobuos kampányhoz tatozik, melyet a G Data cég fedezett fel 2014 deekán [G D14]. A vizsgálatok soán a koábban említett biztonsági háziend mellett aktív Intenet kapcsolat volt engedélyezve. Peiodikusan minden 5 pecben, 2 óán keesztül készültek a pillanatképek (n = 24). Amint a 1. ába mutatja, a legtöbb osztályozási szempont esetén megn tt az eseménygyakoiság (az µ aány kisebb, mint egy), miután a VM meglett fet zve. Míg a Demand Zeo lapozási események ugálnak, a Zeo PTE-hez tatozó számosságok viszonylag stabilak maadtak a legtöbb esetben, a Flame-et leszámítva. A továbbiakban kiétékeltem olyan mintákat is, melyek más endsze folyamatba injektálnak. A sevices.exe-t választottam, hiszen ez a folyamat is egy népsze célpont, és jól szemlélteti a megközelítésem el nyeit. Minden egyes családhoz tatozó mintáól készült egy-egy pillanatkép. Ezután kiszámoltam a medián aányt az eedményeim kiétékelése céljából. Ahogyan a 2 mutatja, a legtöbb lapozási esemény jelent sen megnövekedett, különösen a Zeo a ZAccess minták esetén. Édekes meggyelés, hogy a Demand Zeo eseményszámok viszont lecsökkentek a Mydoom és Redyms-hez családokhoz tatozó minták esetén. Ez a viselkedés annak tudható be, hogy a koábban lefoglalt, ám fel nem használt teületeket most a sevies.exe ténylegesen el kezdte használni. Mivel az aányok kisebbek, mint az exploe.exe esetén, aa a következ- (1) 5

7 1. ába. Célzott minták kiétékelése exploe.exe-n, a Zeo, Demand Zeo (Dz), Acessed (A) és Witable (W) osztályozási szempontok mentén a Win7_1 könyezetben. 2. ába. Különböz családokhoz tatozó minták kiétékelése sevices.exe-n, a Zeo, Demand Zeo (Dz), Acessed (A) és Witable (W) osztályozási szempontok mentén a Win7_1 könyezetben. tetése jutottam, hogy a célfolyamat befolyásolja a detekciós pontosságot. Ez a meggyelés az alábbiakban található alapaányok is mege sítenek, melyeket az alábbiakban tágyalok. Különböz futtatási könyezeteket poloztam az alapszint lapeseményekhez hogy megétsem miét csökken a detekciós áta abban a speciális esetben, amiko a malwae az exploe.exebe injektál Win7_1 alatt. Hasonlóképpen a medián aányhoz, a szóás aányt is deniálom, mely zajbecslést tesz lehet vé különböz osztályozási szempontok mentén, különböz beállítások mellett. σ (G (f) p, M p (f) ) = σ(g(f) p ) (2) σ(m p (f) ) Ezt követ en kiszámoltam a medián és szóás aányokat bizonyos osztályozási szempontok 6

8 mellett számos endsze folyamata. Egészen pontosan el szö 24 pillanatkép lett ögzítve 2 óa lefogása alatt (tehát 5 pecenként egyet) Membane segítségével a WinXP, Win7_1, Win7_2 futtatókönyezetek l bámilyen plusz alkalmazás elindítása nélkül. Ezt követ en úja 24 pillanatkép keült ögzítése, de legitim alkalmazások elindításával. Ekko kiszámoltam a néhány osztályozási szempontot és összehasonlítottam a két futás eedményeit. Azét, hogy azt is megmutassam, hogy a futó folyamatok mennyie befolyásolják a folyamatzajt, készítettem további 24 pillanatképet úgy is, amiko csak egy MS számológép és egy Dopbox kliens lett elindítva. Ezt a konguációt hívom Win7_1c-nek. A meggyelésem a folyamatszint alapszint lapeseményekkel kapcsolatban a következ : ˆ A endszefolyamatok zaját befolyásolják más futó folyamatok is. Az egyik legzajosabb endszefolyamat az exploe.exe melyet a magas szóás aány is deniál, ahogy a 2 táblázat is mutatja (σ Zeo = 0.051, σ V p = 0.039, σ W = 0.033) Win7_1 könyezet esetén. Mivel az exploe.exe felel s a gakus feleület elindításáét sikees felhasználói bejelentkezés után, ez nem meglep viselkedés. Habá, amiko a kíséletet megismételtem Win7_1c alatt, néhány eseményzaj jelent sen lecsökkent (σ Zeo = 1.728, σ V p = 0.423) miközben a medián aány közel maadt egyhez (i.e., µ Zeo = 1.046, µ Dz = ). Ugyanakko, más endszefolyamatokat (pl.: winlogon.exe, sevices.exe) ez nem befolyásolja ilyen métékben. Például, egy másik népsze injekciós célpont a sevices.exe Win7_1 alatt µ Zeo = σ Zeo = 0.613, µ W = és σ W = 0.31 étékeket mutat. ˆ A endszefolyamatok zaját befolyásolja az opeációs endsze. A WinXP és Win7_* futtató könyezetek számos közös osztályozási szempontot tatalmaznak (pl.: Zeo PTE, Demand Zeo, Valid Pototype). Összehasonlítva ezeket az osztályozási szempontokat, megállapítottam az alapesemény aányok WinXP estén közelebb vannak egyhez, mint bámilyen más Win7_* könyezet esetén bámilyen endszefolyamata. Míg σ Zeo = 0.051, σ Dz = 0.121, σ V p = a exploe.exe esetén Win7_1 alatt, σ Zeo = 0.711, σ Dz = 1.328, σ V p = 0.89 WinXP-nél. A medián aányok egészen hasonlóan alakulnak, habá µ Zeo = 1.044, µ Dz = 0.819, µ V p = Win7_1 esetén és µ Zeo = 1.024, µ Dz = 0.998, µ P v = 0/0 WinXP-nél. Fontos kiemelni, hogy a "0/0" jelölés azt jelenti, hogy az összehasonlított mintáknak nulla a mediánjuk. Ez a különbség más endszefolyamatok esetén is jelentkezik. Így például winlogon esetén is: σ Zeo = 0.543, σ Dz = 0.021, σ V p = Win7_1 alatt és σ Zeo = 0.964, σ Dz = 1.571, σ V p = WinXPnél. THESIS 1.3:. Javaslom továbbá a Membane-nek egy online vezióját Membane Live néven, mely ugyanazokkal a detekciós képességekkel endelkezik, mint a Membane. A Membane Live-val kapcsolatos méések megmutatták, hogy az analízis könyezet nem befolyásolja a lapozási alapaányokat. Membane Live egy hypeviso kiegészítésként keült implementálása Vitual Machine Intospection (VMI) segítségével. Javaslom a Membane Live-ot, ami egy kiegészítése a DRAKVUF [LMP + 14] malwae analízis könyezetnek. Membane Live ugyanazokat a funkcionalitásokat implementálja, mint a Membane, habá az eseményszámosságot minden monitoozott kenel függvény mentén ögzíti. Ennek köszönhet en mélyen meg lehetett éteni az egyes kódinjekciós eljáásokat, illetve az anomáliát, amit okoznak. Ehhez egy újabb vendégkönyezetet kellett felállítani Win7_3, melyet a Membane Live segítségével monitooztunk. Membane Live a folyamatszint alap eseményszámok összehasonítása céljából keült implementálása. 7

9 2. táblázat. Lapozási alapaányok különböz detekciós osztályozási szemponta WinXP, Win7_1, Win7_1c, Win7_2 futtatókönyezetek esetén 24 pillanatkép elemzéseko. A övidítések a következ k: Zeo - Zeo PTE, Cw - Copy-on-wite, Dz - Demand Zeo, Vp - Valid Pototype, Mfp - Mapped File Pototype, A - Accessed, W - Witeable. Az alapaányok Win7_3c esetén a Membane Live segítségével lettek ögzítve és kiétékelve, miután n = 400 osztályozási vektot el állítottunk. Az aányok a nem használt osztályozási szempontoka (nulla, vagy minimális infomációnyeeség esetén) a "-" szimbólummal lettek jelölve a különböz futtatási könyezetek esetén. Featues Pocess VM Ratios Zeo Cw Dz Vp Mfp A W WinXP µ /0 0/0 - - σ Win7_1 µ σ exploe Win7_1c µ σ Win7_2 µ σ Win7_3c µ σ / WinXP µ /0 0/0 - - σ Win7_1 µ σ sevices Win7_1c µ σ Win7_2 µ σ / Win7_3c µ σ WinXP µ σ Win7_1 µ σ winlogon Win7_1c µ σ Win7_2 µ σ / Win7_3c µ σ 1-0/0 0/ WinXP µ σ Win7_1 µ σ lsass Win7_1c µ σ Win7_2 µ σ / Win7_3c µ σ /

10 Ehhez teljesen tiszta, 400 soból álló futási logokat hasonlítottunk össze Win7_3 esetén. Amint a 2 táblázat mutatja, nincsen jelent s különbség a tiszta lapozási alapesemény aányok között a Membane-nel és a Membane Live-val vizsgált endszeek esetén. Tetsz leges osztályozási szemponta kimondható, hogy az aány minél közelebb áll egyhez, úgy az eseményszámok annál hasonlóbbak. THESIS 1.4:. Megmutatom, hogy az injektált kátékony funkcionalitások különböz képpen befolyásolják a különböz lapozási eseményeket. Tehát, a kátékony funkcionalitás befolyásolja a detekciós aányt. Ahhoz, hogy megétsük az egyes injektált funkcionalitások hogyan befolyásolják a folyamatszint lapozási eseményszámokat, néhány funkcionalitás ténylegesen is implementálása keült és injektálva lett egy távoli szál meghívásával a winlogon.exe-ben, amint azt a 3. táblázat mutatja. A winlogon.exe jó választásnak t nt, hiszen alacsony alapesemény zajjal endelkezik, tehát könnyebb detektálni benne kátékony viselkedést. A medián és szóás aányok kiszámításához n = 24 pillanatképet ögzítettünk 2 óa alatt és ezeket összehasonlítottam a Win7_1c számosságaival. El szö is a keylogge keült implementálása, mely egy végtelen ciklus segítségével gyelte a billenty lenyomásokat és egy bels buebe ögzítette azokat. Édekes meggyelés, hogy ez a funkcionalitás viszonylag észevételen maadt és csak az íható lapok száma növekedett meg jelent sebben (µ W baseline = 0.90 and µ W keylogge = 0.53). Mivel csak egy kicsi bue szükséges a billenty leütések táolásához, melyet ki lehet íni néhány lapa, ezt a funkcionalitást nehéz detektálni önmagában. A második injektált funkcionalitást egy szeve alkalmazás volt, amely egy kis szöveges fájlt (néhány KB méettel) sziváogtatott ki a csatlakozó kliensek felé. Szándékosan választottam kis méet fájlt, hiszen ez lehet séget ad a legosszabb eshet ségek esetén is vizsgálni a detekciós képességeket. Amint a 3. táblázat is mutatja, a folyamatzaj jelent sen megnövekedett (pl.: σ Dz baseline = és σ Dz dataexfiltation = 0.42). Másfel l a medián aányok lecsökkentek, tehát kulcsfontosságú eseményszámok növekedtek ebben az esetben (pl.: µ W baseline = 0.90 és µ W dataexfiltation = 0.02). Mivel a kisziváogtatott le-t be kell tölteni a folyamat címteébe és a Windows késleltetett betöltést használ, csak a Zeo PTE eseményszámok növekednek, amíg a betöltött fájlt ténylegesen nem kezdi el íni vagy olvasni. Végül, egy egisty bejáó funkcionalitás keült implementálása, amely végigiteál az összes HKEY_* kulcson és néhány étéket fel is vesz azok alá. A 3. táblázat szeint a folyamatzaj megn tt az íható lapok számával együtt. THESIS 1.5:. Megmutatom, hogy az injektálás ténye is befolyásolja a lapesemények számosságát a célfolyamat esetén. Demonstálom továbbá ezt az állítást egy konkét injekciós technika analízisével, mely távoli szálhívást kezdeményez a célfolyamatban A legfontosabb lapozási eseménye a folyamatonként Gini index segítségével keültek kiválasztása. Azét, hogy jobban megétsük miét is ezek a lapozási események a lényegesek a detekció szempontjából, meg kell vizsgálni közelebb l a Windows bels m ködését. Ehhez különböz foásokat használtam fel [RSI12, Wil11, Rea14], beleétve a WinDBG kenel debugget is a dinamikus analízishez. A 4. táblázat példát mutat egy tipikus kódinjekciós támadás vizsgálatáa, mely bizonyos WinAPI függvényhívásokat használ. Egészen pontosan el szö VitualAllocEx keül meghívása, ami egy pivát memóiateületet foglal a célfolyamatban azét, hogy eltáolja a betöltend DLL-nek a nevét. A vonatkozó kenel függény NtAllocateVitualMemoy tehát készít és inicializál egy VAD bejegyzést az RW védelmi bitek beállításával, majd kinullázza a PTE-t (tehát 9

11 3. táblázat. Különböz kátékony funkcionalitások által okozott lapozási eseményszámosságok összehasonlítása (➊ Keylogge, ➋ Adatlopás, ➌ Registy m veletek) a Win7_1c osztályozási vektookkal. A WinAPI hívások oszlop néhány WinAPI hívást emel ki, mely meghívása keült az adott injektált funkcionalitásban. Minden funkcionalitás a CeateRemoteThead injekciós technikával keült elhelyezése a célfolyamatban, ahogy a 4. táblázat is észletezi. Malwae WinAPI hívások µ Zeo σ Zeo µ A σ A µ Dz σ Dz µ W σ W func. ➊ ➋ ➌ CeateFile GetAsyncKeyState MapVitualKeyEx GetKeyNameText WiteFile CloseHandle socket bind listen accept ecv CeateFile ReadFile send CloseHandle RegOpenKeyEx(HK*) RegQueyInfoKey RegEnumKeyW RegSetValueEx RegEnumValueW RegOpenKeyExW RegQueyValueExW RegCloseKey RegCloseKey egy Zeo PTE bejegyzés készül) a lefoglalt memóiateülete vonatkozólag. Ezt követ en pedig beállítja egy laphibakezel t kivételt(#pf). Az NtPotectVitualMemoy kenel függvény szintén meghívása keül, miután az NtAllocateVitualMemoy lefutott, mely beállítja szoftvees PTE védelmi biteket, és ezáltal megváltoztatja a szoftvees PTE típusát Demand Zeo (Dz)-a. Amiko a WitePocessMemoy megpóbálja eléni a lapot, a laphibakezel keül meghívása. Majd ez elkapja a laphibát és egy hadvees PTE készül el és inicializálódik (évényes 10

12 és íható hadvees PTE bitek beállítódnak) a koábban elkészült VAD bejegyzés segítségével. Ez a késleltetett memóia allokációs mechanizmus lehet vé teszi a Windows számáa, hogy csak akko építse fel a laptáblákat, amiko azoka ténylegesen szükség van. Amiko a #PF lefutott, a futás az NtWiteVitualMemoy kenel függvényhez keül, ami beíja a célfolyamatba kátékony DLL nevét, ami kés bb majd betöltése keül. Édemes megjegyezni, hogy az NtAllocateVitualMemoy és NtWiteVitualMemoy függvények a célfolyamat kontextusában futnak, ezét engedi a Windows, hogy íjanak egy folyamat pivát címteébe. Amiko a lefoglalt teületekhez el szö hozzáfének és azokat módosítják hadvees MMU beállítja az acessed (A) és dity (D) biteket a vonatkozó PTE-ben. Következ lépésként a CeateRemoteThead függény keül meghívása beállítva LoadLibay WinAPI függvényt a szál kezd címének. Ennél a pontnál a LoadLibay az újonnan létehozott szál által keül meghívása a betöltend DLL nevével. Ekko el szö egy le handle-lel té vissza az NtOpenFile, ami átadása keül a NtCeateSection hogy egy újsection objektumot hozzon léte a vonatkozó DLL számáa. A Windows késleltetett memóiakezelésének köszönhet en itt még nem készül hadwae-es PTE bejegyzés, hanem csak egy Pototípus PTE (PPTE) kenel stuktúa inicializálódik. Itt kihangsúlyoznám, hogy a PPTE-k a EXECUTE_WRITECOPY védelmi maszkkal keülnek inicializálása (ezt az RWX és Cw szimbólumokkal jelölöm a táblázatban) Copy-On-Wite m veletek engedélyezéséhez. A memóiamegosztás engedélyezéséhez a DLL most egy Section objektum nézetként keült betöltése az NtMapViewOfSection kenel függvény segítségével, mely VAD bejegyzést is készít ezen a ponton a Pototípus PTE segítségével. Következ lépésként pedig beállít egy laphiba kezel utint, hogy a tényleges hadvees PTE bejegyzések elkészüljenek a DLL els hozzáféésénél. Végezetül a fájl bezáása keül a NtClose kenel függvény segítségével. Amint a 4. táblázat is mutatja, a bemutatott injekciós technika Zeo szoftvees PTE-t és hadvees PTE-ket készít, ahol ez utóbbinál a Valid, Witeable, Accessed, Dity and Copyon-Wite bitek keülnek beállítása. Ez a példa jól mutatja, hogy bizonyos WinAPI hívások hogyan befolyásolják a Windows opeációs endszeek memóia kezelését. Ugyanakko ez a gazdag funkcióhalmaz lehet vé teszi, hogy különböz kód injekciós eljáásokt detektáljunk, melyek különböz képpen befolyásolják a folyamatok lapozási eseményszámosságát. THESES 2:. Egy új endsze-monitoozó eljáást javaslok, ami igény szeinti (on-demand) vitualizációt használva növeli a létez megoldásoknak (pl.: Nito [PSE11] és Ethe [DRSL08a]) a monitoozás tanszpaenciáját vagy teljesítményét. Tehát a megközelítésem nem igényeli, hogy másolatot készítsünk az analizálandó endsze l, sem pedig azt, hogy analizáto eszközöket telepítsünk magáa a vizsgálandó endszee. Tehát a meglév megoldások kolátaitól mentes. Egy komoly kolátja a meglév hosztalapú anomáliadetekciós megközelítéseknek, hogy az analizálandó endszet egy izolált (tipikusan vitualizált) könyezetben fut, vagy analízis eszközök installálása szükséges magáa az analizálandó endszee. Az els esetben, valakinek egy vituális másolatot kell csinálni az analizált endsze l és az eedeti könyezet l (pl.: más szeveek ugyanazon hálózaton) azét, hogy a vitualizált könyezetben is együtt tudjanak m ködni. Megjegyzend, hogy ha az analizálandó endsze másolata önmagában fut, a malwae könnyen detektálni tudja a könyezeti változásokat és megváltoztathatja a viselkedését a detekció elkeülésének céljából. Repezentáns másolat készítése egy opeációs endsze l azonban egy komoly pobléma lehet, ami sok e foást igényel és megszakításokat okozhat a futó endsze m ködésében. Ugyanakko magas kockázata van annak is, hogy az elkészült másolat nem lesz epezentáns, ami a teljes detekció folyamatát elonthatja. A második esetben, amiko analízis eszközök keülnek telepítése magáa az analizálandó endszee, akko az analízis nem lesz tanszpaens. Ez azt jelenti, hogy a telepített eszközöket könnyen detektálni tudja a malwae. Ráadásul, néhány kö- 11

13 4. táblázat. Egy DLL injektálása a célfolyamatba a ➊ VitualAllocEx, ➋ WitePocessMemoy, ➌ CeateRemoteThead és ➍ LoadLibay WinAPI függvények segítségével. Fontos kiemelni, hogy a vonatkozó kenel függvények a VitualAllocEx és WitePocessMemoy függvényeknek a célfolyamat kontextusában futnak. Ezúton gaantálja Windows, hogy nem tötnéik memóiavédelmi hatásétés, amiko egy új DLL keül betöltése. Megjegyzend továbbá, hogy a stat addess (sa) paamétee aceateremotethead függvénynek azt a címet jelöli, ahol az új injektált szál indítása után a futás megkezd dik. Míg a HW PTE oszlop azon biteket mutatják, amiket a vonatkozó kenel függvények állítottak be a SW PTE oszlop azon szoftvees PTE altípusokat jelöli, melyek az événytelen lapok kezelésée használ fel a Windows. Ehhez hasonlóan a PPTE és VAD bejegyzés oszlopok a Pototípus PTE-khez és VAD bejegyzésekhez tatoznak. Míg a táblázat fels észe azon memóia teületeke utal, melyek a betöltend DLL nevének kezeléséhez szükségesek, az alsó ész má a DLL számáa lefoglalt memóiateület lapozási eseményeit mutatja. Win API ➊ ➋ ➌ ➍ Paametes Kenel function HW PTE SW PTE PPTE VAD enty Laptábla bejegyzés változások a DLL nevée vonatkozóan potection=rw NtAllocateVitualMemoy Zeo RW NtPotectVitualMemoy Dz RW #PF (NtWiteVitualMemoy) V,W RW size=len(dll_name) V,W, NtWiteVitualMemoy A,D RW sa= V,W, NtCeateTheadEx &LoadLibay A,D RW Laptáblta bejgyezés változások a DLL-e vonatkozóan NtOpenFile R,W, NtCeateSection X,Cw R,W, NtMapViewOfSection Zeo X,Cw dll_name R,W, NtQueySection Zeo X,Cw R,W, NtClose Zeo X,Cw V,W, R,W, #PF (on st access) Cw X,Cw R,W, X,Cw R,W, X,Cw R,W, X,Cw R,W, X,Cw nyezetben, mint például a kitikus infastuktúák IT endszeei, sem a m ködési megszakítása, meg pedig tetsz leges pogamok telepítése nem engedélyezett. Ezét javaslok egy új endsze monitoozó eljáást, amely a létez megoldásoknak (pl.: Nito [PSE11] and Ethe [DRSL08a])a teljesítményét vagy a tanszpaenciáját javítja. Ráadásul, a megközelítésem nem igényli a vizsgált endsze lemásolását, sem pedig azt, hogy új alkalmazásokat telepítsünk a célendszee. Tehát mentes a koábbi megoldások kolátaitól. A megközelítésem a hadwae-el támogatott vitualizációs megoldáson alapul ami a moden CPU-kban éhet el, és melynek alapötletek, hogy indítsunk el egy hypeviso éteget a futó opeáció endsze alatt anélkül, hogy azt úja kéne indítani vagy meg kéne állítani. Ez a hypeviso magasabb pivilégiumszinten fut, mint maga az opeációs endsze, tehát az analizált endszenek a viselkedését tanszpaensen képes meggyelni anélkül, hogy telepítenénk bámilyen eszközt magáa 12

14 az analizált endszee. Ugyanakko a futó endsze az eedeti könyezetében maad, tehát a malwae-ek nem tudnak detektálni semmilyen gyanús könyezeti változást. Ezen felül javaslok egy új endsze-monitoozó eljáást is, melyet lehet szabályozni a monitoozás ganulaitása és tanszpaenciája mentén. THESIS 2.1:. Javaslok egy új endsze-monitoozó algoitmust, ami a tanszpaencia és a ganulaitás tekintetében konguálható. Ugyanakko, megmétem a megközelítésem teljesítményét, ami elhanyagolható veszteséget mutatott a memóia-intenzív m - veletek esetén, és a CPU-intenzív esetben pedig maximálisan 35%-os csökkentést tapasztaltam. Ennek eedményeképp a vizsgált endsze stabil és használható maad monitoozás alatt is. A koábbi, a vendég opeációs endszeen kívül elhelyezked endszehívás monitoozó eljáásokkal ellentétben (Ethe [DRSL08a]), teveztem és implementáltam egy új és általános metódust, ami teljesen kompatibilis 64-bites endszeekkel. 32-bites módban a SYSENTER utasítást használják a gyos endszehívásokhoz. Mivel a SYSENTER utasítást nem támogatja az AMD64 platfom, egy másik gyos endszehívási utasítása támaszkodtam (SYSCALL) ami kompatibilis, mint az Intel, mind pedig az AMD pocesszookkal. A következ kben, bemutatom az új endszehívás monitoozó eljáásom észleteit 64-bites móda. Ahhoz, hogy egy módosítatlan opeációs endszet tudjak monitoozni egy hypevisoból, meg kell gyelnem a kontextus váltásokat, amik a VMEXIT hatásáa töténnek. Habá, hasonlóan a SYSENTER utasításhoz,a SYSCALL sem geneál VMEXIT-et, amiko futtatása keül. Tehát ezt a poblémát specikusabban kell feloldani. Egy módját ennek kezelésée az [DRSL08a]-ben javasoltak a SYSENTER utasítása. Lefodítva ezt ez ötletet SYSCALL-a, ezen utasítás célcímét módosítani kell úgy, hogy egy kilapozott teülete mutasson. Ezt a *STAR egiszteek (STAR, CSTAR, LSTAR) módosításával lehet megtenni. Amiko a pocesszo hozzáféne ehhez a címhez, egy laphiba keletkezik (#PF) és egy VMEXIT töténik a kontextusváltás céljából. Elkapva a laphibát hypeviso szintjén, a SYSCALL eedeti célcímét visszatöltik *STAR egiszteekbe és újafuttatják az utasítást. Ezzel a megoldással az a pobléma, hogy nagyon sok laphiba van alapból az opeációs endsze nomál m ködése soán is. Minden ilyen laphibát elkapva és gyelve az OS teljesítménye dasztikusan lecsökkenne. S t, a lapozásnak köszönhet en a gép teljesítménye még jobban lecsökken kisebb memóiakapacitás esetén. Ráadásul, az OS így sokkal több laphibát geneál. Ebb l adódóan egy másik eljáást találtam ki, ahol is a VMEXIT-ek száma nem függ az hadve és a futtatott alkalmazások számától. Az új megközelítésem, hasonlóan a Nitohoz [PSE11], événytelen opcode kivételeket használt a laphibák helyett azét, hogy a koábbi megoldások alacsony teljesítményén javítani lehessen. Els lépésként kinullázom azsce (system call enable) bitet a vendégkönyezet EFER egiszteén keesztül, melynek hatásáa a SYSCALL utasítás ismeetlen lesz a pocesszo számáa. Ennek eedményeképp amiko az utasítás lefut egy événytelen opcode kivétel (#UD) geneálódik, melynek hatásáa VMEXIT (VMEXIT_EXCEPTION_UD) keletkezik. Ekko a endszehívás száma a hypeviso segítségével kinyehet az EAX egiszteb l a vendégkönyezet felhasználó módú adatstuktúáival együtt melyet a GS szelektoon keesztül lehet eléni. Mivel az #UD kivétel nem növeli az utasításszámlálót (RIP), nem kell annak igazításával foglalkoznom a SYSCALL újafuttatása édekében. A koább megoldásokkal ellentétben [PSE11], a EFER.SCE bitet újaengedélyezem ekko a magasabb tanszpaencia gaantálása édekében. Habá ezt úja letilthatom attól függ en, hogy milyen ganulaitás és tanszpaencia konguáció mellett döntöttem. Ennek elééséhez, egy másik VMEXIT geneálását választottam, ami ugyan teljesítményveszteséggel já, de az analízis tanszpaenciáját iányíthatóvá teszi. Tehát, amiko egy invalid opcode kivétel lekezel dik, és a szükséges tulajdonságokat kiolvastuk a vendégkönyezet memó- 13

15 iájából egy hadvees beakpoint keül elhelyezése a DR0 és DR7 egiszteek segítségével. Ha beakpointot ekko egy olyan címe állítom ami egészen biztosan le fog futni még a következ endszehívás el tt, úgy a monitoozás ganulaitása maximális. Ha azonban egy olyan címet választok, amiko több endszehívás is kimaad, úgy magasabb taszpaenciát étem el, viszont az analízis ganulaitása csökkent. Ez a beakpoint keülhet felhasználó-, vagy kenel módú teületeke is, viszont akko ez pedesztinálja, hogy felhasználó-, vagy kenel módú objektumokat fogunk tudni helyeállítani. Az 3. ába az invalid opcode kivételkezel algoitmust mutatja be észletesen. Amiko a vendég könyezet utasításszámlálója eléi a hadvees beakpointunkat, akko egy VMEXIT_EXCEPTION_DB keletkezik a pocesszo felé, amit a bejegyzett handleek segítségével lehet lekezelni. Ez a handle letiltja a endszehívásokat ismét az EFER.SCE kikapcsolásával a vendégkönyezet számáa, majd letöli az elhelyezett beakpointot. Végül pedig az OS objektumokat is helye lehet állítani itt. Ezt az algoitmust a 4. ába észletezi. 3. ába. Az invalid opcode kivételek kezelésée szolgáló algoitmus. 4. ába. A debug kivételek kezelésée szolgáló algoitmus. Egy másik fontos kontibúciója ennek a munkának megmutatni, hogy ez az új endszehívás monitoozó eljáás jobb teljesítményt biztosít, mint koábbi jól ismet metódusok [DRSL08a, SG10]. Ehhez el szö az #UD and #PF és kivételekhez egisztáltam kezel utinokat a hypevisoban, hogy megméjem egy endsze nomál m ködése soán keletkez invalid opcode kivételek és laphibák számát. Ahhoz, hogy a két eljáás közti különbséget megméjem, el szö megszámoltam a laphibák és invalid opcode kivételek számát ugyanazon endsze alatt különböz feltételek mellet. Ehhez egisztáltam egy kezel utint az NBP-ben az #UD-hez, illetve használtam a TaceView alkalmazást ami a Windows Dive Kit [Mic12] észe. Ez utóbbi azét kellett, met olyan sok laphiba keletkezett a endsze nomális futás közben, hogy az NBP-b l számlált laphibák esetén a monitoozott endsze teljesen válaszképtelenné vált. A mééseim megmutatták, hogy a laphibák száma e sen összefügg a gép konguációjával. Továbbá megmétem a laphibák számát fissen endszeindítás után és miután több alkalmazást elindítottam. A mééseim azt mutatták, hogy ez utóbbi esetben jelent sen megn tt a lapozások száma. Ezeket az eedményeket az 5. táblázat foglalja össze. Ennek a méésnek a 14

16 5. táblázat. A laphibák és invalid opcode kivételek számlálása nomál endszem ködés közben 2 CPU maggal. A mintavételezési id intevallum 2,5 pec és a statiszikák 12 elem mintából lett számítva. #UD #PF Konguáció Mean Std Mean Std 1. Nincs exta pocessz Exta pocesszek legédekesebb észe, hogy egyetlen invalid opcode kivételt sem találtam még egy hosszabbított 30 peces id ablak alatt sem. Másfel l pedig megállapítható, hogy a laphibák száma e sen összefügg a futó alkalmazások számával is. 6. táblázat. A Passmak CPU teljesítményteszt eedményei egy nem monitoozott, Blue-Pilles és egy monitoozott endsze esetén. Az els oszlop listázza a viszgált m veleteket, melyeket a teszt futtatott. A másik két oszlop pedig az átlagot és szóást jelzi. Native Blue-Pilled Monitoozott M veletek Mean Std Mean Std Mean Std 1. Egész mat. (MOps/s) Lebeg pontos mat. (MOps/s) Pímek keesése (Eze pím/s) SSE (Mill. mátix/s) Tömöítés (KBytes/s) Rejtjelezés (MBytes/s) Fizikai (Fame/s) Szting endezés (Eze szting/s) Megmétem továbbá a teljesítményvesztést a javasolt endsze monitoozó algoitmus futtatásako is a Passmak Pefomance Test [Pas12] segítségével. A teszteket 12-sze futtattam le minden konguációnál, majd kiszámoltam a vonatkozó statisztikai metikákat (átlag és szóás). Kiétékeltem a teljesítményét a pocesszonak natív, Blue-Pilles és monitoozott esetben is. 7. táblázat. A Passmak memóia teljesítményteszt eedményei egy nem monitoozott, Blue-Pilles és egy monitoozott endsze esetén. Az els oszlop listázza a viszgált m veleteket, melyeket a teszt futtatott. A másik két oszlop pedig az átlagot és szóást jelzi. Native Blue-Pilled Monitoozott M veletek Mean Std Mean Std Mean Std 1. Kis blokkok foglalása(mbytes/s) Cachelt olvasás (Mbytes/s) Olvasás cache nélkül (Mbytes/s) Íás (MBytes/Sec) Nagy RAM (M velet/s)

17 Amint a 6. táblázat mutatja, az NBP futtatása önmagában nem já teljesítményvesztéssel az endsze számáa. Ezét is adja meg a lehet ségét, hogy saját monitoozó kiegészítést íjunk. A endsze monitoozása alatt a CPU teljesítményveszteség 30.7% (Lebeg pontos) és 35.4% (Tömöítés), ami még mindig elfogadhatónak számít a gyakolatban, hiszen az OS stabil maadt a m ködése soán. Fontos megjegyezni, hogy a endsze monitoozást maximális ganulaitása állítottam azét, hogy egyetlen endszehívást sem hagyjon ki. Habá azt is ki kell emelni, hogy a debug pint utasítások jelent sen befolyásolhatják az eedményeket. Ezen felül a memóia teljesítményvesztést is megmétem ugyanazon feltételek mellett. Amint a 7. táblázat mutatja, a memóiaveszteség elhanyagolható hiszen 0.1% (Cachelt olvasás) és a 8.5% (Kis blokkok foglalása) étékek között mozognak a számok. A vonatkozó publikációk: [PLV + 15, PB14, BPBF12b, BPBF12a] Új támadások hadvevitualizáció ellen THESES 3:. Két új támadást javaslok I/O vitualizáció ellen. Az egyik a Peipheal Component Inteconnect expess (PCIe) konguációs címteének a módosításán alapszik, míg a másik egy hosztoldali Non-Maskable Inteupt (NMI) segítségével lehet kivitelezni. Míg az el bbit kézzel fedeztem fel, addig a másikat a PTFuzz nev fuzzeem segítségével, amit DMA m veletekkel kapcsolatos alacsony szin poblémák feldeítéséhez készítettem. Ráadásul ez az utóbbi támadás m ködik moden hadveen és szoftveen még akko is, ha minden létez védelmi megoldás be van kapcsolva. A támadásomat Xen 4.2- n és KVM 3.5-ön demonstálom, továbbá megmutatom, hogy ez a séülékenység nem egyedülálló, hiszen más anomáliát is felfedeztem a PTFuzz segítségével. A támadásaim komoly jelzések a hadve és szoftve gyátók felé, hogy hangsúlyosabban kellene foglalkozniuk temékeik biztonságosabbá tételével. Az elmúlt tíz év soán nagy mennyiség cikket [SLQP07, WJ10, MLQ + 10, GAH + 12, ANW + 10, KSRL10] közöltek a VMM-ek biztonságosabbá tételével, illetve teljesítményük, kapacitásuk növelésével kapcsolatban. Számos munka [WR11, Woj08b, Woj08a, RT08, LSLND10, Pat12] említést tesz és implementál lehetséges támadásokat is. Sajnos legtöbbjük csak elméleti lehet ségeket taglalja és csak néhány lett ezek közül tényleges implementálva és tesztelve. S t mi több, még ha léteznek is demonstációs célból készült implementációk, gyakan nehéz megéteni, hogy pontosan milyen el feltételek szükségesek a támadások kivitelezéséhez, azoknak ténylegesen milyen hatása van, illetve azokat mennyie lehet általánosítani más könyezeteke, VMM-eke is. A legtöbb ilyen kédést nehéz megválaszolni és nem itka, hogy a szakét k is elté véleménnyel vannak ezekkel kapcsolatban. Végül, hogy a dolgokat még jobban megnehezítsük, a mostani VMM-ek endkívül gyosan fejl dnek. Minden egyes új kiadás, új technológiákat tatalmaz, ami potenciálisan új séülékenységhez vezetnek és temészetesen védelmi megoldásokat is implementálnak ekko, ami pedig a égi támadásokat eszközölik ki. Például, számos technikát javasoltak nemég a I/O m veletek hatékonyabbá és biztonságosabbá tételéhez. Az úgy nevezett közvetlen eszközcsatolással (vagy más néven passthough), a VMM kizáólagos eszközhozzáféést kínál egy vendégkönyezet számáa anélkül, hogy ezt a hozzáféést más vituális gépekkel meg kéne osztania. Ezt úgy valósítják meg, hogy az eszközt felcsatolják közvetlenül a vituális gép címteébe, és ezáltal lehet vé teszik a VM számáa, hogy azt közvetlenül iányítsa. Ezáltal jelent s teljesítménynövekedést lehet eléni. Ugyanakko ez a megközelítés számos biztonsági poblémát is felvet, ami végül aa ösztönözte a hadvegyátókat, hogy hadveel támogatott védelmi megoldásokat implementáljanak mind a chipset-ben, mind pedig a CPU-ban. Ezét javaslok egy új támadást az I/O vitualizáció ellen, mely m ködik moden hadveen 16

18 és szoftveen. Ezen felül, minden más támadást is különböz hadve és VMM konguáción futtatom két támadási fogatókönyv szeint. Az els esetben azt feltételezem, hogy a támadónak teljes hozzáféése van egy vendég könyezethez, melyhez egy passthough eszköz csatlakozik. Ez egy általános konguáció IaaS felh k esetén, melyek például gakus kátyákhoz adnak ilyen típusú hozzáféést (pl.: Amazon EC2 Cluste GPU) A második esetben, azt feltételezem, hogy a támadó képes a pivilegizált vendégkönyezet kontollálni vagy valamilyen módon má kompomittálta azt. Habá ezt az esetét nehezebb eléni, mégis egy fontos támadó modellt jelöl melyet gondosan ki kell étékelni. Fontos azonban megjegyezni, hogy kolátlat hozzáféés a pivilegizált vendégkönyezethez nem jelent teljes hozzáféést a zikai géphez [Woj08b]. Más szóval, a VMM-et úgy tevezték, hogy védve legyen egy kompomittált pivilegizált VM-mel szemben. A támadásokat KVM hoszt OS-ben is elindítottam, hogy beazonosítsak különbségeket a Xen pivilegizált vendégkönyezettel (Dom0). Fontos kiemelni, hogy ezt csupán a vizsgálat teljessége miatt végeztem el, mivel a host OS pivilégiumok KVM alatt megegyeznek a VMM teljes iányításával is. THESIS 3.1:. Javaslok egy új Memoy Mapped I/O támadást a PCI Expess eszközök konguációs címteén keesztül koábbi VMM-ek ellen. Az x86-os achitektúában a PCI eszközöket kétféleképpen lehet eléni: Pot Mapped I/O (PIO) vagy Memoy Mapped I/O (MMIO) segítségével. Minden egyes PCI eszköznek a konguációs címtee az eszköz bels konguációs memóiájában táolódik. Ezt a memóiát speciális egiszteeken vagy az MMIO címtéen keesztül lehet eléni. Ezt a konguációs címteet tipikusan a BIOS kezeli, vagy az OS kenelje inicializálja és konguálja be. A Base Addess Registe-ek a konguációs címtéeben helyezkednek el, a PCI szabvány íja le és azt a címet specikálják ahová az eszköz memóiája fel van csatolva a PIO vagy MMIO címtében. A konguációs címté egiszteei tipikusan emuláltak a teljesen vitualizált vendégkönyezetek számáa, és néha még a pivilegizált VM-ek számáa is. Ebben az esetben ha a vendégkönyezet a konguációs címteét szeetnék eléni, úgy a kéést a VMM elkapja, ami pesze jelent s teljesítményveszteséggel já. Tehát a teljesítmény javítása édekében néhány VMM (pl.: KVM) közvetlen hozzáféést enged a PIO és MMIO címtéhez [YBYW08], kivéve azokat a kééseket, amik a konguációs memóiát címzik meg. A PCI Expess (PCIe) eszközöknek egy kitejesztett konguációs címtee van, melyet hagyományos memóia m veletekkel (MMIO) lehet eléni. Ahhoz hogy ezt az esetet teszteljem, implementáltam egy új konguációs címté támadást, melyet az MMIO címteén keesztül lehet elindítani azzal a céllal, hogy a memóiába felcsatolt egiszteeit a céleszköznek manipulálni tudjam hasonlóan a má koábban ismet PIO támadásokhoz [DA07]. Ehhez megcímeztem a céleszköz PCIe konguációs címteét felhasználva annak azonosítóját [Fle08], és megpóbáltam módosítani a konguációs egiszteeit (pl.: BAR). Hasonlóan a PIO támadáshoz az MMIO támadásom csak koábbi VMM-eken m ködik, ahol az MMIO címté nincs emulálva. 17

19 THESIS 3.2:. Javaslok továbbá egy Non-maskable Inteupt (NMI) injekciós támadást melyet leteszteltem és veikáltam mind Xen 4.2-es és KVM ás endszeeken. Fontos azonban megjegyezni, hogy a támadás bámely VMM-et éinthet ahol a System Eo Repoting engedélyezett. Meggy z dtem továbbá, hogy a támadás biztosan m ködik minden létez biztonsági konguáció mellet, mivel engedélyeztem a DMA és inteupt emapping, valamint a x2apic módot is a pivilegizált VM-en/hoszton. Ezt a konguációt ugyanis biztonságosnak ítélnek minden létez inteupt támadás ellen. Azét, hogy az inteupt geneálás soán fellép alacsony szint poblémákat ki tudjam tesztelni, teveztem és implementáltam egy eszközt PTFuzz néven az Intel e1000e hálózati dive kiegészítésével. PTFuzz képes bámilyen típusú Message-signalled Inteuptot (MSI) geneálni az MSI cím és adat komponenseken keesztül. Ezen felül pedig a DMA kéések méetét is tudja változtatni. Úgy m ködik, hogy DMA segítségével adatot í (MSI adat komponens) a LAPIC MMIO címtébe. Mivel a PTFuzz képes fuzzolni minden egyes MSI mez t külön-külön lehetséges úgy nomhangolni, hogy mind a kompatibilitást meg z, mind pedig az új, emappable fomátumú MSI-ket támogassa. A PTFuzz m ködése néhány lépésben összegezhet : 1. Készítsünk el egy küld buet (TXb) a vendég OS-ben és töltsük fel az MSI adat komponens étékével. 2. Készítsünk el egy fogadó buet (RXb) a vendég OS-ben. 3. Változtassuk meg az RXb zikia címét az MSI cím komponesének megfelel en úgy, hogy az a memóiába csatolt inteupt címtée mutasson (MMIO LAPIC) 4. Mozgassuk az MSI adat komponenst DMA tanzakción keesztül a kátya bels TX bueébe. 5. Küldjük az adatot loopback módon keesztül a kátya RX bueébe. 6. Mozgassuk az MSI adatot a kátya bels RX bueéb l a vonatkozó MMIO LAPIC címtée egy megadott DMA kéés méetben, melyet az MSI cím (0xfeexxxxxx) deniál. 7. Ha az MSI adat komponenst fuzzoljuk, akko válasszunk ki egy új MSI adat étéket és ismételjünk meg a fentieket az els lépést l kezdve. 8. Ha az MSI cím komponenst fuzzoljuk, akko válassznk ki egy új MSI cím étéket és ismételjünk meg a fentieket az hamadik lépést l kezdve. A teljes MSI adat és címté fuzzolása sok manuális munkát igényelne az eedmények kiétékelése soán. Ebb l adódóan úgy döntöttem, hogy azon MSI mez ke fókuszálok, melyek a támadó szempontjából édekesek lehetnek, vagy egyételm kolátokat állított fel velük kapcsolatban a gyátó. Egészen konkétan bemutatom a meggyeléseimet, melyeket a kompatibilitást meg z MSI adat fomátum vecto mez jének, és a emappable fomátumú MSI cím komponensben elhelyezked don't cae mez nek a fuzzolásával kapcsolatban tapasztaltam. Ha nem vát hadve viselkedést tapasztaltam az egyik tesztesetnek megfelel en, úgy instumentáltam a VMM kódját, hogy begy jtsek minden infomációt, ami a pobléma megétéséhez szükséges. Az els kísélet soán, a kompatibilitást meg z MSI adatfomátum vecto mez jét fuzzáltam az MSI kéés méetének állításával együtt. A teszt soán észevettem, hogy a VMM/pvilegizált VM egy hagyományos Non-maskable Inteupt-ot (NMI)kapott a vekto néhány étéke esetén. Ez akko tötént, amiko minden védelmi megoldás be volt kapcsolva. Ráadásul, ugyanezt az 18

20 5. ába. Inteupt geneálás a PTFuzz segítségével. Ez az ába két inteupt geneálási esetet mutat be melyeket egy számozott és egy bet vel jelölt útvonal í le. A számozott útvonalon, a PTFuzz egy legitim MSI-t ké azáltal, hogy (1) DMA íást végez az MMIO LAPIC címtébe (2) mely kéést el szö a DMA emapping modul (DMAR) ellen iz. Ennek eedményeképp egy kompatibilitást meg z MSI geneálódik (3) melyet az inteupt emapping modul (IR) blokkol. A bet vel jelölt útvonal viszont a nem támogatott fomátumú MSI kéésemet mutatja (a), melyet a platfom detektál és blokkol. Viszont, ha a System Eo Repoting engedélyezve van, úgy a platfom a SERR státusz bitet beállítja a Memoy Contolle Hub (MCH) PCI eszközben (b). Ennek eedményeképp egy hosztoldali Non-maskable Inteupt (NMI) keletkezik, melyet közvetlenül annak zikai CPU-nak küldi a platfom amely a pivilegizált VM-et/hoszt OS-t/VMM-et futtatja. A SERR által indukált NMI-k viszont VMM hoszt szoftve leállást okozhatnak, vagy pedig meghívják a hosztoldali NMI kezel utint (d) mely megnyitja a lehet séget a vendégkönyezetb l a VMM-be való kitöéshez. eedményt kaptam, amiko az MSI kéés méete nem egyezett meg kívánt MSI átvitel méetével (tehát nem 32-bit hosszú volt). A tesztjeim közvetetten hosztoldali hagyományos NMI-t geneáltak az egyik zikai CPU felé (egészen konkétan a Bootstap Pocessonak - BSP). Egészen pontosan azáltal, hogy egy nem támogatott fomátumú MSI kéést intéztem DMA tanzakció segítségével a memóiába felcsatolt inteupt címtébe, a platfom blokkolta az MSI kéést és egy PCI System Eo-t (SERR#) geneált, mely NMI fomájában küldtek tovább, hogy jelezzék a hadvees hibát. Ebben az esetben a SERR status bitet beállítja a platfom a Memoy Contolle Hub (MCH (BDF 00:00.0) PCI eszközben. Tehát a nem ellen zött hosztoldali NMI annak a zikai CPU-nak továbbítja, mely a pivilegizált VM-et/hoszt OS-t/VMM-et futtatja. A pivilegizált VM/hoszt OS/VMM kenel beállításától függ en ezt az NMI lekezelheti a pivilegizált VM/hoszt OS/VMM vagy teljes endszeleállást (panic) okozhat. A 5. ába egy magasabb szint áttekintést nyújt a támadásól. Amiko közelebb l megvizsgáltam a támadás köülményeit, észevettem, hogy az NMI akko geneálódik, amiko az MSI fomátumban a vektoszám kisebb mint 16, vagy a kéésnek nem megfelel a méete (konkétan nem 32-bites). Az el z esetnek az az oka, hogy az MSI nem képes inteuptokat szállítani a 16-os vektoszám alatt [Int12]. A legf bb különbség az el z támadások és az NMI injekciós támadásom között az az, hogy ez utóbbi minden védelmi megoldás mellett m ködik. Ezt úgy mutattam meg, hogy bekapcsoltam a DMA és inteupt emappinget, csak úgy, mint az x2apic módot a pivilegizált VM-ben/hoszt- 19