Kinesiske bokmerker: en sann historie om virtualisering, sikkerhet og spioner. Maskinvare "bokmerker" Maskinvarebokmerke på databussen

Mange informasjonssystemer opererer på grunnlag av det Maskinvare bringer ingen trusler. I denne situasjonen utføres ikke engang innledende og regelmessige kontroller. Bokmerke- en logisk/maskinvareenhet som implementerer visse udokumenterte funksjoner, vanligvis til skade for brukeren av et bestemt informasjonssystem. Et bokmerke kan lagre eller overføre systemdata.

Ikke alle virksomheter har de nødvendige spesialistene som er i stand til å identifisere maskinvareproblemer. For innledende tillit til fravær av slike bokmerker på det nye utstyret, må du stole på de medfølgende sertifikatene fra leverandøren. For å øke tilliten til slikt utstyr, kan du invitere spesialister til å utføre en fullstendig eller tilfeldig inspeksjon av utstyret.

Implementering av regelmessig kontroll er mulig på forskjellige måter, alt avhenger av kravene til en bestemt informasjonsklasse eller metoder for å jobbe med den. Verifiseringsmetoder kan være som følger:

Periodisk inspeksjon av utstyr av inviterte spesialister fra visse autoriserte strukturer
Analyse av utstyrets serienummer
Automatisert inventar av maskinvarekomponenter i informasjonssfæren til bedriften
Forsegling av ulike deler av utstyrshus med regelmessige integritetskontroller

I kritiske områder er det mulig å implementere utstyr for kontinuerlig overvåking, eller undertrykking av ulike overføringssignaler fra utenfor virksomheten. Slike midler inkluderer: radiosendinger, kablede informasjonsoverføringsnettverk, strømnettverk, infrarød rekkevidde, bakgrunnslyd.

I denne saken er et viktig kriterium for sikopplæring av brukere, som må varsle bedriftens sikkerhetstjeneste i tilfelle mistanke. Slike metoder for å jobbe med brukere kalles.

