Sipos Péter
2026. január 5.
1. Bevezetés
Ez a dokumentum egy körülbelül öt hónapon át zajló, egy adott kliens számára végzett penteszt (Software Security Assessment) projektet mutat be esettanulmány formájában. A célja, hogy bemutassa a projekt során vizsgált szoftver típusokat, az alkalmazott vizsgálati megközelítést, valamint az egyes platformokhoz kapcsolódó tapasztalatokat. A dokumentum áttekinti a vizsgált iOS, Android, macOS és Windows alkalmazásokat, és azt, hogy ezek esetében milyen platform-specifikus sajátosságokkal és biztonsági kihívásokkal kellett számolni. Külön foglalkozom a projekt során kialakított automatizációs megoldásokkal, illetve azok szerepével egy hosszabb ideig tartó, több alkalmazást érintő vizsgálat támogatásában, valamint röviden kitérek a további fejlesztési lehetőségekre is.
Az esettanulmány egy olyan biztonsági probléma bemutatásával egészül ki, ahol egy proof-of-concept elkészítése indokolt volt, végül pedig összefoglalom a projekt során szerzett tapasztalatokat és tanulságokat. Általában ezeket a vizsgálatokat a penetrációs teszt szolgáltatásaink keretében végezzük.
2. Vizsgálati módszertan és projektfelosztás
A vizsgálat során alkalmazott módszertan célja nem pusztán technikai hiányosságok azonosítása volt, hanem azok üzleti és kockázati kontextusba helyezése. Az elemzést üzleti hatásalapú szemlélettel végeztük, amely lehetővé tette a feltárt problémák valós jelentőségének és prioritásának meghatározását.
A technikai megállapításokat abból a szempontból értékeltük, hogy azok milyen hatással lehetnek az üzletmenet folytonosságára, az adatok védelmére, valamint a vállalat működési stabilitására és reputációjára.A vizsgálat kiterjedt az általános IT-biztonsági elvárásokkal és releváns szabályozásokkal való összhang értékelésére is, különös tekintettel azokra a területekre, ahol a jelenlegi állapot megfelelőségi vagy kockázati szempontból hiányosságot mutathat.
Kiemelt figyelmet fordítottunk az elavult, nem támogatott vagy ismert sérülékenységekkel rendelkező csomagok és függőségek azonosítására, mivel ezek jelenléte gyakran rejtett, de üzletileg jelentős kockázatot hordozhat. A módszertan eredményeként a megállapítások nem csupán technikai szinten, hanem üzletileg értelmezhető, döntéstámogató formában kerültek összegzésre, támogatva a kockázatok priorizálását és a célzott kockázatcsökkentési intézkedések meghozatalát.
3. Platform-specifikus vizsgálatok
Ebben a fejezetben bemutatom, hogy a projekt során milyen platformokon futó rendszerek és alkalmazások kerültek elemzésre, valamint áttekintést adok azok vállalati környezetben betöltött szerepéről. A vizsgálat célja nem az alkalmazások klasszikus értelemben vett feltörése volt, hanem annak értékelése, hogy egy adott alkalmazás milyen módon jelenthet kockázatot egy vállalat számára, amennyiben azt a szervezet munkavállalói vállalati vagy vegyes használatú eszközökön futtatják.
A konkrét, alkalmazás- és platformszintű vizsgálati módszerek, valamint az ezekhez kapcsolódó megállapítások a későbbi fejezetekben kerülnek részletezésre. Az egyes platformokon az elemzés egységes szemlélet mentén történt: minden esetben figyelembe vettük a platform által biztosított védelmi mechanizmusokat, valamint azokat a tipikus működési és konfigurációs sajátosságokat, amelyek egy vállalati környezetben üzleti, megfelelőségi vagy reputációs kockázatot hordozhatnak.
3.1. iOS alkalmazás sajátosságai
Kiemelt figyelmet kapott az alkalmazások által használt jogosultságok és entitlementek köre. Elemeztük, hogy ezek mennyiben indokoltak az alkalmazás funkciói szempontjából, illetve hogy egy esetleges visszaélés vagy kompromittálódás milyen hatással lehet a vállalati adatokra. Egy túlzott jogosultságokkal rendelkező alkalmazás önmagában is kockázatot jelenthet, különösen akkor, ha a felhasználó nincs tisztában azzal, hogy az alkalmazás milyen adatokat ér el vagy továbbít.
A vizsgálat kiterjedt az alkalmazások adatkezelési és adattárolási gyakorlatára is. Ennek során azt értékeltük, hogy a lokálisan kezelt adatok (beleértve az esetlegesen vállalati jellegű információkat) milyen védelem mellett kerülnek tárolásra, illetve hogy egy eszközvesztés, jogosulatlan hozzáférés vagy kompromittált környezet milyen üzleti következményekkel járhat.
Fontos szempont volt továbbá annak megértése, hogy az alkalmazások működése mennyire átlátható és kontrollálható vállalati környezetben. Az olyan alkalmazások, amelyek háttérben kommunikálnak külső szolgáltatásokkal, vagy nehezen követhető adatáramlást valósítanak meg, akkor is kockázatot jelenthetnek, ha technikailag megfelelnek a platform biztonsági elvárásainak.
3.2. Android alkalmazás sajátosságai
Központi vizsgálati szempont volt az alkalmazások által igényelt és használt jogosultságok köre. Elemeztük, hogy ezek a jogosultságok mennyiben indokoltak az alkalmazás funkciói szempontjából, illetve hogy egy túlzott vagy nem megfelelően kezelt jogosultsági modell milyen üzleti kockázatokat hordozhat. Egy vállalati környezetben egy ilyen alkalmazás akár közvetett adatvesztési vagy adatvédelmi incidenshez is vezethet.
Az Android komponensmodell sajátosságai miatt értékeltük azt is, hogy az alkalmazások egyes komponensei milyen módon érhetők el más alkalmazások számára. A nem megfelelően védett vagy túlzottan nyitott komponensek lehetőséget teremthetnek arra, hogy egy kevésbé megbízható alkalmazás közvetett módon férjen hozzá vállalati adatokhoz vagy funkciókhoz.
A vizsgálat során elemeztük az alkalmazások külső szolgáltatásokkal folytatott kommunikációját is. Az ilyen adatáramlások (különösen mobil környezetben) jelentős megfelelőségi és reputációs kockázatot hordozhatnak, még abban az esetben is, ha technikailag helyesen vannak megvalósítva.
3.3. macOS alkalmazás sajátosságai
A vizsgálat egyik alapvető területe az alkalmazások integritásának és futtathatóságának ellenőrzése volt. Ennek keretében megvizsgáltuk, hogy az alkalmazások megfelelően alá vannak-e írva, valamint hogy a code signing, a hardened runtime, a Gatekeeper és a notarization mechanizmusok hogyan vannak alkalmazva a gyakorlatban. Külön figyelmet kapott az, hogy a védelmi mechanizmusok valóban érvényesülnek-e futás közben, illetve hogy az alkalmazás csomagjának módosítása esetén a rendszer megfelelően blokkolja-e az indítást.
A System Integrity Protection (SIP) szempontjából azt elemeztük, hogy az alkalmazások vagy azok komponensei rendelkeznek-e olyan entitlementekkel, amelyek indokolatlanul gyengíthetik az operációs rendszer által biztosított védelmet. A vizsgálatok során több esetben is előfordult, hogy az alkalmazások a működésükhöz nem feltétlenül szükséges jogosultságokkal rendelkeztek, ami növelte egy esetleges kompromittálás hatását.
A macOS alkalmazások esetében kiemelt figyelmet kapott a binárisok futásidejű viselkedése és a dinamikusan betöltött könyvtárak kezelése. Ennek során vizsgáltuk az @rpath, @executable_path és egyéb relatív hivatkozások használatát, valamint azt, hogy a dinamikus libraryk milyen forrásból kerülnek betöltésre. A cél annak megállapítása volt, hogy előfordulhat-e olyan helyzet, ahol az alkalmazás nem megfelelően védett vagy írható helyről tölt be kódot, ami potenciálisan lehetőséget adhat dylib hijacking vagy hasonló támadási technikákra. Külön figyelmet fordítottunk a helper alkalmazásokra és beágyazott frameworkökre, mivel ezek gyakran eltérő jogosultsági és betöltési szabályokkal rendelkeznek.
A vizsgálat során elemeztük az alkalmazások frissítési mechanizmusait is, mivel ezek az ellátási lánc szempontjából kiemelt kockázatot jelenthetnek. Megvizsgáltuk, hogy a frissítések milyen forrásból származnak, milyen módon történik azok hitelesítése, valamint hogy a frissítési folyamat során alkalmazásra kerülnek-e aláírás- és integritásellenőrzések. Azokban az esetekben, ahol egyedi frissítési megoldás volt használatban, különösen fontos volt annak ellenőrzése, hogy a frissítések letöltése és telepítése nem megkerülhető-e, illetve nem biztosít-e támadási felületet egy rosszindulatú frissítés becsempészésére.
A macOS alkalmazások jelentős része harmadik féltől származó könyvtárakat és komponenseket is tartalmazott. Ezek biztonsági állapotának felmérésére automatizált eszközökkel történt elemzés, amelynek célja az ismert sérülékenységekkel rendelkező függőségek azonosítása volt. A vizsgálat során nemcsak az egyes sérülékenységek megléte volt fontos, hanem az is, hogy az alkalmazások milyen verziókat használnak, mennyire naprakészek ezek a komponensek, illetve hogy a függőségek frissítése mennyire tűnik tudatos és karbantartott folyamatnak. A visszatérő minták alapján jól látható volt, hogy a harmadik féltől származó komponensek kezelése jelentős hatással van az alkalmazások általános biztonsági szintjére.
A vizsgálatok során felmerült annak a lehetősége is, hogy az alkalmazások viselkedése eltérő lehet egy szigorúbban kontrollált környezetben. Ennek kapcsán megfontolandó lehet egy olyan tesztkörnyezet kialakítása, ahol az alkalmazások MDM-mel vagy további OS-szintű hardeninggel ellátott rendszeren kerülnek vizsgálatra.
Ez a megközelítés nem az alkalmazások hibáinak elfedését célozza, hanem annak megértését, hogy a környezeti védelmi intézkedések milyen mértékben képesek csökkenteni egy esetleges sérülékenység gyakorlati kihasználhatóságát, illetve hogyan változik a kockázati profil egy vállalati környezetben.
3.4. Windows alkalmazás sajátosságai
A vizsgálat során elemeztük, hogy az alkalmazások binárisai milyen mértékben használják ki a Windows által biztosított exploit-mitigációs mechanizmusokat, különös tekintettel az Address Space Layout Randomization (ASLR) alkalmazására. A binárisok vizsgálata során nemcsak a fő futtatható állományokra, hanem a kapcsolódó DLL-ekre és segédkomponensekre is kiterjedt az ellenőrzés.
A több alkalmazást érintő elemzés lehetővé tette annak azonosítását, hogy az ASLR használata mennyire volt egységes, illetve előfordultak-e olyan komponensek, amelyek eltérő vagy hiányos védelmi beállításokkal rendelkeztek. Ezek az eltérések különösen fontosak lehetnek egy sikeres támadás során, mivel egy gyengébben védett komponens az egész alkalmazás támadhatóságát növelheti.
A Windows alkalmazások esetében a harmadik féltől származó könyvtárak és komponensek biztonsági állapota szintén kiemelt figyelmet kapott. Ennek vizsgálatára automatizált eszközök segítségével történt a csomagolt függőségek elemzése, az ismert sérülékenységek és elavult verziók azonosítása érdekében.
A vizsgálat során nem önmagában az egyes sérülékenységek megléte volt a fókuszban, hanem az, hogy a függőségek kezelése mennyire tűnik következetesnek és karbantartottnak. A visszatérő minták alapján megfigyelhető volt, hogy a dependency-kezelési gyakorlat jelentős hatással van az alkalmazások hosszú távú biztonsági kockázataira.
4. Automatizáció
A projekt során végzett vizsgálatok egyértelműen rávilágítottak arra, hogy számos részfeladat és ellenőrzési lépés hatékonyan automatizálható. Ennek alapját az adta, hogy az alkalmazott eszközök jellemzően strukturált kimenetet szolgáltatnak, amelyek sok esetben objektíven és egyértelműen értékelhetők: egy adott beállítás vagy megfelel a biztonsági elvárásoknak, vagy nem. Ezt felismerve több automatizáció is kialakításra került. Egyes megoldások kizárólag a különböző eszközök kimenetének elemzésére épülnek, míg mások már dinamikus vizsgálatok végrehajtására is alkalmasak. Utóbbiak esetében a tesztelés nem csupán statikus adatok feldolgozását jelenti, hanem az alkalmazások működés közbeni viselkedésének elemzését is.
Ennek egyik példája a macOS alkalmazásokhoz készült tesztelő script, amely lehetőséget biztosít egy időkorlátos, 60 másodperces dinamikus elemzés futtatására. A vizsgálat ideje alatt javasolt az alkalmazás aktív használata, így az automatizáció képes lokális és hálózati események naplózására is. A futás végén a script ezeket a logokat elemzi, és azonosítja az esetleges gyanús vagy kockázatos aktivitásokat.
Az automatizált vizsgálatokat minden esetben kézi visszaellenőrzés egészíti ki, amely a megalapozott döntéshozatal szempontjából kiemelten fontos. Ennek támogatására az automatizációk automatikusan összegyűjtik azokat a bizonyítékokat (proofokat), amelyek alapján az egyes megállapítások születtek. Ezek a proofok részletesen tartalmazzák az érintett fájlok elérési útvonalát, valamint szükség esetén a konkrét sorokat vagy sorcsoportokat is.
A vizsgálat eredményeként egy strukturált Excel állomány készül, amely átlátható módon összefoglalja a megállapításokat és a hozzájuk tartozó bizonyítékokat. Ez jelentősen megkönnyíti az utólagos visszakeresést és a bizonyítékalapú egyeztetéseket, még akkor is, ha egy későbbi időpontban merül fel további kérdés vagy proof igény.
4.1. Windows
A Windows alkalmazások vizsgálata során több esetben is szükség volt arra, hogy az alkalmazások binárisainak alapvető biztonsági beállításai gyorsan és egységes módon ellenőrizhetők legyenek. Ennek támogatására készült el az aslr_analyzer.py script. A script célja a Windows alkalmazásokban használt exploit-mitigációs mechanizmusok vizsgálata. A bináris állományok elemzése során ellenőrzi többek között az ASLR, a DEP és a Control Flow Guard használatát. Az automatizáció lehetővé tette, hogy több alkalmazás esetén is gyorsan azonosíthatók legyenek azok a binárisok, amelyek nem használták megfelelően a rendelkezésre álló védelmi mechanizmusokat.
A dep_check_automate.py script a harmadik féltől származó komponensek biztonsági állapotának feldolgozására szolgált. A script az OWASP Dependency-Check által generált riportokat elemzi, és azokból strukturált formában kinyeri a releváns sérülékenységi adatokat, például a CVE-azonosítókat és a súlyossági besorolásokat. Ez jelentősen megkönnyítette több alkalmazás függőségeinek összehasonlítható értékelését és a riportolási folyamatot.
4.2. macOS
A macOS alkalmazások vizsgálata során kiemelt szempont volt, hogy a binárisok alapvető biztonsági beállításai gyorsan, következetesen és reprodukálható módon ellenőrizhetők legyenek. Ennek támogatására egy olyan automatizált script került kialakításra, amely korábban többször manuálisan validált módszertant, eszközkészletet és elemzési struktúrát követve segíti a releváns biztonsági információk kinyerését.
A script célja nem önmagában technikai részletek feltárása, hanem azoknak a jellemzőknek azonosítása, amelyek egy vállalati környezetben kockázati tényezőt jelenthetnek. Ennek keretében többek között képes feltárni az indokolatlan vagy túlzott jogosultságigényeket, valamint az alkalmazás által használt dinamikus kódbetöltési mechanizmusokat.
Utóbbiak közül kiemelten vizsgálja azokat a hivatkozásokat, amelyek meghatározzák, hogy az alkalmazás futás közben honnan tölti be a szükséges kódkönyvtárakat. Ezek a keresési útvonalak lehetőséget teremthetnek arra, hogy az alkalmazás nem várt vagy módosított kódot töltsön be, ami egy vállalati eszközön közvetett módon biztonsági és üzleti kockázatot jelenthet.
A script emellett olyan működési mintákra is igyekszik rávilágítani, amelyek gyanús fájlkezelési gyakorlatra utalhatnak, például nem megfelelően védett ideiglenes fájlok használatára vagy olyan írási műveletekre, amelyek érzékeny adatok kiszivárgásához vagy manipulációjához vezethetnek. Az automatizált elemzés eredményei strukturált formában kerülnek összegzésre, támogatva a gyors áttekintést és az egységes kockázatértékelést.
5. Kiemelt biztonsági probléma és PoC
A projekt során alkalmazott Software Security Assessment módszertan jellemzően nem teszi szükségessé Proof of Concept exploit készítését. Ugyanakkor az üzletileg kritikus szerepet betöltő alkalmazásban azonosított magas kockázatú sérülékenység esetében indokolttá vált annak gyakorlati demonstrálása.
A Proof of Concept keretében egy általunk fejlesztett exploit segítségével került bemutatásra egy dependency injection támadás. A demonstráció célja a sérülékenység működésének, lehetséges kihatásainak és potenciális következményeinek szemléltetése volt, kontrollált környezetben, károkozás nélkül.
6. Összefoglalás és tanulságok
Az alkalmazott módszertan alapján az öt hónapon át zajló szoftverbiztonsági vizsgálat során összesen 170 különálló alkalmazás és komponens elemzésére került sor. A vizsgálat döntően Windows környezetben futó alkalmazásokat (105) érintett, emellett 23 macOS és 31 mobilplatformon (iOS és Android) használt alkalmazás biztonsági értékelését végeztük el. A scope részét képezték továbbá különböző vállalati kiegészítők és komponensek is, köztük PowerShell scriptek (2), böngésző-kiegészítők (2), NuGet csomagok (7), valamint egyedi Microsoft Teams és PowerPoint kiterjesztések.
A vizsgálatok eredményeként kritikus súlyosságú szoftver megállapítás nem került azonosításra, ugyanakkor 31 magas, 111 közepes és 29 alacsony súlyosságú szoftver került dokumentálásra. Ezek az eredmények lehetővé tették az érintett alkalmazások kockázati szintjének összehasonlítható értékelését, valamint megalapozták a szükséges technikai és üzleti prioritások meghatározását.
Az eredmények nemcsak az egyes alkalmazások önálló kockázati szintjének meghatározását tették lehetővé, hanem átfogó képet adtak arról is, hogy a különböző platformokon futó megoldások biztonsági érettsége mennyire egységes. A projekt során alkalmazott módszertan és az azt támogató automatizációk lehetővé tették a nagy számú alkalmazás következetes, összehasonlítható és hosszabb időn át fenntartható vizsgálatát.