A macOS eléggé marcona módon védi a rendszer biztonságát, de a külső fejlesztők alkalmazásai esetén ez már nem feltétlen igaz. Ezért a Mac-ek esetén a legtöbbször épp ezt használják ki a támadók.

Nem könnyű Endpoint Security jogosultságot szerezni az Apple-től, de Csabának sok türelem árán végül mégis sikerült, és azt fel is használta a macOS-re fejlesztett alkalmazásában, a Shieldben, ami képes jelezni és megakadályozni a különféle appokon keresztüli, magasabb jogosultság szerzését (privilege escalation) vagy az adatvédelmi korlátozások kijátszását. Az alábbi bejegyzésében az alkalmazás megszületéséről, a fejlesztésről és az Endpoint Security jogosultság megszerzéséről ír.

Ebben a posztban szeretném elmesélni a Shield.app készítésének történetét és bemutatni, hogy mire lehet használni. Az elmúlt egy év igen mozgalmas volt, és nem mindig éreztem úgy, hogy sikerül valóra váltani az elképzelést, de végül sikerült.

A motiváció

IT biztonsági karrierem elmúlt két évében gyakorlatilag kizárólag macOS biztonsággal foglalkoztam, és ez valószínűleg folytatódni fog az elkövetkezendő években. Elég gyorsan nyilvánvalóvá ált, hogy macOS-en az egyik legjobb mód jogosultság szerzésére, ha egy másik alkalmazás kontextusában futtatjuk a kódunkat. Ez történhet memóriakorrupciós hibák kihasználásával, illetve folyamat-injektálással is. Itt az utóbbira fogok fókuszálni.

A macOS-en (és minden más, az Apple által írt operációs rendszeren is) a legkülönfélébb hozzáférésekhez jogosultságokra, azaz entitlement-ekre van szükség. Minden ilyen jogosultság hozzáférést biztosít valamihez, például a sandbox alatt futó alkalmazások így érhetik el a hálózatot, és az adatvédelem (privacy) kategóriába sorolt erőforrásokhoz (mikrofon, kamera, vagy a merevlemez bizonyos területei) is jogosultságokra van szükség.

Az Apple saját programjai számára több száz féle különböző privát jogosultság áll rendelkezésre, például van olyan, ami a SIP (system integrity protection) által védett régiókhoz enged hozzáférést, vagy olyan, ami által kernel kiterjesztést (kernel extension, KEXT) tudunk telepíteni. Ez mind privát, vagyis a nem az Apple által írt programok nem birtokolhatják.

Mindemellett az XPC kommunikáció egyik biztonsági alappillére, hogy kontrollálni tudjuk, hogy csak azok a folyamatok küldhessenek üzenetet egy privilegizált folyamatnak, amelyek erre jogosultak. Apple folyamatok esetében ez általában jogosultságokhoz kötött, míg mások által írt alkalmazások esetében ez a program digitális aláírásához kapcsolódik. Mindkét esetben ha kódot tudunk futtatni egy XPC kliensen belül, akkor lehetőségünk lesz kommunikálni az XPC szerver komponenssel és adott esetben privilegizált funkciókhoz férhetünk hozzá.

A Kulcskarika (keychain) gyakran szintén kód aláíráshoz, vagy jogosultságokhoz kötött.

Röviden, ha kódot tudok futtatni egy alkalmazáson belül, akkor megörököljük annak a jogait. Éppen ezért a folyamat-injektálás rendkívüli módon korlátozva van macOS-en. Az Apple elég jó munkát végez a saját folyamatainak védelmével, azonban ez nem igaz a harmadik fél által írt alkalmazásokra.

Ez a rés megnyitja a lehetőséget a különböző XPC hibákhoz, amik általában root jogosultság szerzését vagy az adatvédelmi korlátozások kijátszását teszik lehetővé egy támadónak. Ilyen esetek voltak például az alábbiak: LPE in Microsoft AutoUpdate és TCC bypass with Zoom.

A folyamat-injektálásnak három fő típusa van.

1. dylib injektálás környezeti változón keresztül
2. dylib eltérítés
3. task port-on keresztüli kód injektálás

Továbbá Electron alkalmazások (például Slack, Microsoft Teams, Discord, stb.) esetében az alkalmazás debug módban történő futtatása során lehetőség van kód futtatásra az alkalmazásban. (Kapcsolódó cikkek: running Electron apps in debug mode, Electron specific environment variables.)

Azt látva, hogy ezek a hibák mennyire gyakoriak, Mac felhasználó lévén úgy döntöttem, írok egy kis alkalmazást, ami kivédi ezeket a támadásokat.

A Shield fejlesztése

