Et verktøy for å oppdage metamorfe smarte kontrakter

En kritisk Ethereum-sikkerhetsantagelse er at smart kontraktskode er uforanderlig og derfor ikke kan endres når den først er distribuert på blokkjeden. I praksis noen smarte kontrakter kan endre – selv etter at de har blitt distribuert. Med noen smarte triks kan du lage metamorfe smarte kontrakter som "metamorfose” inn i noe annet – og ved å forstå hva som gjør dem mulige, kan du oppdage dem.

Metamorfe smarte kontrakter kan endres, noe som betyr at utviklere kan endre koden i dem. Disse smarte kontraktene utgjør en alvorlig risiko for web3-brukere som setter sin lit til kode som de forventer å kjøre med absolutt konsistens, spesielt ettersom dårlige skuespillere kan utnytte denne formskiftende evnen. Se for deg en angriper som bruker teknikken til å "klegge" folk som satser tokens i en smart kontrakt de ikke er klar over er metamorfe. Angrep basert på dette og lignende premisser kan utstyre svindlere til å tære på mennesker og generelt undergrave tilliten til det fulle løftet om desentraliserte systemer.

For å analysere om en smart kontrakt inneholder metamorfe egenskaper, Jeg bygde en enkel Metamorf kontraktsdetektor (inspirert av og bygger på det originale verket til Jason carver, Aldringog andre). Hvem som helst kan bruke verktøyet til å sjekke om en gitt kontrakt viser røde flagg som kan indikere potensialet for metamorfose. Metoden er ikke idiotsikker: bare fordi en smart kontrakt viser et flagg, betyr det ikke at den nødvendigvis er metamorf; og bare fordi det ikke gjør det, betyr det ikke at det er trygt. Kontrolløren tilbyr bare en rask innledende vurdering av en kontrakt kunne være metamorfe basert på mulige indikatorer. 

Web3-brukere bør gjøre seg kjent med truslene som utgjøres av metamorfe kontrakter, slik at de kan se etter og unngå mulige angrep. Lommebøker og blokkjedeindeksere kan hjelpe ved å advare brukere før de samhandler med en smart kontrakt som kan inneholde metamorfe egenskaper. Dette verktøyet er ment å hjelpe både med å utdanne folk om denne potensielle trusselen ... og forsvare seg mot den.

Oppdage metamorfe smarte kontrakter

De Metamorf kontraktsdetektor Jeg bygget analyser seks egenskaper som kan indikere om en smart kontrakt er metamorf.

