Az elektronikus és a számítógépes rendszerekben a firmware ( angolul firmware ) a futtatható kód és a benne tárolt adatok kombinációjának számít. A beágyazott szoftver olyan eszköz vagy készülékvezérlő számára kifejlesztett szoftver, amely általában nem tekinthető teljes értékű számítógépnek. Különösen olyan berendezésekben használják, amelyek magas idő- és memóriahiánnyal működnek. Ez a cikk a firmware sérülékenységeit és azok ellenintézkedéseit ismerteti .
A firmware sérülékenysége a beágyazott rendszerek és általában az informatika biztonságával kapcsolatos alapvető és skálázható probléma . Ezek a biztonsági rések kihasználhatók, és javítás (frissítés) hiányában támadhatják a firmware-t beágyazó rendszereket. A kutatás területén elért számos technológiai újítás lehetővé tette a firmware biztonságának előrehaladását. Ezek az ellenintézkedések, bár megbízhatóak, egyes esetekben nem tarthatóak fenn a kialakulóban lévő technológia és hibák miatt .
A sérülékenység mindenre utal, amely hiányosságai, tökéletlenségei miatt támadásokat okozhat. A sérülékenység fogalma úgy is felfogható, mint az eszköz érzékenységének összessége a sérülésekre, támadásokra vagy annak képtelenségére (nehézségére), hogy működőképes maradjon, ha mások veszélyeztetik.
A firmware, más néven „firmware”, firmware , sőt beágyazott szoftver is be van ágyazva a hardveres rendszerekbe. A firmware leginkább az általunk használt berendezésekben, számítógépekben, autókban, laptopokban, nyomtatókban, hűtőszekrényekben található meg. A firmware többféle lehet. Ezek memóriában tárolt és csak olvasható programok.
A firmware sérülékenysége visszavezet minket bármely számítógépes rendszer sebezhetőségéhez . Ez a firmware minden hibájára és hibájára jellemző, javítás hiányában, és amelyeket akaratlanul is támadásokra lehet kihasználni. Az autonóm vagy nem autonóm rendszerek firmware-je ezért sok hiba miatt számos támadásnak lehet kitéve. A hangsúly itt minden lehetséges, ismert vagy nem ismert hibán van, amelyek kihasználhatók a rendszer ellenőrzése, sebezhetővé tétele vagy a rendszer megfelelő működésének veszélyeztetése érdekében.
A biztonsági kérdés nem a végfelhasználóknak szánt szokásos számítógépes rendszerekre vonatkozik, hanem az összes fedélzeti számítógépes rendszerre, amelyek manapság számos biztonsági kihívással néznek szembe . A firmware általában specifikus számítógépes firmware, amelyet adatnyelven kódolnak. Ismert, hogy bizonyos nyelvek bizonyos programozási hibái sok sebezhetőség forrása, és ezért a támadások kiindulópontja. Ez az állítás nem kíméli a firmware-t, még akkor sem, ha beágyazott rendszerekben van. Lényegében tehát a firmware hajlamos a programozási hibákra (sérülékenységekre), amelyek támadások forrását jelenthetik.
Bár lehetséges a firmware visszafejtése, bizonyos korlátozások megszüntetése, az ilyen típusú támadások végrehajtása jelentős erőfeszítéseket igényel. Számos alternatív mechanizmus ismert a firmware interfész által előírt korlátozások megkerülésére. Megközelítésünk megértéséhez először meg kell értenünk az architektúráját. Az alábbi példa 802.11 firmware-t mutat be nekünk.
Az elmúlt években számos kutató megvizsgálta a firmware, valamint a különféle eszközök, például alapsávok, kártyák, chipsetek biztonságát. Ezeknek a fedélzeti firmware-összetevőknek a biztonsági rései hajlamosak a támadásokra, amelyek lehetővé tehetik a betolakodók számára, hogy teljes mértékben átvegyék az irányítást az alkatrész felett, és ugródeszkaként használhassák további támadások indításához más operációs rendszerek vagy rendszerek ellen.
Számos architektúra ismert a firmware alkalmazási területe szerint, kezdve a számítógépektől vagy a nagy hasznosságú berendezésektől [8], de a firmware típusa szerint is. A különböző firmware-architektúrák az input-output buszokon alapulnak. Ezért helyénvaló meghatározni, hogy a firmware-hez nincs szabványos architektúra vagy fix architektúra-modell.
A firmware-t, mint minden memóriarendszert, általában a memória mérete jellemzi, amely indukálja a villogási időt, az átviteli folyamatot és a frissítési módszert. A firmware két nagy családba sorolható. Megvannak a „bináris” típusok: tömörítettek vagy nem, és archív típusúak .
Beágyazott rendszerekben a firmware általában a fenti ábra szerint rendeződik. A rendszerindítási folyamat során a rendszerindító betöltődik, először a rendszer bekapcsolásakor lehet indítani, majd az operációs rendszer rendszermagja szorosan követi.
Mivel a rendszerindító először működik, inicializálja a szükséges hardvert és előkészíti a szoftveres környezetet a működéshez. Részletesen: a rendszerbetöltő két részre osztja a betöltési folyamatot. Az 1. lépés szorosan kapcsolódik a hardverhez.
A fennmaradó térben az alkalmazásprogramokat tárolják és általában fájlrendszer és RAM által rendezik. A 2. lépés megkezdése előtt általában ellenőrzi a hardver által betöltött első 4 kb-os kódot a leírt indítási folyamatnak megfelelően.
Ezután a 2. lépés betöltődik és elindul. Ez a lépés lehetővé teszi a kifinomultabb funkciók elindítását. Inicializálja a hardver különféle igényeit (portok, bemenetek és kimenetek). Ezután betölti és elindítja a rendszermagot, amely felelős a rendszererőforrások, például a különböző folyamatok, a memóriakezelés kezeléséért. Így a rendszer elindul és az alkalmazásprogramok ezek alapján futhatnak: inicializálási értékek.
Nyilvánvaló, hogy ez a firmware architektúra nagyon törékeny, mert nem garantálja a különböző folyamatok egyetlen lépésének megbízhatóságát.
A firmware-támadók általában a megvalósítási hibákat használják a rendszer károsítására. Még akkor is, ha ez az első felfogás a támadások fogalmáról, el kell ismernünk, hogy ezek lehetővé teszik a beágyazott rendszerek biztonságának és robusztusságának felmérését. Bár a támadás célja a firmware-t hordozó rendszer üzemen kívül helyezése, más szempontból szükséges lenne gazdasági, stratégiai, sőt politikai érdekek megismerése.
Az SMM (System Management Mode) az elsődleges kivitelű x86 és x64 processzorok megtestesítője . Amikor a processzor ebben az üzemmódban van, a CPU normál végrehajtása fel van függesztve, általában a kezét egy firmware-re vagy egy hardver hibakeresőre hagyva. Az SMM egy 16 bites mód, amelyet olyan alkalmazásokhoz használnak, mint a hőmérséklet vagy az energiagazdálkodás (pl .: ACPI). Ebbe az üzemmódba csak akkor lehet belépni, ha SMI-t kap (amelyet a Northbridge generált, vagy amikor az AMPC regisztert írta). Az SMRAM nevű speciális memóriaterület lehetővé teszi a CPU kontextusának mentését, amikor SMM-re vált . Az SMI kézhezvételekor és ezért az SMM-re való átálláskor egy SMI kezelő végrehajtásra kerül az SMRAM-ból. Az SMRAM a RAM-ban található, de a processzor nem érhető el a chipset D_OPEN zárolása miatt. Így még a ring0-ben sem tudja a CPU észrevenni az SMI-kezelők létét, vagy akár észrevenni a CPU normál végrehajtásának megszakadását.
SMRAM védelemAz SMM-ben végrehajtott kód még több jogosultsággal rendelkezik, mint a ring0 mód, ezért meg kell védeni. Az SMRAM pozícióját az SMBASE regiszter jelzi, amely csak SMM-ben érhető el . Az SMRAM csak akkor érhető el más CPU módokból, ha a D_OPEN zár nyitva van. Az SMI kezelők kódmódosításának megakadályozása érdekében van egy D_LCK zár, amely csak olvashatóvá teszi az SMRAM-ot.
A D_LCK zárolás megkerüléseAnnak érdekében, hogy lehetővé tegye az SMRAM sérülését a D_LCK zár ellenére, néhány kutatás bemutatta a zár megkerülésének technikáit. Például léteznek gyorsítótár-mérgezési támadási technikák vagy az AGP grafikus nyitó (be) nyíló (in) chipkészlete
Támadás grafikus nyíláson keresztülLoïc Duflot megmutatta, hogyan lehet használni a grafikus nyitó mechanizmusokat a D_LCK megkerüléséhez. Az AGP grafikus nyitottsága a fizikai címtér azon területe, amelyet a grafikus vezérlő (pl .: X szerver) és a GPU között a DMA-n keresztül történő gyors kommunikációra használnak. Mivel nem biztos, hogy rendelkezésünkre áll a fizikai memória összefüggő területe ehhez a grafikus nyíláshoz, egy címfordító mechanizmus létezik a chipsetben (nem tévesztendő össze az MMU-val. Ami a CPU és a az északi híd). Ennek a mechanizmusnak köszönhetően lehetséges az a benyomás, hogy a fizikai tér egy területe rendelkezésre áll. A bemutatott probléma az, hogy egy I / O jogosultságokkal rendelkező felhasználói alkalmazásból módosítani lehet a grafikus nyitó konfigurációs regisztereket. Ezek lehetővé teszik különösen a nyitás önkényes elhelyezését és a fordítási táblázat címének megadását. Így elhelyezhetjük a grafikus nyílást a kern egy kritikus területén (pl .: GDT), hogy átirányítsuk azt a fizikai memória egy részére, amely megfelel az általunk vezérelt memóriának.
CPU gyorsítótár mérgezési támadás SMRAM és gyorsítótárAz x86 platformon vannak speciális regiszterek, az úgynevezett MSR. Ezen MSR-ek egy része MTRR-ek. Rögzített MTRR-eket használnak bizonyos "régi" memóriaterületek gyorsítótár-stratégiájának (visszaírási, átírási stb.) Jelzésére. A változó MTRR-ek lehetővé teszik egy tetszőleges fizikai memóriaterület gyorsítótár-stratégiájának megadását. Ha egy változó MTRR-t úgy konfigurálunk, hogy jelezze az SMRAM zóna visszaírási gyorsítótár stratégiáját, akkor egy SMI kezelő végrehajtása ezt a zónát átmásolja a gyorsítótárba. Ha a végrehajtás végén a gyorsítótár nincs kitisztítva, az operációs rendszer átvételekor az SMRAM egy része továbbra is jelen lesz a gyorsítótárban. Így az SMI kezelő rejtett verziója védett módban lesz elérhető a D_LCK ellenére. Ez a gyorsítótár adat-gyorsítótár. Így az ebben a gyorsítótárban található SMI kezelő verziójának módosítása nem járhat semmilyen hatással, mert a helyes verzió lenne az utasítások gyorsítótárában. A védett mód közötti átmenet során (32 bit vagy 64 bit a hosszú üzemmódban (in) ) érvényteleníti az utasítás gyorsítótárát, és újratölti az adatgyorsítótárban lévő adatoknak köszönhetően. Éppen ezért az adatgyorsítótárban lévő SMI kezelő kódjának módosítása lehetővé teszi a D_LCK zár megbízható megkerülését és az SMRAM vezérlésének a védett módból történő átvételét .
Számos támadást mutattak be olyan firmware ellen, mint a BIOS vagy az UEFI . A közelmúltban egy UEFI megvalósítás elleni támadást mutattak be a BlackHat USA konferencián . Ez lehetővé teszi a privilégiumok kibővítését a firmware frissítési mechanizmus kihasználásával. Általában, miután egy gép felhasználói folyamata veszélybe került, egy tipikus kihasználás utáni forgatókönyv megpróbálja átvenni a kernelterületet a rootkit telepítése érdekében . Ezt azonban bizonyos védelem miatt megnehezíti. Például a Windows operációs rendszerek megkövetelik, hogy az összes kód, amely a kerneltérben fut, aláírásra kerül. Ezenkívül a PatchGuard rendszeresen ellenőrzi a kernel integritását. Vannak azonban más lehetőségek is. Ha a támadó nem akarja megrontani a kernelt, megpróbálhatja veszélyeztetni a bootstrappert (MBR), az SMRAM-ot vagy akár az UEFI-t. Amint az a következő ábrán látható, vannak technikák az egyes összetevők támadásainak enyhítésére.
Így a Windows 8 UEFI Extreme Privilege Escalation szerzői azt javasolják, hogy vizsgálják meg az UEFI megvalósítását, hogy ne a firmware-t írják felül, hanem kihasználják a sérülékenységet a legitim firmware-rel. A Windows 8 olyan API-t vezetett be, amely lehetővé teszi egy privilegizált felhasználói folyamat számára, hogy interakcióba lépjen egy UEFI interfésszel, hogy jelentősen módosítson bizonyos UEFI környezeti változókat. Néhány sebezhetőséget fedeztek fel az UEFI változókat használó MITER és Intel csapatok. Ezen változók egyike vezérli a frissítési "kapszula" címét. Ezután az operációs rendszer feldarabolja a tartalmat a címtérben.
Speciális újraindítás („meleg visszaállítás”) után az UEFI kód az új firmware aláírásának ellenőrzése előtt összegyűjti a széttöredezett darabokat, elemzi a frissítő kapszula borítékját, majd elemzi a kapszula néhány aláíratlan tartalmát (pl .: kezdőképernyő kép). Az első BIOS reflash-kiaknázást Wojtczuk és Tereshkin mutatta be, és egy biztonsági rést használt ki az üdvözlő képernyő képének elemzésében. Az UEFI Privilege Escalation szerzői további sebezhetőségeket tártak fel, mint például egy egész szám túlcsordulást a kapszula méretének ellenőrzésekor, egy egész szám túlcsordulást, amikor a töredék hosszának összegét kiszámítják, vagy egy egész számot, ha a töredék hosszának összegét számítják. kiosztás boríték elemzésekor. Jelentésük szerint a szerzők sok könnyen megtalálható egész szám túlcsordulást fedezhettek fel egy hét leforgása alatt. Azt is észreveszik, hogy az Edk2 implementáció nyílt forráskódú és kritikus, de úgy tűnik, hogy nem jó a kódminősége.
Az absztrakt értelmezések elmélete abból áll, hogy egy program szemantikáját absztrakt módon abszolválják, hogy teljes túlbecsülést („hangot”) hozzanak létre. Ezért az absztrakt szemantika minden lehetséges esetre (és még többre) kiterjed. A közelítésnek kellően durvának kell lennie, hogy kiszámíthatóvá váljon. Ezt próbálják megmutatni a következő diagramok.
Ezt az elméletet különösen olyan projektekben használják, mint az Astrée.
Szimbolikus végrehajtásA program szimbolikus végrehajtása során a bemeneteknek megfelelő változók szimbolikus értékek. Ez azt jelenti, hogy egy változó az általa felvehető értékkészletet jelenti, és nem egy pontos értéket. Ezután a programot egy megfelelő végrehajtó motorral hajtják végre. Minden utasításhoz a változók korlátai módosulnak. Minden csatlakozáskor, egy SAT-megoldó segítségével a motor eldönti, hogy az alábbi utasítások melyik sorozatát lehet végrehajtani. Így egy szimbolikus végrehajtásnak köszönhetően, egy adott állapotból, megismerhetjük az összes állapotot, amelyhez ezután el lehet jutni. Egy Harvard SEAS tanfolyam elég jól elmagyarázza a témát.
Fuzzy tesztelésA szoftverek tesztelésére léteznek fuzzing technikák, amelyek számos teszt generálását és az összeomlások megfigyelését tartalmazzák. Az olyan keretrendszerek, mint az őszibarack, speciális interfészeket biztosítanak a firmware-hez. Vannak olyan firmware-ek fuzizálására szakosodott fuzzerek is, mint a Plashdance. Ez egy protokollok és fájlformátumok fuzzere, amely a meglévő firmware bizonyos kivonatainak mutációin alapul.
A „BIOS chronomancy” rendszer egy védelmi rendszer, amelyet a MITER csapata fejlesztett ki az „időbeli igazolások” gondolata alapján. Ez egy alternatíva a TPM (Trusted Platform Module) „Mérésbiztonsági statikus alapgyökere” (S-CRTM) fogalmához.
Kopernikusz SMRAM védelemA DeepWatch egy integritási szkenner, amely lehetővé teszi különösen az SMRAM monitorozását. A koncepció bizonyítéka az Intel Q35 chipsetek (G) MCH firmware- jében valósul meg . A rootkiteket is megpróbálja felismerni a VT-x (en) használatával .
ChipsecA Chipsec az Intel Security által elindított projekt egy platform biztonságának javítása érdekében. Alkalmanként a CanSecWest 2014-en mutatták be. A platform biztonságával két külön helyzetet jelölünk meg. Az első a hardver konfigurációjának és megvalósításának ellenőrzése. Így a Chipsec biztosítja, hogy a hardver bizonyos biztonsági funkciókkal rendelkezzen, és hogy ezek megfelelően legyenek konfigurálva. A „platformbiztonságnak” nevezett második helyzet a firmware konfigurálására és megvalósítására vonatkozik. Ezután megpróbáljuk megbizonyosodni arról, hogy léteznek-e hozzáférések a firmware-interfészekhez, és hogy az összes zár a helyén van-e. Mindkét esetben a Chipsec megpróbálja bemutatni, hogy firmware és hardver biztonsági mechanizmusok vannak-e jelen és vannak-e. Például a Loïc Duflot által az SMRAM elleni első támadások, a hardveres támadások megelőzése érdekében a platform ellenőrzi, hogy a D_LOCK zár valóban aktiválva van-e. A firmware biztonságára példa a BIOS vezérlő regiszterek használatának ellenőrzése, különös tekintettel a BLE és a BIOSWE zárakra. A Chipsec szerint a firmware biztonsági ellenőrzőlista a következő:
| Gépezet | Modul | Referencia |
|---|---|---|
| A BIOS billentyűzetének tisztítása | bios_kdr_buffer | DEFCON, 2008. |
| BIOS írásvédelem | bios_wp | CanSecWest 2013 |
| BIOS interfész zár | bios_ts | POC 2007 |
| Secureboot kulcs-hozzáférés-vezérlés | secureboot.keys | UEFI specifikáció |
| A Secureboot változók hozzáférés-vezérlése | secureboot.változók | UEFI specifikáció |
| SPI vezérlő zár | spi_lock | Kopernikusz |
A Secure Boot az UEFI firmware által támogatott mechanizmus, amelyet az Intel valósított meg az operációs rendszerek rendszerindítóinak aláírására. A számítógép indításakor a Biztonságos Boot a kulcsok katalógusa segítségével ellenőrzi az iniciátor digitális aláírását , mielőtt betöltené azt. Az utóbbi majd indítsa el a kernel az érintett rendszer. Ha a kezdeményező aláírását érvénytelennek tekintik, az UEFI elutasítja az indítást.
Ennek a mechanizmusnak a legfőbb előnye, hogy megvédje a bootloader („Bootkits”) rosszindulatú módosítását, mert egy ilyen módosítás érvényteleníti a társított aláírást. Erre a célra az UEFI tárolja az engedélyezett kulcsok katalógusát, amelyek csak a rendszer telepítése során vagy manuális műveletekkel módosíthatók az UEFI konfigurációs szoftverben (fizikai hozzáférés a géphez).
Ezt a katalógust általában az NVRAM tárolja, amely a rendszer indításakor nem érhető el, valamint a Biztonságos rendszerindítás beállításai, amelyek szintén megakadályozzák a rosszindulatú szoftverek módosítását vagy letiltását. Ez a mechanizmus magában foglalja a számítógép kizárólag az UEFI általi indítását is, mivel ez eredendően megakadályozza a klasszikus rendszerindítást („Legacy Boot”).
TPM: Intel TXTAz Intel Trusted Execution Technology (Intel TXT) a bizalom „gyökérzetének” biztosítására szolgáló mechanizmus. Ez a lehető legkisebb összetevő, nehezen módosítható vagy megkerülhető, és lehetővé teszi a platform egyes összetevőinek mérését a gép indításakor, például a BIOS-t, a rendszerindítót vagy a virtuális gép-kezelőt (VMM). Ehhez létezik egy „Measured Launch Environment” (MLE) nevű referenciakörnyezet, amely lehetővé teszi bizonyos kritikus elemek összehasonlítását ezzel a referenciával. Érdekes, hogy már több támadást is bemutattak a TXT ellen.