Som du vet, er koden som kjøres i enklaven alvorlig begrenset i sin funksjonalitet. Den kan ikke foreta systemanrop. Den kan ikke utføre I/O-operasjoner. Den kjenner ikke basisadressen til vertsapplikasjonens kodesegment. Den kan ikke jmp eller ringe vertsapplikasjonskode. Den har ingen anelse om adresseromstrukturen som styrer vertsapplikasjonen (for eksempel hvilke sider som er kartlagt eller hva slags data som er plassert på disse sidene). Den kan ikke be operativsystemet om å tilordne en del av vertsapplikasjonens minne til det (for eksempel gjennom /proc/pid/maps). Naive forsøk på å blindt lese en vilkårlig minneregion i en vertsapplikasjon, for ikke å nevne forsøk på å skrive, vil før eller siden (mest sannsynlig førstnevnte) føre til tvungen avslutning av enklaveprogrammet. Dette skjer når det virtuelle adresseområdet som er forespurt av enklaven, er utilgjengelig for vertsapplikasjonen.
Gitt slike harde realiteter, vil en virusskribent være i stand til å bruke SGX-enklaver for å oppnå sine ondsinnede mål?
Basert på alt det ovennevnte er det generelt akseptert at en enklave bare er i stand til å betjene vertsapplikasjonen, og at enklaven ikke kan utøve eget initiativ, inkludert ondsinnede. Dette betyr at enklaver ikke har noen praktisk verdi for virusforfattere. Denne forhastede antagelsen er en av grunnene til at SGX-beskyttelse er asymmetrisk: vertsapplikasjonskode kan ikke få tilgang til enklaveminne, mens enklavekode kan lese og skrive til hvilken som helst vertsapplikasjonsminneadresse.
Derfor, hvis ondsinnet enklavekode var i stand til å foreta vilkårlige systemanrop på vegne av vertsapplikasjonen, kjøre vilkårlig kode på dens vegne, skanne vertsapplikasjonens minne og finne misbrukbare ROP-kjeder i den, kan den ta fullstendig kontroll over vertsapplikasjonen, i snikemodus. Den kan ikke bare stjele og kryptere brukerfiler, men også handle på vegne av brukeren. Send for eksempel phishing-e-poster på hans vegne eller utføre DoS-angrep. Uten frykt for selv de mest moderne beskyttelsesmekanismene, som stablekanarifugler og adresserensing.
Vi viser deg noen hacks som angripere bruker for å overvinne begrensningene beskrevet ovenfor for å dra nytte av SGX til sine egne ondsinnede formål: ROP-angrep. Enten for å utføre vilkårlig kode forkledd som en vertsapplikasjonsprosess (ligner på prosessuthuling, som ofte brukes av skadelig programvare), eller for å skjule en ferdiglaget skadelig programvare (for å redde skadelig programvare fra forfølgelse av antivirus og andre forsvarsmekanismer).
Hack for å undersøke adresser for å se om de kan leses
Siden enklaven ikke vet hvilke områder av det virtuelle adresserommet som er tilgjengelig for vertsapplikasjonen, og siden enklaven blir tvunget til å avsluttes når han forsøker å lese en utilgjengelig adresse, står angriperen overfor oppgaven med å finne en måte å feile- skanne adresseområdet tolerant. Finn en måte å kartlegge tilgjengelige virtuelle adresser på. Skurken løser dette problemet ved å misbruke Intels TSX-teknologi. Bruker en av TSXs bivirkninger: hvis minnetilgangsfunksjonen er plassert i en TSX-transaksjon, vil unntak som oppstår fra tilgang til ugyldige adresser undertrykkes av TSX uten å nå operativsystemet. Hvis det gjøres et forsøk på å få tilgang til en ugyldig minneadresse, blir bare den gjeldende transaksjonen avbrutt, ikke hele enklaveprogrammet. At. TSX lar en enklave sikkert få tilgang til hvilken som helst adresse fra en transaksjon - uten risiko for kollaps.
Hvis den angitte adressen er tilgjengelig vertsapplikasjon, er TSX-transaksjonen oftest vellykket. I sjeldne tilfeller kan det mislykkes på grunn av ytre påvirkninger som avbrudd (som planleggeravbrudd), cache-utkastelser eller samtidig modifikasjon av en minneplassering ved flere prosesser. I disse sjeldne tilfellene returnerer TSX en feilkode som indikerer at feilen er midlertidig. I disse tilfellene trenger du bare å starte transaksjonen på nytt.
Hvis den angitte adressen er utilgjengelig vertsapplikasjon, undertrykker TSX unntaket som skjedde (operativsystemet er ikke varslet) og avbryter transaksjonen. En feilkode returneres til enklavekoden slik at den kan reagere på at transaksjonen er kansellert. Disse feilkodene indikerer at den aktuelle adressen ikke er tilgjengelig for vertsapplikasjonen.
Denne manipulasjonen av TSX fra innsiden av enklaven har en fin funksjon for skurken: siden de fleste maskinvareytelsestellere ikke er oppdatert på det tidspunktet enklavekoden utføres, er det umulig å spore TSX-transaksjoner utført inne i enklaven. Dermed forblir ondsinnet manipulasjon av TSX helt usynlig for operativsystemet.
I tillegg, siden hacket ovenfor ikke er avhengig av noen systemanrop, kan det verken oppdages eller forhindres ved å blokkere systemanrop; som vanligvis gir et positivt resultat i kampen mot eggjakt.
Skurken bruker hacket beskrevet ovenfor for å søke i vertsapplikasjonskoden etter gadgets som er egnet for å danne en ROP-kjede. Samtidig trenger han ikke å undersøke hver adresse. Det er nok å undersøke én adresse fra hver side i det virtuelle adresserommet. Å sondere alle 16 gigabyte med minne tar omtrent 45 minutter (på en Intel i7-6700K). Som et resultat mottar skurken en liste over kjørbare sider som er egnet for å konstruere en ROP-kjede.
Hack for å undersøke adresser for skrivbarhet
For å utføre en enklaversjon av et ROP-angrep, må en angriper kunne søke etter skrivbare ubrukte minneområder i vertsapplikasjonen. Angriperen bruker disse minnestedene til å injisere en falsk stabelramme og til å injisere en nyttelast (shellkode). Poenget er at en ondsinnet enklave ikke er i stand til å kreve at vertsapplikasjonen tildeler minne til seg selv, men kan i stedet misbruke minne som allerede er tildelt av vertsapplikasjonen. Hvis han selvfølgelig klarer å finne slike områder uten å kollapse enklaven.
Skurken utfører dette søket ved å utnytte en annen bivirkning av TSX. Først, som i det forrige tilfellet, undersøker den adressen for dens eksistens, og sjekker deretter om siden som tilsvarer denne adressen er skrivbar. For å gjøre dette bruker skurken følgende hack: han plasserer en skrivefunksjon i en TSX-transaksjon, og etter at den er fullført, men før den er fullført, avbryter han transaksjonen med makt (eksplisitt avbryt).
Ved å se på returkoden fra en TSX-transaksjon forstår angriperen om den er skrivbar. Hvis det er en «eksplisitt abort», forstår skurken at innspillingen ville vært vellykket hvis han hadde fulgt opp. Hvis siden er skrivebeskyttet, ender transaksjonen med en annen feil enn "eksplisitt avbryt".
Denne manipulasjonen av TSX har en annen funksjon som er hyggelig for skurken (foruten umuligheten av å spore gjennom maskinvareytelsestellere): siden alle minneskrivekommandoer bare utføres hvis transaksjonen er vellykket, vil tvinge transaksjonen til å fullføre sikre at den undersøkte minnecellen forblir uendret.
Hack for å omdirigere kontrollflyten
Når du utfører et ROP-angrep fra en enklave - i motsetning til tradisjonelle ROP-angrep - kan angriperen få kontroll over RIP-registeret uten å utnytte noen feil i det angrepne programmet (bufferoverløp eller noe sånt). En angriper kan direkte overskrive verdien til RIP-registeret som er lagret på stabelen. Spesielt kan den erstatte verdien av dette registeret med sin egen ROP-kjede.
Men hvis ROP-kjeden er lang, kan overskriving av en stor del av vertsapplikasjonens stabel føre til datakorrupsjon og uventet programoppførsel. Skurken, som prøver å utføre angrepet sitt i det skjulte, er ikke fornøyd med denne tingenes tilstand. Derfor lager den en falsk midlertidig stabelramme for seg selv og lagrer ROP-kjeden i den. Den falske stabelrammen er plassert på et tilfeldig skrivbart minnested, og lar den virkelige stabelen være intakt.
Hva gir de tre hackene som er oppført ovenfor skurken?
(1) Først den ondsinnede enklaven gjennom hack for å undersøke adresser for å se om de kan leses, – søker i vertsapplikasjonen etter misbrukbare ROP-gadgets.
(2) Så ved hack for å undersøke adresser for skrivbarhet, – en ondsinnet enklave identifiserer områder i vertsapplikasjonens minne som er egnet for å injisere en nyttelast.
(3) Deretter lager enklaven en ROP-kjede fra gadgetene som ble oppdaget i trinn (1) og injiserer denne kjeden inn i vertsapplikasjonsstakken.
(4) Til slutt, når vertsapplikasjonen møter ROP-kjeden opprettet i forrige trinn, begynner den ondsinnede nyttelasten å kjøre - med privilegiene til vertsapplikasjonen og muligheten til å foreta systemanrop.
Hvordan en skurk bruker disse hackene til å lage ranzowari
Etter at vertsapplikasjonen overfører kontrollen til enklaven gjennom en av ECALL-ene (uten å mistenke at denne enklaven er ondsinnet), søker den ondsinnede enklaven etter ledig plass i minnet til vertsapplikasjonen for å injisere kode (tar som ledige rom disse cellesekvensene som er fylt med nuller). Så gjennom hack for å undersøke adresser for å se om de kan leses, – enklaven søker etter kjørbare sider i vertsapplikasjonen og genererer en ROP-kjede som lager en ny fil kalt "RANSOM" i gjeldende katalog (i et ekte angrep krypterer enklaven eksisterende brukerfiler) og viser en løsepengemelding. Samtidig tror vertsapplikasjonen naivt at enklaven ganske enkelt legger til to tall. Hvordan ser dette ut i koden?
For å lette oppfatningen, la oss introdusere noen mnemonics gjennom definisjonene:
Vi lagrer de opprinnelige verdiene til RSP- og RBP-registrene for å gjenopprette normal drift av vertsapplikasjonen etter å ha utført nyttelasten:
Vi ser etter en passende stabelramme (se koden fra avsnittet "hack for omdirigering av kontrollflyt").
Finne passende ROP-dingser:
Finne et sted å injisere nyttelasten:
Vi bygger en ROP-kjede:
Dette er hvordan Intels SGX-teknologi, designet for å motvirke ondsinnede programmer, utnyttes av skurker for å oppnå motsatte mål.
Kilde: www.habr.com