1. 1. Ble kjent metamorf kode brukt til å distribuere kontrakten? Hvis kjent metamorf bytekode – den virtuelle maskinlesbare koden på lavere nivå som Ethereum smarte kontrakter, vanligvis skrevet i Solidity, blir til etter å ha blitt kompilert – dukker opp i en transaksjon for en gitt smart kontrakts utplassering, er det et stort rødt flagg. I avsnittene som følger, vil vi diskutere et slikt eksempel på metamorf bytekode utviklet av 0age. Et viktig forbehold: Det er potensielt utallige variasjoner av metamorf bytekode, noe som gjør det vanskelig å oppdage alle varianter. Ved å skanne etter velkjente tilfeller eliminerer detektoren imidlertid lavthengende frukt for angripere som bare kopierer og limer inn eksisterende eksempler.
   2. Kan den smarte kontraktskoden selvdestruere? For å erstatte koden i en kontrakt – et nøkkeltrinn i å lage en metamorf kontrakt – må en utvikler først slette eksisterende kode. Den eneste måten å gjøre dette på er å bruke SELVDESTRUKT. op-kode, en kommando som gjør akkurat det den høres ut som – den sletter all kode og lagring på en gitt kontraktadresse. Tilstedeværelsen av selvdestruerende kode i en kontrakt beviser ikke at den er metamorf; det gir imidlertid en anelse om at kontrakten kunne være metamorfe, og det er uansett verdt å vite om kontrakter du stoler på kan atombombe seg selv.
   3. Kaller den smarte kontrakten inn kode fra andre steder? Hvis den aktuelle smarte kontrakten ikke direkte kan selvdestruere, kan den fortsatt være i stand til å slette seg selv ved å bruke DELEGATECALL opkode. Denne opkoden lar en smart kontrakt dynamisk laste og utføre kode som lever i en annen smart kontrakt. Selv om den smarte kontrakten ikke inneholder SELFDESTRUCT-opkoden, kan den bruke DELEGATECALL til å laste selvdestruerende kode fra et annet sted. Selv om DELEGATECALL-funksjonaliteten ikke direkte indikerer om en smart kontrakt er metamorf, er det en mulig ledetråd – og potensielt sikkerhetsproblem – som er verdt å merke seg. Vær advart om at denne indikatoren har potensial til å øke mange falske positiver. 
   4. Har en annen kontrakt implementert denne kontrakten? Metamorfe kontrakter kan utplasseres bare av andre smarte kontrakter. Dette er fordi metamorfe kontrakter er aktivert av en annen opkode, som bare kan brukes av andre smarte kontrakter, kalt CREATE2. (Vi vil diskutere CREATE2 – hvordan det fungerer og hvorfor det betyr noe – mer i et senere avsnitt.) Denne egenskapen er en av de minst iøynefallende indikatorene på mulig metamorfose; det er en nødvendig, men utilstrekkelig forutsetning. Skanning etter denne egenskapen vil sannsynligvis gi mange falske positiver – men det er verdifull informasjon å vite da det kan vekke mistanker og gi en grunn til å granske en kontrakt nærmere, spesielt hvis den smarte kontrakten inneholder opkoden som er beskrevet neste.
   5. Inneholder distribusjonskontrakten CREATE2-opkoden? Som nevnt ovenfor er distribusjon via CREATE2 en essensiell forutsetning for metamorfose. Hvis en distribusjonskontrakt inneholder CREATE2-opkoden, kan det indikere at den brukte CREATE2 for å distribuere den aktuelle kontrakten. Hvis distribusjonsgiveren faktisk brukte CREATE2 for å distribuere nevnte kontrakt, mens det ikke betyr at kontrakten nødvendigvis er metamorf, betyr det at den kunne være metamorfe, og det kan være lurt å gå videre med forsiktighet og undersøke nærmere. Igjen, pass på falske positiver: LAG 2 har masse lovlig bruk, inkludert forsterkning "Layer 2" skaleringsløsninger og gjør det enklere å lage smarte kontraktslommebøker som kan forbedre web3 bruker-onboarding og viktige gjenopprettingsalternativer.
   6. Har koden endret seg? Dette er den mest åpenbare fortellingen, men den vil først dukke opp etter at en metamorf kontrakt allerede har endret seg. Hvis den smarte kontraktens kodehash – en unik, kryptografisk identifikator – er annerledes enn den var da kontrakten opprinnelig ble distribuert, er det sannsynlig at koden ble fjernet, erstattet eller endret. Hvis hashen ikke lenger samsvarer, har noe med koden endret seg og kontrakten kan være metamorf. Dette flagget er den sikreste indikatoren på metamorfose, men det vil ikke hjelpe til med å forutsi eller forhindre morphing siden det bare sjekker at det allerede har skjedd.

I tillegg til å bygge et enkelt kommandolinjeverktøy for Metamorphic Contract Detector, bygde jeg noen eksempler på smarte kontrakter som demonstrerer et svindel-metamorfisk kontraktsscenario, som jeg beskriver i neste avsnitt. All koden er tilgjengelig i denne GitHub repository. 

Hvordan en ondsinnet aktør kan bruke metamorfe kontrakter for å stjele folks midler

Her er hvordan noen kan bruke en metamorf smart kontrakt som en del av en svindel. 

