Et værktøj til at opdage metamorfe smarte kontrakter

En kritisk Ethereum-sikkerhedsantagelse er, at smart kontraktkode er uforanderlig og derfor ikke kan ændres, når den først er implementeret på blockchain. I praksis nogle smarte kontrakter kan ændres – også efter at de er blevet indsat. Med et par smarte tricks kan du skabe metamorfe smarte kontrakter, der "metamorfose” ind i noget andet – og ved at forstå, hvad der gør dem mulige, kan du opdage dem.

Metamorfe smarte kontrakter kan ændres, hvilket betyder, at udviklere kan ændre koden i dem. Disse smarte kontrakter udgør en alvorlig risiko for web3-brugere, der sætter deres lid til kode, som de forventer at køre med absolut konsistens, især da dårlige skuespillere kan udnytte denne formskiftende evne. Forestil dig en angriber, der bruger teknikken til at "ruge" folk, der sætter poletter i en smart kontrakt, som de ikke er klar over er metamorfe. Angreb baseret på denne og lignende præmisser kan udstyre svindlere til at forgribe sig på mennesker og generelt underminere tilliden til det fulde løfte om decentraliserede systemer.

For at analysere, om en smart kontrakt indeholder metamorfe egenskaber, Jeg byggede en simpel Metamorfisk kontraktdetektor (inspireret af og bygger på det originale værk af Jason carver, 0alderog andre). Enhver kan bruge værktøjet til at kontrollere, om en given kontrakt udviser røde flag, der kunne indikere potentialet for metamorfose. Metoden er ikke idiotsikker: bare fordi en smart kontrakt viser et flag, betyder det ikke, at det nødvendigvis er metamorfisk; og bare fordi det ikke gør det, betyder det ikke, at det er sikkert. Checkeren tilbyder blot en hurtig indledende vurdering af en kontrakt måske være metamorfe baseret på mulige indikatorer. 

Web3-brugere bør gøre sig bekendt med de trusler, som metamorfe kontrakter udgør, så de kan holde øje med og undgå mulige angreb. Tegnebøger og blockchain-indeksere kan hjælpe ved at advare brugere, før de interagerer med en smart kontrakt, der kan indeholde metamorfe egenskaber. Dette værktøj er beregnet til at hjælpe både med at oplyse folk om denne potentielle trussel... og forsvare sig mod den.

Detektering af metamorfe smarte kontrakter

Metamorfisk kontraktdetektor Jeg byggede analyser seks egenskaber, der kan indikere, om en smart kontrakt er metamorf.

