Back to Blog

BlockSec'in Jump "Karşı İstismar" Hakkındaki Görüşü: Güvenlik Açığı Gerçekten Var mı?

Code Auditing
March 1, 2023
7 min read
Fotoğraf: Kevin Ku, Unsplash
Fotoğraf: Kevin Ku, Unsplash

Son zamanlarda, Oasis çoklu imza cüzdanını kullanarak MakerDao Vault'tan fon taşımaya yönelik "karşı istismar" işlemine büyük ilgi gösterilmektedir. Bu arada, 18 Şubat'ta Platypus'a 2,4 milyon dolarlık kurtarma işleminde yer aldığımız için BlockSec'in bu operasyonun arkasındaki "beyaz şapkalı" olup olmadığına dair birkaç soru aldık. BlockSec'in Jump davasındaki hiçbir işlemde yer almadığını açıkça belirtmek istiyoruz. Ayrıntılı bir analizin ardından (BlockWorks'te Dan Smith tarafından yayımlanan mükemmel analize teşekkürler), Jump "karşı istismar" işleminde kullanılan yöntemin Platypus durumundan temelden farklı olduğunu düşünüyoruz.

Bunun yanı sıra, Oasis'in açıklamasına göre karşı istismar, yönetici çoklu imza erişimindeki bir güvenlik açığı nedeniyle mümkün olmuştur

Oasis açıklamasından ekran görüntüsü
Oasis açıklamasından ekran görüntüsü

Ancak analizimize göre, karşı istismarın temel adımları şunlardır:

  • Gecikmeli yürütmenin devre dışı bırakılması. Bu işlemin, Oasis Çoklu İmza cüzdanı olan Service Registry sözleşmesinin sahibi tarafından yapılması tasarlanmıştır.
  • AUTOMATION_EXECUTOR (AutomationBot sözleşmesi için) ve MCD_VIEW, MULTIPLY_PROXY_ACTIONS (CloseCommand sözleşmesi için) dahil olmak üzere kritik roller için kayıtlı sözleşme adresinin değiştirilmesi. Bu, Oasis çoklu imza cüzdanının doğrudan AutomationBot'u çağırarak kapatma komutunu çalıştırmasına olanak tanır; gerçek yürütülen işlem ise İstismarcının Vault'larını taşımak amacıyla yenisiyle değiştirilmiştir.

Analizimiz, bu temel adımların yönetici çoklu imza erişimindeki iddia edilen güvenlik açıklarından KAYNAKLANMADIĞını ortaya koymaktadır.

Sorumluluk Reddi: Bu blog, zincir üstü işlemler ve kamuya açık bilgiler temel alınarak yazılmıştır. Soru veya yorumlarınız için [email protected] adresinden bizimle iletişime geçmekten çekinmeyin.

Genel Süreç

Bu operasyon süresince birkaç adres yer aldı. Bunların bir kısmını aşağıdaki Google belgelerinde listeliyoruz.

https://docs.google.com/spreadsheets/d/1k0PEci8wQ16X7JT7KRq9SvhaCA2yerJcqLn6EfAoPZs/edit?usp=sharing

Jump karşı istismarının üst düzey fikri özellikle şu şekildedir:

  1. İstismarcı'nın Maker Vault'ları, İstismarcı'nın Oasis tarafından sunulan otomasyon satış ve satın alma hizmetlerini etkinleştirmesi nedeniyle Oasis AutomationBot akıllı sözleşmesi tarafından yönetilebilir.

  2. AutomationBot yalnızca AUTOMATION_EXECUTOR rolüne sahip adres tarafından çalıştırılabilir. Bu adres, Oasis çoklu imza cüzdanı tarafından güncellenebilen Oasis Service Registry sözleşmesindeki bir yapılandırmadır. Ancak Oasis Service Registry sözleşmesinin yapılandırmasında yapılacak güncellemenin, Oasis çoklu imza cüzdanı tarafından devre dışı bırakılabilen gecikmeli bir yürütme mekanizması vardır.

  3. AutomationBot tarafından yürütülen gerçek sözleşme ve işlev, Oasis Service Registry'de de yapılandırılabilir niteliktedir.

Bu nedenle Oasis çoklu imza cüzdanı önce Oasis Service Registry sözleşmesinin gecikmeli yürütmesini devre dışı bırakır ve AUTOMATION_EXECUTOR rolünü kendisi (çoklu imza cüzdanı) olarak ayarlamak için Oasis Service Registry sözleşmesindeki yapılandırmayı değiştirir. Değişiklik hemen geçerli olur. Ardından çoklu imza cüzdanı, İstismarcı'nın Maker Vault'larını devralmaya (kaydırma ve devretme) yarayacak bir komutu çalıştırması için AutomationBot'u çağırır. AutomationBot, İstismarcı'nın Vault'larını yönetebildiğinden tüm operasyon başarılı olabilir.

