Mint tudják, az enklávéban végrehajtott kód funkcionalitása erősen korlátozott. Nem tud rendszerhívásokat kezdeményezni. Nem tud I/O műveleteket végrehajtani. Nem ismeri a gazdagép alkalmazás kódszegmensének alapcímét. Nem tud jmp-t küldeni, és nem hívja le a gazdagép-alkalmazás kódját. Fogalma sincs a gazdagép alkalmazást irányító címtér-struktúráról (például arról, hogy mely oldalak vannak leképezve, vagy milyen adatok találhatók azokon). Nem kérheti az operációs rendszert, hogy rendelje hozzá a gazdagép alkalmazás memóriájának egy részét (például a /proc/pid/maps fájlon keresztül). A naiv kísérletek egy gazdaalkalmazás tetszőleges memóriaterületének vak olvasására, nem is beszélve az írási kísérletekről, előbb-utóbb (valószínűleg az előbbi) az enklávéprogram kényszerített leállításához vezetnek. Ez akkor történik meg, amikor az enklávé által kért virtuális címtérrégió nem érhető el a gazdagép alkalmazás számára.
Ilyen durva valóság mellett képes lesz egy vírusíró SGX enklávékat használni rosszindulatú céljainak eléréséhez?
A fentiek alapján általánosan elfogadott, hogy egy enklávé csak a fogadó alkalmazást képes kiszolgálni, és az enklávé nem gyakorolhatja saját kezdeményezését, beleértve a rosszindulatúakat is. Ez azt jelenti, hogy az enklávéknak nincs gyakorlati értéke a vírusírók számára. Ez az elhamarkodott feltételezés az egyik oka annak, hogy az SGX védelem aszimmetrikus: a gazdagép alkalmazás kódja nem tud hozzáférni az enklávé memóriához, míg az enklávé kód bármilyen gazdaalkalmazás memóriacímét képes olvasni és írni.
Ezért, ha a rosszindulatú enklávé kód képes volt tetszőleges rendszerhívásokat indítani a gazdagép alkalmazás nevében, tetszőleges kódot futtatni a nevében, átvizsgálni a gazdaalkalmazás memóriáját, és visszaélésre alkalmas ROP-láncokat találni benne, akkor teljes ellenőrzést kaphat a gazdagép alkalmazás felett. lopakodó mód. Nemcsak ellophatja és titkosíthatja a felhasználói fájlokat, hanem a felhasználó nevében is eljárhat. Például adathalász e-maileket küldhet a nevében, vagy DoS-támadásokat hajthat végre. A legmodernebb védelmi mechanizmusoktól sem félve, mint például a kanárik rakásától és a címfertőtlenítéstől.
Mutatunk néhány feltörést, amelyeket a támadók a fent leírt korlátok leküzdésére használnak, hogy kihasználják az SGX előnyeit saját rosszindulatú céljaikra: ROP támadások. Vagy tetszőleges kód futtatása gazdagép alkalmazási folyamatnak álcázva (hasonlóan a rosszindulatú programok által gyakran használt folyamatürítéshez), vagy egy kész rosszindulatú program álcázására (hogy megmentse a kártevőt az antivírusok és más védelmi mechanizmusok üldöztetésétől).
Feltörni a címeket, hogy lássa, olvashatók-e
Mivel az enklávé nem tudja, hogy a virtuális címtér mely tartományai érhetők el a gazdagép alkalmazás számára, és mivel az enklávé kénytelen véget érni, amikor egy elérhetetlen címet próbál beolvasni, a támadónak meg kell találnia a hiba módját. toleránsan átvizsgálja a címteret. Találja meg a rendelkezésre álló virtuális címek feltérképezésének módját. A gonosztevő az Intel TSX technológiájának visszaélésével oldja meg ezt a problémát. Kihasználja a TSX egyik mellékhatását: ha a memóriaelérési funkciót egy TSX tranzakcióba helyezik, akkor az érvénytelen címek eléréséből adódó kivételeket a TSX elnyomja anélkül, hogy elérné az operációs rendszert. Ha egy érvénytelen memóriacímhez próbál hozzáférni, csak az aktuális tranzakció szakad meg, nem a teljes enklávéprogram. Hogy. A TSX lehetővé teszi az enklávé számára, hogy biztonságosan hozzáférjen bármely címhez a tranzakción belül – az összeomlás veszélye nélkül.
Ha a megadott cím elérhető fogadó alkalmazás esetén a TSX tranzakció leggyakrabban sikeres. Ritka esetekben meghiúsulhat olyan külső hatások miatt, mint például megszakítások (például ütemező megszakítások), gyorsítótár-kiürítések vagy egy memóriahely több folyamat általi egyidejű módosítása. Ezekben a ritka esetekben a TSX hibakódot ad vissza, jelezve, hogy a hiba átmeneti. Ezekben az esetekben csak újra kell indítania a tranzakciót.
Ha a megadott cím nem elérhető gazdaalkalmazás esetén a TSX elnyomja a bekövetkezett kivételt (az operációs rendszert nem értesíti), és megszakítja a tranzakciót. A rendszer egy hibakódot küld vissza az enklávé kódjába, hogy az reagálhasson a tranzakció törlésére. Ezek a hibakódok azt jelzik, hogy a kérdéses cím nem elérhető a gazdagép számára.
A TSX-nek az enklávé belsejéből történő manipulálása egy jó tulajdonsággal rendelkezik a gazember számára: mivel a legtöbb hardverteljesítmény-számláló nem frissül az enklávé kódjának végrehajtásakor, lehetetlen nyomon követni az enklávéban végrehajtott TSX-tranzakciókat. Így a TSX rosszindulatú manipulációja teljesen láthatatlan marad az operációs rendszer számára.
Ezenkívül, mivel a fenti feltörés nem támaszkodik semmilyen rendszerhívásra, nem észlelhető és nem is akadályozható meg egyszerűen a rendszerhívások blokkolásával; ami általában pozitív eredményt ad a tojásvadászat elleni küzdelemben.
A gazember a fent leírt hack segítségével megkeresi a gazdagép alkalmazás kódjában a ROP-lánc kialakítására alkalmas kütyüket. Ugyanakkor nem kell minden címet megvizsgálnia. A virtuális címtér minden oldaláról elegendő egy-egy címet megvizsgálni. A 16 gigabájt memória vizsgálata körülbelül 45 percet vesz igénybe (Intel i7-6700K esetén). Ennek eredményeként a gazember megkapja a végrehajtható oldalak listáját, amelyek alkalmasak egy ROP-lánc felépítésére.
Hack a címek írhatóságának vizsgálatához
A ROP támadás enklávé változatának végrehajtásához a támadónak képesnek kell lennie a gazdagép alkalmazás írható, nem használt memóriaterületeinek megkeresésére. A támadó ezeket a memóriahelyeket használja egy hamis veremkeret beillesztésére és egy hasznos adat (shellcode) beillesztésére. A lényeg az, hogy egy rosszindulatú enklávé nem tudja megkövetelni a gazdagéptől, hogy magának foglaljon memóriát, hanem visszaélhet a gazdaalkalmazás által már lefoglalt memóriával. Ha persze sikerül ilyen területeket találnia az enklávé összeomlása nélkül.
A gazember ezt a keresést a TSX egy másik mellékhatását kihasználva hajtja végre. Először is, mint az előző esetben, megvizsgálja a cím létezését, majd ellenőrzi, hogy a címnek megfelelő oldal írható-e. Ehhez a gonosztevő a következő feltörést használja: egy írási funkciót helyez el egy TSX-tranzakcióba, és annak befejeződése után, de még mielőtt befejeződött volna, erőszakkal megszakítja a tranzakciót (explicit abort).
A TSX-tranzakció visszatérési kódjának megtekintésével a támadó megérti, hogy az írható-e. Ha „kifejezett abortuszról” van szó, a gazember megérti, hogy a felvétel sikeres lett volna, ha végigcsinálja. Ha az oldal csak olvasható, akkor a tranzakció az „explicit megszakítástól” eltérő hibával zárul.
A TSX ezen manipulációja egy másik, a gazember számára előnyös tulajdonsággal is rendelkezik (a hardveres teljesítményszámlálókon keresztüli nyomon követés lehetetlensége mellett): mivel az összes memóriaírási parancs csak akkor érvényesül, ha a tranzakció sikeres, a tranzakció befejezésének kényszerítése biztosítja, hogy a vizsgált memóriacella változatlan marad.
Hack az irányítási folyamat átirányításához
Amikor ROP támadást hajt végre egy enklávéból - a hagyományos ROP támadásokkal ellentétben - a támadó anélkül szerezheti meg az irányítást a RIP regiszter felett, hogy kihasználná a támadott program hibáit (puffer túlcsordulás vagy valami hasonló). A támadó közvetlenül felülírhatja a veremben tárolt RIP-regiszter értékét. Ennek a regiszternek az értékét különösen saját ROP-lánccal tudja helyettesíteni.
Ha azonban a ROP lánc hosszú, akkor a gazdagép alkalmazás veremének nagy részének felülírása adatsérüléshez és váratlan programviselkedéshez vezethet. A támadását rejtetten végrehajtani igyekvő gazember nem elégedett ezzel az állapottal. Ezért létrehoz magának egy hamis ideiglenes verem keretet, és abban tárolja a ROP láncát. A hamis veremkeret egy véletlenszerűen írható memóriahelyre kerül, így a valódi verem érintetlenül marad.
Mit ad a fent felsorolt három hack a gonosztevőnek?
(1) Először is, a rosszindulatú enklávé keresztül feltöri a címeket, hogy megnézze, olvashatók-e, – megkeresi a gazdaalkalmazásban visszaélhető ROP-modulokat.
(2) Akkor a hack a címek írhatóságának vizsgálatához, – egy rosszindulatú enklávé azonosítja a gazdaalkalmazás memóriájában azokat a területeket, amelyek alkalmasak a hasznos adatok beillesztésére.
(3) Ezután az enklávé létrehoz egy ROP-láncot az (1) lépésben felfedezett modulokból, és beilleszti ezt a láncot a gazdagép alkalmazási verembe.
(4) Végül, amikor a gazdagép alkalmazás találkozik az előző lépésben létrehozott ROP-lánccal, a rosszindulatú hasznos adat végrehajtása megkezdődik – a gazdaalkalmazás jogosultságaival és rendszerhívások lebonyolításának lehetőségével.
Hogyan használja egy gazember ezeket a hackeléseket ranzowari létrehozására
Miután a gazdagép alkalmazás átadja az irányítást az enklávénak az egyik ECALL-on keresztül (anélkül, hogy sejtené, hogy ez az enklávé rosszindulatú), a rosszindulatú enklávé szabad helyet keres a gazdaalkalmazás memóriájában kód beszúrásához (szabad helynek veszi a cellasorozatokat amely nullákkal van kitöltve). Aztán át feltöri a címeket, hogy megnézze, olvashatók-e, – az enklávé végrehajtható oldalakat keres a gazdagép alkalmazásban, és létrehoz egy ROP-láncot, amely létrehoz egy új „RANSOM” nevű fájlt az aktuális könyvtárban (valódi támadás esetén az enklávé titkosítja a meglévő felhasználói fájlokat), és megjelenít egy váltságdíj üzenetet. Ugyanakkor a gazdagép alkalmazás naivan azt hiszi, hogy az enklávé egyszerűen két számot ad hozzá. Hogy néz ki ez a kódban?
Az észlelés megkönnyítése érdekében vezessünk be néhány mnemonikát a definíciókon keresztül:
Elmentjük az RSP és RBP regiszterek eredeti értékeit, hogy visszaállítsuk a gazdaalkalmazás normál működését a hasznos terhelés végrehajtása után:
Megfelelő verem keretet keresünk (lásd a kódot a „Hack for redirecting control flow” fejezetből).
Megfelelő ROP modulok keresése:
Hely keresése a rakomány befecskendezéséhez:
ROP láncot építünk:
Így használják ki a gonosztevők az Intel rosszindulatú programok elleni küzdelemre tervezett SGX technológiáját ellentétes célok elérésére.
Forrás: will.com