Jeg er ikke en profesjonell innen informasjonssikkerhet; mitt interesseområde er datasystemer med høy ytelse. Jeg kom til temaet informasjonssikkerhet helt tilfeldig, og det er dette som vil bli diskutert videre. Jeg tror denne sanne historien vil fremheve problemene knyttet til virtualiseringsmaskinvare mye bedre enn en tørr faktaerklæring. Allerede før den offisielle kunngjøringen av nye Intel-prosessorer med støtte for maskinvarevirtualisering (i begynnelsen av 2007), bestemte jeg meg for å bruke disse brikkene til å lage et enkelt databehandlingssystem basert på flere servere, som skulle bli en enkelt databehandlingsinstallasjon med SMP-arkitektur for OS og applikasjonsprogrammer. For å gjøre dette var det nødvendig å skrive en kompakt hypervisor med ikke-standard funksjonalitet, hvis hovedtrekk ikke ville være delingen av ressursene til en enkelt datamaskininstallasjon mellom forskjellige operativsystemer, men tvert imot kombinasjonen av ressursene til flere datamaskiner til et enkelt kompleks, som vil bli administrert av ett operativsystem. Samtidig burde operativsystemet ikke engang innse at det ikke handlet med et enkelt system, men med flere servere. Virtualiseringsmaskinvare ga en slik mulighet, selv om den opprinnelig ikke var ment å løse slike problemer. Faktisk er det ennå ikke opprettet et system der virtualiseringsutstyr skal brukes til databehandling med høy ytelse, og på den tiden var jeg generelt en pioner på dette området. Hypervisoren for denne oppgaven ble selvfølgelig skrevet fra bunnen av. Det var grunnleggende viktig å starte OS allerede på en virtualisert plattform, slik at fra de første kommandoene til OS-lasteren ville alt fungere i et virtuelt miljø. For å gjøre dette måtte vi virtualisere den virkelige modellen og alle prosessordriftsmodi og starte virtualisering umiddelbart etter initialisering av plattformen før lasting av OS. Siden virtualiseringssystemet for dette formålet viste seg å være ikke-standard og så ut som en helt autonom kompakt programvaremodul (kodevolum ikke mer enn 40–60 KB), turte jeg på en eller annen måte ikke kalle det en hypervisor, og jeg begynte å bruke begrepet "hyperdriver", siden det er mer nøyaktig formidlet essensen av det funksjonelle formålet med systemet. Det fantes ikke noe seriellt utstyr med virtualiseringsmaskinvare på den tiden, men takket være samarbeidet med Craftway hadde jeg tilgang til pre-produksjonsprøver av prosessorer og hovedkort med virtualiseringsstøtte som ennå ikke var offisielt utgitt (de såkalte samples som Intel vennligst gir til sine forretningspartnere). Derfor begynte arbeidet å koke på dette "prøvetakings"-utstyret. Layouten ble satt sammen, hyperdriveren ble skrevet, alt fungerte etter hensikten. Det må sies at virtualiseringsutstyret på den tiden var veldig "rått", og det er grunnen til at det mer enn en gang nektet å fungere som skrevet i dokumentasjonen. Det var nødvendig å håndtere bokstavelig talt hver monteringskommando, og kommandoene for virtualiseringsmaskinvaren i seg selv måtte skrives i maskinkode, siden det på den tiden ikke var noen kompilatorer som støttet virtualiseringskommandoer. Jeg var stolt over de oppnådde resultatene, jeg følte meg nesten som herskeren over virtuelle verdener... men euforien min varte ikke lenge, bare en måned. På det tidspunktet hadde jeg allerede satt sammen en prototype basert på servere med virtualiseringsutstyr, hvor de første produksjonsprøvene nettopp hadde dukket opp, men oppsettet fungerte ikke. Jeg begynte å se på det og skjønte at systemet mitt ble hengende når jeg utførteoer. Inntrykket var at de enten ikke fungerte i det hele tatt, eller fungerte på en eller annen måte ikke-standardisert. Frysingen skjedde bare når virtualiseringsutstyret kjørte i ekte modus, men hvis systemet mitt ble startet fra beskyttet modus, etter at operativsystemet ble lastet, var alt i orden. Fagfolk vet at i de første revisjonene støttet ikke Intel virtualiseringsmaskinvare prosessordrift i ekte modus. Dette krevde et ekstra lag med tilstrekkelig stort volum til å emulere virtuell x86. Siden hyperdriveren ble lansert før operativsystemet ble lastet slik at det kunne stole fullt ut på den nye virtuelle konfigurasjonen, ble en liten del av OS-oppstartskoden utført i ekte prosessormodus. Systemet døde nøyaktig på real-mode emuleringsbehandlere i hyperdriveren. Først trodde jeg at jeg gjorde en feil et sted, ikke forsto noe, glemte noe. Jeg sjekket alt til siste bit i koden min, fant ingen feil og begynte å klandre ikke meg selv, men kollegene mine fra utlandet. Det første jeg gjorde var å bytte ut prosessorene, men det hjalp ikke. På hovedkort på den tiden var virtualiseringsutstyret kun i BIOS, hvor det ble initialisert når serveren ble slått på, så jeg begynte å sammenligne BIOSer på hovedkort (kort av samme type med samples) - alt matchet ned til byte og nummeret til selve BIOS. Jeg falt i stupor og, uten å vite lenger hva jeg skulle gjøre, brukte jeg siste utvei - "poke-metoden". Det jeg ikke gjorde, tenkte ikke lenger, men bare kombinerte, og til slutt lastet jeg dumt ned BIOSer fra den offisielle Intel-nettsiden og skrev dem inn på hovedkortene på nytt, hvoretter alt fungerte... Min overraskelse visste ingen grenser: BIOS-nummeret var det samme, BIOS-bildene matchet byte for byte, men av en eller annen grunn fungerte de serielle hovedkortene bare når jeg lastet dem med samme BIOS hentet fra Intel-nettstedet. Så, årsaken er fortsatt i hovedkortene? Men deres eneste forskjell var i markeringene: Assembled Canada ble skrevet på prøvene, og Assembled China ble skrevet på seriebrettene. Det ble klart at brettene fra Kina inneholder flere programvaremodulers fastvare i BIOS, men standard analyseprogrammer så ikke disse modulene. De jobbet tilsynelatende også med virtualiseringsutstyr og var følgelig i stand til å skjule det sanne innholdet i BIOS. Grunnen til at hyperdriveren min frøs på disse kinesiske brettene ble også tydelig: to programvaresystemer jobbet samtidig med den samme virtualiseringsmaskinvaren, som ikke tillot deling av ressursene deres. Jeg ønsket å takle denne ondsinnede BIOS-en, og uten noen baktanker om "bokmerker", "bakdører", "udokumenterte evner", var det rett og slett akademisk interesse, og ingenting mer. Det må sies at parallelt med introduksjonen av virtualiseringsutstyr, oppdaterte Intel brikkesettet radikalt. Dette brikkesettet, nummerert 5000x, produseres fortsatt i flere modifikasjoner. Sørbroen til dette brikkesettet, 631xESB/632xESB I/O Controller Hub, som flash-brikker med BIOS er koblet til, har blitt produsert nesten uendret siden 2007 og brukes som basisbrikke for nesten alle servere i to-sockets design. Jeg lastet ned dataarket for sørbroen, leste beskrivelsen og ble rett og slett lamslått. Det viser seg at tre flash-minnebrikker er koblet til denne nye sørbroen: den første er en standard BIOS, den andre er dedikert til prosessorprogrammer for nettverkskontroller, og den tredje er beregnet på BMC-enheten integrert i sørbroen. System Management Unit (SMU) er et middel for fjernkontroll og overvåking av en databehandlingsinstallasjon. Den er uunnværlig for store serverrom, hvor det rett og slett er umulig å oppholde seg lenge på grunn av støy, temperatur og trekk. Det faktum at VMC-enheter har sin egen prosessor og følgelig flash-minne for programmene er selvfølgelig ingen nyheter, men til nå ble en slik prosessor og minne plassert på et eget kort, som var koblet til hovedkortet: hvis du vil , installer det, hvis du ikke vil, installer det. ikke legg det. Nå har Intel integrert disse komponentene i den sørlige broen; dessuten koblet den denne enheten til systembussen og brukte ikke en dedikert nettverkskanal (som levert av IPMI-standarden, som beskriver funksjonene til BMC-enheten) for å betjene tjenesten nettverk, men tunnelerte all tjenestenettverkstrafikk til hovednettverksadapterne. Deretter lærte jeg fra dokumentasjonen at programmene på flash-brikken til marineenheten er kryptert, og for å pakke dem ut, brukes en spesiell maskinvarekryptografisk modul, også integrert i sørbroen. Jeg har aldri vært borti slike IUD-enheter før. For ikke å være ubegrunnet gir jeg et utdrag fra dokumentasjonen for denne sørbrua:

ARC4-prosessor som jobber med 62,5 MHz hastighet.
Grensesnitt til begge LAN-portene til Intel® 631xESB/632xESB I/O Controller Hub som gir direkte tilkobling til nettet og tilgang til alle LAN-registre.
Kryptografisk modul, som støtter AES og RC4 krypteringsalgoritmer og SHA1 og MD5 autentiseringsalgoritmer.
Sikret mekanisme for lastbar Regulert FW.

Bruk av utenlandske kryptografiske midler med en nøkkellengde på mer enn 40 biter er forbudt i Russland ved lov, men her er du velkommen! - hver Intel-server inneholder en kryptomodul med ukjente nøkler på 256 biter. Dessuten ble disse nøklene brukt til å kryptere programmer innebygd i hovedkortbrikker under produksjon. Det viser seg at marineenheter i Russland på Intel-servere som inneholder 5000x-brikkesettet må deaktiveres. Imidlertid er disse blokkene, tvert imot, alltid i fungerende tilstand, selv om selve datainstallasjonen er slått av (for at VMC skal fungere, er standby-spenningen tilstrekkelig, det vil si serverens strømkabel plugget inn i stikkontakten) . Alt dette virket sekundært for meg på den tiden, siden jeg først trengte å finne ut hvilken av flash-brikkene som inneholdt en programvaremodul som fungerte med virtualiseringsmaskinvare og forstyrret hyperdriveren min, og jeg begynte å eksperimentere med fastvare. Etter å ha lest dokumentasjonen var jeg på vakt, og da jeg oppdaget at funksjonaliteten til hyperdriveren ble gjenopprettet like etter at flash-brikken til marineenheten ble blinket, ble jeg ikke engang overrasket. Det var umulig å forstå videre uten spesielle stands, siden kryptografi fullstendig dekket mulighetene for kodereversering for marinen. Jeg fant ikke dokumentasjon på den interne arkitekturen til denne integrerte marinen; i dataarket for sørbroen beskrev Intel bare grensesnittregistrene for å kontrollere denne blokken ved hjelp av standard tilgangsmetoder, noe som resulterte i en klassisk "svart boks". Helheten av fakta var alarmerende og antydet paranoide tanker i stil med spiondetektiver. Disse fakta indikerer tydelig følgende:

Intels nye produksjonsserverkort basert på 5000-brikkesettet har programmer innebygd i flashminnet til BMC-enheten og utført på sentralprosessoren, og disse programmene kjøres ved hjelp av CPU-virtualiseringsmaskinvare.
Flash-minnebildene fra det offisielle Intel-nettstedet inneholder ikke slike programvaremoduler, derfor ble programvaremodulene som forstyrret meg ulovlig flashet inn på hovedkortene på produksjonsstadiet.
Flashminnet til marineenheten inneholder krypterte programvaremoduler som ikke kan settes sammen og lastes inn i flashminnet uten å kjenne til krypteringsnøklene, derfor kjente den som satte inn disse ulovlige programvaremodulene krypteringsnøklene, det vil si at de faktisk hadde tilgang til hemmelig informasjon.

Jeg informerte ledelsen til Craftway om problemet med fastvaren til flashminnet til marineenheten og den tvilsomme situasjonen fra lovsynspunktet med de nye Intel-brikkesettene, som jeg fikk et ganske forventet svar på i stil med " ikke rot det til, du forstyrrer virksomheten.» Jeg måtte roe meg ned, for du kan egentlig ikke argumentere mot arbeidsgivere. Hendene mine var bundet, men "mine tanker, mine hester" ga meg ikke fred, det var ikke klart hvorfor disse vanskelighetene var nødvendige og hvordan alt dette ble gjort. Hvis du har muligheten til å plassere din egen programvare i minnet til marineenheten, hvorfor trenger du alt dette problemet med sentralprosessoren? En rimelig grunn kan bare være at problemet som ble løst krevde overvåking av gjeldende datakontekst på sentralprosessoren. Det er åpenbart umulig å holde styr på informasjonen som behandles på hoveddatasystemet ved å bruke kun en lavhastighets perifer prosessor med en frekvens på 60 MHz. Dermed ser det ut til at oppgaven til dette ulovlige systemet var å fange opp informasjon behandlet på hoved hjelp av virtualiseringsutstyr. Det er selvfølgelig mer praktisk å fjernstyre hele det ulovlige systemet fra prosessoren til BMC-enheten, siden den har sin egen uavhengige tilgang til nettverkskortene på hovedkortet og sine egne MAC- og IP-adresser. Spørsmålet er "hvordan gjøres dette?" var mer akademisk av natur, siden noen klarte å lage en hypervisor som kan dele vimed en annen hypervisor og gjør dette riktig for alle moduser bortsett fra den virkelige modusen for CPU-drift. Nå vil du ikke overraske noen med slike systemer, men så, for fem år siden, ble de oppfattet som et mirakel, i tillegg var emuleringshastigheten fantastisk - det var umulig å emulere en vert programmatisk uten betydelige tap i ytelse. For å forklare, må vi gå litt dypere inn i teorien. Arkitekturen til Intel- og AMD-virtualiseringssystemer innebærer ikke tilstedeværelsen av flere hypervisorer på plattformen samtidig, men hypervisoren som ble lansert først kan emulere drift på ekte virtualiseringsmaskinvare for hypervisorer som lanseres senere. I dette tilfellet kjøres alle hypervisorer etter den første i et emulert vertsmiljø. Jeg kaller dette prinsippet «den første natts rett». Det kan enkelt implementeres ved å bruke spesielle behandlere i rotverten, mens oppgavemodusen ikke vil endre seg vesentlig, og de sekundære hypervisorvertene vil kjøre i oppgavemodus for rotverten. Emuleringsmodusen er ikke vanskelig å organisere, men ytelsesproblemer oppstår. Virtualiseringsmaskinvare fungerer hovedsakelig med VMCB-blokken (VMCS), vertsprogrammer har konstant tilgang til denne blokken, og hver slik tilgang krever 0,4–0,7 μs. Det er nesten umulig å skjule slik programvarevertsemulering for et Intel-virtualiseringssystem; for mange virtualiseringskommandoer vil måtte emuleres i programvaren gjennom utganger til rotverten, i stedet for å kjøre dem på ekte maskinvare. Jeg skal fortelle deg litt om forskjellene mellom virtualiseringsarkitekturer. Mfra Intel og AMD er helt forskjellige fra hverandre. Den viktigste arkitektoniske forskjellen mellom disse systemene er vertsdriftsmodusen. På et AMD-system kjører verten med virtualiseringsmaskinvare deaktivert, noe som betyr at programmene kjører på den virkelige prosessoren. Virtualisering av en sekundær vert på AMD-systemer krever virtualisering av kun VMRUN-kommandoen (vi kan anta at det ikke finnes andre kommandoer). Arbeid med kontroll-VMCB-blokken i AMD-arkitekturen skjer gjennom de vanlige kommandoene for tilgang til RAM, som lar deg kun kontrollere utførelsen av VMRUN-kommandoer ved å bruke den sekundære verten og, om nødvendig, korrigere VMCB-blokken før du faktisk går inn i oppgavemodus. Det er fortsatt mulig å forlenge hendelsesbehandlingssyklusen med det halve, og slik emulering er mulig på AMD-plattformen. I Intels virtualiseringssystem er alt mye mer komplisert. For å få tilgang til VMCB-blokken brukes spesialkommandoer VMREAD og VMLOAD, som må virtualiseres. Vanligvis har vertsbehandlere tilgang til feltene til en VMCB-blokk dusinvis, om ikke hundrevis, av ganger, og hver slik operasjon må emuleres. Samtidig er det merkbart at hastigheten synker med en størrelsesorden, dette er veldig lite effektivt. Det ble klart at ukjente kolleger brukte en annen, mer effektiv mekanisme for emulering. Og jeg fant hint om nøyaktig hvilken i dokumentasjonen. Intel-verten i seg selv er et virtuelt miljø, det vil si at i denne forbindelse er det ikke forskjellig fra oppgaveutførelsesmiljøet og styres ganske enkelt av en annen VMCB (se diagram). I tillegg beskriver dokumentasjonen konseptet med en "dobbel monitor" for virtualisering av SMM-modus (systemadministrasjonsmodus), når faktisk to verter og derfor to VMCB-blokker er aktive samtidig, og verten virtualiserer systemadministrasjonsmodusen kontrollerer hovedverten som en oppgave, men bare på punktene der systemadministrasjonsavbrudd kalles. Dette settet med omstendigheter antyder at Intels virtualiseringsmaskinvare sannsynligvis har en mekanisme for å kontrollere flere sekundære verter administrert av rotverten, selv om denne mekanismen ikke er beskrevet noe sted. Dessuten er det akkurat slik systemet mitt fungerte, og jeg har fortsatt ingen annen forklaring på de nesten umerkelige handlingene til rothypervisoren. Ting ble enda mer interessant: det ser ut til at noen hadde tilgang til disse udokumenterte funksjonene og satt dem i praktisk bruk. Omtrent seks måneder før slutten av samarbeidet med Craftway tok jeg posisjonen som en passiv observatør, men fortsatte likevel å regelmessig lansere systemet mitt på nye serier med serielle hovedkort fra Kina og nye prøver. På prøver fortsatte alt å fungere stabilt. Da jeg byttet til kinesiske brett, dukket det opp flere og flere mirakler i systemet. Det så ut til at kolleger fra utlandet aktivt forbedret ytelsen til rothypervisoren deres. De siste mistenkelige partiene med brett oppførte seg nesten normalt, det vil si at den første lanseringen av hyperdriveren min førte til en omstart av systemet under oppstarten av operativsystemet, men alle påfølgende lanseringer av hyperdriveren og operativsystemet gikk uten problemer. Til slutt skjedde det jeg hadde ventet på lenge: en ny gruppe med serielle hovedkort kom, når jeg brukte, som hyperdriveren min ikke frøs i det hele tatt. Jeg hadde allerede begynt å tvile på mine paranoide mistanker, men en ny hendelse styrket dem. Det skal bemerkes at Intel aktivt forbedrer virtualiseringsutstyr. Hvis den første revisjonen av utstyret jeg begynte å jobbe med var nummer 7, så skjedde den beskrevne situasjonen på den 11. revisjonen, det vil si at revisjonen ble oppdatert to ganger i løpet av et år (av en eller annen grunn har revisjoner bare oddetall). Så, i revisjon nummer 11, ble betingelsene for utganger til verten i henhold til oppgavetilstanden for virtualiseringsutstyr betydelig utvidet, ifølge hvilket et nytt kontrollfelt til og med ble introdusert i VMCB-blokken. Da prøveprosessorer dukket opp med denne revisjonen av virtualiseringsmaskinvare, ønsket jeg å teste de nye egenskapene i praksis. Jeg forbedret hyperdriveren ved å bruke de nye funksjonene i den 11. revisjonen av virtualiseringsmaskinvare, installerte prøveprosessoren på et seriekort fra Kina, der alt allerede fungerte uten problemer, og begynte å feilsøke. De nye egenskapene til utstyret manifesterte seg ikke på noen måte, og jeg falt igjen i utmattelse og syndet på prøvebehandleren og dokumentasjonen. Etter en tid var hovedkortet nødvendig for en annen oppgave, og etter å ha gjenopptatt eksperimenter byttet jeg prosessorer med den 11. revisjonen av virtualiseringsutstyr til en kanadisk prøve for å være på den sikre siden. Se for deg min overraskelse da alt fungerte på denne prøven! Først trodde jeg at jeg hadde skrudd opp et sted med seriekortet, siden de nye utgangene til verten ikke hadde noe med hovedkortet å gjøre, det var en ren prosessorfunksjon. For å teste den flyttet jeg prøveprosessoren til et seriekort, og alt sluttet å fungere igjen. Dette betyr at jeg ikke har ødelagt noe, men problemet lå i det faktum at hovedkortet på en eller annen måte påvirket de nye egenskapene tilren. Med tanke på mine mistanker, var den eneste konklusjonen i seg selv at den ulovlige rotverten av kolleger fra utlandet, sydd inn i flashminnet på hovedkortet, ikke visste om den nye revisjonen av virtualiseringsutstyret. Da denne ukjente maskinvaren begynte å fungere, sluttet den å sende utdata fra oppgavetilstanden til min sekundære vert gjennom sin egen hendelsesbehandler. Allerede da jeg visste hvordan jeg skulle takle denne plagen, lastet jeg opp fastvaren for marineenheten fra Intels nettsted til seriekortet, slått på systemet i tillit til at alt ville fungere med en gang, og ble igjen skuffet, siden frysene gjensto. Dette var noe nytt. I følge min teori ble den ulovlige hypervisoren frekk og ble trygg på sin usårbarhet. Tilsynelatende mente forfatterne at hjernebarnet deres hadde bestått teststadiet og at det ikke lenger var behov for å skjule ufeilbar programvare som en BIOS-feil. Etter at funksjonen for å beskytte initialiseringskoden fra å bli overskrevet i flash-minnet ble aktivert, ble bokmerket praktisk talt uutslettelig. Jeg hadde ingen tillit til at jeg hadde rett; kontrolleksperimenter var nødvendig. Jeg måtte finne opp min egen metode for å oppdage maskinvarehypervisoren. Så viste det seg imidlertid at jeg hadde funnet opp hjulet. Metoden gjorde det mulig å kontrollere utførelsestiden for systemkommandoer som krevde obligatorisk emulering i hypervisorverten. Jeg brukte en syklisk rammeteller i USB-kontrollerens maskinvare som en timer, og skrev programmet for den virkelige driftsmodusen for å minimere side- og ukontrollerte avbrudd som maskerte den sanne utførelsestiden for systemkommandoer. Den første testen jeg utførte var på et rent system basert på eksempel hovedkort fra Canada.

