Wormhole Köprü Hack’i: 326 Milyon Dolar Değerindeki Sömürü Teknik Analizi

2 Şubat 2022’de, Wormhole token köprüsü yaklaşık 326 milyon dolara tekabül eden 120.000 wETH kaybetti. Bu, DeFi tarihindeki en büyük akıllı sözleşme sömürülerinden biri olarak kabul edilmektedir. Bu saldırı, çalınmış anahtarlar, sosyal mühendislik veya Guardian doğrulayıcı ağının çoğunluk kontrolü gerektirmedi. Gereken tek şey, hangi hesabın okunduğunu doğrulamayan eski bir Solana program API’siydi.

Bu sömürüyü anlamak, Solana üzerine inşa eden her ekip, zincirler arası mesajlaşmaya dayanan her protokol ve Solana programlarını inceleyen her denetçi için kritik önemdedir. Sorunun kökü, Wormhole Solana köprü programındaki bir akıllı sözleşme doğrulama hatasıydı — bir anahtar sızıntısı ya da Guardian ağı arızası değil. Guardian anahtarlarına hiç dokunulmadı. Köprünün kendi kodu saldırgana verilmeyecek yetkiyi verdi.

Wormhole hack’indeki temel teknik zafiyet neydi?

Zafiyet Wormhole’un Solana köprü programındaki (bridge.so) verify_signatures komutunda bulunuyordu. Bu fonksiyon, Guardian düğümlerinden gelen Ed25519 veya Secp256k1 imzalarını içeren SignatureSet hesabının gerçek bir konsensüsü temsil ettiğini doğrulamak ve bir Doğrulanabilir Eylem Onayı’nı (VAA) yetkilendirmekle sorumluydu.

Hata şu: verify_signatures, aynı işlem içinde daha önce çağrılmış bir Secp256k1 ön-doğrulama komutunu kontrol etmek için eski solana_program::sysvar::instructions::load_instruction_at fonksiyonunu kullanıyordu. Bu eski varyant, kendisine geçirilen hesabın aslında Solana instructions sysvar (Sysvar1nstructions1111111111111111111111111) olup olmadığını doğrulamıyordu. Bu fonksiyon, adlandırılmış dizinde bulunan herhangi bir hesabı okuyor — çağıranın tamamen kontrol ettiği bir hesap da dahil.

Bir saldırgan, instructions sysvar düzenini taklit eden, saldırgan tarafından kontrol edilen imza verileriyle önceden doldurulmuş sahte bir hesap geçirebilir. Fonksiyon sahte veriyi okur, Secp256k1 çağrısının “var olduğunu” (bambaşka bir bağlamda) bulur, VAA’yı Guardian onaylı olarak işaretler ve başarılı dönüş yapar.

Sahte onaylı bir VAA elinde, saldırgan complete_wrapped‘i çağırdı; bu fonksiyon, köprü programının VAA onayını Solana’da sarmalanmış varlıklar basımı için yetki olarak kabul eder. Sonuç: Ethereum’da ETH kilitlenmeden 120.000 wETH basılmış oldu.

Bir düzeltme — load_instruction_at‘in, hesabın gerçekten instructions sysvar olup olmadığını zorunlu kılan load_instruction_at_checked ile değiştirilmesi — sömürü gerçekleşmeden önce Wormhole GitHub deposuna işlenmişti ancak mainnet’e henüz dağıtılmamıştı.

Wormhole açığı Ronin gibi diğer köprü saldırılarından nasıl farklıydı?

Ronin köprü hack’i (Mart 2022, ~625 milyon dolar) genellikle Wormhole ile birlikte köprü güvenlik hataları konuşulurken anılır. Ancak temel olarak farklı arıza türleridir.

Wormhole, Solana köprü programındaki akıllı sözleşme doğrulama hatasıydı. 19 düğümlü eşiğe dayalı Guardian ağı asla ele geçirilmedi. Saldırgan, verify_signatures‘in okuduğu hesabı asla kontrol etmemesi yüzünden ağı tamamen atlattı. Guardian anahtarları sağlamdı, ağ çalışıyordu, ancak bunların hiçbiri kodun gerçek Guardian konsensusunu sormaması nedeniyle alakasızdı.

