Een hulpmiddel voor het detecteren van metamorfe slimme contracten

Een kritieke veiligheidsaanname van Ethereum is dat slimme contractcode onveranderlijk is en daarom niet kan worden gewijzigd als deze eenmaal op de blockchain is geïmplementeerd. In de praktijk enkele slimme contracten wel veranderen – zelfs nadat ze zijn ingezet. Met een paar slimme trucs kun je metamorfe slimme contracten maken die “metamorfose” in iets anders – en door te begrijpen wat ze mogelijk maakt, kun je ze detecteren.

Metamorfe slimme contracten zijn veranderlijk, wat betekent dat ontwikkelaars de code erin kunnen wijzigen. Deze slimme contracten vormen een ernstig risico voor web3-gebruikers die hun vertrouwen stellen in code waarvan ze verwachten dat deze met absolute consistentie wordt uitgevoerd, vooral omdat slechte actoren dit vermogen om van vorm te veranderen kunnen misbruiken. Stel je een aanvaller voor die de techniek gebruikt om mensen die tokens inzetten in een slim contract waarvan ze niet beseffen dat het een metamorfose is. Aanvallen op basis van deze en soortgelijke premissen zouden oplichters kunnen uitrusten om op mensen te jagen en in het algemeen het vertrouwen in de volledige belofte van gedecentraliseerde systemen te ondermijnen.

Om te analyseren of een slim contract metamorfe eigenschappen bevat, Ik heb een simpele gebouwd Metamorfe contractdetector (geïnspireerd door en voortbouwend op het originele werk van Jason Carver, 0leeftijd en anderen). Iedereen kan de tool gebruiken om te controleren of een bepaald contract rode vlaggen vertoont die kunnen wijzen op de mogelijkheid van metamorfose. De methode is niet onfeilbaar: alleen omdat een slim contract een vlag laat zien, wil nog niet zeggen dat het noodzakelijkerwijs metamorf is; en dat het niet zo is, wil nog niet zeggen dat het veilig is. De checker biedt slechts een snelle eerste beoordeling van een contract macht metamorf zijn op basis van mogelijke indicatoren. 

Web3-gebruikers moeten zich op de hoogte stellen van de bedreigingen van metamorfe contracten, zodat ze kunnen uitkijken naar mogelijke aanvallen en deze kunnen vermijden. Portemonnees en blockchain-indexers kunnen helpen door gebruikers te waarschuwen voordat ze interactie hebben met een slim contract dat metamorfe eigenschappen kan bevatten. Deze tool is bedoeld om mensen zowel te informeren over deze potentiële dreiging... als om zich ertegen te verdedigen.

Metamorfe slimme contracten detecteren

De Metamorfe contractdetector Ik heb analyses gemaakt van zes eigenschappen die kunnen aangeven of een slim contract metamorf is.