Utførelsestiden som er angitt på bildet er en vilkårlig verdi som omtrent tilsvarer prosessorens klokkesyklus. Så kjørte jeg den samme testen på et serielt hovedkort og var overbevist om mine paranoide antakelser - kommandoutførelsessyklusene var betydelig lengre.

Det vil si at i flashminnet til Navy-blokken med serverkort fra Kina, produsert under Intel-etiketten, var det installert en uerklært programvaremodul på produksjonsstadiet som fungerte som hypervisorvert. Det gjenstår bare å overbevise andre om dette. Det første jeg gjorde var å kontakte den russiske representanten for Intel. Dette var slett ikke vanskelig, siden ansatte ved det russiske kontoret ofte dukket opp på Craftway. Jeg fortalte og viste alt, men jeg var ikke sikker på at teknikeren forsto alt. Disse såkalte tekniske spesialistene skiller seg lite fra ledere i deres kompetansenivå. Han lovet imidlertid å rapportere alt til ledelsen. Jeg vet ikke om han gjorde dette, men det kom ikke noe svar fra Intel, alt gikk i vasken. Arbeidet mitt i Craftway var avsluttet på det tidspunktet, og jeg startet et nytt prosjekt i et selskap knyttet til informasjonssikkerhetssystemer. Lederen for dette selskapet, som jeg delte mine «oppdagelser» med, tok mine ord på alvor. I denne forbindelse ble det besluttet å kontakte ledelsen av FSB-senteret for informasjonsbeskyttelse og spesiell kommunikasjon. Denne strukturen i FSB er ansvarlig for å ivareta informasjonssikkerheten i landet og regulerer virksomheten til statlige og kommersielle organisasjoner som er knyttet til informasjonsbeskyttelse. Den regulerer også informasjonsbeskyttelsestiltak for offentlige etater og kommersielle firmaer som behandler klassifisert og konfidensiell informasjon. Selskapet jeg jobbet for på det tidspunktet opprettholdt offisielle kontakter med senteret for å sertifisere og lisensiere kommersielle prosjekter, så det var ganske enkelt å organisere et møte på spesialistnivå. Det ble forutsatt at senterets eksperter skulle rapportere sine meninger til ledelsen, og dersom ledelsen etter det mente det var nødvendig å lytte til oss, ville neste trinn være et møte på et høyere nivå. Møtet fant sted, jeg fortalte og viste alt jeg klarte å finne ut, så demonstrerte jeg tilstedeværelsen av en ulovlig programvaremodul ved å bruke eksempler på tavler fra Canada og Kina. Det var forresten første gang jeg hørte det profesjonelle uttrykket "bokmerke", som betegner en slik modul. Da samtalen dreide seg om spiralen, dukket det opp misforståelser i øynene til kolleger fra senteret. Jeg måtte gjennomføre et pedagogisk program. Underveis viste det seg at de ikke en gang mistenkte eksistensen av en spesiell mikroprosessor i sørbroen med tilgang til nettverksadapteren og tilstedeværelsen av en kryptografisk modul i marineenheten som brøt med russisk lov. Avslutningsvis hørte vi helt uventet at denne trusselmodellen allerede er studert, et sett med mottiltak blir brukt på dem, og generelt er vi ikke redde for bokmerker, siden systemene våre ikke har tilgang til Internett. Ytterligere spørsmål førte til ingenting, alt kom ned til hemmelighold, som, vi er smarte og super-litterate, men du skal ikke vite om noe. Jeg tvilte imidlertid alvorlig på deres tekniske kompetanse, siden de rett og slett ikke forsto det meste av det jeg fortalte og viste. De skilte seg på at de skulle rapportere til sine overordnede, og de skulle ta stilling til videre handlinger. Litt senere fant jeg ut hva denne "hemmelige metoden" for å oppdage vertsprogrammer var. Dessuten fant jeg ut ved et uhell under forhandlinger i et selskap - en lisenshaver av senteret, autorisert til å sjekke BIOS for bokmerker. Tekniske spesialister fra dette selskapet som utfører BIOS-undersøkelser sa at programvaremodulene som bruker virtualiseringsmaskinvare må søkes etterr. Faktisk inneholder prosessorkommandoer for virtualiseringsmaskinvare tre eller fire byte i programkoden, men hvem sa at de vil finne denne programkoden i ukryptert form på flash-brikken? Hvordan vil de skanne denne koden inn i RAM hvis disse minneområdene er beskyttet mot visning av maskinvare? Generelt etterlot resultatet av det første møtet en ubehagelig ettersmak, og jeg var i det dystreste humøret mens jeg ventet på utviklingen av hendelsene. Halvannen måned senere ble vi invitert til selve Senter for informasjonsbeskyttelse og spesiell kommunikasjon slik at vi kunne demonstrere bokmerket vi hadde oppdaget. Denne gangen var det ikke vanlige ansatte som samlet seg for å lytte til oss, men ledere og ledende spesialister (det var i alle fall slik de presenterte seg selv). Møtet ble til et foredrag, de lyttet oppmerksomt til meg i nesten tre timer, det var tydelig at de hørte for første gang hva jeg fortalte dem om. Jeg listet opp de nye sårbarhetene til x86-plattformen, viste bokmerket og fortalte hvordan jeg skulle oppdage det, og svarte på mange spørsmål. Til slutt takket de oss, sa at temaet måtte utvikles innenfor rammen av spesielle forskningsprosjekter, og med det skiltes vi. Euforien forsvant da informasjon nådde oss gjennom uoffisielle kanaler om at de rett og slett ikke ville tro oss. Dette la imidlertid ingen demper på ønsket om å bevise at jeg hadde rett. Det virket for meg da at løsningen var åpenbar: Jeg måtte skrive en slik bokmerkeprogramvaremodul selv. Jeg ville ikke ha vært i stand til å plassere bokmerket i flashminnet til marinen, men jeg kunne enkelt lagt det inn i hoved-BIOS. Jeg bestemte meg for å utstyre hypervisoren med sin egen sikkerhetsmodul for maskering i minnet og på flash-brikken, og også blokkere skriving til flash-brikken der bokmerkekoden vil være plassert, hvoretter den bare kan fjernes ved å ulodde BIOS og omprogrammere det på en ekstern programmerer. Alt som gjensto var å bestemme den "ondsinnede" funksjonen som hypervisoren skulle utføre. Jeg husket uttalelsen fra en av FSB-spesialistene om at de ikke var redde for bokmerker, siden systemene deres ble koblet fra det globale Internett. Men informasjon fra omverdenen må på en eller annen måte komme inn i disse sikre lokale nettverkene, i det minste gjennom optiske engangsdisker. Dermed kom jeg til den åpenbare konklusjonen og bestemte meg for å analysere den innkommende informasjonsflyten i bokmerket ved hjelp av hyperdriver-midler for å implementere, så å si, et dommedagsvåpen, det vil si bruke bokmerket til å ødelegge datasystemet med en ekstern kommando , overfører den gjennom input-informasjonsflyten, steganografisk. Å skanne en informasjonsflyt skjult, uten tap av ytelse, er vanskelig bare for virtualiseringsutstyr. Det er også klart hvor du skal skanne: på I/O-bufferne til disksystemer og nettverksadapteren. Skanning av I/O-buffere er et stykke kake for virtualiseringsmaskinvare. Ikke før sagt enn gjort! Denne hyperdriveren, omtrent 20 KB i størrelse, ble skrevet inn i hovedkortets BIOS og utstyrt med en anti-deteksjonsfunksjon. Den blokkerte forsøk på å omskrive den ved oppdatering av BIOS og utførte en enkelt funksjon: den tilbakestilte BIOS-flash-brikken når en kommando om å ødelegge ble mottatt. For å lette implementeringen ble selve kommandoen innebygd i en DOC-tekstfil i konfigurasjonskodene. Da alt var klart, henvendte selskapets ledelse seg igjen til FSB med et forslag om å se på arbeidet til vårt eget bokmerke og sørge for at virtualiseringsteknologier utgjør en reell trussel. Men ingen ønsket å se på bokmerket vårt i aksjon; det kom en ordre fra toppen (jeg fant aldri ut hvem sin ordre det var) om ikke å kommunisere med oss lenger. Hovedkjemperne for informasjonssikkerhet ønsket ikke å høre på oss. Så, i håp om praktisk talt ingenting for å rense samvittigheten vår, prøvde vi å formidle informasjon om problemet til brukere av informasjonssikkerhetssystemer. Vi tok kontakt med Gazprom for å informere selskapets spesialister om moderne trusler mot distribuerte prosesskontrollsystemer. Det var mulig å organisere et møte med ledelsen av bedriftsbeskyttelses- og administrasjonstjenesten for komplekse sikkerhetssystemer til dette selskapet. En mer visuell versjon av bokmerket med et forenklet kommandogrensesnitt ble utarbeidet spesielt for dem. Bokmerket ble aktivert etter å ha lastet ned en tekstfil til datamaskinen, hvis innhold inkluderte to ord - "Gazprom" og "stopp" - ordnet i tilfeldig rekkefølge. Etter dette døde datamaskinen, men ikke umiddelbart, men med en forsinkelse på fem minutter. Naturligvis var det mulig å utsette det med en dag, men da hadde vi ikke truffet tiden som var avsatt til demonstrasjonen. Gazprom-ansatte klaget på det lave nivået på informasjonssikkerhet og sa at det ikke var deres sak, siden de ble styrt av kravene og reglene fastsatt av FSB. Sirkelen sluttet, det ble klart at dette monolitiske systemet med "informasjonsuransvar" ikke kunne brytes gjennom. I de tre pluss årene som har gått siden den gang, har jeg aldri hørt noen snakke om virtualiseringsmaskinvare som et verktøy for å penetrere målsystemer. Paradoks? Ikke tenk. Det spesifikke ved emnet er at vi bare lærer om mislykkede teknologier. Vi vet ikke om teknologier som ikke har blitt oppdaget, og deres forfattere forblir selvfølgelig tause. Det bør tas i betraktning at pålitelig plassering av bokmerker i BIOS bare er mulig under fabrikkforhold. Under driftsforhold vil dette kreve fokus på en spesifikk hovedkortmodell, og slike alternativer er ikke særlig interessante for hackere. De trenger massedeltakelse, de jobber, som de sier, «i områder». Imidlertid er det også de som angriper med presisjon, "som en snikskytter." Teknologier for å plassere bokmerker i BIOS, og til og med aktivering av virtualiseringsutstyr, som lar deg effektivt skjule dem, er selvfølgelig et praktisk verktøy for slike "snikskyttere". En gang ble de nesten tatt, nesten ved et uhell. Jeg tror det ikke lenger vil være mulig å gjøre dette nå, og som du sikkert forstår, er det ingen som fanger det.