1. 1. Blev kendt metamorfisk kode brugt til at implementere kontrakten? Hvis kendt metamorfisk bytekode – den lavere niveau, virtuelle maskinlæsbare kode, som Ethereum smart-kontrakter, typisk skrevet i Solidity, bliver til efter at være blevet kompileret – dukker op i en transaktion for en given smart kontrakts udrulning, er det et stort rødt flag. I de følgende afsnit vil vi diskutere et sådant eksempel på metamorf bytekode udviklet af 0age. En vigtig advarsel: Der er potentielt utallige variationer af metamorf bytekode, hvilket gør det svært at opdage alle varianter. Ved at scanne efter velkendte tilfælde eliminerer detektoren dog lavthængende frugter for angribere, der blot kopierer og indsætter eksisterende eksempler.
   2. Kan den smarte kontraktkode selvdestruere? For at erstatte koden i en kontrakt – et nøgletrin i at skabe en metamorfisk kontrakt – skal en udvikler først slette allerede eksisterende kode. Den eneste måde at gøre dette på er ved at bruge SELVDESTRUKTØR opcode, en kommando, der gør præcis, hvad den lyder som - den sletter al kode og lagring på en given kontraktadresse. Tilstedeværelsen af ​​selvdestruerende kode i en kontrakt beviser ikke, at den er metamorf; det giver dog et fingerpeg om, at kontrakten måske være metamorfe, og det er i hvert fald værd at vide, om kontrakter, du stoler på, kan ødelægge sig selv.
   3. Indkalder den smarte kontrakt kode fra andre steder? Hvis den pågældende smarte kontrakt ikke direkte kan selvdestruere, kan den muligvis stadig slette sig selv ved at bruge DELEGATECALL opkode. Denne opcode gør det muligt for en smart kontrakt dynamisk at indlæse og udføre kode, der findes i en anden smart kontrakt. Selvom den smarte kontrakt ikke indeholder SELFDESTRUCT-opkoden, kan den bruge DELEGATECALL til at indlæse selvdestruerende kode fra et andet sted. Selvom DELEGATECALL-funktionaliteten ikke direkte indikerer, om en smart kontrakt er metamorfe, er det et muligt spor – og et potentielt sikkerhedsproblem – der er værd at bemærke. Vær advaret om, at denne indikator har potentialet til at rejse mange falske positiver. 
   4. Har en anden kontrakt implementeret denne kontrakt? Metamorfe kontrakter kan implementeres kun af andre smarte kontrakter. Dette skyldes, at metamorfe kontrakter er aktiveret af en anden opcode, som kun kan bruges af andre smarte kontrakter, kaldet CREATE2. (Vi vil diskutere CREATE2 – hvordan det virker, og hvorfor det betyder noget – mere i et senere afsnit.) Dette træk er en af ​​de mindst iøjnefaldende indikatorer for mulig metamorfose; det er en nødvendig, men utilstrækkelig forudsætning. Scanning for denne egenskab vil sandsynligvis give mange falske positiver - men det er værdifuld information at vide, da det kan rejse mistanke og give en grund til at granske en kontrakt yderligere, især hvis den smarte kontrakt indeholder den opkode, der beskrives herefter.
   5. Indeholder deployer-kontrakten CREATE2-opkoden? Som nævnt ovenfor er implementering via CREATE2 en væsentlig forudsætning for metamorfose. Hvis en deployer-kontrakt indeholder CREATE2-opkoden, kan det indikere, at den brugte CREATE2 til at implementere den pågældende kontrakt. Hvis deployeren faktisk brugte CREATE2 til at implementere nævnte kontrakt, selvom det ikke betyder, at kontrakten nødvendigvis er metamorf, betyder det, at den måske være metamorfe, og det kan være klogt at gå forsigtigt frem og undersøge nærmere. Igen, pas på falske positiver: OPRET2 har masser af lovlige anvendelser, herunder forstærkning "Layer 2" skaleringsløsninger og gør det nemmere at skabe smarte kontrakttegninger, der kan forbedre web3 bruger-onboarding og vigtige gendannelsesmuligheder.
   6. Ændrede koden sig? Dette er den mest oplagte fortælling, men den vil først dukke op, efter at en metamorfisk kontrakt allerede har ændret sig. Hvis den smarte kontrakts kodehash – en unik, kryptografisk identifikator – er anderledes, end den var, da kontrakten oprindeligt blev implementeret, er det sandsynligt, at koden er blevet fjernet, erstattet eller ændret. Hvis hasherne ikke længere matcher, så er noget ved koden ændret, og kontrakten kan være metamorf. Dette flag er den sikreste indikator for metamorfose, men det hjælper ikke med at forudsige eller foregribe morphing, da det kun kontrollerer, at det allerede er sket.

Ud over at bygge et simpelt kommandolinjeværktøj til Metamorphic Contract Detector, byggede jeg nogle eksempler på smarte kontrakter, der demonstrerer et svindel-metamorfisk kontraktindsatsscenarie, som jeg beskriver i næste afsnit. Al koden er tilgængelig i denne GitHub repository. 

Hvordan en ondsindet skuespiller kan bruge metamorfe kontrakter til at stjæle folks penge

Her er, hvordan nogen kan bruge en metamorf smart kontrakt som en del af en fidus. 