1. 1. Werd een bekende metamorfosecode gebruikt om het contract te implementeren? Als bekende metamorfe bytecode – de lagere, virtuele machine-leesbare code die Ethereum slimme contracten, meestal geschreven in Solidity, veranderen in nadat ze zijn gecompileerd – verschijnt in een transactie voor de implementatie van een bepaald slim contract, dat is een grote rode vlag. In de volgende secties bespreken we zo'n voorbeeld van metamorfe bytecode ontwikkeld door 0age. Een belangrijk voorbehoud: er zijn potentieel ontelbare variaties van metamorfe bytecode, wat het detecteren van alle varianten moeilijk maakt. Door echter te scannen op bekende gevallen, elimineert de detector laaghangend fruit voor aanvallers die alleen maar bestaande voorbeelden kopiëren en plakken.
   2. Kan de slimme contractcode zichzelf vernietigen? Om de code in een contract te vervangen – een belangrijke stap bij het maken van een metamorfisch contract – moet een ontwikkelaar eerst de reeds bestaande code verwijderen. De enige manier om dit te doen is door gebruik te maken van de ZELFVERNIETIGING opcode, een commando dat precies doet hoe het klinkt: het wist alle code en opslagruimte op een bepaald contractadres. De aanwezigheid van zelfvernietigende code in een contract bewijst niet dat het metamorfisch is; het biedt echter een aanwijzing dat het contract macht wees metamorfisch en het is hoe dan ook de moeite waard om te weten of contracten waarop je vertrouwt zichzelf kunnen vernietigen.
   3. Roept het slimme contract code van elders op? Als het betreffende slimme contract zichzelf niet direct kan vernietigen, kan het zichzelf mogelijk nog steeds wissen met behulp van de DELEGATECALL opcode. Met deze opcode kan een slim contract dynamisch code laden en uitvoeren die zich in een ander slim contract bevindt. Zelfs als het slimme contract de SELFDESTRUCT-opcode niet bevat, kan het DELEGATECALL gebruiken om zelfvernietigende code ergens anders te laden. Hoewel de DELEGATECALL-functionaliteit niet direct aangeeft of een slim contract metamorfisch is, is het een mogelijke aanwijzing – en een potentieel beveiligingsprobleem – dat het vermelden waard is. Wees gewaarschuwd dat deze indicator het potentieel heeft om veel valse positieven te genereren. 
   4. Heeft een ander contract dit contract ingezet? Metamorfe contracten kunnen worden ingezet Slechts door andere slimme contracten. Dit komt omdat metamorfe contracten mogelijk worden gemaakt door een andere opcode, die alleen bruikbaar is voor andere slimme contracten, genaamd CREATE2. (We zullen CREATE2 bespreken – hoe het werkt en waarom het ertoe doet – meer in een latere sectie.) Deze eigenschap is een van de minst opvallende indicatoren van mogelijke metamorfose; het is een noodzakelijke maar onvoldoende voorwaarde. Scannen op deze eigenschap levert waarschijnlijk veel valse positieven op, maar het is waardevolle informatie om te weten, omdat het argwaan kan wekken en een reden kan zijn om een ​​contract verder te onderzoeken, vooral als het slimme contract de hierna beschreven opcode bevat.
   5. Bevat het Deployer-contract de CREATE2-opcode? Zoals hierboven vermeld, is inzet via CREATE2 een essentiële voorwaarde voor metamorfose. Als een implementatiecontract de CREATE2-opcode bevat, kan dit erop duiden dat het CREATE2 heeft gebruikt om het betreffende contract te implementeren. Als de exploitant inderdaad CREATE2 heeft gebruikt om het genoemde contract in te zetten, betekent dat niet dat het contract noodzakelijkerwijs een metamorfose is, maar wel dat het macht metamorf zijn en het kan verstandig zijn om voorzichtig te werk te gaan en verder te onderzoeken. Nogmaals, pas op voor valse positieven: CREËER2 heeft er genoeg van legitiem gebruik, inclusief versterking "Laag 2" schaaloplossingen en het gemakkelijker maken om slimme contractportefeuilles te maken die web3 kunnen verbeteren onboarding van gebruikers en opties voor sleutelherstel.
   6. Is de code veranderd? Dit is de meest voor de hand liggende vertelling, maar het zal pas verschijnen nadat een metamorf contract al is veranderd. Als de code-hash van het slimme contract – een unieke, cryptografische identificatie – anders is dan toen het contract voor het eerst werd geïmplementeerd, is de code waarschijnlijk verwijderd, vervangen of gewijzigd. Als de hashes niet meer overeenkomen, is er iets aan de code veranderd en kan het contract metamorf zijn. Deze vlag is de zekerste indicator van metamorfose, maar het helpt niet om morphing te voorspellen of te voorkomen, omdat het alleen controleert of het al is gebeurd.

Naast het bouwen van een eenvoudige opdrachtregeltool voor de Metamorphic Contract Detector, heb ik enkele voorbeelden van slimme contracten gebouwd die een zwendel metamorfisch contract-staking-scenario demonstreren, dat ik in de volgende sectie beschrijf. Hierin is alle code beschikbaar GitHub-repository. 

Hoe een kwaadwillende metamorfe contracten kan gebruiken om geld van mensen te stelen

Hier is hoe iemand een metamorfisch slim contract kan gebruiken als onderdeel van een zwendel. 