Praktiske fjernkontrollverktøy sparer systemadministratorer for mye energi – og utgjør samtidig en enorm sikkerhetsrisiko når de ikke kan deaktiveres i maskinvare ved hjelp av en jumper eller bryter på hovedkortet. Intel Management Engine 11-enheten i moderne Intel-plattformer utgjør nettopp en slik fare - i utgangspunktet kan den ikke deaktiveres, og dessuten er noen mekanismer for initialisering og drift av prosessoren knyttet til den, så grov deaktivering kan ganske enkelt føre til fullstendig systeminoperabilitet. Sårbarheten ligger i Intel Active Management Technology (AMT) og lar deg, med et vellykket angrep, få full kontroll over systemet, slik det ble beskrevet i mai i år. Men forskere fra Positive Technologies.

Selve IME-prosessoren er en del av systemhuben (PCH)-brikken. Med unntak av PCI Express-prosessorspor, går all kommunikasjon mellom systemet og omverdenen gjennom PCH, noe som betyr at IME har tilgang til nesten all data. Før versjon 11 var et angrep med denne vektoren usannsynlig: IME-prosessoren brukte en proprietær arkitektur med ARC-instruksjonssettet, som var lite kjent for tredjepartsutviklere. Men i versjon 11 ble det spilt en dårlig vits om teknologien: den ble overført til x86-arkitekturen, og den modifiserte MINIX ble brukt som OS, noe som betyr at tredjeparts studier av binær kode ble betydelig forenklet: både arkitekturen og OS var godt dokumentert. Russiske forskere Dmitry Sklyarov, Mark Ermolov og Maxim Goryachiy klarte å dekryptere de kjørbare modulene til IME versjon 11 og starte deres grundige studie.

