Ett verktyg för att upptäcka metamorfa smarta kontrakt

Ett kritiskt säkerhetsantagande för Ethereum är att smart kontraktskod är oföränderlig och därför inte kan ändras när den väl har installerats på blockkedjan. I praktiken några smarta kontrakt Kan ändra – även efter att de har distribuerats. Med några smarta knep kan du skapa metamorfa smarta kontrakt som "metamorphose” till något annat – och genom att förstå vad som gör dem möjliga kan du upptäcka dem.

Metamorfa smarta kontrakt är föränderliga, vilket innebär att utvecklare kan ändra koden inuti dem. Dessa smarta kontrakt utgör en allvarlig risk för web3-användare som litar på kod som de förväntar sig att köra med absolut konsistens, särskilt som dåliga aktörer kan utnyttja denna formförändringsförmåga. Föreställ dig en angripare som använder tekniken för att "rugga" människor som satsar tokens i ett smart kontrakt som de inte inser är metamorft. Attacker baserade på denna och liknande premisser kan utrusta bedragare att förgripa sig på människor och i allmänhet undergräva förtroendet för det fulla löftet om decentraliserade system.

För att analysera om ett smart kontrakt innehåller metamorfa egenskaper, Jag byggde en enkel Metamorfisk kontraktsdetektor (inspirerad av och bygger på originalverket av Jason carver, 0 ålderoch andra). Vem som helst kan använda verktyget för att kontrollera om ett givet kontrakt uppvisar röda flaggor som kan indikera potentialen för metamorfism. Metoden är inte idiotsäker: bara för att ett smart kontrakt visar en flagga, betyder det inte att det nödvändigtvis är metamorft; och bara för att det inte gör det betyder det inte att det är säkert. Checkaren erbjuder bara en snabb första bedömning som ett kontrakt kanske vara metamorfisk utifrån möjliga indikatorer. 

Web3-användare bör bekanta sig med hoten från metamorfa kontrakt så att de kan hålla utkik efter och undvika eventuella attacker. Plånböcker och blockchain-indexerare kan hjälpa genom att varna användare innan de interagerar med ett smart kontrakt som kan innehålla metamorfa egenskaper. Detta verktyg är avsett att hjälpa både att utbilda människor om detta potentiella hot... och att försvara sig mot det.

Upptäcka metamorfa smarta kontrakt

Smakämnen Metamorfisk kontraktsdetektor Jag byggde analyser sex egenskaper som kan indikera om ett smart kontrakt är metamorft.