Ten eerste is er de setup-fase. De aanvaller implementeert een slim contract op een specifiek adres op de blockchain met behulp van twee tools: metamorfe bytecode en de CREATE2 opcode. (We zullen later op beide concepten ingaan.) De metamorfe bytecode doet dan wat de naam doet vermoeden en 'morphs'. Hier verandert het in een uitzetten contract waar gebruikers ERC-20-tokens kunnen inzetten. (Nogmaals, we zullen de details van deze morphing-truc later bespreken. Beloofd!)

Vervolgens komt het aas en de schakelaar. Nietsvermoedende gebruikers zetten hun tokens in dit contract, gelokt door de mogelijkheid om een ​​opbrengst of een ander voordeel te verdienen. De aanvaller verwijdert vervolgens alle uitzetcode en "status" - blockchain-opslag of geheugen - op dit slimme contractadres met behulp van de ZELFVERNIETIGING opcode besproken in het vorige deel. (Opgemerkt moet worden dat de tokens - die bestaan ​​als onderdeel van een afzonderlijk ERC-20-contract - blijven bestaan, onaangetast door het zelfvernietigende contract.)

Tot slot de rug-pull. De aanvaller hergebruikt dezelfde metamorfe bytecode die in de installatiefase is gebruikt om een ​​nieuw contract opnieuw in te zetten. Dit nieuwe contract wordt ingezet op hetzelfde adres dat onlangs is ontruimd door het zelfvernietigende contract. Deze keer "verandert" de bytecode echter (nogmaals, we zullen later uitleggen hoe) in een kwaadaardig contract dat alle tokens kan stelen die op het contractadres zijn ingezet. Oplichterij compleet. 

De risico's die metamorfe slimme contracten vormen, zijn inmiddels duidelijk. Maar je vraagt ​​je misschien nog steeds af, hoe werkt deze metamorfose-truc eigenlijk? Om dat te begrijpen, moet je dieper graven, tot op bytecode-niveau. 

Hoe CREATE2 de mogelijkheid van metamorfose opent 

CREËER2 is een opcode-upgrade, geïntroduceerd in Ethereum in februari 2019, dat een nieuwe manier biedt om slimme contracten in te zetten. 

CREATE2 geeft ontwikkelaars meer controle over de implementatie van hun slimme contracten dan voorheen. De originele CREATE-opcode maakt het moeilijk voor ontwikkelaars om het bestemmingsadres te controleren voor een in te zetten smart contract. Met CREATE2 kunnen mensen het adres van een bepaald slim contract van tevoren controleren en kennen, voordat het daadwerkelijk op de blockchain wordt geïmplementeerd. Deze voorkennis – plus enkele slimme trucs – stelt mensen in staat om metamorfe slimme contracten te creëren. 

Hoe kan CREATE2 de toekomst voorspellen? De berekening van de opcode is deterministisch: zolang de ingangen niet veranderen, verandert het adres bepaald door CREATE2 niet. (Zelfs de kleinste wijziging zorgt ervoor dat de implementatie ergens anders plaatsvindt.)

Meer gedetailleerd, CREATE2 is een functie die een paar elementen combineert en samenvoegt. Ten eerste bevat het het adres van de exploitant (of afzender): het initiërende slimme contract dat fungeert als ouder voor het contract dat moet worden gemaakt. Vervolgens voegt het een willekeurig nummer toe dat door de afzender wordt verstrekt (of "salt"), waardoor de ontwikkelaar dezelfde code op verschillende adressen kan implementeren (door het salt te wijzigen) en voorkomt dat bestaande, identieke contracten worden overschreven. Ten slotte gebruikt het de keccak256-hash van een of andere slimme contractinitialisatie ("init") bytecode, die het zaad is dat verandert in een nieuw slim contract. Deze gehashte combinatie bepaalt een Ethereum-adres en implementeert vervolgens de gegeven bytecode op dat adres. Zo lang als de bytecode blijft precies hetzelfde, CREATE2 zal de gegeven bytecode altijd op hetzelfde adres op de blockchain inzetten.

Zo ziet de formule CREATE2 eruit. (Opmerking: in het onderstaande voorbeeld ziet u een ander element, een '0xFF'. Dit is gewoon een constante die CREATE2 gebruikt botsingen voorkomen met de voorgaande CREATE opcode.)