Først er oppsettfasen. Angriperen distribuerer en smart kontrakt på en bestemt adresse på blokkjeden ved hjelp av to verktøy: metamorf bytekode og CREATE2-opkoden. (Vi vil utdype begge disse konseptene senere.) Den metamorfe bytekoden gjør deretter det navnet antyder og «forvandles». Her endres det til en staking kontrakt hvor brukere kan satse ERC-20-tokens. (Igjen, vi vil diskutere detaljene i dette morphing-trikset senere. Lover!)

Deretter kommer agnet og bryteren. Intetanende brukere satser sine tokens i denne kontrakten, lokket av muligheten for å tjene en avkastning eller en annen fordel. Angriperen sletter deretter all innsatskoden og "staten" - blokkjedelagring eller minne - på denne smarte kontraktsadressen ved å bruke SELVDESTRUKT. op-kode diskutert i forrige avsnitt. (Det bør bemerkes at tokens – som eksisterer som en del av en separat ERC-20-kontrakt – vedvarer, upåvirket av den selvdestruerte kontrakten.)

Til slutt teppetrekket. Angriperen gjenbruker den samme metamorfe bytekoden som ble brukt i oppsettfasen for å "redistribuere" en ny kontrakt. Denne nye kontrakten distribueres til samme adresse som nylig ble forlatt av den selvødeleggende kontrakten. Denne gangen "forvandles" imidlertid bytekoden (igjen, vi skal forklare hvordan senere) til en ondsinnet kontrakt som kan stjele alle tokenene som er satt på kontraktsadressen. Svindel fullført. 

Risikoen som metamorfe smarte kontrakter utgjør, er nå tydelig. Men du lurer kanskje fortsatt på hvordan dette metamorfotrikset egentlig fungerer? For å forstå det, må du sondere dypere, til bytekode-nivå. 

Hvordan CREATE2 åpner muligheten for metamorfose 

LAG 2 er en opcode-oppgradering, introdusert til Ethereum i februar 2019, som tilbyr en ny måte å distribuere smarte kontrakter på. 

CREATE2 gir utviklere mer kontroll over utrullingen av sine smarte kontrakter enn de hadde tidligere. Den originale CREATE-opkoden gjør det vanskelig for utviklere å kontrollere destinasjonsadressen for en smart kontrakt som skal distribueres. Med CREATE2 kan folk kontrollere og vite adressen til en bestemt smart kontrakt på forhånd, før de faktisk distribuerer den til blokkjeden. Denne forkunnskapen – pluss noen smarte triks – er det som gjør folk i stand til å lage metamorfe smarte kontrakter. 

Hvordan kan CREATE2 forutsi fremtiden? Opkodens beregning er deterministisk: så lenge inngangene ikke endres, vil ikke adressen bestemt av CREATE2 endres. (Selv den minste endring vil føre til at utplasseringen skjer et annet sted.)

Mer detaljert er CREATE2 en funksjon som kombinerer og hashes sammen noen få elementer. For det første inkluderer den adressen til distribusjonsgiveren (eller avsenderen): den initierende smarte kontrakten som fungerer som en forelder til den som skal opprettes. Deretter legger den til et vilkårlig nummer gitt av avsenderen (eller "salt"), som lar utvikleren distribuere den samme koden til forskjellige adresser (ved å endre saltet) og forhindrer overskriving av eksisterende, identiske kontrakter. Til slutt bruker den keccak256-hashen til en eller annen smart kontraktinitialisering ("init") bytekode, som er frøet som blir til en ny smart kontrakt. Denne hashed-sammen-kombinasjonen bestemmer en Ethereum-adresse og distribuerer deretter den gitte bytekoden til den adressen. Så lenge som bytekoden forblir nøyaktig den samme, CREATE2 vil alltid distribuere den gitte bytekoden til samme adresse på blokkjeden.