Først er opsætningsfasen. Angriberen implementerer en smart kontrakt på en specifik adresse på blockchainen ved hjælp af to værktøjer: metamorf bytekode og CREATE2-opkoden. (Vi vil udvide på begge disse begreber senere). Den metamorfe bytekode gør derefter, hvad dens navn antyder, og "forvandler". Her ændres det til en staking kontrakt hvor brugere kan satse ERC-20 tokens. (Igen, vi vil diskutere detaljerne i dette morphing-trick senere. Lov!)

Dernæst kommer madding og switch. Intetanende brugere satser deres tokens i denne kontrakt, lokket af muligheden for at tjene et udbytte eller et andet frynsegode. Angriberen sletter derefter al indsatskoden og "tilstanden" - blockchain-lagring eller hukommelse - på denne smarte kontraktadresse ved hjælp af SELVDESTRUKTØR opcode diskuteret i forrige afsnit. (Det skal bemærkes, at tokens - som eksisterer som en del af en separat ERC-20-kontrakt - fortsætter, upåvirket af den selvdestruerede kontrakt.)

Til sidst tæppe-pull. Angriberen genbruger den samme metamorfe bytekode, som blev brugt i opsætningsfasen til at "ominstallere" en ny kontrakt. Denne nye kontrakt udsendes til den samme adresse, som for nylig blev forladt af den selvdestruerende kontrakt. Denne gang "forvandles" bytekoden imidlertid (igen, vi forklarer hvordan senere) til en ondsindet kontrakt, der kan stjæle alle de tokens, der er sat på kontraktadressen. Svindel fuldført. 

De risici, som metamorfe smarte kontrakter udgør, er nu tydelige. Men du spekulerer måske stadig på, hvordan fungerer dette metamorfi-trick egentlig? For at forstå det, skal du sondere dybere, til bytekode-niveau. 

Hvordan CREATE2 åbner muligheden for metamorfose 

OPRET2 er en opcode-opgradering, introduceret til Ethereum i februar 2019, der tilbyder en ny måde at implementere smarte kontrakter på. 

CREATE2 giver udviklere mere kontrol over implementeringen af ​​deres smarte kontrakter, end de tidligere havde. Den originale CREATE-opkode gør det vanskeligt for udviklere at kontrollere destinationsadressen for en smart kontrakt, der skal implementeres. Med CREATE2 kan folk kontrollere og kende adressen på en bestemt smart kontrakt på forhånd, før de rent faktisk implementerer den til blockchain. Denne forudviden – plus nogle smarte tricks – er det, der gør folk i stand til at skabe metamorfe smarte kontrakter. 

Hvordan kan CREATE2 forudsige fremtiden? Opkodens beregning er deterministisk: så længe inputs ikke ændres, vil adressen bestemt af CREATE2 ikke ændre sig. (Selv den mindste ændring vil få implementeringen til at ske et andet sted.)

Mere detaljeret er CREATE2 en funktion, der kombinerer og hashes sammen nogle få elementer. For det første inkorporerer den adressen på deployeren (eller afsenderen): den initierende smarte kontrakt, der fungerer som en forælder til den, der skal oprettes. Dernæst tilføjer den et vilkårligt nummer leveret af afsenderen (eller "salt"), som gør det muligt for udvikleren at implementere den samme kode til forskellige adresser (ved at ændre saltet) og forhindrer overskrivning af eksisterende, identiske kontrakter. Endelig bruger den keccak256-hash af en eller anden smart kontraktinitialisering ("init") bytekode, som er frøet, der bliver til en ny smart kontrakt. Denne hashed-sammen-kombination bestemmer en Ethereum-adresse og implementerer derefter den givne bytekode til denne adresse. Så længe bytekoden forbliver nøjagtig den samme, CREATE2 vil altid implementere den givne bytekode til den samme adresse på blockchainen.

