18 Ocak'ta, izleme sistemimiz AnySwap projesine (diğer adıyla Multichain) yönelik bir saldırı tespit etti. Güvenlik açığı, doğrulama mekanizması atlatılarak onaylanan token'ların çekilmesine olanak tanıyan hatalı anySwapOutUnderlyingWithPermit() fonksiyonundan kaynaklanmaktadır.
Proje, etkilenen kullanıcıları bilgilendirmek için farklı yaklaşımlar benimsemiş olsa da (örneğin, Şekil 1'de gösterildiği gibi kullanıcılara işlem göndermek), bazı kullanıcılar fonlarını korumak için zamanında gerekli adımları atmayı (yani onayları iptal etmeyi) başaramamıştır. Sonuç olarak, saldırganlar kurban fonlarını elde etmek amacıyla saldırılarını sürdürmeye devam edebildi.
Potansiyel kurbanları korumak amacıyla, uzun süren müzakereler sonucunda ekibimiz, Ethereum üzerindeki AnySwap güvenlik açığı bulunan sözleşmesi (0x6b7a87899490EcE95443e979cA9485CBE7E71522) için acil bir kurtarma operasyonu gerçekleştirmeye karar verdi. Özellikle, güvenlik açığı bulunan hesabın fonlarını, Ethereum üzerinde çok imzalı bir cüzdan (0xd186540FbCc460f6a3A9e705DC6d2406cBcc1C47) olan beyaz şapka cüzdanımıza aktarabiliriz.
Beyaz şapka kurtarma operasyonumuzu şeffaf kılmak amacıyla, niyetimizi bir PDF dosyasında belgeleyerek dosyanın hash değerini toplulukla paylaştık. Bu yaklaşım, acil kurtarma operasyonumuzu saldırıdan ayırt etmemizi sağlarken aynı zamanda ayrıntıların sızdırılmasını önledi (zira güvenlik açığı hâlâ istismar edilebilir durumdaydı). Acil kurtarma operasyonunu 21 Ocak 2022 ile 11 Mart 2022 tarihleri arasında gerçekleştirdik; ilgili duyurular kamuoyuyla aşağıdaki şekilde paylaşıldı:
Acil kurtarma operasyonu basit bir görev değildi. Nitekim başarılı bir kurtarma gerçekleştirmek için hem teknik hem de teknik olmayan çeşitli zorluklarla karşılaşıldı. Acil kurtarma operasyonu sona erdiğinden, tüm süreci kapsamlı biçimde değerlendirerek öğrendiğimiz dersleri paylaşabiliriz. Bu deneyimin DeFi ekosisteminin güvenliğinin sağlanmasına ışık tutacağına inanıyoruz.
Temel Çıkarımlar (Özet)
- Beyaz şapkalılar ve saldırganlar dahil farklı katılımcılar arasında rekabet mevcuttur. Flashbots için ödenen işlem ücreti, zaman geçtikçe hızla arttı.
- Flashbots her zaman işe yaramadı. Bunun yerine, bazı saldırganlar gelişmiş stratejiler benimseyerek başarılı saldırılar gerçekleştirmek için normal bellek havuzunu kullanmayı tercih etti.
- Bazı saldırganlar, çalınan fonun bir kısmını iade ederek aklandı; kalan kısım ise ödül olarak ellerinde tutuldu. Bu fenomen, ilk kez ortaya çıkmamasına rağmen, toplulukta tartışmalı olmaya devam etmektedir; zira böyle bir teşvik gerçek beyaz şapkalılar açısından adil olmayabilir.
- Topluluğu ikna etmek için, beyaz şapkalıların hassas ayrıntıları sızdırmadan eylemlerini önceden kamuoyuyla paylaşmaları iyi bir pratik oluşturur.
- Topluluk, kurtarma operasyonunu daha etkin ve verimli biçimde gerçekleştirmek için birlikte çalışabilir. Örneğin, beyaz şapkalılar arasındaki rekabeti azaltmak/önlemek için bir koordinasyon mekanizması oluşturulabilir.
Aşağıda, önce bu süreçteki kurtarma operasyonunun genel tablosunu sunacağız. Ardından, kurtarma operasyonunu nasıl gerçekleştirdiğimizi ve çözülmesi gereken zorlukları ele alacağız. Sonrasında, kurtarma operasyonundan çıkardığımız bazı dersleri tartışacağız. Son olarak, ekosistemi güvence altına almak açısından anlamlı olabilecek bazı düşünce ve önerileri paylaşacağız.
0x1 Kurtarmalar ve Saldırılar
0x1.1 Genel Sonuç
Bu raporda incelediğimiz saldırı ve kurtarma operasyonları aylarca sürmüş; blok 14028474 (18 Ocak 2022) ile blok 14421215 (20 Mart 2022) arasındaki dönemi kapsamaktadır.
Kurtarma ve saldırı gerçekleştiren hesaplar aşağıdaki tabloda özetlenmiştir. Basitlik adına, bir EOA'yı temsil etmek için yalnızca adresin ilk dört biti kullanılmıştır. Bir hesap ya kurtarma hesabı ya da saldırı hesabı olarak sınıflandırılmaktadır. Bir hesabın türünün, ya Etherscan.io tarafından etiketlenen bilgilere ya da gözlemlediğimiz transfer hedef adreslerine göre belirlendiğini belirtmek gerekir.
Toplamda 9 kurtarma hesabı 483,027693 ETH kurtarmış (işlem ücreti 295,970554 ETH, yani toplam miktarın %61,27'si) ve 21 saldırı hesabı 1433,092224 ETH elde etmiştir (işlem ücreti 148,903707 ETH, yani toplam miktarın %10,39'u). Bazı karmaşık etkileşimler nedeniyle zararın yaklaşık bir tahmin olduğunu belirtmek gerekir. Örneğin, bir saldırı hesabı AnySwap ile müzakere ettikten sonra kurtarma hesabına dönüşebilir; bu fenomeni ilerleyen kısımlarda ele alacağız. Tablonun son sütunu, Flashbots kullanımındaki rekabeti kazanmak için madenciye gönderilen ücreti göstermektedir.
| No. | Hesap | Tür | # Kurban Sayısı | # Kayıp (ETH) | # Ücret (ETH) |
|---|---|---|---|---|---|
| 1 | 0x14ca** | Kurtarma hesabı | 50 | 432.958062 | 287.849654 |
| 2 | 0x9a65** | Kurtarma hesabı | 23 | 22.569429 | 0.000000 |
| 3 | 0x9117** | Kurtarma hesabı | 14 | 18.897622 | 7.213585 |
| 4 | 0x17d2** | Kurtarma hesabı | 3 | 3.552833 | 0.000000 |
| 5 | 0x6360** | Kurtarma hesabı | 21 | 3.540061 | 0.907168 |
| 6 | 0x0edd** | Kurtarma hesabı | 7 | 1.498706 | 0.000000 |
| 7 | 0x281e** | Kurtarma hesabı | 1 | 0.006000 | 0.000000 |
| 8 | 0xd83b** | Kurtarma hesabı | 1 | 0.004000 | 0.000000 |
| 9 | 0x8af3** | Kurtarma hesabı | 6 | 0.000980 | 0.000147 |
| 10 | 0x4986** | Saldırı hesabı | 332 | 456.004547 | 0.000000 |
| 11 | 0xfa27** | Saldırı hesabı | 42 | 433.438935 | 46.636389 |
| 12 | 0x48e9** | Saldırı hesabı | 66 | 312.014657 | 0.000000 |
| 13 | 0x5738** | Saldırı hesabı | 67 | 83.589240 | 62.587238 |
| 14 | 0x34b2** | Saldırı hesabı | 7 | 63.599821 | 20.642705 |
| 15 | 0xd374** | Saldırı hesabı | 86 | 45.452703 | 12.824763 |
| 16 | 0x1fe7** | Saldırı hesabı | 9 | 12.817241 | 0.000000 |
| 17 | 0x98f5** | Saldırı hesabı | 20 | 8.381273 | 0.000000 |
| 18 | 0x455d** | Saldırı hesabı | 11 | 5.047377 | 0.544263 |
| 19 | 0x1b45** | Saldırı hesabı | 6 | 4.942442 | 3.074813 |
| 20 | 0x3ec7** | Saldırı hesabı | 6 | 3.705686 | 0.741137 |
| 21 | 0xbca4** | Saldırı hesabı | 1 | 2.784250 | 1.392125 |
| 22 | 0xb0ab** | Saldırı hesabı | 18 | 0.834068 | 0.296000 |
| 23 | 0x0a5b** | Saldırı hesabı | 1 | 0.286750 | 0.143375 |
| 24 | 0x2d3a** | Saldırı hesabı | 2 | 0.080090 | 0.000000 |
| 25 | 0x835d** | Saldırı hesabı | 5 | 0.063945 | 0.000000 |
| 26 | 0x1dbd** | Saldırı hesabı | 1 | 0.027431 | 0.012893 |
| 27 | 0x813d** | Saldırı hesabı | 1 | 0.019528 | 0.008007 |
| 28 | 0x85dd** | Saldırı hesabı | 6 | 0.002240 | 0.000000 |
| 29 | 0x2394** | Saldırı hesabı | 1 | 0.000000 | 0.000000 |
| 30 | 0x6360** | Saldırı hesabı | 2 | 0.000000 | 0.000000 |
0x1.2 Flashbots Teklifine Yönelik Ücretin Eğilimi
Daha önce belirtildiği gibi, beyaz şapkalıların işlemleri göndermek için saldırganlarla rekabet etmesi gerekmektedir. Sonuç olarak, madenciye ödenen ücretin yüzdesi (Flashbots işlemlerinde) rekabetin düzeyini yansıtabilir. Bunu nicel olarak ölçmek amacıyla, her blok için ücret yüzdesini (hem saldırı işlemlerini hem de kurtarma işlemlerini kapsayacak şekilde) inceledik.
Şekil 4, şimdiye kadar gözlemlediğimiz eğilimi (blok 14028474'ten blok 14369199'a kadar) göstermektedir. İlk birkaç saldırı işlemi herhangi bir ücret içermemektedir; bu durum, söz konusu dönemde çok az (hatta hiç) rekabetin olmadığına işaret etmektedir. Bu, söz konusu erken saldırıların başkaları tarafından henüz bilinmiyor olabileceği düşünüldüğünde makul bir sonuçtur.
Gerçekte, ücret içeren ilk saldırı (%10) blok 14029765'te gerçekleşti. O tarihten itibaren, daha fazla katılımcının sürece dahil olmasıyla birlikte ücret yüzdesi hızla arttı. Örneğin, yüzde blok 14072385'te %80'e, ardından blok 14129449'da %91'e ulaştı.
Kısacası, bu eğilim, madenciye daha fazla ücret ayarlayarak rekabeti kazanmanın kesinlikle bir silahlanma yarışı olduğuna işaret etmektedir.
0x2 Kurtarma Operasyonumuz ve Zorluklar
0x2.1 Kurtarma Operasyonunu Gerçekleştirme Yöntemi
Kurtarma operasyonunu gerçekleştirmenin temel fikri oldukça basittir. Özellikle, güvenlik açığı bulunan sözleşmeye WETH onaylamış hesapları izlememiz gerekmektedir. Herhangi bir hesaba WETH transfer edildiğinde, güvenlik açığı bulunan AnySwap sözleşmesinden yararlanarak bunu doğrudan çok imzalı cüzdanımıza aktarabiliriz. Temel gereksinimler şunlardır:
- G1: Kurban hesaplara token transferi gerçekleştiren işlemleri verimli biçimde tespit etmek. Bu işlemleri aşağıda transfer İşlemleri olarak adlandırıyoruz.
- G2: Kurtarma işlemlerini gerçekleştirmek için gerekli işlemleri doğru biçimde oluşturmak. Bu işlemleri aşağıda kurtarma İşlemleri olarak adlandırıyoruz.
- G3: Saldırganlar (ve diğer üçüncü taraflar) tarafından gönderilen işlemlerin önüne başarıyla geçmek. Bu işlemleri aşağıda saldırı İşlemleri olarak adlandırıyoruz.
G1 ve G2 bizim için engel teşkil etmedi. Özellikle, transfer işlemlerini zamanında tespit etmemize olanak tanıyan dahili bir bellek havuzu izleme sistemi kurduk. Bu arada, işlemleri otomatik olarak oluşturan bir araç da geliştirdik.
Ancak G3 bir zorluk olmaya devam etti. Flashbots'un rekabeti kazanmak için kullanılabileceği düşünülebilir; ancak bu hedefe ulaşmak o kadar kolay değildir. Her şeyden önce, saldırganlar da Flashbots'u kullanıyor olabilir. Bir ücret teklifi sistemi olarak, başarı oranı madenciye belirtilen ücrete bağlı olabilir. Ücreti belirlemek için uygulanacak stratejinin kararlaştırılması gerekmektedir. İkinci olarak, yoğun rekabet nedeniyle Flashbots kullanmak iyi bir tercih olmayabilir. Bu nedenle, normal bellek havuzunu kullanarak da işlemler gönderdik. Başarıyı garanti altına almak için, işlemi doğru konuma yerleştirme stratejisi göz önünde bulundurulmalıdır. Son olarak, bazı durumlarda şüpheli görünen davranışlar sergileyen diğer beyaz şapkalılarla da mücadele ettik.
0x2.2 Dahil Olduğumuz Rekabetler
Toplamda 171 potansiyel kurbanı korumaya çalıştık; bunlardan 10'u, kurtarma operasyonunu gerçekleştirmeye çalışmamızdan hemen önce onayları iptal ederek kendilerini korudu. Geriye kalan 161 geçerli kurban için ise yalnızca 14'ünü kurtarmayı başarabildik; bu, rekabetin bir sonucuydu. Başarısızlık vakaları aşağıdaki tabloda özetlenmiş olup 3 kurtarma hesabı ve 16 saldırı hesabı içermektedir.
| No. | Hesap | Tür | # Kurban Sayısı | # Kayıp (ETH) | # Ücret (ETH) | Ort. Ücret % |
|---|---|---|---|---|---|---|
| 1 | 0x14ca** | Kurtarma hesabı | 44 | 431.651020 | 286.891724 | 66.46% |
| 2 | 0x9a65** | Kurtarma hesabı | 7 | 11.321441 | 0.000000 | 0.00% |
| 3 | 0x6360** | Kurtarma hesabı | 3 | 3.300000 | 0.891000 | 27.00% |
| 4 | 0x48e9** | Saldırı hesabı | 35 | 301.681589 | 0.000000 | 0.00% |
| 5 | 0x5738** | Saldırı hesabı | 58 | 78.482472 | 58.851862 | 74.99% |
| 6 | 0x34b2** | Saldırı hesabı | 2 | 53.591712 | 17.685265 | 33.00% |
| 7 | 0xd374** | Saldırı hesabı | 6 | 23.658698 | 10.073638 | 42.58% |
| 8 | 0x4986** | Saldırı hesabı | 16 | 22.900105 | 0.000000 | 0.00% |
| 9 | 0x1fe7** | Saldırı hesabı | 6 | 12.057241 | 0.000000 | 0.00% |
| 10 | 0x1b45** | Saldırı hesabı | 5 | 4.402442 | 3.010013 | 68.37% |
| 11 | 0xbca4** | Saldırı hesabı | 1 | 2.784250 | 1.392125 | 50.00% |
| 12 | 0x98f5** | Saldırı hesabı | 8 | 2.339543 | 0.000000 | 0.00% |
| 13 | 0x455d** | Saldırı hesabı | 3 | 0.741817 | 0.175454 | 23.65% |
| 14 | 0xfa27** | Saldırı hesabı | 3 | 0.320288 | 0.032590 | 10.18% |
| 15 | 0x0a5b** | Saldırı hesabı | 1 | 0.286750 | 0.143375 | 50.00% |
| 16 | 0x3ec7** | Saldırı hesabı | 1 | 0.245000 | 0.049000 | 20.00% |
| 17 | 0xee7e** | Saldırı hesabı | 1 | 0.190000 | 0.096900 | 51.00% |
| 18 | 0x835d** | Saldırı hesabı | 3 | 0.024533 | 0.000000 | 0.00% |
| 19 | 0xb0ab** | Saldırı hesabı | 1 | 0.000618 | 0.000000 | 0.00% |
Bu nedenle, toplulukla paylaşmak istediğimiz bazı dersler mevcuttur.
0x3 Öğrendiğimiz Bazı Dersler
0x3.1 Flashbots Madencisine Ödenecek Ücret Nasıl Belirlenir?
Özetle, 2'si kurtarma hesabı ve 10'u saldırı hesabı olmak üzere 12 rakip tarafından geride bırakıldık; hepsi Flashbots kullanıyordu.
Madenci ücretini belirleme stratejimiz oldukça temkinliydi. Özellikle, kurbanları mümkün olduğunca az ücret harcayarak korumayı hedefliyorduk. Bu nedenle, başarılı bir saldırı işlemi ücret belirlemediği sürece ücret kullanmıyor/artırmıyorduk. Örneğin, bir saldırgan fonun %10'unu ücret olarak belirlerse, o saldırganla rekabet edebilmek için bir sonraki kurtarma işleminde %11 kullanabilirdik. Ancak sonuçlar, saldırganların (hatta bazı beyaz şapkalıların) çoğu zaman (her zaman olmasa da) başkalarını geride bırakmak için agresif biçimde ücret artırdığını gösterdi:
- Şekil 5, saldırgan 0x5738**'in blok 14071986'da ücret yüzdesini %70 olarak belirlediğini göstermektedir.
- Şekil 6, beyaz şapkalı 0x14ca**'nın blok 14072255'te ücret yüzdesini %79 olarak belirlediğini göstermektedir.
- Şekil 7, beyaz şapkalı 0x14ca**'nın blok 14072385'te ücret yüzdesini %80 olarak belirlediğini göstermektedir.
- Şekil 8, beyaz şapkalı 0x9117**'nin blok 14072417'de ücret yüzdesini %81 olarak belirlediğini göstermektedir.
- Şekil 9, saldırgan 0x5738**'in blok 14073395'te ücret yüzdesini %86 olarak belirlediğini göstermektedir.
Kısaca, bu durum, rekabeti kazanmak için farklı katılımcıların davranışlarının modellenmesini gerektiren sıfır toplamlı bir oyuna benzemektedir.
Ancak pratikte, daha iyi/optimal stratejiler bulmak ve aynı zamanda maliyeti mümkün olduğunca azaltmak oldukça zorludur.
0x3.2 Bellek Havuzunda Doğru Konum Nasıl Belirlenir?
Artık kurtarma operasyonunun, Flashbots teklifinde ücret rekabeti silahlanma yarışına bağlı olduğu görülmektedir. Ancak kurtarma ve saldırıyla hiçbir ilgisi olmayan diğer katılımcılardan kaynaklanan yoğun rekabet nedeniyle Flashbots kullanımının her derde deva olmadığını keşfettik. Böyle bir durumda, bir saldırı işlemi tarafından belirlenen en yüksek ücret bile Flashbots kullanma şansını kazanmayı garanti edemez.
Alternatif olarak, bellek havuzunda doğru konumdaki normal bir işlemin hedefe ulaşma fırsatı yakalayabileceği görülmüştür. Burada doğru konum, kurtarma/saldırı işleminin transfer işleminin hemen arkasına yerleştirilmesi ve transfer işlemine mümkün olduğunca yakın olması (ne kadar yakın olursa o kadar iyi) anlamına gelmektedir. Bu stratejiyi kullanan saldırgan 0x48e9**'in Flashbots madencilerine herhangi bir ücret ödemeden 312.014657 ETH elde ettiğini belirtmek gerekir.
Aşağıdaki dört şekil, saldırganın elde ettiği en büyük iki kârı göstermektedir:
- Şekil 10, bir kurbanın blok 14051020'nin 65. konumunda 50 ETH yatırdığını; Şekil 11 ise saldırganın aynı blokta 66. konumda bu 50 ETH'yi ele geçirdiğini göstermektedir.
- Şekil 12, bir kurbanın blok 14052155'in 161. konumunda 200 ETH yatırdığını; Şekil 13 ise saldırganın aynı blokta 164. konumda bu 200 ETH'yi ele geçirdiğini göstermektedir.
Bu gelişmiş stratejinin son derece kullanışlı ve aydınlatıcı olduğu açıktır; bu konudan ders çıkarmak için daha fazla dikkat ve çaba gösterilmesi gerekmektedir.
0x4 Diğer Bazı Düşünceler
0x4.1 Beyaz Şapka Hack'i mi, Saldırı mı?
Beyaz şapka hack'lerinin tanınması söz konusu olduğunda, bunlar düşünüldüğü kadar basit olmayabilir.
Örneğin, 0xfa27 adresi Etherscan.io tarafından Multichain Exploiter 4 (Beyaz Şapka) olarak etiketlendi. Aslında başlangıçta Multichain Exploiter 4 olarak etiketlenmişti. Saldırgan ile AnySwap projesi arasında birkaç tur müzakerenin ardından, saldırgan çalınan fonların bir kısmını iade etmeye ikna edildi.
- 0x3c3d** işleminde AnySwap, saldırganla iletişime geçti:
Her şeyden önce WETH'i güvende tuttuğunuz için teşekkürler. Hack'ten haberdar değildim ve cowswap işleminin ardından WETH cüzdanıma ulaşmadığında durumu fark ettim. Söz konusu miktarı göz önünde bulundurarak, 50 ETH'yi adil bir bahşiş olarak kabul eder misiniz? İşte benim işlemim: 0x2db9a6a51604e2be8b2c3469773afb201f0b48a318fb7e5f5e49175e818df5ba 0xe50ed602bd916fc304d53c4fed236698b71691a95774ff0aeeb74b699c6227f7
- 0xd360** işleminde saldırgan yanıt verdi:
Lütfen bana geri bir işlem göndererek doğrulayın. Geri kalan 258 ETH'yi göndereceğim. Başka saldırganlar olduğu için 39 ETH madencilere gitti, bu yüzden parayı kurtarmak için o bahşişi ödemek zorunda kaldım.
- 0x354f** işleminde AnySwap, fonları aldıktan sonra teşekkürlerini iletti:
Alındı, dürüstlüğünüz için teşekkür ederiz.
Bu saldırganın aklandığı ve aynı zamanda saldırıdan kâr elde ettiği açıktır. Benzer vakalar geçmişte birçok kez yaşanmış olup toplulukta hâlâ tartışmalıdır; zira böyle bir teşvik adil olmayabilir.
0x4.2 Beyaz Şapka Hack'leri Arasındaki Rekabet?
Beyaz şapkalılar arasındaki rekabeti azaltmak/önlemek için bir koordinasyon mekanizması oluşturmak gerekmektedir. Böyle bir rekabet, kaçınılmaz olarak kurtarma gücünün israfına yol açar. Bu kurtarma operasyonunda, kurtarma girişimimize rağmen diğer üç beyaz şapkalı tarafından korunan 54 kurban (450 ETH fon ile) mevcuttu.
Beyaz şapkalılar arasındaki rekabet yalnızca kurtarma gücünü israf etmekle kalmadı, aynı zamanda operasyonun maliyetini de artırdı. Örneğin, şekil 7 ve şekil 8'de gösterildiği gibi, farklı beyaz şapkalıların iki kurtarma işleminin harcadığı ücretler sırasıyla %80 ve %81 oldu.
Ne yazık ki, beyaz şapkalılar birbirleriyle koordinasyon sağlamak için herhangi bir mekanizma olmadıkça geri adım atmayacaktır. Aksi takdirde, rekabetin ortadan kalkması mümkün olmayacaktır.
0x4.3 Daha İyi Bir Kurtarma Nasıl Gerçekleştirilir?
Bir yandan, topluluğu ikna etmek için, beyaz şapkalıların hassas ayrıntıları sızdırmadan eylemlerini önceden kamuoyuyla paylaşmaları iyi bir pratik oluşturur. Kurtarma operasyonu, belirli bir saldırıyı engellemek gibi tek seferlik bir çabadan farklı olarak genellikle birden fazla deneme içeren uzun soluklu bir süreç olduğundan, bunu yapmak için yeterli zaman mevcuttur. Elbette, güvenlik açıklarına ilişkin ayrıntılı bilgiler sızdırılmamalıdır.
Bunu başarmak için, ayrıntılı bilgiler başlangıçta açıklanmayacak ve kurtarma operasyonu tamamlandıktan sonra toplulukla paylaşılacaktır; tıpkı AnySwap kurtarma operasyonunda yaptığımız gibi. Ancak, beyaz şapka niyetini içeren belgenin hash değeri toplulukla paylaşılabilir.
Öte yandan, topluluk kurtarma operasyonunu daha etkin ve verimli biçimde gerçekleştirmek için daha fazlasını yapabilir; bunlar şunları içermekle birlikte bunlarla sınırlı değildir:
- Flashbots/Madenci, sertifikalı beyaz şapkalılar için yeşil bir kanal sağlayabilir. Bu yeşil kanal, saldırganların işlemlerinin önüne geçmek için yüksek öncelik tanıyabilir ve beyaz şapkalılar arasındaki rekabeti önleyebilir.
- Saldırıya uğrayan projeler, Flashbots/madenci maliyetlerini karşılayabilir.
- Projeler, kullanıcılara yönelik kullanışlı ve hızlı bildirim mekanizmaları uygulayabilir.
- Proje, kod içinde acil durum mekanizması uygulayabilir.
BlockSec Hakkında
BlockSec, 2021 yılında dünya genelinde tanınan güvenlik uzmanlarından oluşan bir ekip tarafından kurulan öncü bir blok zinciri güvenlik şirketidir. Şirket, kitlesel benimsemeyi kolaylaştırmak amacıyla gelişmekte olan Web3 dünyasının güvenliğini ve kullanılabilirliğini artırmaya kararlıdır. Bu doğrultuda BlockSec, akıllı sözleşme ve EVM zinciri güvenlik denetimi hizmetleri, güvenlik geliştirme ve tehditleri proaktif olarak engellemeye yönelik Phalcon platformu, fon takibi ve araştırma için MetaSleuth platformu ve web3 geliştiricilerinin kripto dünyasında verimli biçimde gezinmesine yardımcı olan MetaSuites eklentisini sunmaktadır.
Bugüne kadar şirket, MetaMask, Uniswap Foundation, Compound, Forta ve PancakeSwap gibi 300'den fazla saygın müşteriye hizmet vermiş; Matrix Partners, Vitalbridge Capital ve Fenbushi Capital gibi önde gelen yatırımcılardan iki tur finansmanda onlarca milyon ABD doları yatırım almıştır.
Resmi web sitesi: https://blocksec.com/
Resmi Twitter hesabı: https://twitter.com/BlockSecTeam