Slik ser CREATE2-formelen ut. (Merk: du vil legge merke til et annet element, en "0xFF," i eksemplet nedenfor. Dette er bare en konstant CREATE2 bruker til forhindre kollisjoner med den forrige CREATE-opkoden.)

Nå som vi har en måte å distribuere kode til en deterministisk adresse, hvordan er det mulig å endring koden på samme adresse? I begynnelsen kan dette virke umulig. Hvis du vil distribuere ny kode ved hjelp av CREATE2, må bytekoden endres, og derfor vil CREATE2 distribueres til en annen adresse. Men hva om en utvikler konstruerte bytekoden på en slik måte at den kunne "omdannes" til en annen kode når CREATE2 distribuerer en smart kontrakt?

Hvordan en metamorf kontrakt faktisk fungerer

Oppskriften på å gjøre en smart kontrakt til en metamorf kontrakt krever tre smarte kontrakter, som hver spiller en unik rolle.

En av disse nødvendige komponentene er Metamorphic Contract Factory, hjernen i operasjonen. Denne "fabrikken" er ansvarlig for å distribuere den metamorfe kontrakten, så vel som en annen smart kontrakt kalt implementeringskontrakten, slik kalt fordi koden til slutt blir implementert i den metamorfe kontrakten. En subtil koreografi mellom disse tre kontraktene resulterer i metamorfose, som vist i diagrammet nedenfor.

La oss diskutere hvert trinn, 1-7, i detalj for å belyse operasjonene på jobben.

Trinn 1: En utvikler setter alt i gang

En koder designer en smart kontraktkode – implementeringskontraktens bytekode – som til slutt vil ende opp i den metamorfe kontrakten. Utvikleren sender denne koden til Metamorphic Contract Factory, en smart kontrakt hvis hovedformål er å distribuere andre smarte kontrakter. Denne handlingen setter hele prosessen med å lage metamorfe kontrakter i gang.

Alt som følger er et resultat av dette første trinnet. Faktisk, Trinn 1 til 6 skjer i én atomtransaksjon på blokkjeden, noe som betyr nesten alt på en gang. Disse trinnene kan gjentas om og om igjen, i det uendelige, for å erstatte koden i den metamorfe kontrakten og holde den i endring.

Trinn 2: Fabrikken implementerer implementeringskontrakt

Den første kontrakten fabrikken distribuerer er implementeringskontrakten, som inneholder implementeringskode. (Kreativt, vi vet.) Tenk på implementeringskontrakten som en lastebrygge, eller et veipunkt, som inneholder en kode før den sendes til sin endelige destinasjon, som i dette tilfellet vil være innenfor den metamorfe kontrakten. 

Trinn 3: Fabrikklagre Implementeringskontraktadresse

Etter at den er distribuert til blokkjeden, vil implementeringskontrakten nødvendigvis eksistere på en blokkjedeadresse. Fabrikken lagrer denne kontraktsadressen i sitt eget minne (som skal brukes senere, i trinn 5). 

Trinn 4: Fabrikken implementerer Metamorphic Contract

Fabrikken distribuerer den metamorfe kontrakten ved å bruke CREATE2 og metamorfisk bytekode. Du kan finne en teknisk, grundig gjennomgang av hvordan metamorf bytekode fungerer her., men det er nok å si at når metamorfisk bytekode kjøres, kopierer den kode fra et annet sted i kjeden – i dette tilfellet fra implementeringskontrakten – inn i den metamorfe kontrakten. Som vi snakket om i forrige avsnitt, siden CREATE2 er deterministisk – så lenge samme avsender, salt og bytekode brukes – forblir Metamorphic Contract-adressen den samme uansett hvor mange ganger disse trinnene gjentas.

Nedenfor er et eksempel på hvordan metamorf bytekode ser ut, fra metamorfe repo etter 0 alder. Dette er bare ett eksempel på metamorf bytekode - potensielt utallige variasjoner eksisterer, noe som kompliserer oppdagelsen av metamorfe kontrakter.