Miután a kernel kiterjesztések egyre inkább háttérbe szorulnak, és nem támogatottak az Apple által, így az Endpoint Security (Végpont Biztonság) keretrendszert használtam. Bevallom, én nem tartom magamat fejlesztőnek, így valószínűleg nem a legjobb a kód, amit írtam, de megtettem minden tőlem telhetőt.

Nagyban hagyatkoztam a Patrick Wardle által létrehozott, nyílt forráskódú Objective-See programokra. (Ezeket mindenkinek ajánlom, aki szeretné védeni macOS rendszerét.) Néhány kódrészletet, főleg a folyamtok monitorozásáért felelős részt egy az egyben átemeltem, illetve hozzásegítettek, hogy rengeteget tanuljak magáról az Objective-C nyelvről és annak használatáról. Munkájáért nagyon hálás vagyok.

Szintén sok időt töltöttem Stephen Davis Crescendo alkalmazásának tanulmányozásával. Habár az Swiftben íródott, és én Objective-C-ben írtam a Shieldet, segített, hogy még jobban megértsem az Endpoint Security keretrendszert.

Sok, kódolással töltött éjszaka után végre olyan fázisba érkezett az app, hogy nyilvánosságra is hozzam. El sem tudom mondani, hogy az elmúlt par hónapban mennyit tanultam a macOS-re szánt alkalmazások programozásáról.

Az eredeti elképzeléseimet jócskán túllépve került bele az automatikus indítás, engedélyezett listás megoldás a hamis riasztások szűrésére, és a tanuló üzemmód is.

Az Endpoint Security jogosultság megszerzése

Az alkalmazás fejlesztése csak a történet egyik fele. Ahhoz, hogy az egész valóra váljon, és ki lehessen adni nyilvánosan is, szükségem volt az Endpoint Security jogosultságra az Apple részéről. Bárki, aki részt vesz az Apple fejlesztői programban, igényelheti – és a dolog itt vált rendkívül idegesítővé.

A jogosultságot 2020 márciusában igényeltem meg. Egy hónap elteltével mindenféle egyéb visszajelzés nélkül megkaptam a jogosultság fejlesztői változatát. Ez lehetővé tette, hogy az általam fejlesztett rendszerkiterjesztést (system extension, a továbbiakban csak SEXT) úgy írjam alá, hogy azt be tudjam tölteni a saját gépemen. Ez nagyban megkönnyíti a fejlesztést, azonban kevés ahhoz, hogy nyilvánosan is elérhetővé tegyem az alkalmazást.

Ahogy haladtam előre a fejlesztéssel, egyre többször írtam az Apple-nek, hogy szükségem lenne a jogosultság éles változatára, amely lehetővé tenné, hogy más is használhassa az appot. Hónapok teltek el bármiféle visszajelzés nélkül, végül júliusban kaptam egy levelet néhány kérdéssel. Ezeket azonnal megválaszoltam, aztán megint következett a nagy csend. Ez nem csak idegesítő volt, de rendkívül demotiváló is. Gyakorlatilag leálltam a fejlesztéssel, teljesen elvesztettem a motivációmat. Semmi értelmét nem láttam a dolognak, hogy a szabadidőmben egy olyan programon dolgozzak, amit rajtam kívül senki más nem fog tudni használni. A saját szórakoztatásom már nem volt elég motiváló erő. 🙂

További hónapok teltek el, és végül november környékén jóváhagyták a jogosultság használatát. Sajnos az öröm nem volt felhőtlen, mivel a profilomban nem engedélyezték rendesen, így gyakorlatilag hiába hagyták jóvá, nem tudtam használni. Hiába írtam több levelet is, szokás szerint nem jött válasz. Jött a karácsony, majd az újév, és végül január elején megcsinálták a profilomat. Alig akartam elhinni. “Röpke” 10 hónap alatt megkaptam, és még bocsánatot is kértek hogy eddig elhúzódott.

Ezzel visszatért a motivációm és végül elérkeztünk 2021 februárjához, amikorra is olyan állapotba hoztam az alkalmazást, hogy nyilvánosságra is hozzam, illetve hogy megkapja az 1.0-s verzió számot.

A Shield használata

Az appnak nincsen klasszikus, ablakos üzemmódja jelenleg, kizárólag a menüsávról vezérelhető. Amikor elindítjuk, egy kis fekete pötty jelzi az alkalmazást:

Ha ráklikkelünk, megnyílik az alábbi menü:

Mielőtt bármit is csinálhatnánk, telepítenünk kell a System Extension-t. Ez automatikusan elindul, amint a programot elindítjuk és több felugró ablak segíti a telepítés folyamatát. Sajnos a felhasználónak több helyen is manuálisan jóvá kell hagynia a telepítést. Miután ez megtörtént, az Endpoint Security (továbbiakban csak “ES”) kliens, ami a védelemért felel és ami a SEXT-en belül található, alapból kikapcsolt állapotban lesz.