Intel AMT-teknologi har en sårbarhetsscore på 9,8 av 10. Dessverre er fullstendig deaktivering av IME på moderne plattformer ikke mulig av grunnen beskrevet ovenfor - delsystemet er nært knyttet til initialisering og oppstart av CPU, samt strømstyring. Men fra et flashminnebilde som inneholder IME-moduler kan du fjerne alt som er unødvendig, selv om dette er veldig vanskelig å gjøre, spesielt i versjon 11. Me_cleaner-prosjektet utvikler seg aktivt, et verktøy som lar deg fjerne den generelle delen av bildet og la bare vitale komponenter være igjen. Men la oss gi en liten sammenligning: hvis i IME-versjoner opp til 11 (før Skylake), slettet verktøyet nesten alt, og etterlot omtrent 90 KB kode, nå er det nødvendig å lagre omtrent 650 KB kode - og i noen tilfeller Systemet kan slå seg av etter en halvtime, siden blokkeringen IME går inn i gjenopprettingsmodus.

Det er imidlertid fremgang. Den ovennevnte gruppen av forskere klarte å bruke utviklingssettet, som leveres av Intel selv og inkluderer Flash Image Tool for å konfigurere IME-parametere og Flash-programmeringsverktøyet, som fungerer gjennom den innebygde SPI-kontrolleren. Intel gjør ikke disse programmene offentlig tilgjengelige, men å finne dem på nettet er ikke spesielt vanskelig.