Sådan ser CREATE2-formlen ud. (Bemærk: du vil bemærke et andet element, et "0xFF," i eksemplet nedenfor. Dette er bare en konstant CREATE2 bruger til forhindre kollisioner med den foregående CREATE-opkode.)

Nu hvor vi har en måde at implementere kode til en deterministisk adresse, hvordan er det muligt at lave om koden på den samme adresse? I første omgang kan dette virke umuligt. Hvis du vil implementere ny kode ved hjælp af CREATE2, skal bytekoden ændres, og derfor vil CREATE2 implementere til en anden adresse. Men hvad nu hvis en udvikler konstruerede bytekoden på en sådan måde, at den kunne "omdannes" til en anden kode, når CREATE2 implementerer en smart kontrakt?

Hvordan en metamorf kontrakt faktisk fungerer

Opskriften på at omdanne en smart kontrakt til en metamorf kontrakt kræver i alt tre smarte kontrakter, der hver spiller en unik rolle.

En af disse nødvendige komponenter er Metamorphic Contract Factory, hjernen i operationen. Denne "fabrik" er ansvarlig for at implementere den metamorfe kontrakt såvel som en anden smart kontrakt kaldet implementeringskontrakten, så navngivet, fordi dens kode med tiden bliver implementeret i den metamorfe kontrakt. En subtil koreografi mellem disse tre kontrakter resulterer i metamorfose, som afbildet i diagrammet nedenfor.

Lad os diskutere hvert trin, 1-7, i detaljer for at belyse operationerne på arbejdet.

Trin 1: En udvikler sætter alt i gang

En koder designer en smart kontraktkode – implementeringskontraktens bytekode – som til sidst vil ende i den metamorfe kontrakt. Udvikleren sender denne kode til Metamorphic Contract Factory, en smart kontrakt, hvis hovedformål er at implementere andre smarte kontrakter. Denne handling sætter hele processen til oprettelse af Metamorphic Contract i gang.

Alt, hvad der følger, er et resultat af dette indledende trin. Ja, Trin 1 til 6 sker i én atomtransaktion på blockchain, hvilket betyder næsten alt på én gang. Disse trin kan gentages igen og igen, ad infinitum, for at erstatte koden inde i den metamorfe kontrakt og holde den konstant i forandring.

Trin 2: Fabrikken implementerer implementeringskontrakt

Den første kontrakt, som fabrikken implementerer, er implementeringskontrakten, som indeholder implementeringskode. (Kreativt, vi ved det.) Tænk på implementeringskontrakten som en ladeplads eller et waypoint, der indeholder en kode, før det afsendes til sin endelige destination, som i dette tilfælde vil være inde i den metamorfe kontrakt. 

Trin 3: Fabriksbutikker Implementeringskontraktadresse

Efter implementeringen til blockchain, vil implementeringskontrakten nødvendigvis eksistere på en eller anden blockchain-adresse. Fabrikken gemmer denne kontraktadresse i sin egen hukommelse (til brug senere i trin 5). 

Trin 4: Fabrikken implementerer Metamorphic Contract

Fabrikken implementerer den metamorfe kontrakt ved hjælp af CREATE2 og metamorfisk bytekode. Du kan finde en teknisk, dybdegående gennemgang af, hvordan metamorf bytekode fungerer link., men det er tilstrækkeligt at sige, at når metamorfisk bytekode udføres, kopierer den kode fra en anden placering i kæden - i dette tilfælde fra implementeringskontrakten - til den metamorfe kontrakt. Som vi talte om i sidste afsnit, da CREATE2 er deterministisk – så længe den samme afsender, salt og bytekode bruges – så forbliver den metamorfe kontraktadresse den samme, uanset hvor mange gange disse trin gentages.

Nedenfor er et eksempel på, hvordan metamorf bytekode ser ud, fra metamorfe repo i 0-alderen. Dette er blot ét eksempel på metamorfisk bytekode - der findes potentielt utallige variationer, hvilket i høj grad komplicerer påvisningen af ​​metamorfe kontrakter.

