A kényelmes távirányítók sok energiát takarítanak meg a rendszergazdáknak - és ugyanakkor óriási biztonsági kockázatot jelentenek, ha azokat hardveres kapcsolókkal nem lehet kikapcsolni egy jumper vagy az alaplapi kapcsoló segítségével. Az Intel Management Engine 11 blokk a modern Intel platformokon éppen ilyen veszélyt jelent - kezdetben nem szétkapcsolható, ráadásul a processzor inicializálásának és működésének egyes mechanizmusai hozzá vannak kötve, így a durva deaktiválás egyszerűen a rendszer teljes működésképtelenségéhez vezethet. A sebezhetőség az Intel Active Management Technology (AMT) területén rejlik, és sikeres támadással lehetővé teszi a rendszer teljes irányításának megszerzését, amiről még idén májusban beszámoltunk. De a pozitív technológiák kutatói.
Maga az IME processzor a System Hub Chip (PCH) része. A PCI Express processzorhelyek kivételével a rendszer és a külvilág közötti minden kommunikáció átmegy a PCH-n, ami azt jelenti, hogy az IME szinte minden adathoz hozzáfér. A 11. verzió előtt valószínűtlen volt a vektor elleni támadás: az IME processzor a saját architektúráját használta az ARC utasításkészlettel, amelyet harmadik fél fejlesztői alig ismertek. De a 11. verzióban rossz viccet játszottak a technológiával: átkerült az x86 architektúrára, és módosított MINIX-et használtak operációs rendszerként, ami azt jelenti, hogy a bináris kód harmadik fél általi tanulmányozása sokkal könnyebbé vált: mind az architektúra, mind az operációs rendszer jól dokumentált. Dmitrij Szklyarov, Mark Ermolov és Maxim Goryachy orosz kutatóknak sikerült megfejteniük az IME 11-es verziójának futtatható moduljait, és megkezdték azok alapos tanulmányozását.
Az Intel AMT 10-ből 9,8 besorolást kapott a biztonsági rés miatt. Sajnos az IME teljes kikapcsolása a modern platformokon a fenti ok miatt lehetetlen - az alrendszer szorosan kapcsolódik a CPU inicializálásához és indításához, valamint az energiagazdálkodáshoz. De eltávolíthatja az összes felesleges elemet az IME modulokat tartalmazó flash memória képről, bár ezt nagyon nehéz megtenni, különösen a 11. verzióban. A me_cleaner projekt, egy olyan segédprogram, amely lehetővé teszi a kép közös részének eltávolítását, és csak a létfontosságú összetevőket hagyja meg. De adjunk egy kis összehasonlítást: ha az IME 11-es verzióiig (a Skylake előtt) a segédprogram szinte mindent töröl, körülbelül 90 KB kódot hagyva, akkor jelenleg körülbelül 650 KB kódot kell menteni - és akkor bizonyos esetekben a rendszer fél óra múlva leállhat, mivel a blokk Az IME helyreállítási módba lép.
Van azonban némi előrelépés. A fent említett kutatócsoportnak sikerült fejlesztői készletet használnia, amelyet maga az Intel biztosít, és amely magában foglalja az IME paraméterek konfigurálásához szükséges Flash Image Tool segédprogramokat és egy integrált SPI vezérlőn keresztül működő Flash programozó eszköz villogót. Az Intel nem teszi nyilvánosan elérhetővé ezeket a programokat, de nem nehéz megtalálni őket az interneten.
Az ezzel a készlettel kapott XML fájlokat elemeztük (tartalmazzák az IME firmware felépítését és a PCH hevedermechanizmus leírását). Egy "reserve_hap" (HAP) nevű bit gyanúsnak tűnt a "High Assurance Platform (HAP) enable" leírása miatt. Egy internetes keresés során kiderült, hogy ez az amerikai NSA-hoz társított, nagy megbízhatóságot biztosító platformprogram neve. Ennek a bitnek az engedélyezése azt jelezte, hogy a rendszer Alt Disable módba lépett. Az IME blokk nem válaszolt a parancsokra és nem reagált az operációs rendszer hatásaira. Számos finomabb árnyalat található a Habrahabr.ru cikkén, de a me_cleaner új verziója már megvalósította a legtöbb veszélyes modul támogatását a HAP bit beállítása nélkül, ami az IME motort "TemporaryDisable" állapotba hozza.
A me_cleaner legújabb módosítása csak az RBE, a KERNEL, a SYSLIB és a BUP modulokat hagyja meg az IME 11. verziójában is, nem található bennük olyan kód, amely lehetővé tenné magának az IME rendszernek az engedélyezését. Ezeken felül a HAP bit használatával megbizonyosodhat arról, hogy a segédprogram is képes rá. Az Intel áttekintette a kutatást és megerősítette, hogy számos IME-beállítás valóban összefügg a kormányzat fokozott biztonságú igényeivel. Ezeket a beállításokat az amerikai kormányzati ügyfelek kérésére vezették be, korlátozott ellenőrzésen estek át, és az Intel nem támogatja őket hivatalosan. A cég tagadja az úgynevezett hátsó ajtók bevezetését a termékeibe.
Röviden, a következőket mondja ki (a továbbiakban a szövegben: szubjektív szabad elbeszélésem).
Állítólag a világ nagyvállalatai, beleértve az Apple-t, az Amazon-ot és a hozzájuk hasonlókat, sok éven át drága csúcskiszolgálókat rendeltek a SuperMicro-tól. Utóbbi ilyen megrendelésekből evett, saját gyárai már nem voltak képesek megbirkózni. Aztán bizonyos mennyiségű alaplap gyártását odaadta kínai alvállalkozóinak.
Kínai udvarias emberek ugyanezekhez az alvállalkozókhoz érkeztek, és olyan ajánlatot tettek nekik, amelyet nem lehet visszautasítani. Tetszik, gyertek, srácok, kérésünkre, kérésünkre, még egy ma-a-a-a-scarlet ilyen, nem dokumentált chipet telepítünk az Ön által gyártott alaplapokra. Ha megteszi - további pénzt hozunk Önnek, de ha nem teszi meg, különféle csekkekkel kivesszük az üzleti vállalkozását. Ennek eredményeként az ilyen módon "módosított" alaplapokat az egész világon eladták, és közülük néhány az első ešelon amerikai nagyvállalataiban, bankokban és kormányzati szervekben is véget ért.
Egy idő telt el. Az Amazon egyik részlege, egy bizonyos "Elements" nevű vállalat gondoskodott megoldásai biztonságáról a videofolyamok tömeges feldolgozása terén. Többek között egy kanadai cég hardverbiztonsági auditját rendelték el. És itt fedezték fel az alaplapokra ügyesen elrejtett, dokumentálatlan chipeket. Amiket például nem olyan könnyű megtalálni. Mert először is nagyon kicsik és szürkeak. Másodsorban szokásos forrasztó tengelykapcsolóknak vagy chip-kondenzátoroknak álcázzák magukat. Harmadszor, a legutóbbi verziókban kezdtek el rejtőzni a textolit vastagságában, így csak a röntgensugarakon láthatók.
Ha hiszel a szövegben, akkor a beágyazott mikrokód segítségével a BMC modulon keresztüli kém chip rendszeresen "pingál" az egyik névtelen "bábjátékosával", akitől további cselekvési utasításokat kap. Állítólag még a fent említett ellenfél is képes "onnan" letölteni valamilyen kódot, amelyet ezután közvetlenül a futó operációs rendszer kerneljébe vagy az alkalmazás kódjába injektálnak.
Nos, további röhögések következnek arról, hogy mekkora lyuk van a biztonságban, milyen kecskék ezek a kínaiak, milyen merészségük és szemtelenségük van, az összes kecskében nem lehet megbízni, "most mindannyian meghalunk", és ennyi. A technikailag érdekes érvelés itt ér véget.
Általában nagy szkeptikus vagyok az életben. Anélkül, hogy tagadnám a kínaiak zsenialitását, néhány pillanat személy szerint nekem nagyon irreálisnak tűnik. Fogja csak úgy, mérnökök és menedzserek ravaszságán, és változtasson az alaplap kialakításán a gyártó szintjén, anélkül, hogy megzavarná annak teljesítményét? És ha a menedzsment tudtával, akkor hogyan volt motiválva arra, hogy az összes ilyen nagyvállalkozást ilyen komoly reputációs kockázatnak tegye ki? Injektálja a kódot az operációs rendszerbe és az alkalmazásokba? Nos, Windows-tal nem baj, készen állok hinni egy nyikorgással. De Linuxban, ahol nem tudod előre, hogy ki és hogyan gyűjtött össze? Ujjatlan hálózati tevékenységet gyakorolni? Ami kívánt esetben felismerhető és szűrhető. Nem is beszélve arról a tényről, hogy a normál adminisztrátorok soha nem teszik ki a BMC-ket, hogy "megmutassák csupasz seggüket az interneten", és a jó adminisztrátorok általában külön VLAN-ba dobják őket, anélkül, hogy bárhova hozzáférnének.
Nos, megint az utóbbi időben néhány heves kémiamánia és paranoia fejlődött az amerikaiak körében. És úgy döntöttek, hogy veszekednek Kínával. Tehát az eredeti cikk objektivitása és pártatlansága nagy kérdés. Viszont nem nagyon értem, honnan vesznek ilyen szép témákat. Még 2011-ben a "Ksakep" bulvármagazin a BMC flash meghajtó mikrokódszintjén írt ugyanezekről a kínai könyvjelzőkről. Ez a cikk paranoiás delíriumot is áraszt, de tűz nélkül nincs füst. Vagy megtörténik?
Általában ossza meg véleményét a megjegyzésekben. Különösen érdekes elvtársat hallani kvazimoda24 valamilyen kém mikrokapcsolatok integrálásának lehetőségéről a NYÁK vastagságába.
Nem vagyok szakember az információbiztonság területén, érdeklődési köröm a nagy teljesítményű számítástechnikai rendszerek. Egészen véletlenül jutottam el az információbiztonság témájához, és erről lesz szó tovább. Úgy gondolom, hogy ez a kitalált történet jobban megvilágítja a virtualizációs hardverrel kapcsolatos problémákat, mint egy száraz ténymegállapítás. Még a hardveres virtualizációt támogató új Intel processzorok hivatalos bejelentése előtt (2007 elején) úgy gondoltam, hogy ezeket a chipeket egyetlen kiszolgáló rendszer létrehozására tervezem, amely több szerveren alapul, és amely egyetlen operációs rendszer és alkalmazások SMP architektúrájú számítási egységévé válik. Ehhez kompakt, nem szabványos funkcionalitású hipervizor írására volt szükség, amelynek fő jellemzője nem egy számítógépes egység erőforrásainak felosztása lenne a különböző operációs rendszerek között, hanem éppen ellenkezőleg, több számítógép erőforrásának egyesítése egyetlen komplexumba, amelyet egy operációs rendszer irányítana. Ugyanakkor az operációs rendszernek nem is kellett kitalálnia, hogy nem egyetlen rendszerrel, hanem több szerverrel foglalkozik. A virtualizációs hardver adott ilyen lehetőséget, bár eredetileg nem ilyen problémák megoldására szánták. Valójában még nem jött létre olyan rendszer, amelyben a virtualizációs hardvert nagy teljesítményű számítástechnikához használnák, és akkoriban még általában úttörő voltam ezen a területen. Ennek a feladatnak a hipervizorját természetesen a semmiből írták. Alapvetően fontos volt az operációs rendszert már virtualizált platformon futtatni, hogy az operációs rendszer betöltőjének első parancsaitól kezdve minden működjön egy virtuális környezetben. Ehhez virtualizálnunk kellett a valós modellt és a processzor összes működési módját, és azonnal el kellett kezdenünk a virtualizációt a platform inicializálása után, mielőtt betöltöttük volna az operációs rendszert. Mivel az erre a célra szolgáló virtualizációs rendszer kiderült, hogy nem szabványos, és teljesen autonóm kompakt szoftvermodulnak tűnt (kódméret nem nagyobb, mint 40-60 Kb), a nyelv valahogy nem mert hipervizornak nevezni, és elkezdtem használni a "hiperhajtó" kifejezést, mivel pontosabb. közvetítette a rendszer funkcionális céljának lényegét. Virtualizációs hardverrel ellátott soros berendezés ekkor még nem állt rendelkezésre, azonban a Craftway-vel való együttműködésnek köszönhetően hozzáférhettem a virtualizációs támogatással rendelkező processzorok és alaplapok gyártás előtti mintáihoz, amelyeket hivatalosan még nem adtak ki (úgynevezett minták, amelyeket az Intel szívesen biztosít a üzleti partnerek). Ezért a munka ezen a „minta” berendezésen kezdett forrni. Összeállították a makettet, megírták a hiperhajtót, minden rendben működött. Azt kell mondanom, hogy abban az időben a virtualizációs hardver nagyon "nyers" volt, ezért többször nem volt hajlandó dolgozni a dokumentációban leírtak szerint. Szó szerint minden összeállítási paranccsal kellett megküzdenem, és a virtualizációs hardver parancsait gépi kódokkal kellett leírni, azóta nem voltak fordítók, amelyek támogatták a virtualizációs parancsokat. Büszke voltam az elért eredményekre, szinte a virtuális világok urának éreztem magam ... de az eufóriám nem tartott sokáig, csak egy hónapig. Addigra már összeállítottam egy virtualizációs hardverrel rendelkező szervereken alapuló elrendezést, amelynek első soros mintái éppen megjelentek, de az elrendezés nem működött. Elkezdtem kitalálni, és rájöttem, hogy a rendszerem lefagy, amikor hardveres virtualizációs parancsokat hajtok végre. Az volt a benyomás, hogy vagy egyáltalán nem működtek, vagy valahogy a dobozon kívül dolgoztak. A függesztés csak akkor történt, amikor a virtualizációs hardver valós módban futott, de ha a rendszeremet védett módból indítottuk az operációs rendszer betöltése után, akkor minden rendben volt. A profik tudják, hogy a korai verziókban az Intel virtualizációs hardvere nem támogatta a valós idejű processzor működését. Ehhez további nagy rétegre volt szükség ahhoz, hogy utánozni tudja a virtuális x86-ot. Mivel a hiperhajtóprogramot az operációs rendszer betöltése előtt indították el, hogy teljes mértékben higgyen az új virtuális konfigurációban, az operációs rendszer indítókódjának egy kis darabja valósult meg a processzor valós módjában. A rendszer éppen a hipermeghajtó valós módú emulációs kezelőin halt meg. Először azt hittem, hogy tévedtem valahol, nem értek valamit, elfelejtettem valamit. A kódom utolsó részéig mindent átnéztem, nem találtam hibát, és nem magamra, hanem a domb mögül érkező kollégáimra kezdtem vétkezni. Először a processzorokat cseréltem le, de ez nem segített. Az alaplapokon ekkor a virtualizációs hardver csak a BIOS-ban volt, ahol a szerver bekapcsolásakor inicializálták, ezért elkezdtem összehasonlítani az alaplapok (azonos típusú mintákkal rendelkező alaplapok) bióit - minden megfelelt a bájtnak és maga a BIOS számának. Döbbenten estem, és már nem tudva, mit tegyek, a legvégső eszközt alkalmaztam - a "piszkos módszert". Mit nem tettem, már nem gondolkodtam, hanem egyszerűen kombináltam, és végül hülyén letöltöttem a BI-ket a hivatalos Intel webhelyről, és átírtam őket alaplapokra, ami után minden működött ... Meglepetésemnek nem volt határa: a BIOS száma ugyanaz volt , a BIOS-képek bájtonként egyeztek, de a soros alaplapok valamilyen oknál fogva csak akkor kezdtek el működni, amikor ugyanazokat az Intel webhelyéről vett BIOS-okat töltöttem fel rájuk. Szóval, az ok még mindig az alaplapokon van? De az egyetlen különbség a jelölésben volt: az összeállított Kanada felirat volt a mintákra, az összeszerelt Kína pedig a soros táblákra. Világossá vált, hogy a kínai táblák további szoftvermodulokat tartalmaznak a BIOS-ba ágyazva, de ezeket a modulokat a szabványos elemző programok nem látták. Nyilvánvalóan virtualizációs hardverrel is dolgoztak, és ennek megfelelően el tudták rejteni a BIOS valódi tartalmát. A hiperhajtóm fagyásának oka ezeken a kínai táblákon is világossá vált: két szoftverrendszer egyszerre dolgozott ugyanazzal a virtualizációs hardverrel, ami nem tette lehetővé az erőforrások megosztását. Ezzel a rosszindulatú BI-val szerettem volna foglalkozni, és a "könyvjelzők", a "hátsó ajtók", a "dokumentálatlan funkciók" gondolkodás nélkül csak akadémiai érdeklődés mutatkozott, és semmi más. Azt kell mondanom, hogy a virtualizációs hardver bevezetésével párhuzamosan az Intel radikálisan frissítette a chipsetet. Ezt az 5000x-es lapkakészletet még mindig számos módosítással gyártják. Ennek a lapkakészletnek a déli hídja, a 631xESB / 632xESB I / O Controller Hub, amelyhez bioszalámpás flash-áramkörök csatlakoznak, 2007 óta gyakorlatilag nem változott, és szinte az összes szerver alaplapjaként használatos két foglalatos változatban. Letöltöttem a déli híd adatlapját, elolvastam a leírást és elképedtem. Kiderült, hogy ehhez az új déli hídhoz három flash memóriachip csatlakozik: az első egy szabványos BIOS, a második a hálózati vezérlő processzor programjainak szentelt, a harmadik pedig a déli hídba integrált BMC egységhez. A rendszerkezelő egység (BMC) a számítástechnikai eszköz távvezérlésének és felügyeletének eszköze. Nélkülözhetetlen a nagy kiszolgáló helyiségeknél, ahol a zaj, a hőmérséklet és a huzat miatt egyszerűen lehetetlen hosszú ideig tartózkodni. Az a tény, hogy a BMC egységek saját processzorral és ennek megfelelően flash-memóriával rendelkeznek a programjaihoz, természetesen nem újdonság, de eddig egy ilyen processzort és memóriát külön alaplapra vittek ki, amelyet az alaplaphoz csatlakoztattak: ha akarja - tegye, nem akarja - ne tedd. Most az Intel ezeket a komponenseket a déli hídban implementálta, ráadásul ezt az egységet a rendszerbuszhoz csatlakoztatta, és nem használt dedikált hálózati csatornát (amint azt a BMC egység funkcióit leíró IPMI szabvány előírja) a szolgáltató hálózat üzemeltetéséhez, hanem az összes szolgáltatási hálózati forgalmat alagútba vezette a főhálózathoz. adapterek. Aztán a dokumentációból megtudtam, hogy a BMC egység flash mikrokapcsolatán lévő programok titkosítva vannak, és a kibontáshoz egy speciális hardveres kriptográfiai modult is használnak, amelyet a déli hídba is integráltak. A haditengerészet ilyen egységei még soha nem találkoztak velem. Nem megalapozatlan, itt van egy részlet a déli híd dokumentációjából:
- ARC4 processzor 62,5 MHz sebességgel dolgozik.
- Interfész az Intel® 631xESB / 632xESB I / O Controller Hub mindkét LAN portjához, amely közvetlen kapcsolatot biztosít a hálózattal és hozzáférést biztosít az összes LAN regiszterhez.
- Kriptográfiai modul, amely támogatja az AES és RC4 titkosítási algoritmusokat, valamint az SHA1 és MD5 hitelesítési algoritmusokat.
- Biztonságos mechanizmus a terhelhető szabályozott FW számára.
- Az Intel új 5000-es sorozatú kiszolgálótáblái olyan programokat tartalmaznak, amelyek be vannak ágyazva a BMC egység flash memóriájába és a központi processzoron futnak, és ezek a programok a központi processzor virtualizációs hardverének használatával futnak.
- Az Intel hivatalos weboldalának flash képei nem tartalmaznak ilyen szoftvermodulokat, ezért a gyártási szakaszban illegálisan villantottak be az alaplapokba az engem zavaró szoftvermodulokat.
- A BMC egység flash memóriája olyan titkosított szoftver modulokat tartalmaz, amelyeket nem lehet összeilleszteni és flash memóriába önteni a titkosítási kulcsok ismerete nélkül, ezért aki illegális szoftver modulokat helyezett be, tudta a titkosítási kulcsokat, vagyis hozzáférhetett a ténylegesen titkos információkhoz.
A fotón látható végrehajtási idő egy bizonyos feltételes érték, amely megközelítőleg megfelel a processzor ciklusának. Aztán ugyanazt a tesztet lefuttattam egy produkciós alaplapon, és megbizonyosodtam paranoid feltételezéseimről - a parancs ciklusai jelentősen meghosszabbodtak. 
Vagyis a Kínából érkező, Intel címke alatt gyártott szerverlapok BMC egységének flash memóriájában a gyártás szakaszában egy nem bejelentett szoftver modul volt telepítve, amely hipervizor gazdagént működik. Marad erről meggyőzni másokat. Először megkerestem az orosz orosz képviselőt. Egyáltalán nem volt nehéz, mivel az orosz iroda alkalmazottai gyakran megjelentek a Craftwaynél. Mindent elmondtam és megmutattam, de nem voltam biztos benne, hogy a technikus mindent ért-e. Ezek az úgynevezett műszaki szakemberek kompetenciájukat tekintve alig különböznek a vezetőktől. Megígérte azonban, hogy mindent beszámol a vezetőségnek. Nem tudom, hogy megcsinálta-e, de az Intel nem válaszolt, minden úgy ment, mint a homok. A Craftway munkája ekkor már véget ért, és egy új projektet indítottam el egy információbiztonsági rendszerekkel kapcsolatos vállalatnál. Ennek a cégnek a vezetője, akivel megosztottam a "felfedezéseimet", komolyan vette a szavaimat. Ezzel kapcsolatban úgy határoztak, hogy kapcsolatba lépnek az FSB Információbiztonsági és Speciális Kommunikációs Központjának vezetésével. Az FSB-n belül ez a struktúra részt vesz az ország információbiztonságának biztosításában, és szabályozza az állami és kereskedelmi szervezetek tevékenységét, amely az információ védelmével kapcsolatos. Szabályozza továbbá a minősített és bizalmas információkat feldolgozó kormányzati ügynökségek és kereskedelmi cégek információvédelmi intézkedéseit. Az a cég, amelyben abban az időben dolgoztam, hivatalos kapcsolatokat tartott fenn a Központtal annak érdekében, hogy hitelesítsék és engedélyezzék kereskedelmi projektjeiket, így rendkívül egyszerű volt egy értekezletet megszervezni szakember szinten. Feltételezték, hogy a Központ szakértői közlik véleményüket a vezetőséggel, és ha ezt követően a vezetőség szükségesnek ítéli hallgatni minket, akkor a következő szakasz egy magasabb szintű találkozó lesz. A találkozóra sor került, elmondtam és megmutattam mindent, amit megtudhattam, majd bemutattam egy illegális szoftvermodul jelenlétét a kanadai és kínai testületek példáin. Egyébként először hallottam a "könyvjelző" szakkifejezést, amely egy ilyen modult jelöl. Amikor a beszélgetés a haditengerészet felé fordult, félreértés jelent meg a központ munkatársainak szemében. Oktatási programot kellett vezetnem. Ennek során kiderült, hogy nem is tudtak arról, hogy a déli hídban egy speciális mikroprocesszor létezik, amelyhez hálózati adapter hozzáférhető, és arról, hogy a haditengerészeti egységben létezik egy kriptográfiai modul, amely megsérti az orosz törvényeket. Összegzésként egészen váratlanul hallottuk, hogy a fenyegetéseknek ezt a modelljét már megvizsgálták, ellenintézkedések halmazát alkalmazzák velük kapcsolatban, és általában nem félünk a könyvjelzőktől, mivel rendszereink nem rendelkeznek internetkapcsolattal. A további megkeresések nem vezettek semmihez, minden a titoktartáson nyugodott, például: okosak és szuper műveltségűek vagyunk, és állítólag nem tud semmiről. Mindazonáltal erősen kételkedtem technikai műveltségükben, mivel egyszerűen nem értették, amit elmondtam és mutattam. Elváltunk attól, hogy beszámolni fognak feletteseiknek, és csak ők döntenek a további cselekvésekről. Később megtudtam, mi ez a "titkos módszer" a gazdaprogramok felderítésére. És egészen véletlenül, a vállalatnál folytatott tárgyalások során tudtam meg - a Center engedélyese, aki felhatalmazást kapott a BIOS könyvjelzők ellenőrzésére. A vállalat technikai szakemberei a BIOS-t kutatva azt mondták, hogy virtualizációs hardvert használó szoftvermoduljait a virtualizációs parancsok aláírásával kell megkeresni. Valójában a virtualizációs hardver processzorának utasításai három vagy négy bájtot tartalmaznak a programkódban, de ki mondta, hogy ezt a programkódot titkosítatlan formában találja meg egy flash mikrokapcsolaton? Hogyan olvassák be ezt a kódot a RAM-ba, ha ezeket a memóriaterületeket hardver védi a megtekintéstől? Általánosságban elmondható, hogy az első találkozó eredménye kellemetlen utóízt hagyott maga után, és a legsúlyosabb hangulatban az események fejlődésére számítottam. Másfél hónappal később meghívást kaptunk magához az Információvédelmi és Speciális Kommunikációs Központba, hogy bemutathassuk a felfedezett könyvjelzőt. Ezúttal nem hétköznapi alkalmazottak gyűltek össze minket meghallgatni, hanem vezetők és vezető szakemberek (legalábbis így mutatkoztak be). A találkozó előadássá alakult, csaknem három órán át figyelmesen hallgattak rám, egyértelmű volt, hogy először hallják, miről mesélek nekik. Felsoroltam az új biztonsági réseket az x86 platformon, megmutattam a könyvjelzőt és elmondtam, hogyan lehet felderíteni, valamint sok kérdésre válaszoltam. A végén köszönetet mondtak nekünk, elmondták, hogy a témát speciális kutatási projektek keretében kell kidolgozni, és ezen elváltunk. Az eufória megszűnt, amikor nem hivatalos csatornákon keresztül olyan információ jutott el hozzánk, hogy egyszerűen nem akartak hinni nekünk. Ez azonban nem hűlte le vágyamat, hogy bebizonyítsam esetemet. Ahogy nekem akkor úgy tűnt, a megoldás a felszínen hevert: magamnak kellett egy ilyen programmodult megírnom a könyvjelzőhöz. Nem tudtam volna könyvjelzőt betenni a haditengerészet flash memóriájába, de jól betolhatom a fő BIOS-ba. Úgy döntöttem, hogy a hipervizort egy saját biztonsági modullal látom el, amely a memóriában és a flash mikroszkópon maszkolható, valamint blokkolom az írást egy flash mikrokapcsolathoz, ahová a könyvjelzőkód kerül, majd ezt követően csak a BIOS deszetek eltávolításával és egy külső programozón történő újraprogramozással lehet majd törölni. Csak annak a "rosszindulatú" funkciónak a döntése maradt, amelyet a hipervizornak el kell végeznie. Eszembe jutott az FSB egyik szakemberének kijelentése, miszerint nem félnek a könyvjelzőktől, mivel rendszereik nincsenek összekapcsolva a globális hálózattal. De a külvilágtól származó információknak valamiképpen be kell jutniuk ezekbe a biztonságos helyi hálózatokba, legalábbis eldobható optikai lemezeken keresztül. Így a nyilvánvaló következtetésre jutottam, és úgy döntöttem, hogy a fülön a bejövő információáramlást a hiperhajtómű segítségével elemzem, hogy úgymond világvége fegyvert valósítsam meg, vagyis a fül segítségével egy külső parancsra tönkretegyem a számítási rendszert, steganográfiai úton továbbítva a bemeneti információáramon. Az információáramlás titkos beolvasása, a teljesítmény elvesztése nélkül, csak a virtualizációs hardver képes kezelni. Mikor kell beolvasni, az is világos: a lemezrendszerek I / O pufferein és egy hálózati adapteren. Az I / O pufferek beolvasása nagy probléma a virtualizációs hardverek számára. Csak előbb mondva, mint kész! Egy ilyen, körülbelül 20 KB méretű hiper meghajtót regisztráltak az alaplapi BIOS-ban, és fel van szerelve egy észlelésgátló funkcióval. Blokkolta a felülírási kísérleteket a BIOS frissítésekor, és elvégezte az egyetlen funkciót: visszaállította a BIOS flash chipjét, amikor megsemmisítési parancs érkezett. A megvalósítás megkönnyítése érdekében maga a parancs DOC formátumú szövegfájlba volt varrva a beállítási címkékben. Amikor minden készen állt, a vállalat vezetése ismét az FSB-hez fordult azzal a javaslattal, hogy megvizsgálja saját könyvjelzőnk munkáját és megbizonyosodjon arról, hogy a virtualizációs technológiák valós veszélyt jelentenek-e. De senki nem akarta megnézni a könyvjelzőnket az ügyben, a legfelülről jött egy parancs (soha nem tudtam meg, hogy kinek a pontos sorrendje volt), hogy ne kommunikáljon már velünk. Az információbiztonságért küzdő fő harcosok nem akartak ránk hallgatni. Aztán már reménykedve a semmiben, sőt, a lelkiismeretünk megtisztításában, megpróbáltunk információt közvetíteni a problémáról az információbiztonsági rendszerek felhasználóinak. Megkerestük a Gazpromot, hogy tájékoztassuk a vállalat szakembereit az elosztott folyamatirányító rendszereket fenyegető jelenlegi veszélyekről. Sikerült megbeszélést egyeztetnünk a vállalat biztonságának vezetésével és a vállalat komplex biztonsági rendszereinek irányításával. Kifejezetten nekik készítették el a könyvjelző vizuálisabb változatát, egyszerűsített parancsfelülettel. A könyvjelző aktiválása után egy szöveges fájlt töltött le a számítógépre, amelynek tartalma két szót tartalmazott - "Gazprom" és "stop" - véletlenszerű sorrendben. Ezt követően a számítógép meghalt, de nem azonnal, hanem öt perc késéssel. Természetesen egy napot késni lehetett, de akkor nem értük volna el a demonstrációra szánt időt. A "Gazprom" alkalmazottai panaszkodtak az alacsony szintű információbiztonságra, és azt mondták, hogy ez nem az ő dolguk, mivel az FSB által előírt követelmények és szabályok vezérlik őket. A kör bezárult, világossá vált, hogy ezt az "információ-felelőtlenség" monolitikus rendszerét nem lehet áttörni. Az azóta eltelt több mint három évben soha nem hallottam senkit arról, hogy a virtualizációs hardverről a célrendszerek behatolásának eszközeként beszélnének. Paradoxon? Nem hiszem. A téma sajátossága, hogy csak a sikertelen technológiákról tanulunk. Nem ismerünk olyan technológiákat, amelyeket még nem fedeztek fel, és szerzőik természetesen hallgatnak. Nem szabad megfeledkezni arról, hogy a könyvjelzők megbízható elhelyezése a BIOS-ban csak gyárilag lehetséges. Működési körülmények között ehhez egy adott alaplap modellre kell összpontosítani, és az ilyen lehetőségek nem túl érdekesek a hackerek számára. Tömegmérlegre van szükségük, dolgoznak, ahogy mondani szokták, "területenként". Vannak azonban, akik a célzást, a "mesterlövészstílust" támadják. A könyvjelzők elhelyezése a BIOS-ban, sőt a virtualizációs hardver aktiválásával, amely lehetővé teszi azok hatékony elrejtését, természetesen kényelmes eszköz az ilyen "mesterlövészek" számára. Egyszer majdnem elkapták őket, és szinte véletlenül. Úgy gondolom, hogy ezt most nem lehet megtenni, és senkit sem lehet elkapni, ahogy valószínűleg megértette. Valamikor, amikor a személyi számítógépeket több száz darabos tételekben vásárolták külföldön, és nem több millió "példányszámban", a KGB egyik osztályának égisze alatt kis kereskedelmi irodákat szerveztek "könyvjelzők keresésére". Most már mindannyian tökéletesen megértjük, hogy ez volt az egyik őszinte módszer a pénz elvételére, mert a támogatás és a szervezés ezen szintjén bármit is lehetett találni, de csak nem egy lapot a chipek összetételében. De az állami hivatalok és vállalkozások számának nagy vásárlóinak még mindig nem volt hová menniük. Ők fizették.
hirdető
Ma az Intel nem is titkolja, hogy a távoli PC-vezérlés eszközei beépülnek a modern számítógépes platformok processzoraiba és chipseteibe. A nagy népszerűségnek örvendő Intel Active Management Technology (AMT) segít a felhasználói beavatkozás nélkül egyszerűsíteni a távoli rendszerkarbantartást - diagnosztikát és helyreállítást. De senki sem biztosított, hogy az AMT rendszergazdájának jogait rosszindulatú célokra is fel lehet használni, és mint kiderült, nem csak könyvjelző létezik, hanem egy egész "jelzálog is".Damien Zammit biztonsági szakértő publikációja szerint a modern Intel lapkakészletek beágyazott helyi és elszigetelt Intel Management Engine (Intel ME) mikrovezérlő chipet tartalmaznak. Ez egy olyan megoldás, amelynek saját firmware-je van, amelyet harmadik féltől származó eszközök nem tudnak megvizsgálni, és a processzor, a memória és a rendszer egészének teljes ellenőrzésével rendelkezik. Ezenkívül a vezérlő kikapcsolt számítógéppel működhet, amennyiben a memória áramellátást kap. Természetesen az operációs rendszer és a segédprogramok sem nem alszanak, sem lelkileg nem tudnak a vezérlő tevékenységéről, és nem adnak ki riasztást, miközben a rendszerrel és az adatokkal dolgozik.
Aggodalomra ad okot, hogy az ellenség megfelelő technikai szintje esetén fennáll annak a veszélye, hogy bármely chipet rejtve módosítanak. A módosított chip kritikus csomópontokban fog működni, és a bevezetett "trójai faló" vagy "hardver gerinc" észrevétlen marad, ami a legalapvetőbb szinten aláássa az ország védekezését. Sokáig hipotetikus maradt az ilyen fenyegetés, de egy nemzetközi kutatócsoport nemrégiben fizikai szinten is képes volt megvalósítani.
Georg T. Becker, a Massachusettsi Egyetem svájci és német kollégáival együtt a koncepció bizonyításának részeként létrehozta a "hardverszintű trójai" két változatát, amely megzavarja az (ál) véletlenszám-generátort (PRNG) az Intel Ivy processzorok kriptográfiai blokkjában. Híd. Bármely titkosítási rendszerhez a módosított PRNG használatával létrehozott kriptográfiai kulcsok könnyen kiszámíthatóak lesznek.
A hardver fül jelenlétét semmiképpen sem a speciálisan erre tervezett beépített tesztek, sem a processzor külső vizsgálata nem határozza meg. Hogy történhetett ez? A kérdés megválaszolásához vissza kell térni a hardveres PRNG megjelenésének történetéhez, és meg kell ismerkednie működésének alapelveivel.
A kriptográfiai rendszerek létrehozásakor meg kell szüntetni a kulcsok gyors kiválasztásának lehetőségét. Hosszuk és kiszámíthatatlanságuk közvetlenül befolyásolja azon lehetőségek számát, amelyeket a támadó félnek rendeznie kellene. A hossz közvetlenül beállítható, de sokkal nehezebb elérni a kulcsváltozatok egyediségét és egyenlő valószínűségét. Ehhez véletlenszámokat használnak a kulcsgenerálás során.
Jelenleg általánosan elfogadott tény, hogy csak a szoftveres algoritmusok miatt lehetetlen egy valóban kaotikus eloszlású, véletlenszerű számfolyamot megszerezni a teljes meghatározott halmazon. A tartomány egyes részein mindig magas frekvenciájúak lesznek, és kissé kiszámíthatóak maradnak. Ezért a gyakorlatban alkalmazott számgenerátorok nagy részét ál-véletlenszerűnek kell felfogni. Ritkán kriptográfiailag elég megbízhatóak.
A kiszámíthatóság hatásának csökkentése érdekében bármely számgenerátornak megbízható véletlen magforrásra van szüksége. Általában néhány kaotikus fizikai folyamat mérési eredményeit használják fel. Például a fényrezgések intenzitásának ingadozása vagy a rádiófrekvenciás zaj regisztrálása. Technikailag kényelmes lenne a véletlenszerűség ilyen elemét (és a teljes hardveres PRNG-t) kompakt változatban használni, és ideális esetben beépíteni.
Az Intel a kilencvenes évek vége óta beépíti (ál) véletlenszám-generátorokat a chipjeibe. Korábban a természetük hasonló volt. A kimeneten véletlenszerű értékeket kaptunk a nehezen megjósolható fizikai folyamatok - termikus zaj és elektromágneses interferencia - hatására. Az analóg generátorokat viszonylag könnyű külön blokkként megvalósítani, de nehezen integrálhatók új áramkörökbe. Amint a folyamat kisebb lett, új és hosszú kalibrációs lépésekre volt szükség. Ezenkívül a tápfeszültség rendszeres csökkenése rontotta az ilyen rendszerek jel-zaj arányát. A PRNG-k folyamatosan dolgoztak és jelentős mennyiségű energiát fogyasztottak, és munkájuk sebessége sok kívánnivalót hagyott maga után. Ezek a hiányosságok korlátozásokat szabtak a lehetséges alkalmazásokra.
A teljesen digitális jellegű (ál) véletlenszám-generátor ötlete már régóta furcsa, ha nem is abszurd. Végül is bármely digitális áramkör állapota mindig mereven determinista és kiszámítható. Hogyan lehet bevezetni a véletlenszerűség szükséges elemét, ha nincsenek analóg komponensek?
A kívánt káosz létrehozásának kísérletét kizárólag a digitális elemek alapján az Intel mérnökei 2008 óta végzik, és pár év kutatás után siker koronázta őket. A művet 2010-ben mutatták be a honolului VLSI nyári szimpóziumon, és egy kis forradalmat hozott a modern rejtjelezésben. Először valósítottak meg egy teljesen digitális, gyors és energiatakarékos PRNG-t egy kereskedelmi célú általános processzorban.
Első munkacíme a Bika-hegy volt. Ezután átnevezték Secure Key-re. Ez a kriptográfiai blokk három alapvető modulból áll. Az első véletlenszerű biteket generál viszonylag lassú, 3 Gbps sebességgel. A második értékeli varianciájukat, és 256 bites blokkokká egyesíti őket, amelyeket véletlenszerű magforrásként használnak. A harmadik blokk matematikai eljárásainak sora után nagyobb sebességgel generálunk 128 bites véletlenszerű számokat. Ezek alapján az új RdRand utasítás segítségével szükség esetén a szükséges hosszúságú véletlenszerű számok jönnek létre és kerülnek egy speciálisan kijelölt nyilvántartásba: 16, 32 vagy 64 bit, amelyeket végül átkerülnek az őket kérő programba.
A (pszeudo) véletlenszám-generátorok hibái és azok rosszindulatú módosításai elvesztik a bizalmat a népszerű kriptográfiai termékekkel és a tanúsítással szemben.
A PRNG-k kivételes jelentősége miatt bármely kriptográfiai rendszerben teszteket építettek a Secure Key-be a generált véletlenszámok minőségének ellenőrzésére, és vezető szakértői csoportokat vontak be tanúsítás céljából. A teljes egység megfelel az ANSI X9.82 és a NIST SP 800-90 szabvány kritériumainak. Ezenkívül a NIST FIPS 140-2 2. szintű tanúsítvánnyal rendelkezik.
Eddig a hardveres trójaiakkal kapcsolatos munka nagy része hipotetikus volt. A kutatók kis logikai áramkörökből további terveket javasoltak, amelyeket valamilyen módon hozzá kellett adni a meglévő chipekhez. Például Samuel Talmadge King és társszerzői a LEET-08-on bemutatták egy ilyen hardveres trójai változatát a központi processzor számára, amely teljes ellenőrzést biztosítana a rendszer felett egy távoli támadónak. Egy konfigurált UDP csomag egyszerű elküldésével bármilyen változtatást elvégezhet egy ilyen számítógépen, és korlátlan hozzáférést nyerhet annak memóriájához. A további logikai áramköröket azonban viszonylag könnyű mikroszkóppal azonosítani, nem beszélve az ilyen módosítások keresésének speciális módszereiről. Becker csoportja a másik irányba ment:
Ahelyett, hogy további áramköröket csatlakoztatnánk a lapkához, a hardverszintű füleket úgy hajtottuk végre, hogy egyszerűen megváltoztattuk a benne lévő mikrotranzisztorok működését. Többszöri próbálkozás után képesek voltunk szelektíven megváltoztatni az adalékanyag polaritását, és elvégezni a kívánt módosításokat a teljes kriptográfiai egység működésében. Ezért trójai családunk bizonyítottan ellenáll a legtöbb detektálási módszernek, beleértve a pásztázó mikroszkópiát és a referencia chipekkel való összehasonlítást. "
Az elvégzett munka eredményeként a 128 bites hosszúságú egyedi számok helyett a harmadik Secure Key blokk olyan szekvenciákat kezdett felhalmozni, amelyekben csak 32 bit különbözött. Az ilyen ál-véletlenszerű számok alapján előállított kriptográfiai kulcsok nagyon kiszámíthatóak és néhány percen belül feltörhetők egy szokásos otthoni számítógépen.
A hardver fül alapjául szolgáló elektromos vezetőképesség szelektív módosítását két változatban hajtották végre:
- az Intel Secure Key-ből származó jelek digitális utófeldolgozása;
- oldalsó csatornán használja a Substitution-box módszerrel.
Ez utóbbi módszer sokoldalúbb és kisebb módosításokkal alkalmazható más chipekre.
A fedélzeti PRNG RdRand utasítással történő használatának lehetősége először az Intel Ivy Bridge architektúra processzoraiban jelent meg. Az Intel részletes útmutatókat írt a programozók számára. Leírják a kriptográfiai algoritmusok optimális megvalósításának módszereit, és hivatkozást adnak a Secure Key működésének leírására. A biztonsági szakértők erőfeszítései hosszú ideig a szoftverrész sebezhetőségének felkutatására irányultak. Talán először a hardver szintű rejtett beavatkozás bizonyult sokkal veszélyesebbnek és meglehetősen megvalósítható technológiának.