XML-filene som ble oppnådd ved bruk av dette settet ble analysert (de inneholder strukturen til IME-fastvaren og en beskrivelse av PCH-stroppmekanismen). En bit kalt "reserve_hap" (HAP) virket mistenkelig på grunn av beskrivelsen "High Assurance Platform (HAP) enable". Et nettsøk avslørte at dette er navnet på et plattformprogram med høy tillit knyttet til US NSA. Aktivering av denne biten indikerte at systemet hadde gått inn i Alt Disable Mode. IME-enheten reagerte ikke på kommandoer og reagerte ikke på påvirkninger fra operativsystemet. Det er en rekke mer subtile nyanser som finnes i artikkelen på Habrahabr.ru, men den nye versjonen av me_cleaner støtter allerede de fleste av de farlige modulene uten å sette HAP-biten, som setter IME-motoren i "TemporaryDisable"-tilstanden .

Den siste modifikasjonen av me_cleaner, selv i den 11. versjonen av IME, etterlater bare RBE-, KERNEL-, SYSLIB- og BUP-modulene; ingen kode ble funnet i dem for å aktivere selve IME-systemet. I tillegg til dem kan du bruke HAP-biten for å være helt sikker på at verktøyet også kan gjøre dette. Intel har gjennomgått forskningen og har bekreftet at en rekke IME-innstillinger dekker sikkerhetsbehovene til offentlige etater. Disse innstillingene ble introdusert på forespørsel fra amerikanske offentlige kunder, de har gjennomgått begrenset testing og slike konfigurasjoner støttes ikke offisielt av Intel. Selskapet nekter også for å introdusere såkalte bakdører i produktene sine.

Bekymring for at hvis motstanderen er tilstrekkelig teknisk, er det fare for at han vil utføre skjulte modifikasjoner på en hvilken som helst brikke. Den modifiserte brikken vil fungere i kritiske noder, og den introduserte "trojanske hesten" eller "maskinvaren" vil gå ubemerket hen, og undergrave landets forsvarsevne på det mest grunnleggende nivået. I lang tid forble en slik trussel hypotetisk, men en internasjonal gruppe forskere var nylig i stand til å realisere den på det fysiske nivået.

Georg T. Becker fra University of Massachusetts skapte sammen med kolleger fra Sveits og Tyskland, som en del av et proof of concept, to versjoner av en "maskinvare-nivå trojaner" som forstyrrer driften av (pseudo) tilfeldig tallgenerator ( RNG) i den kryptografiske enheten til Intel Ivy-prosessorer Bridge. Kryptografiske nøkler opprettet ved hjelp av en modifisert PRNG for et hvilket som helst krypteringssystem vil være lett forutsigbare.

Tilstedeværelsen av en maskinvarefeil bestemmes ikke på noen måte, verken av innebygde tester spesialdesignet for dette formålet, eller av ekstern inspeksjon av prosessoren. Hvordan kunne dette skje? For å svare på dette spørsmålet er det nødvendig å gå tilbake til historien om fremveksten av maskinvare PRNG og bli kjent med de grunnleggende prinsippene for driften.

Når du oppretter kryptografiske systemer, er det nødvendig å eliminere muligheten for raskt å velge nøkler. Deres lengde og grad av uforutsigbarhet påvirker direkte antall alternativer som den angripende siden måtte gå gjennom. Lengden kan stilles inn direkte, men det er mye vanskeligere å oppnå unike nøkkelalternativer og like sannsynlighet. For å gjøre dette, brukes tilfeldige tall under oppretting av nøkkel.

Foreløpig er det generelt akseptert at ved bruk av bare programvarealgoritmer er det umulig å oppnå en virkelig tilfeldig strøm av tall med deres ensartede kaotiske fordeling gjennom hele det angitte settet. De vil alltid ha en høy forekomstfrekvens i en del av området og forbli noe forutsigbare. Derfor bør de fleste tallgeneratorer som brukes i praksis oppfattes som pseudo-tilfeldige. De er sjelden sterke nok i kryptografisk forstand.