1. 1. Användes känd metamorf kod för att distribuera kontraktet? Om känd metamorf bytekod – den virtuella maskinläsbara koden på lägre nivå som Ethereums smarta kontrakt, vanligtvis skrivna i Solidity, förvandlas till efter att ha kompilerats – dyker upp i en transaktion för ett givet smart kontrakts utplacering, är det en stor röd flagga. I avsnitten som följer kommer vi att diskutera ett sådant exempel på metamorf bytekod utvecklad av 0age. En viktig varning: Det finns potentiellt otaliga variationer av metamorf bytekod, vilket gör det svårt att upptäcka alla sorter. Genom att skanna efter välkända instanser eliminerar detektorn dock lågt hängande frukt för angripare som bara kopierar och klistrar in befintliga exempel.
   2. Kan den smarta kontraktskoden självförstöra? För att ersätta koden i ett kontrakt – ett nyckelsteg i att skapa ett metamorfiskt kontrakt – måste en utvecklare först ta bort redan existerande kod. Det enda sättet att göra detta är att använda SELFDESTRUCT opcode, ett kommando som gör precis vad det låter som – det raderar all kod och lagring på en given kontraktsadress. Förekomsten av självförstörande kod i ett kontrakt bevisar inte att det är metamorf; det ger dock en ledtråd att kontraktet kanske vara metamorfisk och det är i alla fall värt att veta om kontrakt du förlitar dig på kan kärnvapen.
   3. Ringer det smarta kontraktet in kod från någon annanstans? Om det smarta kontraktet i fråga inte direkt kan självförstöra, kan det ändå kunna radera sig själv genom att använda DELEGATECALL opkod. Denna opcode tillåter ett smart kontrakt dynamiskt att ladda och exekvera kod som finns i ett annat smart kontrakt. Även om det smarta kontraktet inte innehåller SELFDESTRUCT-opkoden, kan det använda DELEGATECALL för att ladda självförstörande kod från någon annanstans. Medan DELEGATECALL-funktionen inte direkt indikerar om ett smart kontrakt är metamorft, är det en möjlig ledtråd – och potentiellt säkerhetsproblem – som är värt att notera. Varnas för att denna indikator har potential att ge många falska positiva resultat. 
   4. Har ett annat kontrakt implementerat detta kontrakt? Metamorfa kontrakt kan användas endast genom andra smarta kontrakt. Detta beror på att metamorfa kontrakt är aktiverade av en annan op-kod, som endast kan användas av andra smarta kontrakt, kallad CREATE2. (Vi kommer att diskutera CREATE2 – hur det fungerar och varför det är viktigt – mer i ett senare avsnitt.) Denna egenskap är en av de minst iögonfallande indikatorerna på möjlig metamorfism; det är en nödvändig men otillräcklig förutsättning. Att söka efter denna egenskap kommer sannolikt att ge många falska positiva resultat – men det är värdefull information att veta eftersom det kan väcka misstankar och ge en anledning att granska ett kontrakt ytterligare, särskilt om det smarta kontraktet innehåller den op-kod som beskrivs härnäst.
   5. Innehåller installationsavtalet CREATE2-opkoden? Som nämnts ovan är distribution via CREATE2 en väsentlig förutsättning för metamorfism. Om ett deployer-kontrakt innehåller CREATE2-opkoden kan det indikera att det använde CREATE2 för att distribuera kontraktet i fråga. Om driftsättaren verkligen använde CREATE2 för att distribuera nämnda kontrakt, även om det inte betyder att kontraktet nödvändigtvis är metamorft, betyder det att det kanske vara metamorfisk och det kan vara klokt att gå försiktigt fram och undersöka vidare. Återigen, akta dig för falska positiva: SKAPA2 har gott om legitima användningar, inklusive förstärkning "Layer 2" skalningslösningar och göra det lättare att skapa smarta kontraktsplånböcker som kan förbättra web3 användarintroduktion och viktiga återställningsalternativ.
   6. Har koden ändrats? Detta är det mest uppenbara berätta, men det kommer bara att dyka upp efter att ett metamorfiskt kontrakt redan har förändrats. Om det smarta kontraktets kodhash – en unik, kryptografisk identifierare – är annorlunda än den var när kontraktet ursprungligen distribuerades, är det troligt att koden togs bort, ersattes eller ändrades. Om hasharna inte längre matchar, så har något med koden ändrats och kontraktet kan vara metamorft. Denna flagga är den säkraste indikatorn på metamorfism, men den hjälper inte att förutsäga eller förebygga morphing eftersom den bara kontrollerar att det redan hänt.

Förutom att bygga ett enkelt kommandoradsverktyg för Metamorphic Contract Detector, byggde jag några exempel på smarta kontrakt som visar ett bedrägerimetamorfiskt kontraktsutsättningsscenario, som jag beskriver i nästa avsnitt. All kod finns tillgänglig i denna GitHub repository. 

Hur en illvillig aktör kan använda metamorfa kontrakt för att stjäla människors pengar

Så här kan någon använda ett metamorfiskt smart kontrakt som en del av en bluff. 

Först är installationsfasen. Angriparen distribuerar ett smart kontrakt på en specifik adress i blockkedjan med hjälp av två verktyg: metamorf bytekod och CREATE2 opcode. (Vi kommer att utvidga båda dessa begrepp senare.) Den metamorfa bytekoden gör sedan vad dess namn antyder och "förvandlas". Här förändras det till en satsningskontrakt där användare kan satsa ERC-20-tokens. (Återigen, vi kommer att diskutera detaljerna i detta morphing-trick senare. Lova!)

Därefter kommer betet och växeln. Intet ont anande användare satsar sina tokens i detta kontrakt, lockade av möjligheten att tjäna en avkastning eller någon annan förmån. Angriparen raderar sedan all insatskod och "tillstånd" - blockchain-lagring eller minne - på denna smarta kontraktsadress med hjälp av SELFDESTRUCT opcode diskuterades i föregående avsnitt. (Det bör noteras att tokens – som finns som en del av ett separat ERC-20-kontrakt – kvarstår, opåverkade av det självförstörade kontraktet.)

Äntligen mattdraget. Angriparen återanvänder samma metamorfa bytekod som användes i installationsfasen för att "omdistribuera" ett nytt kontrakt. Detta nya kontrakt distribueras till samma adress som nyligen lämnats av det självförstörande kontraktet. Den här gången "förvandlas" dock bytekoden (igen, vi ska förklara hur senare) till ett skadligt kontrakt som kan stjäla alla tokens som är insatta på kontraktsadressen. Bedrägeri klar. 