Ronin ise işletme anahtarı hırsızlığıydı. Sky Mavis, Ronin’in dokuz doğrulayıcı düğümünden beşini işletiyordu. Kasım 2021’de Axie DAO, işlem yükünü idare etmesi için imza yetkisini Sky Mavis’e geçici olarak devretti; bu yetki süresi dolduğunda geri alınmadı. Lazarus Group olarak atfedilen bir saldırgan, Sky Mavis iç sistemlerini ele geçirdi ve dört doğrulayıcı anahtarına erişti. Etkin Axie DAO devri ile Sky Mavis’in ücretsiz RPC düğümü üzerinden beşinci imzayı da elde etti. Dokuzdan beşi geçerli imzaydı ve bunlarla Ronin köprü sözleşmesine gerçek çekme işlemleri gönderildi. Hiçbir akıllı sözleşme açığı kullanılmadı. Köprü beş gerçek doğrulayıcı imzası sunulduğunda tasarlandığı gibi davranarak çekimleri onayladı.

Adım adım: Wormhole sömürüsü nasıl gerçekleştirildi

1. Hesap taklidi. Saldırgan, Wormhole köprü programının komut verisinde beklenen SignatureSet konumunu taklit eden bir Solana hesabı oluşturdu. Bu hesapta saldırganın kontrol ettiği Ed25519/Secp256k1 imzaları vardı; geçerli imzalar ama saldırgana 120.000 wETH basım yetkisi veren kendi VAA yükü üzerinde.

2. Eski sysvar API ile atlatma. Saldırgan, Wormhole’un Solana köprü programına verify_signatures çağrısı içeren bir işlem sundu. Program, daha önce aynı işlemde bir Secp256k1 komutu çağrıldığını doğrulamak için eski, doğrulamasız load_instruction_at fonksiyonunu kullandı. Bu fonksiyon, verilen dizindeki hesabın gerçek instructions sysvar olup olmadığını doğrulamadı.

3. Sahte kanıt kabul edildi. verify_signatures, saldırganın kontrol ettiği hesapta saklanan imzaları inceledi, kriptografik olarak geçerli buldu (saldırgan kendisi imzalamıştı), VAA’yı Guardian onaylı olarak işaretledi. Guardian ağı hiç sorgulanmadı.

4. Basım yetkisi verildi. Saldırgan, onaylı VAA ile complete_wrapped fonksiyonunu çağırdı. Köprü programı VAA onay durumuna güvenerek saldırganın Solana adresine 120.000 wETH bastı.

5. Zincirler arası çıkarım. Saldırgan basılan wETH’yi Wormhole’un yasal zincirler arası akışını kullanarak Ethereum’a geri köprüledi. wETH saldırganın Solana cüzdanında görünce köprü çekimi normal transfer gibi işledi. 326 milyon dolar değerindeki desteklenmeyen wETH Ethereum’a geldi, saldırgan ETH ve stablecoin’lere çevirip çıktı. Wormhole’un ana şirketi Jump Crypto, çalınan 120.000 ETH’yi kendi rezervlerinden karşılayarak köprü kullanıcılarının zararını giderdi.

Solana programları ve zincirler arası köprüler için en kritik teknik dersler

1. Solana programlarına geçen her AccountInfo, aksi kanıtlanana kadar saldırgan kontrollüdür.

Bu, Solana program güvenliğinin temel kuralıdır. Program, aldığı her hesabın owner, key ve varsa executable, is_signer alanlarını doğrulamalıdır. Eski load_instruction_at fonksiyonu adlandırılmış dizinde hangi hesap varsa kabul ederdi. Yeni load_instruction_at_checked ise okumadan önce hesabın gerçek instructions sysvar olduğunu zorunlu kılar. Soken’in Solana denetim metodolojisi, bağlam fark etmeksizin _checked olmayan sysvar API kullanımlarını Kritik risk olarak işaretler.

2. İmza doğrulama ile varlık basım yetkisinin ayrı tutulması.

Bir köprünün basım yetkisi, kanonik ve program tarafından sahip olunan durumdan yeniden doğrulama yapan bir doğrulama modülünün arkasında olmalıdır — çağıran tarafından verilen hesaplardan değil. verify_signatures saldırgan kontrolündeki hesabı gerçek kabul ettiğinde, “ağ bunu onayladı mı?” ile “basabilir miyiz?” arasındaki ayrım çöktü. Basım komutu, yetkiyi gerçek Guardian girişi doğrulanmış program durumundan türetmelidir.

3. VAA tekrar oynatma koruması zincir üzerinde uygulanmalıdır.

