Bu blogda, Poly Network Hack'inin tüm sürecini incelemek ve öğrenilen dersleri tartışmak istiyoruz.
Poly Network'ün 10 Ağustos 2021'de (bu blogda +8 saat dilimini kullanıyoruz) saldırıya uğradığını öğrendik. Ancak saldırının nasıl gerçekleştiğine ve temel nedenin ne olduğuna dair hiçbir ipucu yoktu. Bir güvenlik araştırma ekibi olarak soruşturmamıza başladık.
Adım 1: Saldırı işlemini bul
Saldırı işlemi olan 0xd8c1f7424593ddba11a0e072b61082bf3d931583cb75f7843fc2a8685d20033a'yı işlem sanallaştırma sistemimizde (https://tx.blocksecteam.com) yeniden oynadık.
İz oldukça basittir; bu durum, fiyatı manipüle eden diğer saldırılardan farklıdır. Bu tür saldırılar genellikle çok karmaşık fonksiyon çağrımlarına sahiptir (Bkz. Popsicle hack.)
Adım 2: Sözleşme kodunu analiz et
Saldırı izini aldıktan sonra sözleşmenin kaynak kodunu incelememiz gerekiyordu. Şaşırtıcı bir şekilde, poly network'ün Etherscan'da doğrulanmış kaynak kodu BULUNMAMAKTADIR. Ancak yayımlanan kaynak kodu github'da bulmayı başardık.
Kaynak kodunu inceledikten sonra belirgin bir kod güvenlik açığı bulamadık. Saldırı izini meşru bir işlem iziyle de karşılaştırdık ve birbirine benzediklerini gördük.
Adım 3: Kritik durumları kurtar
Ardından saldırı sırasındaki kritik durumları kurtardık. Saldırı, VerifyHeaderAndExecuteTxEvent çağrısından başlatıldığından, ilk analizimizde paylaştığımız [1] birkaç kritik değişken değerini kurtardık.
Bu süreçte yalnızca bir bekçi (keeper) olduğunu fark ettik (yukarıdaki şekle bakınız). Değer saldırı izinden elde edildiğinden ve saldırı işlemi tüm imza doğrulama aşamalarını geçtiğinden, olası nedenin özel anahtarın sızması veya sunucunun imzalama sürecindeki bir hata olabileceğini düşündük [1].
Ancak burada bir hata yaptık. Bir saldırıyı analiz etmek soğan soymaya benzer. Gerçek "asıl asıl asıl" nedeni bulana kadar her seferinde bir katman soyarsınız. O an, bekçinin değiştirilip değiştirilmediğini görmek için soğanı daha fazla soymadık!
Adım 4: Yeni ipucu
Birkaç saat sonra Kelvin ve slow mist, Twitter'da bekçinin değiştirildiğini gösteren yeni ipuçları paylaştı. Değiştirme süreci, güçlü bir fonksiyonu çağırmak için hash çakışmasını kötüye kullanıyor — "akıllıca" bir hack.
Şimdi ilk analizimizin tamamlanmamış olduğunu fark ettik. En son bilgilere dayanarak bekçiyi değiştiren işlemi yeniden oynadık. İz yine de çok basit.
Ancak unutmayın ki bu işlem sırasında dört bekçi vardı (bir yerine). Tüm bu anahtarlar diğer meşru işlemlerle aynıydı — bu da anahtarların meşru olduğu anlamına geliyordu. İşte burada soru ortaya çıktı: bekçiyi değiştiren işlem neden zincire yazılıp ilk etapta yürütülebildi?
Adım 5: Kaynak işlemi bul
Poly Network bir zincirler arası köprü olduğundan kaynak işlemi bulmaya çalıştık. Bir yerde kaynak işlemin bulunması gerekiyordu. Bunu, kritik değişkeni (aşağıdaki resimde gösterildiği gibi) çözerek yaptık. Bu, kaynak zincirin ve poly zincirin işlem hash'ini göstermektedir.
Başka hiçbir yerde bahsedilmemiş bir numara var. Değişkendeki tx hash değeri, poly zincirindeki resmi değerden farklı bir gösterime sahiptir. Örneğin, şekildeki poly zincirinin tx hash değeri 0x80cc978479eb082e1e656993c63dee7a5d08a00dc2b2aab88bc0e465cfa0721a'dır. Ancak poly zinciri tarayıcısında hash değeri 1a72a0cf65e4c08bb8aab2c20da0085d7aee3dc69369651e2e08eb798497cc80'dir (farkı görüyor musunuz?). Bulgularımızı 11 Ağustos 16:55'te EthereumSecurity tg grubunda paylaştık.
Adım 6: Temel nedeni bul
Ancak yine de "bekçiyi değiştiren işlemin neden zincire yazılabildiği" sorusunu yanıtlayamıyorduk. Bu soruyu yanıtlamak için Ontology zincirinden başladık ve işlem akışını bulduk:
Ontology işlemi -> Ontology aktarıcı -> Poly zinciri -> Ethereum aktarıcı -> Ethereum
Ardından Ontology zincirinin ve aktarıcıların kaynak kodunu okuduk. Birkaç saat sonra Ontology aktarıcısının zincirler arası işlem için yeterli doğrulamaya sahip olmadığını keşfettik. Bu durum, kötü niyetli işlemin poly zincirine yazılmasına olanak tanıdı. Bunun ardından sistem ele geçirildi.
Dahili tartışma ve değerlendirmenin ardından bulgularımızı 12 Ağustos 02:41'de Twitter ve medium'da yayımladık [3].
Dersler
-
Tasarım aşamasında güvenlik. Güvenlik, DeFi projesinin tüm sürecinde yer almalıdır. Kullanıcılar paralarını projeye emanet eder. Buna karşılık proje bu güveni hak etmelidir. Ne yazık ki Poly Network'ün güvenliği göz ardı ettiğini gördük. Örneğin, doğrulama eksikliği lisans düzeyindeki derslerde öğrettiğim eski bir güvenlik açığıdır.
-
600M TVL'yi aşan böyle bir DeFi projesinin doğrulanmış kaynak kodu bulunmamaktadır. Merkeziyetsiz altyapının temeli güven, güvenin temeli ise şeffaflıktır. Ne yazık ki kullanıcılar paralarını kapalı kutu bir projeye yatırmaya hazırdır; bu durum beni hem şaşırtmakta hem de endişelendirmektedir. Kullanıcıların güvenlik bilincini nasıl artıracağımız muhtemelen yeni bir çözüm gerektirmektedir.
Referanslar
[1]https://blocksecteam.medium.com/the-initial-analysis-of-the-polynetwork-hack-270ac6072e2a
[2]https://twitter.com/kelvinfichter/status/1425290462076747777
[3]https://blocksecteam.medium.com/the-further-analysis-of-the-poly-network-attack-6c459199c057
Katkıda bulunanlar: Yufeng Hu, Siwei Wu, Lei Wu, Yajin Zhou @ BlockSecTeam
