Som du ved, er koden, der udføres i enklaven, alvorligt begrænset i sin funktionalitet. Den kan ikke foretage systemopkald. Den kan ikke udføre I/O-operationer. Den kender ikke basisadressen for værtsapplikationens kodesegment. Den kan ikke jmp eller kalde værtsapplikationskode. Den har ingen idé om adresserummets struktur, der styrer værtsapplikationen (f.eks. hvilke sider der er kortlagt, eller hvilken slags data der er placeret på disse sider). Det kan ikke bede operativsystemet om at tilknytte et stykke af værtsapplikationens hukommelse til det (for eksempel gennem /proc/pid/maps). Naive forsøg på blindt at læse et vilkårligt hukommelsesområde i en værtsapplikation, for ikke at nævne forsøg på at skrive, vil før eller siden (mest sandsynligt førstnævnte) føre til tvungen afslutning af enklaveprogrammet. Dette sker, når det virtuelle adresseområde, som enklaven anmoder om, er utilgængeligt for værtsapplikationen.
Givet sådanne barske realiteter, vil en virusskribent være i stand til at bruge SGX-enklaver til at nå sine ondsindede mål?
Baseret på alt ovenstående er det generelt accepteret, at en enklave kun er i stand til at betjene værtsapplikationen, og at enklaven ikke kan udøve sit eget initiativ, herunder ondsindede. Det betyder, at enklaver ikke har nogen praktisk værdi for virusskribenter. Denne forhastede antagelse er en af grundene til, at SGX-beskyttelse er asymmetrisk: værtsapplikationskode kan ikke få adgang til enklavehukommelse, mens enklavekode kan læse og skrive til enhver værtsapplikationshukommelsesadresse.
Derfor, hvis ondsindet enklavekode var i stand til at foretage vilkårlige systemkald på vegne af værtsapplikationen, eksekvere vilkårlig kode på dens vegne, scanne værtsapplikationens hukommelse og finde misbrugelige ROP-kæder i den, kunne den overtage fuldstændig kontrol over værtsapplikationen, i stealth mode. Det kan ikke kun stjæle og kryptere brugerfiler, men også handle på vegne af brugeren. Send for eksempel phishing-e-mails på hans vegne eller udføre DoS-angreb. Uden frygt for selv de mest moderne beskyttelsesmekanismer, såsom stakkanariefugle og adresserensning.
Vi viser dig et par hacks, som angribere bruger til at overvinde begrænsningerne beskrevet ovenfor for at udnytte SGX til deres egne ondsindede formål: ROP-angreb. Enten for at udføre vilkårlig kode forklædt som en værtsapplikationsproces (svarende til procesudhulning, som ofte bruges af malware), eller for at skjule en færdiglavet malware (for at redde dens malware fra forfølgelse af antivirus og andre forsvarsmekanismer).
Hack for at undersøge adresser for at se, om de kan læses
Da enklaven ikke ved, hvilke områder af det virtuelle adresserum der er tilgængelige for værtsapplikationen, og da enklaven er tvunget til at afslutte, når den forsøger at læse en utilgængelig adresse, står angriberen over for opgaven at finde en måde at fejle- tolerant scanne adresserummet. Find en måde at kortlægge tilgængelige virtuelle adresser på. Skurken løser dette problem ved at misbruge Intels TSX-teknologi. Bruger en af TSX's bivirkninger: Hvis hukommelsesadgangsfunktionen er placeret i en TSX-transaktion, undertrykkes undtagelser, der opstår ved adgang til ugyldige adresser, af TSX uden at nå operativsystemet. Hvis der gøres et forsøg på at få adgang til en ugyldig hukommelsesadresse, afbrydes kun den aktuelle transaktion, ikke hele enklaveprogrammet. At. TSX giver en enklave mulighed for sikker adgang til enhver adresse inde fra en transaktion - uden risiko for kollaps.
Hvis den angivne adresse er tilgængelig værtsapplikation, er TSX-transaktionen oftest vellykket. I sjældne tilfælde kan det mislykkes på grund af ydre påvirkninger såsom afbrydelser (såsom afbrydelser i skemalæggeren), cache-udsættelser eller samtidig ændring af en hukommelsesplacering ved flere processer. I disse sjældne tilfælde returnerer TSX en fejlkode, der indikerer, at fejlen er midlertidig. I disse tilfælde skal du blot genstarte transaktionen.
Hvis den angivne adresse er ikke tilgængelig værtsapplikation, undertrykker TSX undtagelsen, der opstod (operativsystemet er ikke underrettet) og afbryder transaktionen. En fejlkode returneres til enklavekoden, så den kan reagere på, at transaktionen er blevet annulleret. Disse fejlkoder angiver, at den pågældende adresse ikke er tilgængelig for værtsapplikationen.
Denne manipulation af TSX inde fra enklaven har en god funktion for skurken: da de fleste hardware-ydelsestællere ikke opdateres på det tidspunkt, hvor enklavekoden udføres, er det umuligt at spore TSX-transaktioner udført inde i enklaven. Således forbliver ondsindet manipulation af TSX fuldstændig usynlig for operativsystemet.
Da ovennævnte hack desuden ikke er afhængig af systemopkald, kan det hverken opdages eller forhindres ved blot at blokere systemopkald; hvilket normalt giver et positivt resultat i kampen mod æggejagt.
Skurken bruger hacket beskrevet ovenfor til at søge i værtsapplikationskoden efter gadgets, der er egnede til at danne en ROP-kæde. Samtidig behøver han ikke undersøge alle adresser. Det er nok at undersøge én adresse fra hver side i det virtuelle adresserum. Det tager omkring 16 minutter at sondere alle 45 gigabyte hukommelse (på en Intel i7-6700K). Som et resultat modtager skurken en liste over eksekverbare sider, der er egnede til at konstruere en ROP-kæde.
Hack til at undersøge adresser for skrivbarhed
For at udføre en enklaveversion af et ROP-angreb skal en angriber være i stand til at søge efter skrivbare ubrugte hukommelsesområder i værtsapplikationen. Angriberen bruger disse hukommelsesplaceringer til at injicere en falsk stakramme og til at injicere en nyttelast (shellkode). Den nederste linje er, at en ondsindet enklave ikke er i stand til at kræve, at værtsapplikationen tildeler hukommelse til sig selv, men i stedet kan misbruge hukommelse, der allerede er allokeret af værtsapplikationen. Hvis det selvfølgelig lykkes ham at finde sådanne områder uden at kollapse enklaven.
Skurken udfører denne søgning ved at udnytte en anden bivirkning af TSX. Først, som i det foregående tilfælde, undersøger den adressen for dens eksistens og kontrollerer derefter, om den side, der svarer til denne adresse, er skrivbar. For at gøre dette bruger skurken følgende hack: han placerer en skrivefunktion i en TSX-transaktion, og efter at den er gennemført, men før den er fuldført, afbryder han transaktionen med magt (eksplicit afbryde).
Ved at se på returkoden fra en TSX-transaktion forstår angriberen, om den er skrivbar. Hvis det er en "eksplicit abort", forstår skurken, at optagelsen ville have været vellykket, hvis han havde fulgt op på den. Hvis siden er skrivebeskyttet, ender transaktionen med en anden fejl end "eksplicit afbrydelse".
Denne manipulation af TSX har en anden funktion, der er rart for skurken (udover umuligheden af at spore gennem hardware-ydeevnetællere): da alle hukommelsesskrivekommandoer kun udføres, hvis transaktionen lykkes, sikrer det at tvinge transaktionen til at fuldføre, at den sonderede hukommelsescelle forbliver uændret.
Hack for at omdirigere kontrolflow
Når man udfører et ROP-angreb fra en enklave - i modsætning til traditionelle ROP-angreb - kan angriberen få kontrol over RIP-registret uden at udnytte nogen fejl i det angrebne program (bufferoverløb eller lignende). En angriber kan direkte overskrive værdien af RIP-registeret, der er gemt på stakken. Det kan især erstatte værdien af dette register med sin egen ROP-kæde.
Men hvis ROP-kæden er lang, kan overskrivning af en stor del af værtsapplikationens stak føre til datakorruption og uventet programadfærd. Skurken, der søger at udføre sit angreb i det skjulte, er ikke tilfreds med denne situation. Derfor skaber den en falsk midlertidig stabelramme til sig selv og gemmer sin ROP-kæde i den. Den falske stakramme er placeret på en tilfældig skrivbar hukommelsesplacering, og efterlader den rigtige stak intakt.
Hvad giver de tre hacks, der er nævnt ovenfor, skurken?
(1) Først den ondsindede enklave igennem hack for at undersøge adresser for at se, om de kan læses, – søger i værtsapplikationen for misbrugelige ROP-gadgets.
(2) Derefter ved hack til at undersøge adresser for skrivbarhed, – en ondsindet enklave identificerer områder i værtsapplikationens hukommelse, der er egnede til at injicere en nyttelast.
(3) Dernæst opretter enklaven en ROP-kæde fra de gadgets, der blev opdaget i trin (1), og injicerer denne kæde i værtsapplikationsstakken.
(4) Endelig, når værtsapplikationen støder på den ROP-kæde, der blev oprettet i det foregående trin, begynder den ondsindede nyttelast at eksekvere - med værtsapplikationens privilegier og evnen til at foretage systemkald.
Hvordan en skurk bruger disse hacks til at skabe ranzowari
Efter at værtsapplikationen har overført kontrol til enklaven gennem en af ECALL'erne (uden at have mistanke om, at denne enklave er ondsindet), søger den ondsindede enklave efter ledig plads i værtsapplikationens hukommelse for at injicere kode (der tages som ledige rum disse cellesekvenser der er fyldt med nuller). Så igennem hack for at undersøge adresser for at se, om de kan læses, – enklaven søger efter eksekverbare sider i værtsapplikationen og genererer en ROP-kæde, der opretter en ny fil med navnet "RANSOM" i den aktuelle mappe (i et rigtigt angreb krypterer enklaven eksisterende brugerfiler) og viser en løsesum-meddelelse. Samtidig tror værtsapplikationen naivt på, at enklaven blot tilføjer to tal. Hvordan ser det ud i koden?
For at lette opfattelsen, lad os introducere nogle mnemonics gennem definitionerne:
Vi gemmer de originale værdier af RSP- og RBP-registrene for at genoprette normal drift af værtsapplikationen efter at have udført nyttelasten:
Vi leder efter en passende stackramme (se koden fra afsnittet "hack til omdirigering af kontrolflow").
Find passende ROP-gadgets:
Sådan finder du et sted at indsprøjte nyttelasten:
Vi bygger en ROP-kæde:
Det er sådan, Intels SGX-teknologi, designet til at modvirke ondsindede programmer, udnyttes af skurke til at opnå modsatte mål.
Kilde: www.habr.com