Trinn 5: Metamorfe bytekode-spørringer Fabrikk for implementeringskontraktadresse

Den metamorfe bytekoden ber fabrikken om implementeringskontraktsadressen (som lagret i trinn 3). Det spiller ingen rolle om adressen til implementeringskontrakten endres så lenge den metamorfe bytekoden som ber om adressen forblir den samme. Faktisk, hvis utvikleren senere distribuerer en ny implementeringskontrakt – for eksempel en ondsinnet kontrakt designet for å stjele tokens – vil den nødvendigvis distribueres på en annen blokkjedeadresse, per trinn 2. Dette har ingen innvirkning på opprettelsen av den metamorfe kontrakten.

Trinn 6: Implementeringskontraktskode blir kopiert inn i den metamorfe kontrakten

Ved å bruke blokkjedeadressen som ble lært i trinn 5, lokaliserer den metamorfe bytekoden koden i implementeringskontrakten og kopierer den koden inn i den metamorfe kontraktens lokale lagring. Dette er hvordan den metamorfe kontrakten endrer form: ved å kopiere kode fra implementeringskontrakten. 

Trinn 7: Skyll og gjenta

En utvikler kan gjenta trinn 1 til 6 om og om igjen og erstatte koden i den metamorfe kontrakten med hva de vil ved hjelp av en ny implementeringskontrakt. Alt som trengs er å bruke SELFDESTRUCT-opkoden – eller, mer utspekulert, DELEGATECALL-opkoder som til slutt resulterer i en SELFDESTRUCT – for å fjerne den eksisterende koden i den metamorfe kontrakten. Ved å gjenta syklusen med ny implementeringskontrakt-bytekode, vil den metamorfe kontrakten, som magi, morf!

Ved å bruke denne teknikken for å lage metamorfe kontrakter, kan en smart utvikler hele tiden flytte bakken under web3-brukernes føtter. Tenk for eksempel på svindelscenariet igjen. En utvikler kan først distribuere implementeringskontrakten med token-staking-kode som, gjennom den omløpsveien som er avbildet i grafikken og utdypet i trinnene ovenfor, ender opp i den metamorfe kontrakten. Svindleren kan senere selvdestruere denne koden og erstatte den ved å distribuere en ny implementeringskontrakt som inneholder token-stjele kode. 

Det som blir distribuert i implementeringskontrakten vil til slutt ende opp i den metamorfe kontrakten. Det er essensen av trikset. 

***

Metamorfe smarte kontrakter bryter den implisitte web3 sosiale kontrakten om at det du ser er det du får. I likhet med måten skallspillet bruker tre bevegelige kopper for å skjule en ball, gjør samspillet mellom de tre kontraktene i opprettelsen av en metamorf kontrakt det vanskelig å følge kontraktens sanne funksjon. Skallspillet er en spesielt passende sammenligning fordi selvtillitslurere ofte vil bruke støy og feilretninger for å sikre at de vinner. I web3-versjonen kan metamorfe kontraktskribenter på samme måte få "ballen" - implementeringskoden, det vil si - til å forsvinne (les: selvdestruksjon), og de kan erstatte den med hva de vil.

Eksistensen av metamorfe kontrakter betyr at det er mulig for web3-brukere å inngå kontrakter som kan endres etter eget ønske – det er derfor denne trusselen er så viktig å forstå og forsvare seg mot. Min metamorfe kontraktsdetektor tilbyr bare et første skritt mot å identifisere metamorfe kontrakter ved hjelp av den hånden de bruker. Det er flere måter detektoren kan forbedres på i fremtiden. For eksempel, ved å rekursivt sjekke fabrikken (eller distribusjonskontrakten) som opprettet den metamorfe kontrakten, kan man se om fabrikken i seg selv er metamorf. Denne funksjonen vil være et nyttig tillegg til en oppgradert versjon 2 av detektoren.