Riskerna som metamorfa smarta kontrakt utgör är vid det här laget uppenbara. Men du kanske fortfarande undrar, hur fungerar detta metamorfismtrick egentligen? För att förstå det måste du sondera djupare, till bytekodnivån. 

Hur CREATE2 öppnar upp möjligheten till metamorfism 

SKAPA2 är en opcode-uppgradering, introducerad till Ethereum i februari 2019, som erbjuder ett nytt sätt att implementera smarta kontrakt. 

CREATE2 ger utvecklare mer kontroll över implementeringen av sina smarta kontrakt än vad de tidigare hade. Den ursprungliga CREATE-opkoden gör det svårt för utvecklare att kontrollera destinationsadressen för ett smart kontrakt som ska distribueras. Med CREATE2 kan människor kontrollera och veta adressen till ett visst smart kontrakt i förväg, innan de faktiskt distribuerar det till blockkedjan. Denna förkunskap – plus några smarta knep – är det som gör det möjligt för människor att skapa metamorfa smarta kontrakt. 

Hur kan CREATE2 förutsäga framtiden? Opcodens beräkning är deterministisk: så länge som ingångarna inte ändras kommer adressen som bestäms av CREATE2 inte att ändras. (Även den minsta förändring kommer att göra att distributionen sker någon annanstans.)

Mer detaljerat är CREATE2 en funktion som kombinerar och hashar ihop några element. För det första innehåller det adressen till utgivaren (eller avsändaren): det initierande smarta kontraktet som fungerar som en förälder till den som ska skapas. Därefter lägger den till ett godtyckligt nummer som tillhandahålls av avsändaren (eller "salt"), vilket gör att utvecklaren kan distribuera samma kod till olika adresser (genom att ändra saltet) och förhindrar att befintliga, identiska kontrakt skrivs över. Slutligen använder den keccak256-hash för någon bytekod för smart kontraktsinitiering ("init"), vilket är fröet som förvandlas till ett nytt smart kontrakt. Denna hashade kombination bestämmer en Ethereum-adress och distribuerar sedan den givna bytekoden till den adressen. Så länge som bytekoden förblir exakt densamma, CREATE2 kommer alltid att distribuera den givna bytekoden till samma adress i blockkedjan.

Så här ser CREATE2-formeln ut. (Obs: du kommer att märka ett annat element, en "0xFF," i exemplet nedan. Detta är bara en konstant CREATE2 använder förhindra kollisioner med föregående CREATE op-kod.)

Nu när vi har ett sätt att distribuera kod till en deterministisk adress, hur är det möjligt byta koden på samma adress? Till en början kan detta verka omöjligt. Om du vill distribuera ny kod med CREATE2 måste bytekoden ändras, och därför kommer CREATE2 att distribueras till en annan adress. Men vad händer om en utvecklare konstruerade bytekoden på ett sådant sätt att den kunde "förvandlas" till annan kod när CREATE2 distribuerar ett smart kontrakt?

Hur ett metamorft kontrakt faktiskt fungerar

Receptet för att förvandla ett smart kontrakt till ett metamorfiskt kontrakt kräver totalt tre smarta kontrakt som var och en spelar en unik roll.

En av dessa nödvändiga komponenter är Metamorphic Contract Factory, hjärnan i operationen. Denna "fabrik" är ansvarig för att distribuera det metamorfiska kontraktet såväl som ett annat smart kontrakt som kallas implementeringskontraktet, så kallat för att dess kod så småningom implementeras i det metamorfiska kontraktet. En subtil koreografi mellan dessa tre kontrakt resulterar i metamorfosm, som avbildas i diagrammet nedan.

Låt oss diskutera varje steg, 1-7, i detalj för att belysa verksamheten på jobbet.

Steg 1: En utvecklare sätter allt i rörelse

En kodare designar någon smart kontraktskod – Implementation Contract bytecode – som så småningom kommer att hamna i det Metamorphic Contract. Utvecklaren skickar denna kod till Metamorphic Contract Factory, ett smart kontrakt vars huvudsakliga syfte är att distribuera andra smarta kontrakt. Den här åtgärden sätter igång hela processen för skapande av Metamorphic Contract.

Allt som följer är ett resultat av detta första steg. Verkligen, Steg 1 till 6 sker i en atomär transaktion på blockkedjan, vilket betyder nästan allt på en gång. Dessa steg kan upprepas om och om igen, i det oändliga, för att ersätta koden inuti det metamorfiska kontraktet och hålla det ständigt förändras.