Trin 5: Metamorfe bytekode-forespørgsler Fabriks til implementeringskontraktadresse

Den metamorfe bytekode beder fabrikken om implementeringskontraktens adresse (som gemt i trin 3). Det er lige meget, om adressen på implementeringskontrakten ændres, så længe den metamorfe bytekode, der beder om adressen, forbliver den samme. Faktisk, hvis udvikleren senere implementerer en ny implementeringskontrakt – såsom en ondsindet en designet til at stjæle tokens – vil den nødvendigvis implementeres på en anden blockchain-adresse, pr. trin 2. Dette har ingen indflydelse på oprettelsen af ​​den metamorfe kontrakt.

Trin 6: Implementeringskontraktkode bliver kopieret ind i den metamorfe kontrakt

Ved at bruge blockchain-adressen lært i trin 5, lokaliserer den metamorfe bytekode koden i implementeringskontrakten og kopierer denne kode til den metamorfe kontrakts lokale lager. Sådan skifter den metamorfe kontrakt form: ved at kopiere kode fra implementeringskontrakten. 

Trin 7: Skyl og gentag

En udvikler kan gentage trin 1 til 6 igen og igen og erstatte koden i den metamorfe kontrakt med, hvad de kan lide ved hjælp af en ny implementeringskontrakt. Det eneste, der er brug for, er at bruge SELFDESTRUCT-opkoden – eller mere snedigt, DELEGATECALL-opkoder, der i sidste ende resulterer i en SELFDESTRUCT – for at fjerne den allerede eksisterende kode i den metamorfe kontrakt. Ved at gentage cyklussen med ny implementeringskontrakt bytekode, vil den metamorfe kontrakt, ligesom magi, morf!

Ved at bruge denne teknik til at skabe metamorfe kontrakter kan en klog udvikler konstant flytte jorden under web3-brugeres fødder. Overvej f.eks. fidusscenariet igen. En udvikler kan først implementere implementeringskontrakten med token-staking-kode, der gennem den kredsløbsvej, der er vist i grafikken og uddybet i trinene ovenfor, ender i den metamorfe kontrakt. Svindleren kunne senere selvdestruere denne kode og erstatte den ved at implementere en ny implementeringskontrakt indeholdende token-stjæle kode. 

Uanset hvad der bliver implementeret i implementeringskontrakten vil i sidste ende ende i den metamorfe kontrakt. Det er essensen af ​​tricket. 

***

Metamorfe smarte kontrakter bryder den implicitte web3 sociale kontrakt om, at det, du ser, er, hvad du får. På samme måde som skalspillet bruger tre bevægelige kopper til at skjule en bold, gør samspillet mellem de tre kontrakter i skabelsen af ​​en metamorf kontrakt det svært at følge kontraktens sande funktion. Shell-spillet er en særlig passende sammenligning, fordi selvtillidstrickstere ofte vil bruge fingerfærdighed og fejlretning for at sikre, at de vinder. I web3-versionen kan metamorfe kontraktskribenter på samme måde få "bolden" - implementeringskoden, det vil sige - til at forsvinde (læs: selvdestruktion), og de kan erstatte den med hvad de vil.

Eksistensen af ​​metamorfe kontrakter betyder, at det er muligt for web3-brugere at indgå kontrakter, der kan ændres efter behag – det er derfor, denne trussel er så vigtig at forstå og forsvare sig imod. Min metamorfe kontraktdetektor tilbyder blot et første skridt i retning af at identificere metamorfe kontrakter ved hjælp af den snert af hånd, de anvender. Der er flere måder, hvorpå detektoren kan forbedres i fremtiden. For eksempel ved rekursivt at kontrollere fabrikken (eller deployer-kontrakten), der skabte den metamorfe kontrakt, kunne man se, om fabrikken i sig selv er metamorf. Denne funktion ville være en nyttig tilføjelse til en opgraderet version 2 af detektoren.