Ha szeretnénk a SEXT-et eltávolítani, a megfelelő menü opcióval ezt is megtehetjük, de a macOS csak egy újraindítás után törli véglegesen a SEXT-et. Ez nem távolítja el a teljes alkalmazást, azt nekünk kell megtenni, ha szeretnénk.

Miután a telepítés megvolt, elindíthatjuk az ES klienst akár a Start menüelem kiválasztásával, vagy a Preferences (Beállítások) menüben az ENABLED gomb átállításával.

A beállításokban nincs túl sok lehetőség, így könnyen sorra vehetjük őket egytől-egyig.

Blokkoló üzemmódban ha egy injektálást detektál a program, azt azonnal blokkolja is. Ez többnyire azt eredményezi, hogy az alkalmazás el sem indul, mivel a legtöbb injektálás indulási időben történik. Erről kapunk egy értesítést és a rendszer logokba is bekerül.

Egy értesítés esetén mindig lehetőségünk van azt engedélyezni, azonban az csak a következő futásra lesz hatással. Ha ezt megtettük, akkor a következő ugyanolyan eseményről már nem kapunk riasztást.

He kikapcsoljuk a blokkoló üzemmódot (=detektálás), akkor minden engedélyezve lesz, azonban értesítéseket továbbra is fogunk kapni.

Detektálás üzemmódban lehetőségünk van a tanuló funkcióra. Ebben az esetben a rendszer automatikusan egy engedélyezett listára tesz mindent, amit detektál és nem kapunk semmiféle értesítést.

A következő opció az Apple alkalmazások figyelése. Egyelőre ez nem állítható, ugyanis a task_for_pid típusú hívásokból rendkívül sok van, és nagyon leterhelik a rendszert, akár folyamatos, 20% körüli processor terheltséget eredményezve. Ezt kiiktatva jelenleg nagyjából 0%-os CPU terhelést jelent az alkalmazás. Ez az opció talán engedélyezve lesz a jövőben, de egyelőre így marad. Mivel az Apple programok elég jól védettek ilyen típusú támadásokkal szemben, így ez nem akkora probléma.

A következő rész a különböző védelmek állítása.

A környezeti változókkal történő injektálás védelme négy változót figyel jelen pillanatban. Ezek a DYLD_INSERT_LIBRARIES, CFNETWORK_LIBRARY_PATH, RAWCAMERA_BUNDLE_PATH és ELECTRON_RUN_AS_NODE. Ha bármelyik jelen van, az alkalmazás blokkolva lesz. Ez a Firefox böngészővel okoz némi inkompatibilitást, mert az túlzottan sokat használja ezeket.

A második paraméter a task_for_pid hívások figyelése, amikor egy process a másik task port-jához szeretne hozzáférni. Ez blokkolni fogja például a debuggolást, ami szintén használja ezt a hívást. Így ha egy programot szeretnénk debuggolni, akkor ezt vagy kapcsoljuk ki, vagy pedig engedélyezzük.

A harmadik az Electron típusú alkalmazásokat érinti. Az --inspect kapcsolóval lehet egy Electron programot debug módban indítani, és így kódot injektálni bele. Ez az opció ezt figyeli, és amennyiben ezt detektálja, blokkolja az alkalmazás indítását.

Az utolsó lehetőség a dylib eltérítés figyelése azzal, hogy kötelezővé teszi az alkalmazás, hogy a program és a betöltendő osztott könyvtár (dylib) ugyanazzal a tanúsítvánnyal legyen aláírva. Sajnos a dylib aláírását csak statikus elemzéssel tudom ellenőrizni, úgy, hogy a lemezről beolvasom a fájlt így a sok lemezművelet miatt a nagyobb programok (például Xcode) lassabban indulhatnak.

A beállítások a /Library/Application Support/Shield/com.csaba.fitzl.shield.preferences.plist fájlban kerülnek elmentésre.

Az utolsó dolog amiről érdemes említést tenni, az az engedélyezett injektálások (Allowed Injections) listája.

Itt kapunk egy áttekintést arról, amiket korábban engedélyeztünk és többé nem generálnak értesítést. Van néhány alkalmazás, például a GitHub Desktop, ami kódot injektál saját magába, így egy ilyen listára szükség van ahhoz, hogy a Shield ne okozzon fennakadást a napi munkánkban, szintén ide kell kerüljenek a digitális aláírással nem rendelkező programok, például amiket a brew csomagkezelővel telepítünk.

Végszó

Az egész program ingyenes, forráskódja nyílt és GitHubon elérhető. Bátorítok mindenkit hibák jelentésére es új funkciók igénylésére, azonban nem ígérek gyors reakciót. Az alkalmazást továbbra is szabadidőmben fejlesztem, és abból azért nincs túl sok a család, a munka és a hobbi mellett. 🙂

Az app letölthető GitHubról a Releases alól.