Steg 2: Fabriksinstallerar implementeringskontrakt

Det första kontraktet som Factory distribuerar är Implementation Contract, som innehåller implementeringskod. (Kreativt, vi vet.) Tänk på implementeringskontraktet som en lastkaj, eller waypoint, som innehåller en del kod innan den skickas till sin slutdestination, som i det här fallet kommer att vara inuti det metamorfiska kontraktet. 

Steg 3: Fabriken lagrar implementeringskontraktsadress

Efter implementeringen till blockkedjan kommer implementeringskontraktet nödvändigtvis att finnas på någon blockchain-adress. Fabriken lagrar denna kontraktsadress i sitt eget minne (för att användas senare, i steg 5). 

Steg 4: Factory distribuerar Metamorphic Contract

Fabriken distribuerar det metamorfiska kontraktet med CREATE2 och metamorfisk bytekod. Du kan hitta en teknisk, djupgående genomgång av hur metamorf bytekod fungerar här., men det räcker med att säga att när metamorfisk bytekod körs, kopierar den kod från någon annan plats i kedjan – i det här fallet från implementeringskontraktet – till det metamorfa kontraktet. Som vi pratade om i förra avsnittet, eftersom CREATE2 är deterministisk – så länge som samma avsändare, salt och bytekod används – förblir Metamorphic Contract-adressen densamma oavsett hur många gånger dessa steg upprepas.

Nedan är ett exempel på hur metamorf bytekod ser ut, från metamorfisk repo vid 0 ålder. Detta är bara ett exempel på metamorfisk bytekod – potentiellt otaliga variationer finns, vilket avsevärt komplicerar upptäckten av metamorfa kontrakt.

Steg 5: Metamorfisk bytekod förfrågningar Factory for Implementation Kontraktsadress

Den metamorfa bytekoden frågar fabriken om implementeringskontraktsadressen (som lagras i steg 3). Det spelar ingen roll om adressen till implementeringsavtalet ändras så länge som den metamorfa bytekoden som ber om adressen förblir densamma. Faktum är att om utvecklaren senare distribuerar ett nytt implementeringskontrakt – till exempel ett skadligt avtal som är utformat för att stjäla tokens – kommer det nödvändigtvis att distribueras på en annan blockchain-adress, per steg 2. Detta har ingen inverkan på skapandet av det metamorfiska kontraktet.

Steg 6: Implementeringskontraktskoden kopieras till det metamorfiska kontraktet

Genom att använda blockchain-adressen som lärdes in i steg 5, lokaliserar den metamorfa bytekoden koden i Implementation Contract och kopierar den koden till Metamorphic Contracts lokala lagring. Så här förändras det metamorfiska kontraktet: genom att kopiera kod från implementeringskontraktet. 

Steg 7: Skölj och upprepa

En utvecklare kan upprepa steg 1 till 6 om och om igen och ersätta koden i det metamorfiska kontraktet med vad de vill genom ett nytt implementeringskontrakt. Allt som behövs är att använda SELFDESTRUCT-opkoden – eller, mer snålt, DELEGATECALL-opkoder som i slutändan resulterar i en SELFDESTRUCT – för att ta bort den redan existerande koden i Metamorphic Contract. Genom att upprepa cykeln med den nya bytekoden för implementeringskontraktet kommer det metamorfiska kontraktet, som magi, morf!

Genom att använda denna teknik för att skapa metamorfa kontrakt kan en smart utvecklare ständigt flytta marken under web3-användares fötter. Tänk till exempel på bluffscenariot igen. En utvecklare kan först distribuera implementeringskontraktet med token-insättningskod som, genom den kretslopp som visas i grafiken och utvecklad i stegen ovan, hamnar i det metamorfiska kontraktet. Bedragaren kan senare självförstöra denna kod och ersätta den genom att distribuera ett nytt implementeringskontrakt som innehåller token-stjäla koda. 

Vad som än distribueras i implementeringskontraktet kommer i slutändan att hamna i det metamorfiska kontraktet. Det är kärnan i tricket. 

***

Metamorfa smarta kontrakt bryter det implicita web3 sociala kontraktet att det du ser är vad du får. I likhet med hur skalspelet använder tre rörliga koppar för att dölja en boll, gör samspelet mellan de tre kontrakten i skapandet av ett metamorfiskt kontrakt det svårt att följa kontraktets verkliga funktion. Skalspelet är en särskilt passande jämförelse eftersom självförtroendetricksters ofta använder snålhet och felriktning för att säkerställa att de vinner. I web3-versionen kan metamorfa kontraktsskribenter på liknande sätt få "bollen" – implementeringskoden, det vill säga – att försvinna (läs: självförstörande), och de kan ersätta den med vad de vill.

