Zoals u weet, is de functionaliteit van de code die in de enclave wordt uitgevoerd ernstig beperkt. Er kunnen geen systeemoproepen worden gedaan. Het kan geen I/O-bewerkingen uitvoeren. Het kent het basisadres van het codesegment van de hosttoepassing niet. Het kan de hosttoepassingscode niet jmpen of aanroepen. Het heeft geen idee van de adresruimtestructuur die de hostapplicatie bestuurt (bijvoorbeeld welke pagina's in kaart worden gebracht of wat voor soort gegevens zich op die pagina's bevinden). Het kan het besturingssysteem niet vragen om een deel van het geheugen van de hosttoepassing eraan toe te wijzen (bijvoorbeeld via /proc/pid/maps). Naïeve pogingen om blindelings een willekeurig geheugengebied van een hostapplicatie te lezen, om nog maar te zwijgen van pogingen om te schrijven, zullen vroeg of laat (hoogstwaarschijnlijk de eerste) leiden tot de gedwongen beëindiging van het enclaveprogramma. Dit gebeurt wanneer het door de enclave aangevraagde virtuele adresruimtegebied niet toegankelijk is voor de hosttoepassing.
Zal een virusschrijver, gegeven deze harde realiteit, SGX-enclaves kunnen gebruiken om zijn kwaadaardige doelen te bereiken?
Op basis van al het bovenstaande wordt algemeen aanvaard dat een enclave alleen de hosttoepassing kan bedienen en dat de enclave geen eigen initiatief kan nemen, ook niet van kwaadwillende. Dit betekent dat enclaves geen praktische waarde hebben voor virusschrijvers. Deze overhaaste veronderstelling is een van de redenen waarom de SGX-bescherming asymmetrisch is: de code van de hosttoepassing heeft geen toegang tot het enclavegeheugen, terwijl de enclavecode kan lezen en schrijven naar elk geheugenadres van de hosttoepassing.
Als kwaadaardige enclavecode in staat zou zijn om willekeurige systeemoproepen uit te voeren namens de hostapplicatie, willekeurige code namens de hostapplicatie uit te voeren, het geheugen van de hostapplicatie te scannen en daarin misbruikbare ROP-ketens te vinden, zou deze de volledige controle over de hostapplicatie kunnen overnemen. sluipmodus. Het kan niet alleen gebruikersbestanden stelen en versleutelen, maar ook namens de gebruiker optreden. Verstuur bijvoorbeeld namens hem phishing-e-mails of voer DoS-aanvallen uit. Zonder angst voor zelfs de modernste beschermingsmechanismen, zoals stapelkanaries en adressanering.
We laten u enkele hacks zien die aanvallers gebruiken om de hierboven beschreven beperkingen te omzeilen en misbruik te maken van SGX voor hun eigen kwaadaardige doeleinden: ROP-aanvallen. Hetzij om willekeurige code uit te voeren, vermomd als een hosttoepassingsproces (vergelijkbaar met procesuitholling, dat vaak door malware wordt gebruikt), hetzij om kant-en-klare malware te vermommen (om de malware te behoeden voor vervolging door antivirusprogramma's en andere verdedigingsmechanismen).
Hack voor het onderzoeken van adressen om te zien of ze kunnen worden gelezen
Omdat de enclave niet weet welke delen van de virtuele adresruimte toegankelijk zijn voor de hosttoepassing, en omdat de enclave gedwongen wordt te stoppen wanneer hij probeert een ontoegankelijk adres te lezen, wordt de aanvaller geconfronteerd met de taak een manier te vinden om fouten te herstellen. scan de adresruimte tolerant. Vind een manier om beschikbare virtuele adressen in kaart te brengen. De slechterik lost dit probleem op door misbruik te maken van Intel's TSX-technologie. Maakt gebruik van een van de bijwerkingen van TSX: als de geheugentoegangsfunctie in een TSX-transactie wordt geplaatst, worden uitzonderingen die voortvloeien uit het verkrijgen van toegang tot ongeldige adressen door TSX onderdrukt zonder het besturingssysteem te bereiken. Als er wordt geprobeerd toegang te krijgen tot een ongeldig geheugenadres, wordt alleen de huidige transactie afgebroken, niet het hele enclaveprogramma. Dat. Met TSX kan een enclave veilig toegang krijgen tot elk adres vanuit een transactie - zonder het risico van instorting.
als het opgegeven adres beschikbaar is host-applicatie is de TSX-transactie meestal succesvol. In zeldzame gevallen kan het mislukken als gevolg van externe invloeden zoals interrupts (zoals planner-interrupts), cache-uitzettingen of gelijktijdige wijziging van een geheugenlocatie door meerdere processen. In deze zeldzame gevallen retourneert de TSX een foutcode die aangeeft dat de fout tijdelijk is. In deze gevallen hoeft u alleen maar de transactie opnieuw te starten.
als het opgegeven adres is niet beschikbaar hosttoepassing onderdrukt TSX de opgetreden uitzondering (het besturingssysteem wordt niet op de hoogte gesteld) en breekt de transactie af. Er wordt een foutcode teruggestuurd naar de enclavecode zodat deze kan reageren op het feit dat de transactie is geannuleerd. Deze foutcodes geven aan dat het betreffende adres niet beschikbaar is voor de hosttoepassing.
Deze manipulatie van TSX vanuit de enclave heeft een leuke eigenschap voor de slechterik: aangezien de meeste hardwareprestatietellers niet worden bijgewerkt op het moment dat de enclavecode wordt uitgevoerd, is het onmogelijk om TSX-transacties te volgen die binnen de enclave worden uitgevoerd. Zo blijft kwaadwillige manipulatie van de TSX volledig onzichtbaar voor het besturingssysteem.
Omdat de bovenstaande hack bovendien niet afhankelijk is van systeemoproepen, kan deze niet worden gedetecteerd of voorkomen door eenvoudigweg systeemoproepen te blokkeren; wat meestal een positief resultaat oplevert in de strijd tegen de eierenjacht.
De slechterik gebruikt de hierboven beschreven hack om in de hostapplicatiecode te zoeken naar gadgets die geschikt zijn voor het vormen van een ROP-keten. Tegelijkertijd hoeft hij niet elk adres te onderzoeken. Het is voldoende om één adres op elke pagina van de virtuele adresruimte te onderzoeken. Het onderzoeken van alle 16 gigabytes aan geheugen duurt ongeveer 45 minuten (op een Intel i7-6700K). Als gevolg hiervan ontvangt de slechterik een lijst met uitvoerbare pagina's die geschikt zijn voor het construeren van een ROP-keten.
Hack voor het onderzoeken van adressen op schrijfbaarheid
Om een enclaveversie van een ROP-aanval uit te voeren, moet een aanvaller kunnen zoeken naar beschrijfbare ongebruikte geheugengebieden van de hostapplicatie. De aanvaller gebruikt deze geheugenlocaties om een nep-stackframe te injecteren en een payload (shellcode) te injecteren. Het komt erop neer dat een kwaadaardige enclave niet van de hostapplicatie kan eisen dat hij geheugen voor zichzelf toewijst, maar in plaats daarvan geheugen kan misbruiken dat al door de hostapplicatie is toegewezen. Als hij er natuurlijk in slaagt zulke gebieden te vinden zonder de enclave in te laten storten.
De slechterik voert deze zoektocht uit door gebruik te maken van een andere bijwerking van TSX. Eerst onderzoekt het, net als in het vorige geval, of het adres bestaat, en vervolgens wordt gecontroleerd of de pagina die met dit adres correspondeert beschrijfbaar is. Om dit te doen gebruikt de slechterik de volgende hack: hij plaatst een schrijffunctie in een TSX-transactie, en nadat deze is voltooid, maar voordat deze is voltooid, breekt hij de transactie met geweld af (explicit abort).
Door naar de retourcode van een TSX-transactie te kijken, begrijpt de aanvaller of deze beschrijfbaar is. Als het om een ‘expliciete abortus’ gaat, begrijpt de slechterik dat de opname succesvol zou zijn geweest als hij ermee was doorgegaan. Als de pagina alleen-lezen is, eindigt de transactie met een andere fout dan ‘expliciet afbreken’.
Deze manipulatie van TSX heeft nog een ander kenmerk dat leuk is voor de slechterik (naast de onmogelijkheid om de hardwareprestatietellers te volgen): aangezien alle geheugenschrijfopdrachten alleen worden uitgevoerd als de transactie succesvol is, zorgt het forceren van de transactie ervoor dat de onderzochte geheugencel blijft onveranderd.
Hack om de controlestroom om te leiden
Bij het uitvoeren van een ROP-aanval vanuit een enclave kan de aanvaller - in tegenstelling tot traditionele ROP-aanvallen - controle krijgen over het RIP-register zonder misbruik te maken van eventuele bugs in het aangevallen programma (bufferoverflow of iets dergelijks). Een aanvaller kan de waarde van het RIP-register dat op de stapel is opgeslagen, rechtstreeks overschrijven. In het bijzonder kan het de waarde van dit register vervangen door zijn eigen ROP-keten.
Als de ROP-keten echter lang is, kan het overschrijven van een groot deel van de stack van de hosttoepassing leiden tot gegevensbeschadiging en onverwacht programmagedrag. De slechterik, die zijn aanval heimelijk probeert uit te voeren, is niet tevreden met deze gang van zaken. Daarom creëert het een nep-tijdelijk stapelframe voor zichzelf en slaat het de ROP-keten daarin op. Het nep-stapelframe wordt op een willekeurige beschrijfbare geheugenlocatie geplaatst, waardoor de echte stapel intact blijft.
Wat geven de drie hierboven genoemde hacks de slechterik?
(1) Eerst moet de kwaadaardige enclave er doorheen hack voor het onderzoeken van adressen om te zien of ze kunnen worden gelezen, – zoekt in de hostapplicatie naar misbruikbare ROP-gadgets.
(2) Vervolgens door hack voor het onderzoeken van adressen op schrijfbaarheid, – een kwaadaardige enclave identificeert gebieden in het geheugen van de hostapplicatie die geschikt zijn voor het injecteren van een payload.
(3) Vervolgens creëert de enclave een ROP-keten van de gadgets die in stap (1) zijn ontdekt en injecteert deze keten in de hostapplicatiestack.
(4) Ten slotte, wanneer de hostapplicatie de ROP-keten tegenkomt die in de vorige stap is gemaakt, begint de kwaadaardige payload te worden uitgevoerd - met de privileges van de hostapplicatie en de mogelijkheid om systeemaanroepen te doen.
Hoe een slechterik deze hacks gebruikt om ranzowari te maken
Nadat de hosttoepassing de controle overdraagt aan de enclave via een van de ECALL's (zonder te vermoeden dat deze enclave kwaadaardig is), zoekt de kwaadwillende enclave naar vrije ruimte in het geheugen van de hosttoepassing om code te injecteren (waarbij de reeksen cellen als vrije ruimten worden gebruikt). dat gevuld is met nullen). Dan door hack voor het onderzoeken van adressen om te zien of ze kunnen worden gelezen, – de enclave zoekt naar uitvoerbare pagina's in de hosttoepassing en genereert een ROP-keten die een nieuw bestand met de naam “RANSOM” aanmaakt in de huidige map (bij een echte aanval codeert de enclave bestaande gebruikersbestanden) en geeft een losgeldbericht weer. Tegelijkertijd gelooft de hostapplicatie naïef dat de enclave eenvoudigweg twee cijfers optelt. Hoe ziet dit eruit in code?
Laten we, voor het gemak van de waarneming, enkele geheugensteuntjes introduceren via de definities:
We bewaren de originele waarden van de RSP- en RBP-registers om de normale werking van de hostapplicatie te herstellen na het uitvoeren van de payload:
We zijn op zoek naar een geschikt stapelframe (zie de code uit de sectie “hack voor het omleiden van de controlestroom”).
Geschikte ROP-gadgets vinden:
Een plaats zoeken om de lading te injecteren:
Wij bouwen een ROP-keten:
Dit is hoe Intel's SGX-technologie, ontworpen om kwaadaardige programma's tegen te gaan, door schurken wordt uitgebuit om tegengestelde doelen te bereiken.
Bron: www.habr.com