Nu we een manier hebben om code in te zetten op een deterministisch adres, hoe is dat mogelijk verandering de code op datzelfde adres? In eerste instantie lijkt dit misschien onmogelijk. Als u nieuwe code wilt implementeren met behulp van CREATE2, moet de bytecode worden gewijzigd en daarom zal CREATE2 naar een ander adres worden geïmplementeerd. Maar wat als een ontwikkelaar de bytecode zo heeft geconstrueerd dat deze in een andere code kan "veranderen" wanneer CREATE2 een slim contract implementeert?

Hoe een metamorfosecontract eigenlijk werkt

Het recept om van een slim contract een metamorf contract te maken, vereist in totaal drie slimme contracten, die elk een unieke rol spelen.

Een van deze noodzakelijke componenten is de Metamorphic Contract Factory, het brein van de operatie. Deze "Fabriek" is verantwoordelijk voor het implementeren van het Metamorphic Contract, evenals een ander slim contract, het Implementation Contract genaamd, zo genoemd omdat de code uiteindelijk wordt geïmplementeerd in het Metamorphic Contract. Een subtiele choreografie tussen deze drie contracten resulteert in een metamorfose, zoals weergegeven in onderstaand schema.

Laten we elke stap, 1-7, in detail bespreken om de werkzaamheden op het werk toe te lichten.

Stap 1: Een ontwikkelaar zet alles in beweging

Een codeur ontwerpt een of andere slimme contractcode – de bytecode van het implementatiecontract – die uiteindelijk in het metamorfosecontract terechtkomt. De ontwikkelaar stuurt deze code naar de Metamorphic Contract Factory, een slim contract dat als belangrijkste doel heeft om andere slimme contracten in te zetten. Deze actie zet het hele creatieproces van Metamorphic Contract in gang.

Alles wat volgt is het resultaat van deze eerste stap. Inderdaad, Stappen 1 tot en met 6 vinden plaats in één atomaire transactie op de blockchain, dus bijna allemaal tegelijk. Deze stappen kunnen keer op keer worden herhaald, tot in het oneindige, om de code in het Metamorphic Contract te vervangen en deze voortdurend te laten veranderen.

Stap 2: Factory implementeert implementatiecontract

Het eerste contract dat de fabriek implementeert, is het implementatiecontract, dat implementatiecode bevat. (Creatief, we weten het.) Beschouw het implementatiecontract als een laadperron of waypoint dat een bepaalde code bevat voordat het naar zijn eindbestemming wordt verzonden, in dit geval binnen het Metamorphic Contract. 

Stap 3: Fabriekswinkels Implementatie Contractadres

Nadat het op de blockchain is geïmplementeerd, zal het implementatiecontract noodzakelijkerwijs op een blockchain-adres bestaan. De fabriek slaat dit contractadres op in zijn eigen geheugen (om later te gebruiken, in stap 5). 

Stap 4: Factory implementeert Metamorphic Contract

The Factory implementeert het Metamorphic Contract met behulp van CREATE2 en metamorphic bytecode. U kunt een technische, diepgaande uitleg vinden over hoe metamorfe bytecode werkt hier, maar het volstaat om te zeggen dat wanneer metamorfe bytecode wordt uitgevoerd, het code kopieert van een andere locatie in de keten - in dit geval van het implementatiecontract - naar het metamorfe contract. Zoals we in de vorige sectie hebben besproken, aangezien CREATE2 deterministisch is - zolang dezelfde afzender, salt en bytecode worden gebruikt - blijft het Metamorphic Contract-adres hetzelfde, ongeacht hoe vaak deze stappen worden herhaald.

Hieronder is een voorbeeld van hoe metamorfe bytecode eruit ziet, van de metamorfe repo op 0leeftijd. Dit is slechts één voorbeeld van metamorfe bytecode - er bestaan ​​​​potentieel ontelbare variaties, die de detectie van metamorfe contracten enorm bemoeilijken.

Stap 5: Metamorphic bytecode vraagt ​​fabriek naar implementatiecontractadres