Det er verdt å gjenta igjen: Dette detektorverktøyet er ikke idiotsikkert. Flaggene den fanger er ikke alle avslørende tegn på metamorfisk potensial, men de gir ledetråder. Å identifisere disse flaggene er bare starten på en mer grundig undersøkelse. Det er derfor vi utvidet detektoren til å søke etter flagg som lett kan generere falske positiver, som tilstedeværelsen av CREATE2- eller DELEGATECALL-opkoder. Hvis du har forslag til forbedring av verktøyet eller ønsker å bygge videre på eller legge til dette innledende arbeidet, ta kontakt med meg på .

Analyser smarte kontrakter for metamorfe egenskaper ved hjelp av detektorverktøyet og besøke GitHub repo for mer

Redaktør: Robert Hackett @rhhackett

***

Anerkjennelser: Jeg vil gi en STOR hyllest og takk til Robert Hackett, Eddy Lazzarin, Sam Ragsdale, Riyaz Faizullabhoy, Noah Citron, Mason Hall og Daejun Park for verdifull tilbakemelding og råd for å få dette innlegget og verktøyet til å bli levende. 

***

Synspunktene som uttrykkes her er de fra individuelle AH Capital Management, LLC (“a16z”) personell som er sitert og er ikke synspunktene til a16z eller dets tilknyttede selskaper. Visse opplysninger her er innhentet fra tredjepartskilder, inkludert fra porteføljeselskaper av fond forvaltet av a16z. Selv om a16z er hentet fra kilder som antas å være pålitelige, har ikke a16z uavhengig verifisert slik informasjon og gir ingen representasjoner om den varige nøyaktigheten til informasjonen eller dens hensiktsmessighet for en gitt situasjon. I tillegg kan dette innholdet inkludere tredjepartsannonser; aXNUMXz har ikke vurdert slike annonser og støtter ikke noe reklameinnhold som finnes deri.

Dette innholdet er kun gitt for informasjonsformål, og bør ikke stoles på som juridisk, forretningsmessig, investerings- eller skatterådgivning. Du bør rådføre deg med dine egne rådgivere om disse sakene. Referanser til verdipapirer eller digitale eiendeler er kun for illustrasjonsformål, og utgjør ikke en investeringsanbefaling eller tilbud om å tilby investeringsrådgivningstjenester. Videre er dette innholdet ikke rettet mot eller ment for bruk av noen investorer eller potensielle investorer, og kan ikke under noen omstendigheter stoles på når du tar en beslutning om å investere i et fond som forvaltes av a16z. (Et tilbud om å investere i et a16z-fond vil kun gis av det private emisjonsmemorandumet, tegningsavtalen og annen relevant dokumentasjon for et slikt fond og bør leses i sin helhet.) Eventuelle investeringer eller porteføljeselskaper nevnt, referert til, eller beskrevet er ikke representative for alle investeringer i kjøretøy forvaltet av a16z, og det kan ikke gis noen garanti for at investeringene vil være lønnsomme eller at andre investeringer som gjøres i fremtiden vil ha lignende egenskaper eller resultater. En liste over investeringer foretatt av fond forvaltet av Andreessen Horowitz (unntatt investeringer som utstederen ikke har gitt tillatelse til at a16z kan offentliggjøre så vel som uanmeldte investeringer i børsnoterte digitale eiendeler) er tilgjengelig på https://a16z.com/investments /.

Diagrammer og grafer gitt i er kun for informasjonsformål og bør ikke stoles på når du tar investeringsbeslutninger. Tidligere resultater er ikke en indikasjon på fremtidige resultater. Innholdet taler kun fra den angitte datoen. Eventuelle anslag, estimater, prognoser, mål, prospekter og/eller meninger uttrykt i dette materialet kan endres uten varsel og kan avvike eller være i strid med meninger uttrykt av andre. Vennligst se https://a16z.com/disclosures for ytterligere viktig informasjon.