Det er værd at gentage endnu en gang: Dette detektorværktøj er ikke idiotsikkert. De flag, den fanger, er ikke alle afslørende tegn på metamorfisk potentiale, men de giver spor. At identificere disse flag er kun starten på en mere grundig undersøgelse. Det er derfor, vi udvidede detektoren til at søge efter flag, der nemt kunne generere falske positiver, såsom tilstedeværelsen af ​​CREATE2- eller DELEGATECALL-opkoder. Hvis du har forslag til forbedring af værktøjet eller ønsker at bygge videre på eller tilføje til dette indledende arbejde, så kontakt mig på .

Analyser smarte kontrakter for metamorfe træk ved hjælp af detektorværktøjet og besøge GitHub repo mere

Redaktør: Robert Hackett @rhhackett

***

Tak: Jeg vil gerne give en KÆMPE shoutout og tak til Robert Hackett, Eddy Lazzarin, Sam Ragsdale, Riyaz Faizullabhoy, Noah Citron, Mason Hall og Daejun Park for værdifuld feedback og råd til at få dette indlæg og værktøj til at komme til live. 

***

De synspunkter, der er udtrykt her, er dem fra det enkelte AH Capital Management, LLC ("a16z") personale, der er citeret, og er ikke synspunkter fra a16z eller dets tilknyttede selskaber. Visse oplysninger indeholdt heri er indhentet fra tredjepartskilder, herunder fra porteføljeselskaber af fonde forvaltet af a16z. Selvom det er taget fra kilder, der menes at være pålidelige, har a16z ikke uafhængigt verificeret sådanne oplysninger og fremsætter ingen erklæringer om informationernes vedvarende nøjagtighed eller deres passende for en given situation. Derudover kan dette indhold omfatte tredjepartsreklamer; a16z har ikke gennemgået sådanne annoncer og støtter ikke noget reklameindhold indeholdt deri.

Dette indhold er kun givet til informationsformål og bør ikke påberåbes som juridisk, forretningsmæssig, investerings- eller skatterådgivning. Du bør rådføre dig med dine egne rådgivere om disse spørgsmål. Henvisninger til værdipapirer eller digitale aktiver er kun til illustrationsformål og udgør ikke en investeringsanbefaling eller tilbud om at levere investeringsrådgivningstjenester. Ydermere er dette indhold ikke rettet mod eller beregnet til brug af nogen investorer eller potentielle investorer og kan under ingen omstændigheder stoles på, når der træffes en beslutning om at investere i en fond, der administreres af a16z. (Et tilbud om at investere i en a16z-fond vil kun blive givet af private placement-memorandummet, tegningsaftalen og anden relevant dokumentation for en sådan fond og bør læses i deres helhed.) Eventuelle investeringer eller porteføljeselskaber nævnt, refereret til eller beskrevne er ikke repræsentative for alle investeringer i køretøjer, der administreres af a16z, og der kan ikke gives sikkerhed for, at investeringerne vil være rentable, eller at andre investeringer foretaget i fremtiden vil have lignende karakteristika eller resultater. En liste over investeringer foretaget af fonde forvaltet af Andreessen Horowitz (undtagen investeringer, hvortil udstederen ikke har givet tilladelse til, at a16z offentliggør såvel som uanmeldte investeringer i offentligt handlede digitale aktiver) er tilgængelig på https://a16z.com/investments /.

Diagrammer og grafer, der er angivet i, er udelukkende til informationsformål og bør ikke stoles på, når der træffes nogen investeringsbeslutning. Tidligere resultater er ikke vejledende for fremtidige resultater. Indholdet taler kun fra den angivne dato. Alle fremskrivninger, estimater, prognoser, mål, udsigter og/eller meninger udtrykt i disse materialer kan ændres uden varsel og kan afvige fra eller være i modstrid med andres meninger. Se venligst https://a16z.com/disclosures for yderligere vigtige oplysninger.