De metamorfe bytecode vraagt ​​de Fabriek om het Implementatiecontractadres (zoals opgeslagen in Stap 3). Het maakt niet uit of het adres van het Implementatiecontract verandert, zolang de metamorfe bytecode die om het adres vraagt, hetzelfde blijft. Als de ontwikkelaar later een nieuw implementatiecontract implementeert, zoals een kwaadaardig contract dat is ontworpen om tokens te stelen, zal het noodzakelijkerwijs op een ander blockchain-adres worden geïmplementeerd, volgens stap 2. Dit heeft geen invloed op de totstandkoming van het Metamorphic Contract.

Stap 6: Implementatie Contractcode wordt gekopieerd naar het Metamorphic Contract

Met behulp van het blockchain-adres dat in stap 5 is geleerd, lokaliseert de metamorfe bytecode de code in het implementatiecontract en kopieert die code naar de lokale opslag van het metamorfe contract. Dit is hoe het Metamorphic Contract van vorm verandert: door code uit het Implementatiecontract te kopiëren. 

Stap 7: Spoel en herhaal

Een ontwikkelaar kan de stappen 1 tot en met 6 keer op keer herhalen en de code in het Metamorphic Contract vervangen door wat hij maar wil door middel van een nieuw Implementatiecontract. Het enige dat nodig is, is om de SELFDESTRUCT-opcode te gebruiken - of, meer sluw, DELEGATECALL-opcodes die uiteindelijk resulteren in een SELFDESTRUCT - om de reeds bestaande code in het Metamorphic Contract te verwijderen. Door de cyclus te herhalen met de nieuwe Bytecode van het Implementatiecontract, zal het Metamorfe Contract, als bij toverslag, morph!

Door deze techniek te gebruiken om metamorfe contracten te creëren, kan een slimme ontwikkelaar constant de grond onder de voeten van web3-gebruikers verschuiven. Denk bijvoorbeeld nog eens aan het scam-scenario. Een ontwikkelaar kan eerst het Implementatiecontract implementeren met token-staking-code die, via het omslachtige pad dat wordt weergegeven in de afbeelding en uitgewerkt in de bovenstaande stappen, terechtkomt in het Metamorphic Contract. De oplichter kan deze code later zelf vernietigen en vervangen door een nieuw implementatiecontract te implementeren met token-diefstal code. 

Wat in het Uitvoeringscontract wordt ingezet, komt uiteindelijk terecht in het Metamorfosecontract. Dat is de essentie van de truc. 

***

Metamorfe slimme contracten breken het impliciete web3 sociale contract dat wat je ziet is wat je krijgt. Vergelijkbaar met de manier waarop het shell-spel drie bewegende cups gebruikt om een ​​bal te verbergen, maakt het samenspel van de drie contracten bij het creëren van een metamorfisch contract het moeilijk om de ware functie van het contract te volgen. Het shell-spel is een bijzonder geschikte vergelijking omdat vertrouwensbedriegers vaak goochelarij en misleiding zullen gebruiken om ervoor te zorgen dat ze winnen. In de web3-versie kunnen metamorfe contractschrijvers op dezelfde manier de "bal" - de implementatiecode, dat wil zeggen - laten verdwijnen (lees: zelfvernietiging), en ze kunnen deze vervangen door wat ze maar willen.

Het bestaan ​​van metamorfe contracten betekent dat het voor web3-gebruikers mogelijk is om contracten aan te gaan die naar believen kunnen worden gewijzigd - daarom is deze dreiging zo belangrijk om te begrijpen en ertegen te verdedigen. Mijn metamorfe contractdetector biedt slechts een eerste stap in de richting van het identificeren van metamorfe contracten door de goochelarij die ze gebruiken. Er zijn verschillende manieren waarop de detector in de toekomst kan worden verbeterd. Door bijvoorbeeld recursief de fabriek (of het gebruikerscontract) te controleren die het metamorfe contract heeft gemaakt, kan men zien of de fabriek zelf metamorfisch is. Deze functie zou een nuttige aanvulling zijn op een verbeterde versie 2 van de detector.