Bu sürecin, saldırganın sözleşmesinde bir güvenlik açığı bulduğumuz ve bunu Platypus ile paylaştığımız Platypus davasından temelden farklı olduğunu düşünüyoruz. Ardından Platypus, kendilerine ait fonları taşımak için saldırganın sözleşmesinden yararlandı. Ancak Jump davasında Oasis çoklu imza, gecikmeli yürütme mekanizmasını devre dışı bırakmakta, sözleşmenin davranışını tamamen değiştirebilecek kritik yapılandırmaları güncellemekte ve İstismarcı adına Maker'ın Vault'larında işlem yapmak için AutomationBot'un yönetim rolünden yararlanmaktadır.

Aşağıda Jump "karşı istismarının" tamamını ayrıntılı olarak ele alacağız.

Ayrıntılı Adımlar

Operasyon; Jump, Oasis, Wormhole İstismarcısı ve Maker dahil olmak üzere birden fazla protokol ve tarafı kapsamaktadır. Maker'ın operasyon süresince herhangi bir eylemde bulunmadığını belirtmek gerekir.

Özellikle, İstismarcı Maker Vault'ları (30100 ve 30179) oluşturur ve ETH'yi teminat olarak kullanarak vault'tan DAI borç alır. İstismarcı aynı zamanda Maker vault'unun teminatlandırma oranını yönetmek için Oasis tarafından sunulan otomasyon satış ve satın alma hizmetlerinden yararlanmıştır.

Oasis otomasyon hizmetini kullanabilmek için Oasis tarafından sunulan AutomationBot adlı akıllı sözleşmenin Vault'un yönetim listesine eklenmesi gerekir. Bu, AutomationBot'un İstismarcı tarafından oluşturulan Maker Vault üzerinde denetim sahibi olduğu anlamına gelir. Bunun ardından AutomationBot, Vault'u değiştirebilir ve Vault'un teminatını ve borcunu Jump tarafından kontrol edilen başka bir Vault'a aktarabilir. "Karşı istismarın" temel süreci budur. AutomationBot'u çağırmak için işlemin, ServiceRegistry sözleşmesinde AUTOMATION_EXECUTOR olarak kayıtlı adresten başlatılması gerektiğini de belirtmek gerekir.

Adım 1: 04e1 adresini Oasis çoklu imza cüzdanına ekleme

İşlem, 04e1 adresini Oasis çoklu imza cüzdanına ekler. Bu cüzdan şu anda 12 adrese sahip olup dört imzacının onayını gerektirmektedir.

Adım 2: Oasis Service Registry'nin gecikmeli yürütmesini devre dışı bırakma

Bu işlem, changeRequiredDelay(0) çağrısı yapılarak Oasis Service Registry'nin gecikmeli yürütmesini devre dışı bırakır. Oasis Service Registry'nin, AutomationBot tarafından kullanılacak kritik yapılandırma bilgilerini depolayan bir akıllı sözleşme olduğunu belirtmek gerekir. Genellikle yapılandırma değişikliği, "karşı istismarda" kullanılacak updateNamedService gibi kritik işlemler için gecikmeli bir yürütme mekanizmasına sahiptir. Gecikmeli yürütme, kritik bilgilerin güncellenmesinin hemen geçerli olmamasını ve diğerlerinin yeniden inceleyebilmesini sağlayan bir güvenlik mekanizmasıdır.

