@CetusProtocol'ın hacker güvenlik "incelemesi" raporunu okuduktan sonra, "ilgi çekici" bir fenomenle karşılaşacaksınız: teknik detaylar oldukça şeffaf bir şekilde açıklanıyor ve acil durum müdahalesi ders kitabı düzeyinde, ancak "neden hacklendi" nin en kritik ruh işkencesi kaçamak görünüyor:
Rapor, integer-mate kütüphanesinin checked\_shlw fonksiyonunun hata kontrolünü (gerekli ≤2^192, gerçek ≤2^256) geniş bir şekilde açıklamaktadır ve bunu "anlamsal yanlış anlama" olarak nitelendirmektedir. Bu anlatım, teknik olarak doğru olsa da, ustaca dış sorumluluğa odaklanarak Cetus'un bu teknik açığın masum bir kurbanıymış gibi görünmesini sağlamaktadır.
Sorun şu, integer-mate açık kaynaklı ve geniş bir şekilde kullanılan bir matematik kütüphanesi olduğuna göre, neden burada 1 token ile muazzam bir likidite payı elde edilebilecek absürt bir hata meydana geldi?
Korsan saldırı yollarını analiz ettiğimizde, bir korsanın mükemmel bir saldırı gerçekleştirebilmesi için dört koşulun aynı anda sağlanması gerektiğini göreceğiz: Hatalı taşma kontrolü, büyük kaydırma işlemleri, yukarı yuvarlama kuralları ve ekonomik mantık doğrulamasının eksikliği.
Cetus, her «tetikleme» koşulunda «dikkatsiz» davrandı; örneğin: kullanıcıdan 2^200 gibi astronomik bir sayı kabul etmek, son derece tehlikeli büyük kaydırma işlemleri kullanmak, dış kütüphanelerin kontrol mekanizmasına tamamen güvenmek, en ölümcül olanı ise - sistem «1 token karşılığında astronomik pay» gibi absürt bir sonuç hesapladığında, hiçbir ekonomik akıl kontrolü olmadan doğrudan uygulamaya geçilmesiydi.
Bu nedenle, Cetus'un gerçekten düşünmesi gereken noktalar şunlardır:
Ortak harici kitaplıkları kullandığımda neden güvenlik testi yapmıyorum? 'Integer-mate' kütüphanesi açık kaynaklı, popüler ve yaygın olarak kullanılmasına rağmen, Cetus, kütüphanenin güvenlik sınırlarının nerede olduğunu, kütüphanenin başarısız olması durumunda uygun alternatiflerin olup olmadığını vb. tam olarak anlamadan yüz milyonlarca dolarlık varlığı yönetmek için kullanır. Açıkçası, Cetus en temel tedarik zinciri güvenliği bilincinden yoksundur;
Neden astronomik rakamların girilmesine izin veriliyor ve sınır yok? DeFi protokolleri merkeziyetsiz olmayı hedeflese de, olgun bir finansal sistem ne kadar açık olursa olsun, net sınırlar gerektirir.
Sistem, bir saldırgan tarafından dikkatlice oluşturulmuş astronomik bir miktara izin verdiğinde, ekip görünüşe göre böyle bir likidite gereksiniminin makul olup olmadığını düşünmedi. Dünyanın en büyük hedge fonunun bile bu kadar abartılı bir likidite payına ihtiyaç duyması pek olası değildir. Açıkçası, Cetus ekibi finansal sezgiye sahip risk yönetimi yeteneğinden yoksundu;
Birden fazla güvenlik denetimi turundan sonra neden hala önceden bir sorun bulunamadı? Bu cümle istemeden de olsa ölümcül bir bilişsel yanlış anlaşılmayı ortaya çıkarmaktadır: Proje ekibi güvenlik sorumluluğunu güvenlik şirketine devreder ve denetimi muafiyet için bir altın madalya olarak görür. Ancak gerçek çok açık: güvenlik denetim mühendisleri kod hatalarını bulmakta iyidir ve fantastik değişim oranını hesaplamak için sistemi test etmenin yanlış olabileceğini kim düşünebilirdi?
Bu matematik, kriptografi ve ekonomi arasındaki sınırların doğrulanması, modern DeFi güvenliğinin en büyük kör noktasıdır. Denetim şirketleri "Bu ekonomik model tasarım hatası, kod mantığı sorunu değil" der; proje sahipleri ise "denetim sorunları bulmadı" diye şikayet eder; kullanıcılar sadece paralarının kaybolduğunu bilir!
Görüyorsunuz, bu sonuçta DeFi sektörünün sistematik güvenlik zayıflığını açığa çıkarıyor: Saf teknik bir geçmişe sahip olan ekipler, temel "finansal risk sezgisi" açısından ciddi bir eksiklik yaşıyor.
Cetus raporuna göre, ekip açıkça yeterince düşünmemiş.
Bu tür bir siber saldırıya yönelik teknik eksiklikler yerine, Cetus'tan itibaren tüm DeFi ekiplerinin sadece teknik düşüncenin sınırlılığını terk etmesi ve gerçekten "finans mühendisleri" olarak güvenlik risk bilincini geliştirmesi gerektiğini düşünüyorum.
Örneğin: Finansal risk kontrol uzmanlarını dahil etmek, teknik ekibin bilgi boşluklarını kapatmak; çoklu denetim inceleme mekanizması oluşturmak, sadece kod denetimine bakmakla kalmayıp, gerekli ekonomik model denetimlerini de tamamlamak; "finansal sezgi" geliştirmek, çeşitli saldırı senaryolarını ve buna karşılık gelen önlemleri simüle etmek, anormal işlemlere karşı her zaman hassas kalmak gibi.
Bu, daha önceki güvenlik şirketi deneyimlerimi hatırlatıyor, sektördeki güvenlik devleri @evilcos, @chiachih_wu, @yajinzhou, @mikelee205 ile yapılan tartışmalarda bu tür bir ortak görüş de var:
Sektörün giderek olgunlaşmasıyla birlikte, kod seviyesindeki teknik hata sorunları giderek azalacak, ancak sınırları belirsiz ve sorumlulukları bulanık olan iş mantığı "bilinç hatası" en büyük zorluk olacaktır.
Denetim firmaları yalnızca kodun hatasız olduğunu garanti edebilir, ancak "mantığın sınırlarının belirlenmesi" için proje ekibinin işin doğasına daha derin bir anlayışa ve sınır kontrol becerisine sahip olması gerekir. (Önceki birçok güvenlik denetiminden sonra hâlâ hacker saldırılarına uğramanın "suçlama olayı"nın temel nedeni de buradadır.)
DeFi'nin geleceği, güçlü kod becerilerine ve derin bir iş mantığı anlayışına sahip ekiplere aittir!
The content is for reference only, not a solicitation or offer. No investment, tax, or legal advice provided. See Disclaimer for more risks disclosure.
Cetus güvenlik sorunları uyarısı: Merkezi Olmayan Finans takımlarının nelere dikkat etmesi gerekiyor?
Yazar: Haotian
@CetusProtocol'ın hacker güvenlik "incelemesi" raporunu okuduktan sonra, "ilgi çekici" bir fenomenle karşılaşacaksınız: teknik detaylar oldukça şeffaf bir şekilde açıklanıyor ve acil durum müdahalesi ders kitabı düzeyinde, ancak "neden hacklendi" nin en kritik ruh işkencesi kaçamak görünüyor:
Rapor,
integer-matekütüphanesininchecked\_shlwfonksiyonunun hata kontrolünü (gerekli ≤2^192, gerçek ≤2^256) geniş bir şekilde açıklamaktadır ve bunu "anlamsal yanlış anlama" olarak nitelendirmektedir. Bu anlatım, teknik olarak doğru olsa da, ustaca dış sorumluluğa odaklanarak Cetus'un bu teknik açığın masum bir kurbanıymış gibi görünmesini sağlamaktadır.Sorun şu,
integer-mateaçık kaynaklı ve geniş bir şekilde kullanılan bir matematik kütüphanesi olduğuna göre, neden burada 1 token ile muazzam bir likidite payı elde edilebilecek absürt bir hata meydana geldi?Korsan saldırı yollarını analiz ettiğimizde, bir korsanın mükemmel bir saldırı gerçekleştirebilmesi için dört koşulun aynı anda sağlanması gerektiğini göreceğiz: Hatalı taşma kontrolü, büyük kaydırma işlemleri, yukarı yuvarlama kuralları ve ekonomik mantık doğrulamasının eksikliği.
Cetus, her «tetikleme» koşulunda «dikkatsiz» davrandı; örneğin: kullanıcıdan 2^200 gibi astronomik bir sayı kabul etmek, son derece tehlikeli büyük kaydırma işlemleri kullanmak, dış kütüphanelerin kontrol mekanizmasına tamamen güvenmek, en ölümcül olanı ise - sistem «1 token karşılığında astronomik pay» gibi absürt bir sonuç hesapladığında, hiçbir ekonomik akıl kontrolü olmadan doğrudan uygulamaya geçilmesiydi.
Bu nedenle, Cetus'un gerçekten düşünmesi gereken noktalar şunlardır:
Ortak harici kitaplıkları kullandığımda neden güvenlik testi yapmıyorum? 'Integer-mate' kütüphanesi açık kaynaklı, popüler ve yaygın olarak kullanılmasına rağmen, Cetus, kütüphanenin güvenlik sınırlarının nerede olduğunu, kütüphanenin başarısız olması durumunda uygun alternatiflerin olup olmadığını vb. tam olarak anlamadan yüz milyonlarca dolarlık varlığı yönetmek için kullanır. Açıkçası, Cetus en temel tedarik zinciri güvenliği bilincinden yoksundur;
Neden astronomik rakamların girilmesine izin veriliyor ve sınır yok? DeFi protokolleri merkeziyetsiz olmayı hedeflese de, olgun bir finansal sistem ne kadar açık olursa olsun, net sınırlar gerektirir.
Sistem, bir saldırgan tarafından dikkatlice oluşturulmuş astronomik bir miktara izin verdiğinde, ekip görünüşe göre böyle bir likidite gereksiniminin makul olup olmadığını düşünmedi. Dünyanın en büyük hedge fonunun bile bu kadar abartılı bir likidite payına ihtiyaç duyması pek olası değildir. Açıkçası, Cetus ekibi finansal sezgiye sahip risk yönetimi yeteneğinden yoksundu;
Bu matematik, kriptografi ve ekonomi arasındaki sınırların doğrulanması, modern DeFi güvenliğinin en büyük kör noktasıdır. Denetim şirketleri "Bu ekonomik model tasarım hatası, kod mantığı sorunu değil" der; proje sahipleri ise "denetim sorunları bulmadı" diye şikayet eder; kullanıcılar sadece paralarının kaybolduğunu bilir!
Görüyorsunuz, bu sonuçta DeFi sektörünün sistematik güvenlik zayıflığını açığa çıkarıyor: Saf teknik bir geçmişe sahip olan ekipler, temel "finansal risk sezgisi" açısından ciddi bir eksiklik yaşıyor.
Cetus raporuna göre, ekip açıkça yeterince düşünmemiş.
Bu tür bir siber saldırıya yönelik teknik eksiklikler yerine, Cetus'tan itibaren tüm DeFi ekiplerinin sadece teknik düşüncenin sınırlılığını terk etmesi ve gerçekten "finans mühendisleri" olarak güvenlik risk bilincini geliştirmesi gerektiğini düşünüyorum.
Örneğin: Finansal risk kontrol uzmanlarını dahil etmek, teknik ekibin bilgi boşluklarını kapatmak; çoklu denetim inceleme mekanizması oluşturmak, sadece kod denetimine bakmakla kalmayıp, gerekli ekonomik model denetimlerini de tamamlamak; "finansal sezgi" geliştirmek, çeşitli saldırı senaryolarını ve buna karşılık gelen önlemleri simüle etmek, anormal işlemlere karşı her zaman hassas kalmak gibi.
Bu, daha önceki güvenlik şirketi deneyimlerimi hatırlatıyor, sektördeki güvenlik devleri @evilcos, @chiachih_wu, @yajinzhou, @mikelee205 ile yapılan tartışmalarda bu tür bir ortak görüş de var:
Sektörün giderek olgunlaşmasıyla birlikte, kod seviyesindeki teknik hata sorunları giderek azalacak, ancak sınırları belirsiz ve sorumlulukları bulanık olan iş mantığı "bilinç hatası" en büyük zorluk olacaktır.
Denetim firmaları yalnızca kodun hatasız olduğunu garanti edebilir, ancak "mantığın sınırlarının belirlenmesi" için proje ekibinin işin doğasına daha derin bir anlayışa ve sınır kontrol becerisine sahip olması gerekir. (Önceki birçok güvenlik denetiminden sonra hâlâ hacker saldırılarına uğramanın "suçlama olayı"nın temel nedeni de buradadır.)
DeFi'nin geleceği, güçlü kod becerilerine ve derin bir iş mantığı anlayışına sahip ekiplere aittir!