For å redusere effekten av forutsigbarhet krever enhver tallgenerator en pålitelig kilde til tilfeldig seeding - et tilfeldig frø. Vanligvis brukes det som resultater av målinger av noen kaotiske fysiske prosesser. For eksempel svingninger i intensiteten av lysvibrasjoner eller registrering av radiofrekvent støy. Det ville være teknisk praktisk å bruke et slikt element av tilfeldighet (og hele maskinvaren PRNG) i en kompakt versjon, og ideelt sett gjøre det innebygd.

Intel har bygget (pseudo)tilfeldige tallgeneratorer inn i sine brikker siden slutten av nittitallet. Tidligere var deres natur analog. Tilfeldige utgangsverdier ble oppnådd på grunn av påvirkningen av fysiske prosesser som er vanskelige å forutsi - termisk støy og elektromagnetisk interferens. Analoge oscillatorer var relativt enkle å implementere som separate blokker, men vanskelige å integrere i nye kretser. Etter hvert som prosessen ble nedskalert, var det nødvendig med nye og tidkrevende kalibreringstrinn. I tillegg forverret en naturlig reduksjon i forsyningsspenningen signal-til-støy-forholdet i slike systemer. PRNG-er fungerte konstant og forbrukte en betydelig mengde energi, og operasjonshastigheten deres etterlot mye å være ønsket. Disse manglene la begrensninger på mulige bruksområder.

Ideen om en (pseudo)tilfeldig tallgenerator med en helt digital natur har lenge virket merkelig, om ikke absurd. Tross alt er tilstanden til enhver digital krets alltid strengt bestemt og forutsigbar. Hvordan introdusere det nødvendige elementet av tilfeldighet i det hvis det ikke er noen analoge komponenter?

Forsøk på å oppnå ønsket kaos basert kun på digitale elementer har blitt gjort av Intel-ingeniører siden 2008 og ble kronet med suksess etter et par års forskning. Verket ble presentert i 2010 på VLSI Summer Symposium i Honolulu og produserte en liten revolusjon innen moderne kryptografi. For første gang ble en heldigital, rask og energieffektiv PRNG implementert i masseproduserte universelle prosessorer.

Dens første arbeidstittel var Bull Mountain. Den ble deretter omdøpt til Secure Key. Denne kryptografiske blokken består av tre grunnleggende moduler. Den første genererer en strøm av tilfeldige biter med en relativt lav hastighet på 3 Gbps. Den andre evaluerer variansen deres og kombinerer dem til blokker på 256 biter, som brukes som kilder til tilfeldig seeding. Etter en rekke matematiske prosedyrer genereres en strøm av tilfeldige tall 128 bit lange i den tredje blokken med høyere hastighet. Basert på dem, ved å bruke den nye RdRand-instruksjonen, om nødvendig, opprettes tilfeldige tall med ønsket lengde og plasseres i et spesielt utpekt register: 16, 32 eller 64 biter, som til slutt blir overført til programmet som ba om dem.

Feil i (pseudo)tilfeldige tallgeneratorer og deres ondsinnede modifikasjoner fører til tap av tillit til populære kryptografiske produkter og selve sertifiseringsprosedyren deres.

På grunn av den eksepsjonelle betydningen av PRNG for ethvert kryptografisk system, har Secure Key innebygde tester for å verifisere kvaliteten på de genererte tilfeldige tallene, og ledende ekspertgrupper har vært involvert i sertifiseringen. Hele enheten oppfyller kriteriene til ANSI X9.82 og NIST SP 800-90 standarder. I tillegg er den sertifisert til nivå 2 i henhold til NIST FIPS 140-2 krav.

Fram til nå har det meste av arbeidet med maskinvare-trojanere vært hypotetisk. Forskere har foreslått ytterligere design av små logiske kretser som på en eller annen måte bør legges til eksisterende brikker. For eksempel presenterte Samuel Talmadge King og hans medforfattere på LEET-08-konferansen en variant av en maskinvare-trojaner for sentralprosessoren som ville gi full kontroll over systemet til en ekstern angriper. Bare ved å sende en UDP-pakke konfigurert på en bestemt måte, kan man gjøre endringer på en slik datamaskin og få ubegrenset tilgang til minnet. Imidlertid er ytterligere logiske kretser relativt enkle å identifisere ved hjelp av mikroskopi, for ikke å nevne spesialiserte metoder for å søke etter slike modifikasjoner. Beckers gruppe tok en annen rute:

I stedet for å legge til ytterligere kretser til brikken, implementerte vi funksjonene våre på maskinvarenivå ved ganske enkelt å endre driften til noen av mikrotransistorene som allerede er på den. Etter en rekke forsøk var vi i stand til selektivt å endre polariteten til dopemidlet og gjøre de ønskede modifikasjonene til driften av hele kryptografiske enheten. Derfor viste vår familie av trojanere seg å være motstandsdyktig mot de fleste deteksjonsmetoder, inkludert skannemikroskopi og sammenligning med referansebrikker.»

Som et resultat av arbeidet som ble utført, begynte den tredje Secure Key-blokken i stedet for unike tall på 128 biter å samle sekvenser der bare 32 biter var forskjellige. Kryptografiske nøkler laget av slike pseudo-tilfeldige tall er svært forutsigbare og kan åpnes i løpet av få minutter på en vanlig hjemmedatamaskin.

Den selektive endringen i elektrisk ledningsevne som ligger til grunn for maskinvaren ble implementert i to versjoner:

digital etterbehandling av signaler fra Intel Secure Key;
bruk på en sidekanal ved å bruke tabellbitsubstitusjonsmetoden (Substitusjonsboks).

Sistnevnte metode er mer universell og kan brukes med mindre modifikasjoner på andre brikker.

Muligheten til å bruke den innebygde PRNG gjennom RdRand-instruksjonen dukket først opp i Intel Ivy Bridge-arkitekturprosessorer. Intel har skrevet detaljerte guider for programmerere. De snakker om metoder for optimal implementering av kryptografiske algoritmer og gir en lenke til en beskrivelse av prinsippene for drift av Secure Key. I lang tid var innsatsen til sikkerhetseksperter rettet mot å finne sårbarheter i programvaren. Kanskje for første gang viste skjult interferens på maskinvarenivå seg å være en mye farligere og fullstendig gjennomførbar teknologi.