changeRequiredDelay çağrısının yürütülmesinin, gecikmeli yürütme tarafından kısıtlandığını unutmayın (reqDelay'de yapılan değişiklik henüz geçerli olmadığından).

ServiceRegistry.sol
ServiceRegistry.sol

Adım 3: Karşı istismarı gerçekleştirme

Bu işlem karşı istismarı gerçekleştirir. BlockSec tarafından geliştirilen işlem analiz aracı Phalcon'un yürütme izine dalalım.

Bu işlemin 04e1 adresinden başlatıldığını ve Oasis çoklu imza cüzdanı aracılığıyla yürütüldüğünü, yani işlemin en az dört imzacı tarafından imzalandığını belirtmek gerekir.

Adım 3.1: Gecikmeli yürütmeyi devre dışı bırakma

İzde görüldüğü üzere gecikme sıfıra ayarlanmaktadır. Bu, 2. adımdaki gecikmeli yürütmeyi devre dışı bırakma işlemini uygulamak içindir.

Adım 3.2: İki sözleşme oluşturma ve service registry'yi güncelleme

MCD_VIEW ve MULTIPLY_PROXY_ACTIONS sözleşmeleri olarak kullanılacak iki yeni sözleşme oluşturulur.

  • MCD_VIEW: 0xceca8d8410797bc6c575fd8ba957708d1e85ed36
  • MULTIPLY_PROXY_ACTIONS: 0xcaef24016d0fba2c1a9427371e0d79c5781b6ea8

Ardından bu iki sözleşme, Oasis service registry sözleşmesinde güncellenecektir.

Adım 3.3: Otomasyon Yürütücüsünü değiştirme

Oasis çoklu imzası, ServiceRegistry sözleşmesinde AUTOMATION_EXECUTOR olarak kaydedilmiştir. Bu zorunludur; zira yalnızca bu role sahip kayıtlı sözleşme, AutomationBot sözleşmesini çağırabilir.

AutomationBot.sol
AutomationBot.sol
AutomationBot.sol
AutomationBot.sol

Adım 3.4: AutomationBot'tan İstismarcının Vault'unu kapatmasını isteme

Kritik süreç, AutomationBot'un execute işlevinden başlar. Ayrıntılı yürütülen işlevler argümanlar aracılığıyla iletilir.

Tüm süreci anlamak için önce bu işleve göz atalım.

AutomationBot.sol
AutomationBot.sol

Üst düzey mantık, botun önce vault'tan DAI çekmesi (268. satır) ve ardından vault üzerinde yürütmek üzere somut komut sözleşmesini çağırmasıdır (cdpId ile belirtilmiş) (274 ile 278. satırlar arasında). Bu süreçte komut adresi CloseCommand sözleşmesidir. Bunun ardından isExecutionCorrect kontrolü yapılması gerekmektedir.

Aşağıda CloseCommand sözleşmesinin execute işlevi gösterilmektedir. MULTIPLY_PROXY_ACTIONS anahtarını kullanarak service registry sözleşmesinden gerçek yürütücü sözleşme adresini alır. MULTIPLY_PROXY_ACTIONS'a karşılık gelen sözleşme adresinin yeni biriyle güncellendiğini unutmayın. Bu nedenle CloseCommand'ın gerçek yürütmesi, yeni sözleşmede keyfi işlemler gerçekleştirmek amacıyla kontrol edilebilir hale gelir.

CloseCommand.sol
CloseCommand.sol
CloseCommand.sol
CloseCommand.sol

isExecutionCorrect'in, yürütmenin başarılı olup olmadığını kontrol etmek için CloseCommand üzerinde çağrıldığını hatırlayın (AutomationBot.sol'un 278. satırı). Görünüm adresi güncellendiğinden, viewerContract.getVaultInfo(cdpId) kontrolünün dönüş değeri, CloseCommand.sol'un 24. satırındaki kontrolü geçebilecek rastgele bir değer olabilir.

Koda göz attıktan sonra yürütme izine bakalım. İzden, automationBot'un CloseCommand sözleşmesini çağırdığını görebiliriz. CloseCommand sözleşmesi, yeni bir Vault (30231) açmak, Vault 30100'ü (İstismarcı'nın) 30231'e (yeni oluşturulan) kaydırmak ve yeni Vault 30231'i Oasis Çoklu İmza Cüzdanına devretmek için değiştirilen MULTIPLY_PROXY_ACTIONS sözleşmesini çağırabilir. İstismarcı'nın diğer Vault'u (30179) üzerinde de benzer bir işlem gerçekleştirilir.

Adım 3.5: Durumu geri yükleme

Service Registry'deki değiştirilen girişi geri yükleyin ve gecikmeli yürütmeyi yeniden etkinleştirin.

Adım 3.6: Vault'ları 1536 adresine devretme

Artık yeni Vault'lar (30231 ve 30232) Oasis Çoklu İmza Cüzdanı tarafından kontrol edilmektedir. Ardından Vault'lar bu işlemlerde [TX1 TX2] 0x15364305a06ba3ac6ba13dfe97ca0bad639adf41 adresine devredilir. Bu adres, Vault'taki borcu ödeyebilir ve teminatı (Ethereum) çekebilir. Teminatlandırma oranı yüksek olduğundan (vault 30100 için yaklaşık %293), borcu geri ödeyip teminatı çekmek, vault 30100'den yaklaşık 76 milyon dolar borç ödeme maliyetiyle yaklaşık 120.000 Ethereum geri almayı sağlayabilir. Okuyucular bu işlemler hakkında daha fazla bilgi için Maker protokolü belgesine başvurabilir.

BlockSec Hakkında

BlockSec, 2021 yılında dünya genelinde tanınan bir grup güvenlik uzmanı tarafından kurulmuş öncü bir blok zinciri güvenlik şirketidir. Şirket, kitlesel benimsenmesini kolaylaştırmak amacıyla gelişen Web3 dünyasında güvenliği ve kullanılabilirliği artırmayı taahhüt etmektedir. 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 kripto dünyasında verimli şekilde gezinen web3 geliştiricileri için MetaSuites uzantısı sunmaktadır.

Şirket bugüne kadar 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 seçkin yatırımcıların katıldığı iki finansman turunda on milyonlarca dolar fon sağlamıştır.

Resmi web sitesi: https://blocksec.com/

Resmi Twitter hesabı: https://twitter.com/BlockSecTeam

Best Security Auditor for Web3

Validate design, code, and business logic before launch. Aligned with the highest industry security standards.

BlockSec Audit