SignatureSet gerçek de olsa, complete_wrapped daha önce tüketilmiş VAA’ları reddetmeliydi. Wormhole sonraki versiyonlarda tekrar oynatma koruması ekledi fakat sömürülen sürümde yoktu; sahte onaylı bir VAA defalarca kullanılabilirdi. Her köprü eylemi, yürütme başında atomik olarak güncellenen tüketilmiş-VAA haritalaması (processed_vaas: mapping[bytes32, bool]) ile sınırlandırılmalıdır.

4. Eski API kullanımı Kritik denetim bulgusudur.

Wormhole zafiyeti bilinen bir deprecasyondu. Solana SDK, sömürüden önce load_instruction_at’i eski ilan etmiş ve _checked sürümünü sunmuştu. Eski API’den geçiş yapılmaması, kod kalitesi değil, aktif olarak saldırganların takip ettiği kritik bir güvenlik açığıdır. Solana denetimleri, solana_program::sysvar::instructions::* kullanan ve _checked olmayan bütün varyantları taramalı, tespit edilenleri başarısızlıkla sonuçlandırmalıdır. Ottersec, Halborn ve Soken gibi firmaların 2022 sonrası standart uygulamasıdır.

5. Yayınlanmamış güvenlik yamaları saldırı haritası sunar.

load_instruction_at_checked düzeltmesi saldırıdan önce Wormhole’un açık deposuna işlenmişti. Hedef protokol depolarındaki kritik güvenlik değişikliklerini takip eden yetkin saldırganlar yalnızca diff’i inceleyerek açığı çıkarabilir. Güvenlik kritik programların dağıtım süreçleri “main dalına merge” ile “mainnet’e dağıtım” arasındaki süreyi aktif bir risk penceresi olarak görmeli, acil dağıtım prosedürleri bu pencereyi birkaç saat içinde kapatmalıdır.

6. Eşik multisig, hesap doğrulama hatalarını telafi etmez.

Wormhole Guardian ağı 19 bağımsız düğümden oluşan eşiğe dayalı imza şeması kullanıyordu. Oldukça sağlamdı ama bu saldırıda tamamen alakasız hale geldi. Sömürü verify_signatures’in hangi hesabı okuduğunu değiştirmekle konsensüs katmanını atlattı. Eşik imzalar Guardian anahtarlarının ele geçirilmesine karşı korur ama Guardian’dan girdi bile istemeyen bir hata karşısında işe yaramaz. Savunma derinliği, her katmanın gerçekten çalışmasını gerektirir — atlattığınız kontrol, kontrol değildir.

Bu durum köprü denetimleri ve Solana program güvenliği için ne anlama geliyor?

Wormhole sömürüsü gösteriyor ki zincirler arası köprü güvenliği çok katmanlı bir meseledir. Guardian ağı matematiksel olarak sağlam olabilir, ekonomik teşvikler doğru hizalanmış olabilir, protokol mimarisi iyi tasarlanmış olabilir — ancak zincir üzerindeki programdaki tek bir eski fonksiyon çağrısı tüm bunları anlamsız kılabilir.

Solana üzerine inşa eden ekipler için hesap doğrulama dersi genelleştirilir: programınıza geçen her parametreyi düşmanca veri olarak değerlendirin. Her hesabın owner, key, discriminator ve veri uzunluğunu kullanmadan önce doğrulayın. Anchor framework’ün Account<T> sarmalayıcısı ya da benzeri mekanizmalarla bu kontrolleri tür seviyesinde zorunlu kılın.

Köprü mimarları için ders şudur: ayrıcalık ayrımı ve kanonik durum sabitlemesi. Basım yetkisi, programın kendisi tarafından doğrulanmış program sahipli durumdan gelmeli — doğrulanmadan kabul edilen çağıran kanıtlarından değil.

Soken, tüm Solana programlarında eski sysvar API kullanımı, eksik hesap sahibi kontrolleri ve VAA tekrar oynatma koruma boşluklarını Kritik öncelikli sorunlar olarak denetler. Wormhole modeli — çoklu imza eşiğini, doğrulama fonksiyonunun okuduğu hesabı manipüle ederek atlatma — artık Soken’in Solana denetim metodolojisinde tanımlanmış bir saldırı sınıfıdır. Protokolünüz zincirler arası mesajlaşma veya sarmalanmış varlık basımı kullanıyorsa, dağıtımdan önce bir güvenlik incelemesi için bize soken.dev/services-it.html adresinden ulaşın.