Blockchain güvenlik denetim şirketi Beosin Alert'in gözlemlerine göre 6 Ağustos'ta Ronin Bridge projesinde zincirler arası varlıkların anormal şekilde geri çekilmesi yaşandı. Beosin güvenlik ekibinin analizine göre, bu anormal davranışın temel nedeni, proje tarafının sözleşmeyi yükselttiğinde, zincirler arası işlem onayı için gereken operatör ağırlığının uygun şekilde başlatılmaması ve yapılandırılmaması ve bu durumun da minimumVoteWeight parametresine neden olmasıdır. sözleşmenin sıfır olması, herkesin imzasının zincirler arası doğrulamayı geçebilmesini sağlar.

Saldırı işlem bağlantısı:

https://etherscan.io/tx/0x2619570088683e6cc3a38d93c3d98899e5783864e15525d5f5810c11189ba6cb

Beosin şu anda bu olayı ele almak için proje ekibiyle işbirliği yapıyor. Bu uzun makalede sizinle birlikte bu işlemdeki iki anormalliği de analiz edeceğiz:

İlk olarak, ekstraksiyon miktarı çok yüksektir. Ronin Bridge'de zincirler arası para çekme miktarında bir limit bulunmaktadır. Eğer zincirler arası para çekme tutarı çok büyükse bu işlem için çapraz zincir varlığının WETH limiti 4.000'dir. . Bu işlem 3996'yı çıkardı. Bu bir bug değil elbette ama dikkat çekmeye yetiyor.

İkinci olarak, bu para çekme işlemine baktığımızda yalnızca bir adet çapraz zincir doğrulama Operatörünün olduğunu ve buna karşılık gelen işlem ağırlığının 0 olduğunu gördük. Bu, bu işlemde bir sorun olduğunu doğruluyor çünkü Ronin Bridge projesinde kullanıcılar çapraz para çekiyor -zincir varlıkları. Birden fazla Operatörün imzasının alınması gerekir ve biriken ağırlığın belirtilen eşiğe ulaşması gerekir.

Olay analizi:

Zincirdeki sözleşmeleri ve verileri analiz ederek, Sözleşme Operatörünün ilgili Yönetici sözleşmesi tarafından bağımsız olarak yönetildiğini ve bunun özellikle ronin köprüsünü yönetmek için kullanılan bir yönetim sözleşmesi olduğunu gördük. İşlem kayıtlarını kontrol ederek en son işlemin olduğunu gördük. Ronin Köprüsü sözleşmesini geliştirmek için ve olağandışı işlemden hemen önce. Dolayısıyla zafiyetin genel yönü temelde açıktır. Proje tarafının sözleşmeyi yükseltmesinden kaynaklanan bir sorun olmalıdır.

Daha da ileri giderek, Ronin Bridge yükseltmesinden önceki ve sonraki kodları karşılaştırarak, etkinlikte kullanılan "_totalOperatorWeight" anahtar parametresinin bu yükseltmeye yeni eklendiğini ve yükseltme sırasında "OperatorWeight'ı başlatmak için startupizeV3 işlevinin çağrılması gerektiğini bulduk. " V3 sürümüne eklendi.​

Ancak ne yazık ki: sözleşmeyi yükseltme işleminde, startupizeV3 işlevi çağrılmadı, ancak V4 sürümünü başlatmak için yanlışlıkla startupizeV4 işlevi çağrıldı.

Bu noktada, bu olayın güvenlik açığı prensibi anlaşılmıştır. Ronin Bridge proje ekibi, sözleşme yükseltmesi sırasında yeni verileri doğru bir şekilde başlatmamış ve ilgili anahtar verinin "_totalOperatorWeight" her zaman 0 olmasına ve böylece herhangi bir kullanıcının çıkarma isteğinin gerçekleşmesine neden olmuştur. incelemeyi geçebilir.

Bu yazının yayınlanmasından önce proje ekibi sorunu doğrulamış ve saldırının beyaz şapkadan kaynaklandığını belirten bir belge yayınlamış ve aşırı kayıplara yol açmadan para iadesi gerçekleştirmişti. Bu iyi bir haber ama aynı zamanda sözleşme yükseltmeleri için bir tehlikeyi de ortaya çıkarıyor.

Yükseltilebilir sözleşme

Yükseltilebilir sözleşmeler, dağıtılan sözleşmelerin gelecekte tamamen yeniden konuşlandırmaya gerek kalmadan yükseltilmesine veya değiştirilmesine olanak tanıyan sağlam bir akıllı sözleşme tasarımıdır. Bu konseptin özü, sözleşmenin mantığını ve verilerini ayırmak ve çağrıyı mantıksal sözleşmeye uygulamak için "delege çağrısı"nı kullanmaktır.

Bu model esnek yükseltme yetenekleri sunsa da güvenliğine de büyük önem vermeliyiz. Proxy sözleşmesi tüm kullanıcı isteklerinin iletilmesinden sorumlu olduğundan aslında sözleşme sisteminin giriş noktası haline gelir. Vekalet sözleşmesine yapılacak herhangi bir saldırı, sözleşmenin tamamının güvenliğini etkileyebilir. Bu nedenle yükseltilebilir sözleşmeler tasarlanırken ve dağıtılırken proxy modelinin güvenliğinin sağlanması çok önemlidir. Mevcut acentelik modeli sözleşmelerinde aşağıdaki hususlara dikkat edilmesi gerekmektedir:

İşlev seçici çakışması

Ethereum Sanal Makinesinde (EVM), her akıllı sözleşme işlevinin, işlev seçici adı verilen benzersiz bir tanımlayıcısı vardır. Bu seçici, işlev imzasının ilk 4 baytının karma değeridir. İşlev seçici, sözleşmedeki belirli işlevi belirlemek ve çağrı isteğinin ilgili işlev uygulamasına doğru şekilde yönlendirilmesini sağlamak için kullanılır. Proxy modunda bir işlev çağrılırken, öncelikle proxy sözleşmesindeki işlev arayüzünün çağıran işlevle eşleşip eşleşmediğini kontrol eder. Eşleşemezse, geri dönüşteki temsilci çağrısı mantıksal sözleşmeyi çağırmak için kullanılır.

Bu nedenle, proxy sözleşmesinde ve mantıksal sözleşmede aynı işlev seçiciye sahip bir işlev mevcutsa, proxy sözleşmesi çağrıyı aldığında mantık sözleşmesi yerine doğrudan proxy sözleşmesindeki işlevi çağırır ve bu durum beklenmeyen davranışlara veya güvenlik açıkları.

depolama çakışması

Ethereum Sanal Makinesinde (EVM), bir sözleşmenin durum verileri belirli depolama yuvalarında depolanır ve her depolama yuvasının adresi, endeksine göre (0'dan başlayarak) belirlenir. Sözleşmedeki her durum değişkeni bir depolama yuvasına karşılık gelir ve veriler bu yuvalarda kalıcı olur.

Proxy modelinde, depolama yuvaları genellikle proxy sözleşmeleri tarafından yönetilir ve mantıksal sözleşmeler bu yuvalara proxy sözleşmesi aracılığıyla erişir. Mantık sözleşmesindeki yeni durum değişkenleri aracı sözleşmesindeki mevcut durum değişkeni yuvalarıyla çakıştığında depolama çakışmaları meydana gelebilir. Bu, vekalet sözleşmesindeki verilerin üzerine yazılmasına veya tutarsız olmasına neden olabilir

Sözleşme başlatma sorunu

Aracı modunda, aracı sözleşmesi ile mantıksal sözleşmenin ayrılması nedeniyle, her yükseltme, değişkenlerde değişiklik ve eklemeler içerebilir; bu nedenle, yükseltme sırasında bu anahtar değişkenlerin doğru şekilde ayarlandığından emin olmalısınız. Bu seferki Ronin Köprüsü olayı da bu sorunun çözülememesinden kaynaklandı ve saldırıya yol açtı.

Ek olarak, kötü niyetli saldırganların başlatma sonrasında tekrar tekrar çağırarak anahtar değişkenleri değiştirmesini önlemek için başlatma fonksiyonunun yalnızca bir kez çağrılabilmesinin sağlanması gerekir.

ldelegatecall çağırma mekanizması

temsilci çağrı, bir sözleşmenin kendi bağlamı içinde başka bir sözleşmenin kodunu yürütmesine olanak tanıyan düşük düzeyli bir çağrı mekanizmasıdır. Bu, çağıran sözleşmenin depolama alanı, adresi ve mesaj göndericisinin aynı kaldığı ancak yürütülen mantığın çağrılan hedef sözleşmeden geldiği anlamına gelir. Temsilci çağrısı güçlü işlevler sağlasa da dikkatli kullanılması gerekir.

Hedef sözleşme adresi mevcut değilse, temsilci çağrısının yürütülmesi başarısız olur ve bir hata kodu döndürür, ancak bu hata hemen fark edilmeyebilir. Sonuç olarak, vekalet sözleşmesindeki çağrılar başarılı gibi görünebilir, ancak fiili işlem gerçekleşmez ve bu da sistemde tutarsızlıklara veya hatalara yol açar.

Acente sözleşme otoritesi yönetimi

Proxy modunda izin yönetimi başka bir kritik güvenlik sorunudur. Proxy modeli, sözleşmenin veri depolama alanı değiştirilmeden yükseltilebilmesi için proxy sözleşmesinin ve mantıksal sözleşmenin sorumluluklarını ayırır, ancak aynı zamanda karmaşık izin yönetimi sorunlarını da beraberinde getirir. İzinlerin doğru şekilde yönetilmesi, sözleşme sisteminin güvenliğini ve istikrarını sağlamak için çok önemlidir.

Dünyada resmi doğrulamayı gerçekleştiren ilk blockchain güvenlik şirketlerinden biri olan Beosin, "güvenlik + uyumluluk" tam ekolojik işine odaklanıyor. Dünya çapında 10'dan fazla ülke ve bölgede şubeler kurmuştur ve iş alanı kod içermektedir. projeler çevrimiçi hale gelmeden önce güvenlik denetimleri, "tek noktadan" blockchain uyumluluk ürünleri + proje operasyonu sırasında güvenlik riskinin izlenmesi ve engellenmesi, çalıntı kurtarma, sanal varlık kara para aklamayı önleme (AML) ve yerel düzenlemelere uygun uyumluluk değerlendirmeleri gibi güvenlik hizmetleri. gereksinimleri.