Förekomsten av metamorfa kontrakt innebär att det är möjligt för web3-användare att ingå kontrakt som kan ändras efter behag – det är därför detta hot är så viktigt att förstå och försvara sig mot. Min metamorfiska kontraktsdetektor erbjuder bara ett första steg mot att identifiera metamorfa kontrakt med det snålhet de använder. Det finns flera sätt att förbättra detektorn i framtiden. Till exempel, genom att rekursivt kontrollera fabriken (eller distributionskontraktet) som skapade det metamorfiska kontraktet, kunde man se om fabriken i sig är metamorfisk. Denna funktion skulle vara ett användbart tillägg till en uppgraderad version 2 av detektorn.

Det är värt att upprepa än en gång: Detta detektorverktyg är inte idiotsäkert. Flaggorna den fångar är inte alla tecken på metamorfisk potential, men de ger ledtrådar. Att identifiera dessa flaggor är bara början för en mer grundlig undersökning. Det är därför vi utökade detektorn för att söka efter flaggor som lätt kan generera falska positiva, som närvaron av CREATE2- eller DELEGATECALL-opkoder. Om du har förslag på att förbättra verktyget eller vill bygga vidare på eller komplettera detta inledande arbete, kontakta mig på .

Analysera smarta kontrakt för metamorfa egenskaper med hjälp av detektorverktyget och besöka GitHub repo för mer

Redaktör: Robert Hackett @rhhackett

***

Tack: Jag vill ge en ENORM shoutout och tack till Robert Hackett, Eddy Lazzarin, Sam Ragsdale, Riyaz Faizullabhoy, Noah Citron, Mason Hall och Daejun Park för värdefull feedback och råd för att få detta inlägg och verktyg till liv. 

***

De åsikter som uttrycks här är de från den individuella AH Capital Management, LLC (“a16z”) personal som citeras och är inte åsikterna från a16z eller dess dotterbolag. Viss information som finns här har erhållits från tredjepartskällor, inklusive från portföljbolag av fonder som förvaltas av a16z. Även om den är hämtad från källor som anses vara tillförlitliga, har a16z inte självständigt verifierat sådan information och gör inga utfästelser om informationens varaktiga riktighet eller dess lämplighet för en given situation. Dessutom kan detta innehåll innehålla tredjepartsannonser; a16z har inte granskat sådana annonser och stöder inte något reklaminnehåll i dem.

Detta innehåll tillhandahålls endast i informationssyfte och bör inte litas på som juridisk rådgivning, affärs-, investerings- eller skatterådgivning. Du bör rådfråga dina egna rådgivare i dessa frågor. Hänvisningar till värdepapper eller digitala tillgångar är endast i illustrativt syfte och utgör inte en investeringsrekommendation eller erbjudande om att tillhandahålla investeringsrådgivningstjänster. Dessutom är detta innehåll inte riktat till eller avsett att användas av några investerare eller potentiella investerare, och får inte under några omständigheter lita på när man fattar ett beslut om att investera i någon fond som förvaltas av a16z. (Ett erbjudande om att investera i en a16z-fond kommer endast att göras av det privata emissionsmemorandumet, teckningsavtalet och annan relevant dokumentation för en sådan fond och bör läsas i sin helhet.) Alla investeringar eller portföljbolag som nämns, hänvisas till, eller beskrivna är inte representativa för alla investeringar i fordon som förvaltas av a16z, och det finns ingen garanti för att investeringarna kommer att vara lönsamma eller att andra investeringar som görs i framtiden kommer att ha liknande egenskaper eller resultat. En lista över investeringar gjorda av fonder som förvaltas av Andreessen Horowitz (exklusive investeringar för vilka emittenten inte har gett tillstånd för a16z att offentliggöra såväl som oanmälda investeringar i börsnoterade digitala tillgångar) finns tillgänglig på https://a16z.com/investments /.

Diagram och grafer som tillhandahålls i är endast i informationssyfte och bör inte litas på när man fattar investeringsbeslut. Tidigare resultat är inte en indikation på framtida resultat. Innehållet talar endast från det angivna datumet. Alla prognoser, uppskattningar, prognoser, mål, framtidsutsikter och/eller åsikter som uttrycks i detta material kan ändras utan föregående meddelande och kan skilja sig åt eller strida mot åsikter som uttrycks av andra. Se https://a16z.com/disclosures för ytterligare viktig information.