Hack Wormhole – Ukázkový příklad rizika v DeFi, aneb jak ukrást přes 320 milionů dolarů

2. února ve večerních hodinách byla hacknuta Wormhole – bridge mezi blockchainy Ethereum a Solana. Jedná se o druhý největší hack v historii DeFi, ve kterém bylo zcizeno více než 320 milionů dolarů. Útočník díky chybě v kódu dokázal vytvořit 120 000 weETH (Wormhole-wrapped Ether) tokenů, 93 750 z nich následně odeslal zpět na síť Etherea a směnil je za nativní ETH. Zbylé weETH mince směnil za SOL na síti Solany.

Proč je tento útok významný? Za prvé kvůli výši ‘odměny’ pro hackera, ale za druhé hlavně proto, že vyzdvihuje ty nejdůležitější nedostatky DeFi – open-source aspekty a potenciální chyby v kódu – lidské chyby, které jsou díky governance mechanismům a různým úrovním auditů hůře opravitelné.

V následujícím řádku si vysvětlíme, jak k útoku došlo, jak se situace následně vyřešila a proč se podobné situace mohou v DeFi stále opakovat.

Jak k útoku došlo?

Wormhole je kryptoměnový bridge – slouží k přenosu kryptoměn mezi 2 nebo více různými blockchainy, zde mezi Solanou a Ethereem. Každý přenos kryptoměn skrze bridge je též označován za transakci. Jak všichni jistě dobře víme, každá transakce musí být zvalidována.

Transakce na Wormhole validují validátoři s přízviskem “guardians”. Mechanismy vzniku a validace transakcí jsou vždy trochu odlišné v závislosti na konkrétním blockchainu. Solana je zde trochu specifická, každá menší změna v datech zde má svůj vlastní speciální smart kontrakt. Nás zde zajímá zejména kontrakt ověřující podpisy validátorů (guardians).

Zdroj: etherscan.io

Na obrázku výše je jedna z transakcí hackera (Wormhole Network Exploiter). Aby se tato transakce se záznamem na Ethereu uskutečnila, museli ji validátoři Wormhole ověřit, což se také stalo.

Jak tedy hacker postupoval? Využil neopravené skulinky v kódu umožňující vyvolání cizího smart kontraktu (jehož autorem byl sám hacker). Hackerův smart kontrakt byl použit jako důležitý vstupní argument do funkce ověřující podpisy validátorů. Postup hackera se v následujících odstavcích pokusím vysvětlit trochu jednodušeji.

Jeho kroky mohou být zprvu trochu matoucí. Na začátku můžeme i na záznamech Etherscanu vidět, že hacker legitimně vložil 0,1 ETH do bridge. Takto vypadají vstupní argumenty následně vyvolaných funkcí na Solaně pro vytvoření 0,1 weETH.

Zdroj: solscan.io