Het is de moeite waard om nogmaals te herhalen: deze detectortool is niet onfeilbaar. De vlaggen die het vangt zijn niet allemaal veelbetekenende tekenen van metamorfosepotentieel, maar ze bieden wel aanwijzingen. Het identificeren van deze vlaggen is nog maar het begin voor een grondiger onderzoek. Daarom hebben we de detector uitgebreid om te zoeken naar vlaggen die gemakkelijk valse positieven kunnen genereren, zoals de aanwezigheid van CREATE2- of DELEGATECALL-opcodes. Als je suggesties hebt om de tool te verbeteren of als je wilt voortbouwen op of iets wilt toevoegen aan dit eerste werk, neem dan contact met me op via .

Analyseer slimme contracten op metamorfe eigenschappen met behulp van de detectortool en bezoek de GitHub repo meer

Redacteur: Robert Hackett @rhhackett

***

Dankbetuigingen: ik wil een ENORME shoutout geven en Robert Hackett, Eddy Lazzarin, Sam Ragsdale, Riyaz Faizullabhoy, Noah Citron, Mason Hall en Daejun Park bedanken voor hun waardevolle feedback en advies bij het tot leven brengen van dit bericht en deze tool. 

***

De standpunten die hier naar voren worden gebracht, zijn die van het individuele personeel van AH Capital Management, LLC (“a16z”) dat wordt geciteerd en zijn niet de standpunten van a16z of haar gelieerde ondernemingen. Bepaalde informatie in dit document is verkregen uit externe bronnen, waaronder van portefeuillebedrijven van fondsen die worden beheerd door a16z. Hoewel ontleend aan bronnen die betrouwbaar worden geacht, heeft a16z dergelijke informatie niet onafhankelijk geverifieerd en doet het geen uitspraken over de blijvende nauwkeurigheid van de informatie of de geschiktheid ervan voor een bepaalde situatie. Bovendien kan deze inhoud advertenties van derden bevatten; a16z heeft dergelijke advertenties niet beoordeeld en keurt de daarin opgenomen advertentie-inhoud niet goed.

Deze inhoud is uitsluitend bedoeld voor informatieve doeleinden en mag niet worden beschouwd als juridisch, zakelijk, investerings- of belastingadvies. U dient hierover uw eigen adviseurs te raadplegen. Verwijzingen naar effecten of digitale activa zijn alleen voor illustratieve doeleinden en vormen geen beleggingsaanbeveling of aanbod om beleggingsadviesdiensten te verlenen. Bovendien is deze inhoud niet gericht op of bedoeld voor gebruik door beleggers of potentiële beleggers, en mag er in geen geval op worden vertrouwd bij het nemen van een beslissing om te beleggen in een fonds dat wordt beheerd door a16z. (Een aanbod om te beleggen in een a16z-fonds wordt alleen gedaan door middel van het onderhandse plaatsingsmemorandum, de inschrijvingsovereenkomst en andere relevante documentatie van een dergelijk fonds en moet in hun geheel worden gelezen.) Alle genoemde beleggingen of portefeuillebedrijven waarnaar wordt verwezen, of beschreven zijn niet representatief voor alle investeringen in voertuigen die door a16z worden beheerd, en er kan geen garantie worden gegeven dat de investeringen winstgevend zullen zijn of dat andere investeringen die in de toekomst worden gedaan vergelijkbare kenmerken of resultaten zullen hebben. Een lijst van investeringen die zijn gedaan door fondsen die worden beheerd door Andreessen Horowitz (met uitzondering van investeringen waarvoor de uitgevende instelling geen toestemming heeft gegeven aan a16z om openbaar te maken, evenals onaangekondigde investeringen in openbaar verhandelde digitale activa) is beschikbaar op https://a16z.com/investments /.

De grafieken en grafieken die hierin worden verstrekt, zijn uitsluitend bedoeld voor informatieve doeleinden en er mag niet op worden vertrouwd bij het nemen van een investeringsbeslissing. In het verleden behaalde resultaten zijn geen indicatie voor toekomstige resultaten. De inhoud spreekt alleen vanaf de aangegeven datum. Alle projecties, schattingen, voorspellingen, doelstellingen, vooruitzichten en/of meningen die in deze materialen worden uitgedrukt, kunnen zonder voorafgaande kennisgeving worden gewijzigd en kunnen verschillen of in strijd zijn met meningen van anderen. Zie https://a16z.com/disclosures voor aanvullende belangrijke informatie.