DeFi endüstrisi, bir güvenlik açığından yararlanma olayının ardından kaosa sürüklendi. DeFi sektörünün devlerinden Curve Finance, ciddi bir "saldırının" hedefi haline geldi ve alETH/msETH/pETH gibi birden çok stablecoin havuzu risk altında. Eksik istatistiklere göre güvenlik açığından yararlanma olayı, Alchemix, JPEG'd, MetronomeDAO, deBridge, Ellipsis ve CRV/ETH havuzlarında toplam 52 milyon ABD doları kayba neden oldu ve tüm pazarın güveni ciddi şekilde sarsıldı.
Vyper 0.2.15, 0.2.16 ve 0.3.0 sürümlerinin yeniden giriş kilitleri geçersizdir ve Vyper resmi belge kurulum arayüzü yanlış bir sürüm önerir. Vyper derleyicisini kullanan diğer proje tarafları da bir sonraki kurban olmayacaklarından emin olmak için kendi kendini incelemeye koştu. Güvenlik açığından yararlanma olayının kaynağı yavaş yavaş ortaya çıktıkça, piyasa yavaş yavaş bu krizin yalnızca sıradan bir hacker istismarı olayı anlamına gelmediğini, aynı zamanda tüm temel yığının tüm DeFi endüstrisine yönelik potansiyel büyük riskini de ortaya koyduğunu fark ediyor.
Geçmişle karşılaştırıldığında, önceki dönemde bilgisayar korsanlığı olaylarının sayısı giderek azaldı, bu da pazarın refahından ayrılamaz. DeFi yazı ve NFT yazı boyunca her hafta yeni milyar dolarlık anlaşmalar başlatıldı, günümüz piyasasına kıyasla çok daralıyor. Aynı zamanda, bilgisayar korsanlarının açıkları bulma veya büyük ölçekli saldırılar oluşturma pazar fırsatları giderek azalıyor, bu da bilgisayar korsanlarının keşfetmek için daha yeni, kullanılmayan giriş noktalarına ihtiyaç duyduğu anlamına geliyor.
"İlk prensiplere" dönen bilgisayar korsanları, DeFi pazarındaki devasa ve lezzetli "pastayı" yemek için alt düzey derleyicide mükemmel bir giriş noktası bulmuşlardır. Alt düzey derleyici, daha "akıllı" bir bilgisayar korsanı haline gelmiştir. Seçenek. BlockBeats, akıllı sözleşme geliştiricisi Box (@BoxMrChen) ve BTX araştırmacısı Derek (@begas_btxcap) ile bu olay ve ortaya çıkardığı ilgili sorunlar hakkında röportaj yaptı.
Eğri olayı nasıl gerçekleşir?
Aave ve Lens'in kurucusu Stani (@StaniKulechov), sosyal medyada olayla ilgili görüşlerini şöyle dile getirdi: "Bu, Curve ve DeFi için talihsiz bir gerileme. zor ve riskler yüksek. Curve'ün durumunda, bunu protokol düzeyinde anladılar."
Curve'ün maruz kaldığı istismar, Ethereum akıllı sözleşmelerine yönelik en eski ve belki de en yaygın saldırı biçimlerinden biri olan yeniden giriş saldırısıdır. Yeniden giriş saldırıları, bir saldırganın bir akıllı sözleşmenin bir işlevini, o işleve yapılan önceki çağrının tamamlanmasını beklemeden tekrar tekrar çağırmasına olanak tanır. Bu şekilde, mağdurun sözleşmesindeki fonlar bitene kadar para çekmek için boşluğu kullanmaya devam edebilirler.
Yeniden giriş kilidi ve CEI prensibi
Yeniden giriş saldırılarını göstermek için basit bir örnek verin: bir bankanın toplam 100.000 nakit parası vardır. Ama bu bankanın büyük bir açığı var, insanlar ne zaman para çekse banka çalışanları hesap bakiyesini hemen güncellemeyip kontrol edip güncellemek için gün sonuna kadar bekliyorlar. Bu sırada birisi bu boşluğu fark etti, bankada bir hesap açtı, önce 1.000 yuan yatırdı, sonra 1.000 yuan çekti ve 5 dakika sonra 1.000 yuan çekti. Banka bakiyeyi gerçek zamanlı olarak güncellemediğinden sistem, kontrol edip güncellemeden önce hesabında hala 1.000 yuan olduğunu düşünecektir. Tekrarlanan işlemlerle, kullanıcı nihayet bankadaki tüm 100.000 ABD dolarını çıkardı. Banka, boşluğun kötüye kullanıldığını ancak günün sonuna kadar fark etti.
Yeniden giriş saldırısının karmaşıklığı, sözleşmeler ile sözleşmenin mantıksal boşlukları arasındaki karşılıklı çağrıdan yararlanması ve kasıtlı olarak istisnaları ve geri alma işlevlerini tetikleyerek hileli davranışlar gerçekleştirmesinde yatmaktadır. Saldırganlar, fon çalmak için sözleşmedeki mantık boşluklarından defalarca yararlanabilir. Yeniden giriş saldırılarını önleme çözümü de çok yaygındır.Koruma için önceden hedeflenen özel bir kod içeriği belirlenir ve fonların güvenliğini sağlamak için böyle bir koruma mekanizması kullanılır.Buna yeniden giriş kilidi denir.
Sağlamlık, akıllı sözleşme programlaması için işlevleri yeniden giriş saldırılarından iyi bir şekilde koruyabilen bir "CEI ilkesi" (Etki Etkileşimlerini Kontrol Et) belirler. CEI ilkelerinin içeriği şunları içerir:
İşlev bileşenlerinin çağrılma sırası şu şekilde olmalıdır: birincisi, inceleme, ikincisi, durum değişkenleri üzerindeki etki ve son olarak, harici varlıklarla etkileşim.
Harici varlıklarla etkileşime geçmeden önce, tüm durum değişkenleri güncellenmelidir. Bu, etkilerin etkileşim fiilen gerçekleşmeden önce yazıldığı "iyimser defter tutma" olarak adlandırılır.
Çağıran varlığın fonksiyonu çağırma izni olduğundan emin olmak için fonksiyonun başında kontroller yapılmalıdır.
Yeniden giriş saldırılarını önlemek için durum değişkenleri herhangi bir harici çağrıdan önce güncellenmelidir.
Güvenilir harici kuruluşlar bile, kontrol akışını kötü niyetli üçüncü taraflara aktarabilecekleri için CEI modelini izlemelidir.
Belgelere göre, CEI ilkeleri bir sözleşmenin saldırı yüzeyini sınırlamaya, özellikle yeniden giriş saldırılarını önlemeye yardımcı olur. CEI ilkeleri, herhangi bir mantık değiştirilmeden, esas olarak fonksiyon kodları sırasında kolayca uygulanabilir. The DAO'nun Ethereum'un çatallanmasına yol açan iyi bilinen istismarı da "CEI ilkesini" göz ardı etti ve saldırgan, yıkıcı sonuçlara neden olan bir yeniden giriş saldırısı gerçekleştirdi.
Ancak saldırı altındaki Curve havuzu bu CEI ilkesini takip etmedi çünkü Curve Vyper derleyicisini kullanıyor. Derleyicinin Vyper kod güvenlik açığı olarak, reentrancy lock başarısız olur ve hacker'ın reentrancy saldırısının başarılı bir şekilde gerçekleştirilmesini sağlar.
Çoğu kişi Solidity'i bilir, ancak akıllı sözleşmeler oluşturmak için tek dil Solidity değildir. Solidity'nin popüler bir alternatifi Vyper'dır. Vyper, Solidity kadar güçlü ve popüler olmasa da, Python'a aşina geliştiriciler için idealdir çünkü Vyper, Python benzeri kodu Ethereum akıllı sözleşme programlama diline çevirebilir.
Github bilgilerine göre Vyper'ın github kod tabanına ilk katkıyı yapan geliştirici aynı zamanda Curve'un da geliştiricisi. Curve'ün neden Solidity yerine Vyper kullandığını açıklamak zor değil.
![Hackerlar "ilk ilkelere" dönüyor, Curve krizi sıradan bir saldırı değil] (https://img-cdn.gateio.im/resize-social/moments-40baef27dd-c30cf03f91-dd1a6f-1c6801)
Vyper yeniden giriş kilidi neden başarısız oluyor?
Peki bu saldırıda Vyper ile ilgili sorun nedir? Yeniden giriş kilidi neden başarısız oluyor? Test olmadığı için mi? BlockBeats, akıllı sözleşme geliştiricisi Box 826.eth (@BoxMrChen) ile röportaj yaptı, ona göre Vyper giriş kilidi kullanım durumlarıyla test edildi. Ancak başarısızlığın nedeni test senaryosunun sonuç odaklı olmasıdır yani test senaryosunun da yanlış olmasıdır.
Kısacası Vyper reentrancy lock'un başarısız olmasının en büyük sebebi, test case'ini yazan kişinin slotun neden 1'i açıklanamayacak şekilde atlayacağını düşünmeden test case'ini sonuca göre yazmasıdır.
![Hackerlar "ilk ilkelere" dönüyor, Curve krizi sıradan bir saldırı değil] (https://img-cdn.gateio.im/resize-social/moments-40baef27dd-0527942e35-dd1a6f-1c6801)
Box'ın paylaştığı Vyper kodunun aşağıdaki paragraflarında sorun açıkça görülüyor. Kilit adı ikinci kez göründüğünde, depolama_slot sayısının üzerine yazılacaktır, yani ret'te, kilidin ilk edinimi için yuva 0'dır, ancak bir işlev kilidi tekrar kullandıktan sonra, kilit yuvası bir eklenir. Derlemeden sonra yanlış yuva kullanılır ve yeniden giriş kilidinin etkinleşmemesine neden olur.
![Hackerlar "ilk ilkelere" dönüyor, Curve krizi sıradan bir saldırı değil] (https://img-cdn.gateio.im/resize-social/moments-40baef27dd-87ec9b545c-dd1a6f-1c6801)
Soldaki saldırı kodu, sağdaki ise onarılan koddur.
"Yanlış test sonuçları bekleniyor ve tabii ki hiçbir hata doğrulanamıyor. Basit bir örnek vermek gerekirse şu anda bir hesaplama problemi yapıyoruz 1+ 1 = 2 ama verilen standart cevap 1+ 1 = 3 diyerek yanlış. . Ve bu soruyu yapan sınıf arkadaşı yanlış cevap verdi ve 1+ 1 = 3 diye cevapladı, ancak önceden verilen standart cevapla aynıydı, bu nedenle programın doğal olarak test sonucunun yanlış olduğunu belirlemesinin bir yolu yoktu. yanlış." Box, BlockBeats ile yaptığı bir röportajda söyledi.
İki yıldır asılı "Damokles'in Kılıcı"
Tarihte kaydedilen ilk yeniden giriş saldırısı olayında, WETH Attack saldırganları, daha fazla projeyi yeniden giriş saldırılarına karşı bağışık hale getirmek amacıyla, geliştiricilerin yeniden giriş saldırılarına dikkat etmesini sağlamak için kasıtlı olarak saldırılar oluşturan beyaz bilgisayar korsanlarıdır. Akıllı sözleşmeler bağlamında geliştiriciler, koruma elde etmek için durum değiştirme işlevini çağırmak gibi farklı tetikleme mekanizmaları kullanmalıdır. Bu, geliştiricilerin sözleşmeleri tasarlarken olası saldırı senaryolarını tam olarak dikkate almalarını ve uygun önlemleri almalarını gerektirir.
BlockBeats, Vyper editörünü derinlemesine anlamak için BTX araştırmacısı Derek (@begas_btxcap) ile röportaj yaptı ve Python'a aşina olan geliştiriciler için Vyper'ın Solidity'den daha ideal bir seçim olduğunu ve daha rahat bir kullanıcı arabirimi olduğunu söyledi. ve daha hızlı öğrenme. Ancak görünüşe göre, Vyper editör kodunun bazı sürümleri güvenilir bir üçüncü tarafça denetlenmemiş. Hatta bazı denetim çalışmaları geliştiricilerin kendileri tarafından yapılabilir. "Geleneksel BT endüstrisinde bu tür şeyler olmayacak, çünkü yeni bir dil çıktıktan sonra, boşluklarınızı arayan sayısız denetim şirketi olacak."
Bir hatanın iki yıl boyunca açık bir şekilde var olmasına izin vermekten bahsetmiyorum bile.
Vyper yazarı fubuloubu da şunları söyledi: Derleyici herkesin sandığı kadar gözden geçirilmiş veya denetlenmiş değil. Derleyicilerin çoğu, denetimi bir dezavantaj haline getiren önemli ve sık değişikliklere sahiptir. Tam bir kod tabanı denetiminde bile, bundan sonra daha fazla sürüm eklendikçe güncelliğini yitirecektir. Derleyiciyi denetlemek iyi bir fikir değildir, çünkü aracı kullanan son kullanıcı tarafından üretilen nihai ürünü (yani ham EVM kodunu) denetlemek daha mantıklıdır.
Bütün bunlar son bir soruna işaret ediyor: motivasyon. Bununla birlikte, hiç kimsenin derleyicilerde, özellikle eski sürümlerde kritik hatalar bulmaya teşviki yoktur. fubuloubu daha önce kullanıcıların ortak sponsorluğunda bir ödül programı ekleyerek Vyper'ı iyileştirmeye yardımcı olacak bir teklifte bulunmuştu, ancak bu öneri gerçekleşmedi.
Bilgisayar Korsanları "İlk İlkelere" Geri Dönüyor
Bu, protokol ve proje geliştiricileri için sözleşmeye uygun geliştirme uygulamalarının canlı bir örneğidir. Ama en önemlisi Curve olayı hepimize altta yatan derleyicinin güvenliğinin ciddi anlamda göz ardı edildiği ve "ilk prensiplere" dönen bilgisayar korsanlarının alt derleyicide mükemmel bir tane buldukları konusunda bir uyarı verdi.
Ardından, Aave ve Lens'in kurucusu Stani (@StaniKulechov) da duygularını ifade etmek için sosyal medyada uzun bir makale yayınladı: Curve'a yapılan saldırı, DeFi riskinin her zaman tüm temel yığını, programlama dilini, EVM'yi kapsadığı anlamına gelir. , vesaire. Bu, özellikle gelecekte özel EVM'leri ve uygulama zincirlerini kullanırken daha dikkatli ve hassas olmamız konusunda bizi uyarıyor.
![Hackerlar "ilk ilkelere" dönüyor, Curve krizi sıradan bir saldırı değil] (https://img-cdn.gateio.im/resize-social/moments-40baef27dd-3324fcfbcd-dd1a6f-1c6801)
Daha düşük bir seviyeden saldırılar
Derleyici güvenlik açıklarını yalnızca sözleşme kaynak kodunun mantığını denetleyerek bulmak zordur. Sadece sürümler ve sürümler arasındaki farkları araştırmak da büyük bir projedir. Akıllı sözleşmelerin derleyici güvenlik açıklarından etkilenip etkilenmediğini belirlemek için belirli derleyici sürümlerini belirli kod modelleriyle birleştirmek gerekir.
"Şu anda yalnızca iki derleyici en iyisidir, Vyper'ın kod tabanı daha küçüktür, okunması daha kolaydır ve geçmişini analiz etmek için daha az değişikliğe sahiptir, muhtemelen bilgisayar korsanlarının buradan başlamasının nedeni budur, Solidity'nin kod tabanı biraz daha büyüktür ”fubuloubu bundan şüpheleniyor bile- destekli bilgisayar korsanları bu Eğri saldırısına dahil olabilir: "Güvenliği bulmak haftalar veya aylar alabilir ve yatırılan kaynaklar göz önüne alındığında, küçük bir grup veya ekip tarafından gerçekleştirilebilir."
Şifreleme endüstrisinde en yaygın kullanılan derleme dili olan Solidity'nin güvenliği, kullanıcılar tarafından daha da fazla endişelendiriliyor.Sonuçta, Solidity derleyicisi bu kez yeniden giriş kilidi hatası sorunu yaşarsa, o zaman tüm DeFi endüstrisinin geçmişi geçmiş olabilir. yeniden yazılacak.
Solidity geliştirme ekibi tarafından düzenli olarak yayınlanan güvenlik uyarılarına göre, Solidity derleyicisinin birçok farklı sürümünde güvenlik açıkları olmuştur.
Günlüğe kaydedilen en son derleyici hatası, abi.error kullanımıyla ilgili bir güvenlik raporu araştırılırken 26 Haziran'da kaydedildi. Eski kod oluşturucu atamalar, işlev çağrıları veya .selector'a erişilen koşullar gibi karmaşık ifadeleri değerlendirmedi. Bu, bu tür ifadelerin yürütülmemesinin yan etkilerine neden olur, bu nedenle eski ardışık düzen ile derlenen sözleşmeler yanlış davranabilir.
Solidity'nin Github deposunda, Solidity derleyicisinde güvenlikle ilgili bilinen bazı hataları listeleyen bir dosya da görebiliriz. Liste, 0.3.0 sürümüne geri döner, yalnızca bu sürümden önce var olan hatalar listelenmez. Burada başka bir bugs_by_version.json dosyası var. Bu dosya, belirli bir derleyici sürümünün hangi hatalardan etkilendiğini sorgulamak için kullanılabilir.
Neyse ki, tam olarak Solidity dilinin geniş uygulaması ve Ethereum Vakfı'nın desteği sayesinde, dağıtım sürecinde projeler ve protokoller tarafından birçok mevcut soruna dikkat çekilmiştir. Bu nedenle Solidity, Vyper'dan birkaç adım daha hızlı modifikasyon ve geliştirmeyi tamamlamıştır.Bu açıdan Solidity'nin daha standart ve güvenli olmasının sebeplerinden biri de budur.
Solidity geliştiricilerinin daha iyi test yapmasına ve aynı şeyin olmasını engellemesine yardımcı olmak için. UnitasProtocol kurucu ortağı SunSec (@ 1 nf 0 s 3 cpt), Curve saldırısından sonra güvenlik açığı açıklamaları, senaryolar, savunmalar, güvenlik açığı kodları ve azaltma önlemleri ve nasıl test edileceği dahil olmak üzere 47 tür güvenlik açığını destekleyen bir DeFiVulnLabs Solidity güvenlik testi kılavuzu yayınladı. .
Düşük seviyeli saldırılardan mümkün olduğunca nasıl kaçınılır?
Bu Eğri olayında Box, tüm geliştiriciler için aydınlanmanın şu olduğuna inanıyor: teknolojik trendi takip etmeye çalışmayın ve olgun olmayan çözümler seçmeyin; test senaryoları yazmadan kendi kodunuzu onaylamayın (Vyper'ın sorunları olan birkaç versiyonu test senaryoları yanlış); kendi kodunuzu asla kendiniz onaylamayın; bazı servetlerin keşfedilmesi yıllar alabilir; yükseltilemezlik, kendinize karşı kibir ve başkalarını hor görmektir.
Genellikle, geliştiriciler burada herhangi bir tuzak düşünmezler ve istedikleri zaman derlemek için bir sürüm seçerler; bu, sürümler arasındaki farklılıkların getirdiği riskleri göz ardı edebilir. Küçük sürüm yükseltmeleri bile, merkezi olmayan uygulamalar geliştirirken özellikle önemli olan önemli değişiklikleri getirebilir.
Bu Curve etkinliğinden geliştiricilere yönelik uyarılar şunlardır: derleyici dilinin daha yeni bir sürümünü kullanın. Kod tabanınızı, uygulamalarınızı ve işletim sisteminizi güncel tutmanız ve her açıdan kendi güvenlik savunmanızı oluşturmanız önemlidir. Daha yeni sürümler yeni güvenlik sorunları ortaya çıkarsa da, genellikle eski sürümlere göre daha az bilinen güvenlik sorunu vardır. Elbette zamanında topluluk ve resmi sürüm güncelleme duyurularına da dikkat etmeliyiz. Her sürümün getirdiği değişiklikleri anlayın ve kendi kod tabanınızı ve işletim ortamınızı gerektiği gibi güncelleyin. Bu adımları uygulamak, derleyici hatalarından kaynaklanan güvenlik olaylarını büyük ölçüde azaltabilir.
Ek olarak, kodu tamamlamak için birim test durumları. Derleyici düzeyindeki hataların çoğu, yalnızca kod incelemesi yoluyla bulunması zor olan ancak test sırasında ortaya çıkabilen tutarsız kod yürütme sonuçlarına yol açacaktır. Kod kapsamının iyileştirilmesi, bu tür sorunların önlenmesine yardımcı olabilir. Açık bir ihtiyaç olmadıkça satır içi derleme ve çok boyutlu dizi kodlama ve kod çözme gibi karmaşık dil özelliklerini kullanmaktan kaçının. Solidity dil güvenlik açıklarının çoğu tarihsel olarak bu gelişmiş özelliklerle ilişkilendirilmiştir. Geliştiriciler, belirli bir ihtiyaç olmaksızın gösteriş yapmak adına deneysel dil özelliklerini kullanmaktan kaçınmalıdır.
Protokol katmanı ve güvenlik personeli için kod denetimleri yapılırken derleyici sürümünün olası riskleri göz ardı edilemez. Bilgisayar korsanlarının yeni fikirler ortaya çıkardığı öngörülebilir ve gelecekte, giderek daha fazla sayıda alt düzey güvenlik açıklarından yararlanılacak. Aynı zamanda altta yatan altyapı olarak, altta yatan stack, programlama dili, EVM vb. denetimlerin yapılması gerekir. Gelecekte, denetim şirketlerinin pazarı giderek büyüyecek ve beyaz konuk ikramiyelerinin pazarı da giderek büyüyecek. Vyper ekibi, konu resmi olarak çözüldükten sonra hata ödül programını incelemeye başlamayı da planlıyor.
Tabii ki, altta yatan altyapının riskleri konusunda çok fazla paniğe kapılmamıza gerek yok. Şu anda çoğu derleyici hatası yalnızca belirli kod kalıplarında tetikleniyor ve gerçek etkinin proje durumuna göre değerlendirilmesi gerekiyor. Derleyici sürümünü düzenli olarak yükseltmek ve yeterli birim testi yapmak, risklerin önlenmesine yardımcı olabilir.
View Original
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
Curve'ün bu kez karşılaştığı açık, bilgisayar korsanları için yeni fikirlerin kapısını açabilir.
Yazan Jaleel, BlockBeats
DeFi endüstrisi, bir güvenlik açığından yararlanma olayının ardından kaosa sürüklendi. DeFi sektörünün devlerinden Curve Finance, ciddi bir "saldırının" hedefi haline geldi ve alETH/msETH/pETH gibi birden çok stablecoin havuzu risk altında. Eksik istatistiklere göre güvenlik açığından yararlanma olayı, Alchemix, JPEG'd, MetronomeDAO, deBridge, Ellipsis ve CRV/ETH havuzlarında toplam 52 milyon ABD doları kayba neden oldu ve tüm pazarın güveni ciddi şekilde sarsıldı.
Vyper 0.2.15, 0.2.16 ve 0.3.0 sürümlerinin yeniden giriş kilitleri geçersizdir ve Vyper resmi belge kurulum arayüzü yanlış bir sürüm önerir. Vyper derleyicisini kullanan diğer proje tarafları da bir sonraki kurban olmayacaklarından emin olmak için kendi kendini incelemeye koştu. Güvenlik açığından yararlanma olayının kaynağı yavaş yavaş ortaya çıktıkça, piyasa yavaş yavaş bu krizin yalnızca sıradan bir hacker istismarı olayı anlamına gelmediğini, aynı zamanda tüm temel yığının tüm DeFi endüstrisine yönelik potansiyel büyük riskini de ortaya koyduğunu fark ediyor.
Geçmişle karşılaştırıldığında, önceki dönemde bilgisayar korsanlığı olaylarının sayısı giderek azaldı, bu da pazarın refahından ayrılamaz. DeFi yazı ve NFT yazı boyunca her hafta yeni milyar dolarlık anlaşmalar başlatıldı, günümüz piyasasına kıyasla çok daralıyor. Aynı zamanda, bilgisayar korsanlarının açıkları bulma veya büyük ölçekli saldırılar oluşturma pazar fırsatları giderek azalıyor, bu da bilgisayar korsanlarının keşfetmek için daha yeni, kullanılmayan giriş noktalarına ihtiyaç duyduğu anlamına geliyor.
"İlk prensiplere" dönen bilgisayar korsanları, DeFi pazarındaki devasa ve lezzetli "pastayı" yemek için alt düzey derleyicide mükemmel bir giriş noktası bulmuşlardır. Alt düzey derleyici, daha "akıllı" bir bilgisayar korsanı haline gelmiştir. Seçenek. BlockBeats, akıllı sözleşme geliştiricisi Box (@BoxMrChen) ve BTX araştırmacısı Derek (@begas_btxcap) ile bu olay ve ortaya çıkardığı ilgili sorunlar hakkında röportaj yaptı.
Eğri olayı nasıl gerçekleşir?
Aave ve Lens'in kurucusu Stani (@StaniKulechov), sosyal medyada olayla ilgili görüşlerini şöyle dile getirdi: "Bu, Curve ve DeFi için talihsiz bir gerileme. zor ve riskler yüksek. Curve'ün durumunda, bunu protokol düzeyinde anladılar."
Curve'ün maruz kaldığı istismar, Ethereum akıllı sözleşmelerine yönelik en eski ve belki de en yaygın saldırı biçimlerinden biri olan yeniden giriş saldırısıdır. Yeniden giriş saldırıları, bir saldırganın bir akıllı sözleşmenin bir işlevini, o işleve yapılan önceki çağrının tamamlanmasını beklemeden tekrar tekrar çağırmasına olanak tanır. Bu şekilde, mağdurun sözleşmesindeki fonlar bitene kadar para çekmek için boşluğu kullanmaya devam edebilirler.
Yeniden giriş kilidi ve CEI prensibi
Yeniden giriş saldırılarını göstermek için basit bir örnek verin: bir bankanın toplam 100.000 nakit parası vardır. Ama bu bankanın büyük bir açığı var, insanlar ne zaman para çekse banka çalışanları hesap bakiyesini hemen güncellemeyip kontrol edip güncellemek için gün sonuna kadar bekliyorlar. Bu sırada birisi bu boşluğu fark etti, bankada bir hesap açtı, önce 1.000 yuan yatırdı, sonra 1.000 yuan çekti ve 5 dakika sonra 1.000 yuan çekti. Banka bakiyeyi gerçek zamanlı olarak güncellemediğinden sistem, kontrol edip güncellemeden önce hesabında hala 1.000 yuan olduğunu düşünecektir. Tekrarlanan işlemlerle, kullanıcı nihayet bankadaki tüm 100.000 ABD dolarını çıkardı. Banka, boşluğun kötüye kullanıldığını ancak günün sonuna kadar fark etti.
Yeniden giriş saldırısının karmaşıklığı, sözleşmeler ile sözleşmenin mantıksal boşlukları arasındaki karşılıklı çağrıdan yararlanması ve kasıtlı olarak istisnaları ve geri alma işlevlerini tetikleyerek hileli davranışlar gerçekleştirmesinde yatmaktadır. Saldırganlar, fon çalmak için sözleşmedeki mantık boşluklarından defalarca yararlanabilir. Yeniden giriş saldırılarını önleme çözümü de çok yaygındır.Koruma için önceden hedeflenen özel bir kod içeriği belirlenir ve fonların güvenliğini sağlamak için böyle bir koruma mekanizması kullanılır.Buna yeniden giriş kilidi denir.
Sağlamlık, akıllı sözleşme programlaması için işlevleri yeniden giriş saldırılarından iyi bir şekilde koruyabilen bir "CEI ilkesi" (Etki Etkileşimlerini Kontrol Et) belirler. CEI ilkelerinin içeriği şunları içerir:
İşlev bileşenlerinin çağrılma sırası şu şekilde olmalıdır: birincisi, inceleme, ikincisi, durum değişkenleri üzerindeki etki ve son olarak, harici varlıklarla etkileşim.
Harici varlıklarla etkileşime geçmeden önce, tüm durum değişkenleri güncellenmelidir. Bu, etkilerin etkileşim fiilen gerçekleşmeden önce yazıldığı "iyimser defter tutma" olarak adlandırılır.
Çağıran varlığın fonksiyonu çağırma izni olduğundan emin olmak için fonksiyonun başında kontroller yapılmalıdır.
Yeniden giriş saldırılarını önlemek için durum değişkenleri herhangi bir harici çağrıdan önce güncellenmelidir.
Güvenilir harici kuruluşlar bile, kontrol akışını kötü niyetli üçüncü taraflara aktarabilecekleri için CEI modelini izlemelidir.
Belgelere göre, CEI ilkeleri bir sözleşmenin saldırı yüzeyini sınırlamaya, özellikle yeniden giriş saldırılarını önlemeye yardımcı olur. CEI ilkeleri, herhangi bir mantık değiştirilmeden, esas olarak fonksiyon kodları sırasında kolayca uygulanabilir. The DAO'nun Ethereum'un çatallanmasına yol açan iyi bilinen istismarı da "CEI ilkesini" göz ardı etti ve saldırgan, yıkıcı sonuçlara neden olan bir yeniden giriş saldırısı gerçekleştirdi.
Ancak saldırı altındaki Curve havuzu bu CEI ilkesini takip etmedi çünkü Curve Vyper derleyicisini kullanıyor. Derleyicinin Vyper kod güvenlik açığı olarak, reentrancy lock başarısız olur ve hacker'ın reentrancy saldırısının başarılı bir şekilde gerçekleştirilmesini sağlar.
Çoğu kişi Solidity'i bilir, ancak akıllı sözleşmeler oluşturmak için tek dil Solidity değildir. Solidity'nin popüler bir alternatifi Vyper'dır. Vyper, Solidity kadar güçlü ve popüler olmasa da, Python'a aşina geliştiriciler için idealdir çünkü Vyper, Python benzeri kodu Ethereum akıllı sözleşme programlama diline çevirebilir.
Github bilgilerine göre Vyper'ın github kod tabanına ilk katkıyı yapan geliştirici aynı zamanda Curve'un da geliştiricisi. Curve'ün neden Solidity yerine Vyper kullandığını açıklamak zor değil.
![Hackerlar "ilk ilkelere" dönüyor, Curve krizi sıradan bir saldırı değil] (https://img-cdn.gateio.im/resize-social/moments-40baef27dd-c30cf03f91-dd1a6f-1c6801)
Vyper yeniden giriş kilidi neden başarısız oluyor?
Peki bu saldırıda Vyper ile ilgili sorun nedir? Yeniden giriş kilidi neden başarısız oluyor? Test olmadığı için mi? BlockBeats, akıllı sözleşme geliştiricisi Box 826.eth (@BoxMrChen) ile röportaj yaptı, ona göre Vyper giriş kilidi kullanım durumlarıyla test edildi. Ancak başarısızlığın nedeni test senaryosunun sonuç odaklı olmasıdır yani test senaryosunun da yanlış olmasıdır.
Kısacası Vyper reentrancy lock'un başarısız olmasının en büyük sebebi, test case'ini yazan kişinin slotun neden 1'i açıklanamayacak şekilde atlayacağını düşünmeden test case'ini sonuca göre yazmasıdır.
![Hackerlar "ilk ilkelere" dönüyor, Curve krizi sıradan bir saldırı değil] (https://img-cdn.gateio.im/resize-social/moments-40baef27dd-0527942e35-dd1a6f-1c6801)
Box'ın paylaştığı Vyper kodunun aşağıdaki paragraflarında sorun açıkça görülüyor. Kilit adı ikinci kez göründüğünde, depolama_slot sayısının üzerine yazılacaktır, yani ret'te, kilidin ilk edinimi için yuva 0'dır, ancak bir işlev kilidi tekrar kullandıktan sonra, kilit yuvası bir eklenir. Derlemeden sonra yanlış yuva kullanılır ve yeniden giriş kilidinin etkinleşmemesine neden olur.
![Hackerlar "ilk ilkelere" dönüyor, Curve krizi sıradan bir saldırı değil] (https://img-cdn.gateio.im/resize-social/moments-40baef27dd-87ec9b545c-dd1a6f-1c6801)
Soldaki saldırı kodu, sağdaki ise onarılan koddur.
"Yanlış test sonuçları bekleniyor ve tabii ki hiçbir hata doğrulanamıyor. Basit bir örnek vermek gerekirse şu anda bir hesaplama problemi yapıyoruz 1+ 1 = 2 ama verilen standart cevap 1+ 1 = 3 diyerek yanlış. . Ve bu soruyu yapan sınıf arkadaşı yanlış cevap verdi ve 1+ 1 = 3 diye cevapladı, ancak önceden verilen standart cevapla aynıydı, bu nedenle programın doğal olarak test sonucunun yanlış olduğunu belirlemesinin bir yolu yoktu. yanlış." Box, BlockBeats ile yaptığı bir röportajda söyledi.
İki yıldır asılı "Damokles'in Kılıcı"
Tarihte kaydedilen ilk yeniden giriş saldırısı olayında, WETH Attack saldırganları, daha fazla projeyi yeniden giriş saldırılarına karşı bağışık hale getirmek amacıyla, geliştiricilerin yeniden giriş saldırılarına dikkat etmesini sağlamak için kasıtlı olarak saldırılar oluşturan beyaz bilgisayar korsanlarıdır. Akıllı sözleşmeler bağlamında geliştiriciler, koruma elde etmek için durum değiştirme işlevini çağırmak gibi farklı tetikleme mekanizmaları kullanmalıdır. Bu, geliştiricilerin sözleşmeleri tasarlarken olası saldırı senaryolarını tam olarak dikkate almalarını ve uygun önlemleri almalarını gerektirir.
BlockBeats, Vyper editörünü derinlemesine anlamak için BTX araştırmacısı Derek (@begas_btxcap) ile röportaj yaptı ve Python'a aşina olan geliştiriciler için Vyper'ın Solidity'den daha ideal bir seçim olduğunu ve daha rahat bir kullanıcı arabirimi olduğunu söyledi. ve daha hızlı öğrenme. Ancak görünüşe göre, Vyper editör kodunun bazı sürümleri güvenilir bir üçüncü tarafça denetlenmemiş. Hatta bazı denetim çalışmaları geliştiricilerin kendileri tarafından yapılabilir. "Geleneksel BT endüstrisinde bu tür şeyler olmayacak, çünkü yeni bir dil çıktıktan sonra, boşluklarınızı arayan sayısız denetim şirketi olacak."
Bir hatanın iki yıl boyunca açık bir şekilde var olmasına izin vermekten bahsetmiyorum bile.
Vyper yazarı fubuloubu da şunları söyledi: Derleyici herkesin sandığı kadar gözden geçirilmiş veya denetlenmiş değil. Derleyicilerin çoğu, denetimi bir dezavantaj haline getiren önemli ve sık değişikliklere sahiptir. Tam bir kod tabanı denetiminde bile, bundan sonra daha fazla sürüm eklendikçe güncelliğini yitirecektir. Derleyiciyi denetlemek iyi bir fikir değildir, çünkü aracı kullanan son kullanıcı tarafından üretilen nihai ürünü (yani ham EVM kodunu) denetlemek daha mantıklıdır.
Bütün bunlar son bir soruna işaret ediyor: motivasyon. Bununla birlikte, hiç kimsenin derleyicilerde, özellikle eski sürümlerde kritik hatalar bulmaya teşviki yoktur. fubuloubu daha önce kullanıcıların ortak sponsorluğunda bir ödül programı ekleyerek Vyper'ı iyileştirmeye yardımcı olacak bir teklifte bulunmuştu, ancak bu öneri gerçekleşmedi.
Bilgisayar Korsanları "İlk İlkelere" Geri Dönüyor
Bu, protokol ve proje geliştiricileri için sözleşmeye uygun geliştirme uygulamalarının canlı bir örneğidir. Ama en önemlisi Curve olayı hepimize altta yatan derleyicinin güvenliğinin ciddi anlamda göz ardı edildiği ve "ilk prensiplere" dönen bilgisayar korsanlarının alt derleyicide mükemmel bir tane buldukları konusunda bir uyarı verdi.
Ardından, Aave ve Lens'in kurucusu Stani (@StaniKulechov) da duygularını ifade etmek için sosyal medyada uzun bir makale yayınladı: Curve'a yapılan saldırı, DeFi riskinin her zaman tüm temel yığını, programlama dilini, EVM'yi kapsadığı anlamına gelir. , vesaire. Bu, özellikle gelecekte özel EVM'leri ve uygulama zincirlerini kullanırken daha dikkatli ve hassas olmamız konusunda bizi uyarıyor.
![Hackerlar "ilk ilkelere" dönüyor, Curve krizi sıradan bir saldırı değil] (https://img-cdn.gateio.im/resize-social/moments-40baef27dd-3324fcfbcd-dd1a6f-1c6801)
Daha düşük bir seviyeden saldırılar
Derleyici güvenlik açıklarını yalnızca sözleşme kaynak kodunun mantığını denetleyerek bulmak zordur. Sadece sürümler ve sürümler arasındaki farkları araştırmak da büyük bir projedir. Akıllı sözleşmelerin derleyici güvenlik açıklarından etkilenip etkilenmediğini belirlemek için belirli derleyici sürümlerini belirli kod modelleriyle birleştirmek gerekir.
"Şu anda yalnızca iki derleyici en iyisidir, Vyper'ın kod tabanı daha küçüktür, okunması daha kolaydır ve geçmişini analiz etmek için daha az değişikliğe sahiptir, muhtemelen bilgisayar korsanlarının buradan başlamasının nedeni budur, Solidity'nin kod tabanı biraz daha büyüktür ”fubuloubu bundan şüpheleniyor bile- destekli bilgisayar korsanları bu Eğri saldırısına dahil olabilir: "Güvenliği bulmak haftalar veya aylar alabilir ve yatırılan kaynaklar göz önüne alındığında, küçük bir grup veya ekip tarafından gerçekleştirilebilir."
Şifreleme endüstrisinde en yaygın kullanılan derleme dili olan Solidity'nin güvenliği, kullanıcılar tarafından daha da fazla endişelendiriliyor.Sonuçta, Solidity derleyicisi bu kez yeniden giriş kilidi hatası sorunu yaşarsa, o zaman tüm DeFi endüstrisinin geçmişi geçmiş olabilir. yeniden yazılacak.
Solidity geliştirme ekibi tarafından düzenli olarak yayınlanan güvenlik uyarılarına göre, Solidity derleyicisinin birçok farklı sürümünde güvenlik açıkları olmuştur.
Günlüğe kaydedilen en son derleyici hatası, abi.error kullanımıyla ilgili bir güvenlik raporu araştırılırken 26 Haziran'da kaydedildi. Eski kod oluşturucu atamalar, işlev çağrıları veya .selector'a erişilen koşullar gibi karmaşık ifadeleri değerlendirmedi. Bu, bu tür ifadelerin yürütülmemesinin yan etkilerine neden olur, bu nedenle eski ardışık düzen ile derlenen sözleşmeler yanlış davranabilir.
Solidity'nin Github deposunda, Solidity derleyicisinde güvenlikle ilgili bilinen bazı hataları listeleyen bir dosya da görebiliriz. Liste, 0.3.0 sürümüne geri döner, yalnızca bu sürümden önce var olan hatalar listelenmez. Burada başka bir bugs_by_version.json dosyası var. Bu dosya, belirli bir derleyici sürümünün hangi hatalardan etkilendiğini sorgulamak için kullanılabilir.
Neyse ki, tam olarak Solidity dilinin geniş uygulaması ve Ethereum Vakfı'nın desteği sayesinde, dağıtım sürecinde projeler ve protokoller tarafından birçok mevcut soruna dikkat çekilmiştir. Bu nedenle Solidity, Vyper'dan birkaç adım daha hızlı modifikasyon ve geliştirmeyi tamamlamıştır.Bu açıdan Solidity'nin daha standart ve güvenli olmasının sebeplerinden biri de budur.
Solidity geliştiricilerinin daha iyi test yapmasına ve aynı şeyin olmasını engellemesine yardımcı olmak için. UnitasProtocol kurucu ortağı SunSec (@ 1 nf 0 s 3 cpt), Curve saldırısından sonra güvenlik açığı açıklamaları, senaryolar, savunmalar, güvenlik açığı kodları ve azaltma önlemleri ve nasıl test edileceği dahil olmak üzere 47 tür güvenlik açığını destekleyen bir DeFiVulnLabs Solidity güvenlik testi kılavuzu yayınladı. .
Düşük seviyeli saldırılardan mümkün olduğunca nasıl kaçınılır?
Bu Eğri olayında Box, tüm geliştiriciler için aydınlanmanın şu olduğuna inanıyor: teknolojik trendi takip etmeye çalışmayın ve olgun olmayan çözümler seçmeyin; test senaryoları yazmadan kendi kodunuzu onaylamayın (Vyper'ın sorunları olan birkaç versiyonu test senaryoları yanlış); kendi kodunuzu asla kendiniz onaylamayın; bazı servetlerin keşfedilmesi yıllar alabilir; yükseltilemezlik, kendinize karşı kibir ve başkalarını hor görmektir.
Genellikle, geliştiriciler burada herhangi bir tuzak düşünmezler ve istedikleri zaman derlemek için bir sürüm seçerler; bu, sürümler arasındaki farklılıkların getirdiği riskleri göz ardı edebilir. Küçük sürüm yükseltmeleri bile, merkezi olmayan uygulamalar geliştirirken özellikle önemli olan önemli değişiklikleri getirebilir.
Bu Curve etkinliğinden geliştiricilere yönelik uyarılar şunlardır: derleyici dilinin daha yeni bir sürümünü kullanın. Kod tabanınızı, uygulamalarınızı ve işletim sisteminizi güncel tutmanız ve her açıdan kendi güvenlik savunmanızı oluşturmanız önemlidir. Daha yeni sürümler yeni güvenlik sorunları ortaya çıkarsa da, genellikle eski sürümlere göre daha az bilinen güvenlik sorunu vardır. Elbette zamanında topluluk ve resmi sürüm güncelleme duyurularına da dikkat etmeliyiz. Her sürümün getirdiği değişiklikleri anlayın ve kendi kod tabanınızı ve işletim ortamınızı gerektiği gibi güncelleyin. Bu adımları uygulamak, derleyici hatalarından kaynaklanan güvenlik olaylarını büyük ölçüde azaltabilir.
Ek olarak, kodu tamamlamak için birim test durumları. Derleyici düzeyindeki hataların çoğu, yalnızca kod incelemesi yoluyla bulunması zor olan ancak test sırasında ortaya çıkabilen tutarsız kod yürütme sonuçlarına yol açacaktır. Kod kapsamının iyileştirilmesi, bu tür sorunların önlenmesine yardımcı olabilir. Açık bir ihtiyaç olmadıkça satır içi derleme ve çok boyutlu dizi kodlama ve kod çözme gibi karmaşık dil özelliklerini kullanmaktan kaçının. Solidity dil güvenlik açıklarının çoğu tarihsel olarak bu gelişmiş özelliklerle ilişkilendirilmiştir. Geliştiriciler, belirli bir ihtiyaç olmaksızın gösteriş yapmak adına deneysel dil özelliklerini kullanmaktan kaçınmalıdır.
Protokol katmanı ve güvenlik personeli için kod denetimleri yapılırken derleyici sürümünün olası riskleri göz ardı edilemez. Bilgisayar korsanlarının yeni fikirler ortaya çıkardığı öngörülebilir ve gelecekte, giderek daha fazla sayıda alt düzey güvenlik açıklarından yararlanılacak. Aynı zamanda altta yatan altyapı olarak, altta yatan stack, programlama dili, EVM vb. denetimlerin yapılması gerekir. Gelecekte, denetim şirketlerinin pazarı giderek büyüyecek ve beyaz konuk ikramiyelerinin pazarı da giderek büyüyecek. Vyper ekibi, konu resmi olarak çözüldükten sonra hata ödül programını incelemeye başlamayı da planlıyor.
Tabii ki, altta yatan altyapının riskleri konusunda çok fazla paniğe kapılmamıza gerek yok. Şu anda çoğu derleyici hatası yalnızca belirli kod kalıplarında tetikleniyor ve gerçek etkinin proje durumuna göre değerlendirilmesi gerekiyor. Derleyici sürümünü düzenli olarak yükseltmek ve yeterli birim testi yapmak, risklerin önlenmesine yardımcı olabilir.