Důležitý je čtvrtý řádek u vstupů (Account #3), kde se nachází adresa systému ověření podpisů. Pokud je zvolená systémová adresa správná, je pojmenována jako Sysvar: Instructions. Nyní se podíváme na hackerovu transakci reprezentující minting 120 000 weETH prakticky z ničeho.

Zdroj: solscan.io

Na obrázku můžeme vidět, že čtvrtý vstup hacker nějakým způsobem změnil. Místo na jádro programu pro ověřování podpisů instrukce směřují na následující smart kontrakt vytvořený samotným hackerem. Obsahuje pouze jednu sérii instrukcí ústící ve vyvolání dalších proměnných v sekvenci celé transakce – prakticky tím obešel jen ověření podpisů. Validátoři tak ve výsledku nic neověřovali, ale i tak je na transakci jejich razítko.

Dále už proběhlo vše podle původních instrukcí, transakce se finalizovala a 120 000 weETH bylo z ničeho nic na světě.

Struktura kódu – Kde přesně hacker našel chybu?

Aby mohla být transakce hackera potvrzena, muselo k ní být přiložené ověření podpisů, což je výstup zastřešující soubor funkcí s označením ‘verify_signatures’. Tato funkce bere soubor podpisů validátorů a do kódu jej zapíše pod proměnnou ‘SignatureSet’. Žádné ověření ale ve skutečnosti neprovádí, ale deleguje jej na další program (specifikum Solany – na každý kousek kódu nový smart kontrakt).

Ověřování provádí program s označením Secp256k1. Verify_signatures pouze ověřuje, jestli byl tento program vyvolán (řádky 108-110 na následujícím obrázku).

Zdroj: Wormhole Github

Nyní začíná být příběh skutečně zajímavý. Skulinka v kódu spočívá ve funkci ‘load_instruction_at’ (řádky 101-104). Zde je kámen úrazu.

Tato funkce nahrává instrukce programu pro ověřování podpisů. Podle informací na Githubu byla určena k vyřazení, protože neověřuje, jestli nahrává skutečné systémové instrukce nativního programu Solany. To znamená, že hacker mohl vyvolat smart kontrakt z kompletně jiné adresy, a to také udělal. Jedná se přímo o tento smart kontrakt zmiňovaný v kapitole výše.

Ve vstupech hackerovy transakce se tedy na čtvrtém místě nenachází Instructions: sysvar, ale adresa jeho vlastního smart kontraktu.

Hack se stal 3 hodiny poté, co byla oprava chyby nahrána na Github

Nedostatky většího množství funkcí (nejen ‘load_instruction_at’) už tým vývojářů registroval dříve a opravil je v několika fázích. Funkce podstatné pro tento hack byly opraveny 2. 2. – 3 hodiny před hackem. Je zde důležité zmínit, že oprava kódu byla pouze nahrána na Github, ale nebyla uvedena do provozu.

Před každou aplikací kódu je nutné provést několika násobné testování a zároveň několik auditů pro ověření funkčnosti a bezpečnosti. I když kód stále nebyl zprovozněn, nacházel se na Githubu absolutně veřejně a toho přesně hacker zneužil – podíval se, jaké jsou budoucí opravy a tudíž odhalil nedostatky momentálně běžícího kódu.

Zdroj: Github Wormhole

Na řádku 101 byla přepsána naše důležitá funkce z ‘load_instructions_at’ na ‘load_instructions_at_checked’ – aktualizovaná verze, která mimo jiné obsahuje i mechanismus pro ověřování systémové adresy (hackerův vlastní smart kontrakt by zde vyvolán nebyl).

Tým za Wormhole později přiznal, že tato aktualizace nebyla původně zamýšlena čistě na “zalepení” této bezpečnostní díry. Je tedy otázkou, jestli o ní vývojáři vůbec věděli.

Reakce týmu Wormhole na hack – Jak to všechno dopadlo?

První reakce přicházely po půl hodině od hackerova výběru. Vývojáři s komunitou během 10 minut identifikovali bezpečnostní díru v kódu a začali situaci neprodleně řešit. Zhruba hodinu po incidentu přestali validátoři Wormhole potvrzovat veškeré transakce. Většina validátorů přestala během další hodiny.

Oprava kódu (funguje téměř stejně jako úsek kódu zmiňovaný v kapitole výše, instrukce ověřuje pouze jiným způsobem) vznikla zhruba dvě hodiny po incidentu. Vzhledem k nutnosti dosáhnout potřebného souhlasu (governance protokol) byla oprava aplikována teprve v půl druhé v noci.

Ve stejném čase začala Wormhole podávat první veřejná vyjádření.

‼️ The wormhole network is down for maintenance as we look into a potential exploit.

📢 We will provide updates here as soon as we have them.

🙏 Thank you for your patience.

— Wormhole (@wormhole) February 2, 2022

Tým za Wormhole se rozhodl s hackerem začít vyjednávat. Hackerovi bylo nabídnuto 10 milionů dolarů výměnou za navrácení ukradených 120 000 weETH a osvětlení detailů hacku.

Zdroj: medium.com

Během následující noci Wormhole ujišťovala veřejnost o přidání ETH do protokolu, aby byl opět zajištěn poměr 1:1 mezi weETH:ETH. Tohoto se následně ujmula společnost Jump Crypto.

.@JumpCryptoHQ believes in a multichain future and that @WormholeCrypto is essential infrastructure. That’s why we replaced 120k ETH to make community members whole and support Wormhole now as it continues to develop.

— Jump Crypto 🔥💃🏻 (@jump_) February 3, 2022

Ve dvě hodiny 3. 2. Jump Crypto doplnil potřebné ETH a v půl třetí byla síť Wormhole spolu s kryptoměnovým bridge opět zprovozněna – včetně opravy.

Shrnutí s odstupem

Celá kauza Wormhole je ukázkovým příkladem, co se může stát, když je v kódu chyba. Podobné situace mohou samozřejmě ohrozit momentálně přítomné finance v protokolu, ale také jméno protokolu a potenciální důvěru veřejnosti. Je nutné si uvědomit, že podobné události vycházejí pouze z lidských chyb (‘code is law’). Zde se nenacházela jednoduchá podmínka ověření původu vstupních instrukcí.

Jelikož jsou decentralizované finance absolutně neregulované prostředí, není zde žádná autorita , která by udávala pomyslné standardy (samozřejmě, proto DeFi vzniklo). Codebase všech DeFi projektů jsou auditovány různými firmami s různou prestiží. Open-source aspekt na jednu stranu otevírá dveře široké komunitě s možností podílet se na tvorbě, ale také prezentuje hackerům potenciální slabiny v kódu – hack Wormhole je trefným příkladem.

Pravděpodobně se shodneme na tom, že poslední týden Solaně na popularitě nepřidá. Nyní ovšem na hack samozřejmě neměly vliv nějaké bezpečnostní nedostatky PoS či strukturální prvky specifické pro Solanu. Jednalo se čistě o skulinku v kódu.