Panduan Keamanan Ekosistem Kosmos: Mendekonstruksi skenario keamanan berbagai komponen Ekosistem Kosmos

Artikel ini tidak hanya mencakup analisis kerentanan keamanan utama di masa lalu dalam ekosistem Cosmos, namun juga mengklasifikasikan beberapa kerentanan keamanan umum berdasarkan penyebab, dampak, lokasi kode, dll., untuk memberikan panduan keamanan semaksimal mungkin bagi pengembang ekosistem Cosmos , dan untuk memberikan pembelajaran dan panduan bagi auditor keamanan.Mengaudit data indeks untuk masalah keamanan Cosmos.

**Judul asli: “Eksklusif CertiK: Mendekonstruksi Keamanan Ekologis Kosmos dan Memfasilitasi Perjalanan Antarbintang Web3” **

Ditulis oleh: CertiK

*Sebagai salah satu ekosistem blockchain terbesar dan paling terkenal di dunia, Cosmos berfokus pada peningkatan interoperabilitas blockchain dan mencapai interoperabilitas yang efisien antara berbagai blockchain. Serangkaian proyek terkemuka termasuk Celestia dan dYdX v4 dibangun berdasarkan Cosmos SDK dan protokol IBC. *

*Karena komponen pengembangan Cosmos lebih disukai oleh lebih banyak pengembang, masalah keamanan di ekosistem Cosmos pasti memiliki dampak yang lebih luas. Misalnya, kerentanan Dragonfruit di Cosmos SDK sebelumnya memengaruhi operasi normal beberapa jaringan publik arus utama. Karena sifat komponen dasar ekosistem Cosmos yang terdesentralisasi, pengembang perlu menggunakan atau memperluas komponen yang berbeda sesuai dengan kebutuhan fungsional yang berbeda. Akibatnya, masalah keamanan di ekosistem Cosmos juga tersebar dan beragam. Sebuah studi yang membantu pengembang memahami secara struktural status terkini dan tindakan penanggulangan keamanan ekologis Cosmos sangat diperlukan. *

“Panduan Keamanan Ekosistem Cosmos” yang dirilis secara eksklusif oleh tim CertiK merinci skenario keamanan berbagai komponen ekosistem Cosmos melalui klasifikasi yang mudah dibaca*. Laporan ini tidak hanya mencakup analisis kerentanan keamanan utama di masa lalu dalam ekosistem Cosmos, tetapi juga mengklasifikasikan beberapa kerentanan keamanan umum berdasarkan penyebab, dampak, lokasi kode, dll., untuk memberikan panduan keamanan semaksimal mungkin bagi pengembang ekosistem Cosmos. dan untuk memberikan pembelajaran dan panduan bagi auditor keamanan.Mengaudit data indeks untuk masalah keamanan Cosmos. *

*Tim CertiK telah membantu meningkatkan keamanan ekologi Cosmos dan seluruh Web3 melalui penelitian dan penambangan yang berkelanjutan. Kami akan secara rutin memberikan Anda berbagai laporan keselamatan proyek dan penelitian teknis, harap terus memperhatikannya! Jika Anda memiliki pertanyaan, Anda dapat menghubungi kami kapan saja. *

*Berikut ini adalah teks lengkap dari "Panduan Keamanan Ekologi Kosmos"👇. *

Ringkasan

Cosmos adalah jaringan lintas rantai blockchain sumber terbuka, terbuka, sangat skalabel dan salah satu ekosistem blockchain paling terkenal di dunia. Cosmos adalah jaringan heterogen yang diluncurkan oleh CometBFT (sebelumnya tim Tendermint) yang mendukung interaksi lintas rantai. Ini terdiri dari beberapa blockchain independen dan paralel untuk membentuk jaringan terdesentralisasi. Visinya adalah untuk memecahkan efek pulau informasi dan mewujudkan blok yang berbeda. Interoperabilitas antar rantai. Di era multi-rantai saat ini, mewujudkan interaksi lintas rantai telah menjadi kebutuhan mendesak dalam industri blockchain.

Cosmos menyediakan model lintas rantai yang efisien, yang sangat cocok untuk rantai publik yang berfokus pada bidang vertikal tertentu. Dengan menyediakan infrastruktur blockchain modular, Cosmos memberikan kemudahan bagi pengembang aplikasi untuk memilih dan menggunakan rantai publik yang memenuhi kebutuhan mereka.

Aplikasi dan protokol di ekosistem Cosmos terhubung menggunakan IBC (Inter-Blockchain Communication Protocol), yang memungkinkan interaksi lintas rantai antara blockchain independen, memungkinkan aset dan data mengalir dengan bebas. Visi Cosmos adalah membangun internet dari blockchain yang memberikan kemungkinan bagi sejumlah besar blockchain yang otonom dan mudah dikembangkan untuk berkembang dan berinteraksi.

Untuk waktu yang lama, CertiK mempertahankan perhatian penuh dan penelitian terhadap lingkungan ekologi Cosmos. Kami telah mengumpulkan pengalaman yang cukup dalam masalah keamanan ekologi Cosmos. Dalam laporan penelitian ini, kami akan memperkenalkan hasil eksplorasi dan penelitian kami tentang keamanan ekosistem Cosmos, terutama berfokus pada keamanan Cosmos SDK, keamanan protokol IBC, dan keamanan CometBFT. Dan empat arah. Keamanan CosmWasm, objek diskusi akan meluas dari komponen dasar Cosmos hingga rantai dasar atau rantai aplikasi Cosmos. Melalui analisis dan perluasan isu serupa, kami akan menunjukkan kepada pembaca tentang ekosistem Cosmos secara bottom-up cara.Titik keamanan yang terlibat dalam rantai itu sendiri.

Karena kompleksitas dan keragaman ekosistem Cosmos, permasalahan keamanan yang ada pun memiliki karakteristik yang beragam, sehingga laporan penelitian ini tidak mencakup semua jenis kerentanan keamanan.** Hanya membahas karakteristik yang lebih khas dan keberadaan ekosistem Cosmos. kerentanan yang lebih merusak**. Jika Anda ingin mengetahui detail selengkapnya tentang masalah keamanan lainnya, silakan hubungi teknisi keamanan CertiK untuk berdiskusi.

latar belakang

• CometBFT: Landasan skalabilitas lintas rantai

CometBFT adalah algoritma konsensus inovatif, yang mencakup dua komponen utama: mesin konsensus yang mendasarinya (CometBFT Core) dan antarmuka blockchain aplikasi universal (ABCI). Algoritme konsensusnya mengadopsi konsensus hibrid PBFT+Bonded PoS untuk memastikan bahwa node mencatat transaksi secara sinkron. Sebagai komponen inti skalabilitas Interchain, CometBFT menjaga keamanan, desentralisasi, dan integritas ekosistem Interchain melalui konsensus validator.

• Cosmos SDK: Modularitas dan fitur baru

Cosmos SDK adalah perangkat yang membantu pengembang mempercepat proses pengembangan dan menyediakan fitur modular dan pluggable. Dengan menggunakan Cosmos SDK, pengembang dapat membangun blockchain atau komponen fungsional mereka sendiri berdasarkan algoritma konsensus CometBFT. Mencapai pengembangan yang mudah dan mempersingkat pengembangan siklus. Saat ini diadopsi di banyak proyek blockchain seperti Cronos, Kava dan dYdX V4 yang baru saja diluncurkan. Rencana pengembangan di masa depan akan fokus pada modularisasi dan pengenalan fitur-fitur baru, memungkinkan pengembang untuk membuat aplikasi modular yang lebih kompleks dan mendorong ekosistem yang lebih luas dan kuat.

• Protokol IBC: Peningkatan interoperabilitas dan skalabilitas

Protokol IBC (Protokol Komunikasi Antar-Blockchain) memungkinkan transfer data yang aman, terdesentralisasi, dan tanpa izin antar blockchain. Karena Cosmos adalah jaringan terdesentralisasi yang terdiri dari beberapa blockchain independen dan paralel dan menggunakan teknologi relai untuk mewujudkan rantai silang antara berbagai blockchain, IBC dapat dikatakan sebagai bagian inti dari keseluruhan proyek. Interchain Foundation saat ini berfokus pada dua topik: skalabilitas dan kegunaan. Dengan meningkatkan skalabilitas dan interoperabilitas IBC, Cosmos akan semakin meningkatkan kapasitas ekosistemnya, memungkinkan interaksi yang lancar antara blockchain, aplikasi, dan kontrak pintar.

• CosmWasm: Membuka penerapan yang terdesentralisasi dan tanpa izin

CosmWasm (Cosmos WebAssembly) adalah kerangka kerja kontrak pintar berbasis WebAssembly yang dirancang khusus untuk ekosistem Cosmos. Hal ini memungkinkan pengembang untuk menyebarkan aplikasi terdesentralisasi tanpa persyaratan izin, sekaligus memungkinkan pengembang blockchain untuk memisahkan siklus pengembangan produk mereka dari pengembangan blockchain, sehingga mengurangi biaya peningkatan validator. Selain itu, ia juga memiliki arsitektur modular, integrasi Cosmos SDK, komunikasi lintas rantai, dan fitur lainnya.

Hingga saat ini, Cosmos SDK dan protokol IBC relatif matang dan paling banyak digunakan di ekosistem Cosmos saat ini.

Dari perspektif pengembang rantai, sebagian besar fungsi khusus yang diperlukan oleh rantai ekologi saat ini di Cosmos dapat diselesaikan dengan mengandalkan Cosmos SDK Untuk mencapai beberapa operasi khusus dalam proses operasi lintas rantai atau untuk tujuan pengoptimalan kinerja, dll., pengembang rantai akan menyesuaikan modul IBC mereka sendiri. Selain itu, sejumlah kecil rantai akan memodifikasi dan menyesuaikan mesin yang mendasarinya seperti CometBFT Core. Karena keterbatasan ruang, laporan penelitian ini tidak akan dilakukan untuk saat ini Laporan penelitian ini akan Fokus pada analisis poin teknis dan masalah keamanan Cosmos SDK dan protokol IBC.

Panduan Keamanan Cosmos SDK

Cosmos SDK adalah kerangka kerja yang kuat dan fleksibel untuk membangun aplikasi blockchain dan protokol terdesentralisasi. Dikembangkan oleh Interchain Foundation, ini adalah komponen inti dari Cosmos Network, jaringan terdesentralisasi dari blockchain yang saling berhubungan.

Cosmos SDK dirancang untuk menyederhanakan pengembangan aplikasi blockchain khusus dan memungkinkan interoperabilitas yang lancar antar blockchain yang berbeda. Cosmos SDK terutama memiliki beberapa fitur berikut: Arsitektur modular, kemampuan penyesuaian, berdasarkan CometBFT, mengimplementasikan antarmuka yang sesuai dengan IBC, dan ramah pengembang. Cosmos SDK memastikan keamanan yang kuat dengan memanfaatkan mesin konsensus yang mendasari CometBFT Core untuk melindungi jaringan dari serangan jahat dan memberikan perlindungan bagi aset dan data pengguna. Selain itu, modularitasnya memungkinkan pengguna merancang modul khusus dengan mudah. Terlepas dari kelebihan ini, kerentanan keamanan masih ada ketika pengembang menggunakan Cosmos SDK untuk mengimplementasikan aplikasi mereka sendiri.

Dari perspektif audit keamanan, kita harus komprehensif dalam tujuan audit dan sepenuhnya mempertimbangkan risiko keamanan dari semua sudut. Namun, dari perspektif penelitian keamanan, kita perlu lebih memperhatikan kerentanan keamanan yang dapat menimbulkan dampak signifikan. waktu Sebisa mungkin hindari bahaya keselamatan terbesar dalam jangka waktu tertentu, dan berikan bantuan yang lebih efektif kepada penyedia layanan integrasi. Dari perspektif ini, sangat penting dan berharga untuk mengklasifikasikan beberapa kerentanan dengan tingkat bahaya tinggi dan dampak besar serta menganalisis model kerentanannya**.

Di antara antarmuka ABCI di seluruh ekosistem Cosmos, kami fokus pada empat antarmuka BeginBlock, EndBlock, CheckTx, dan DeliverTx. Dua yang pertama secara langsung melibatkan logika eksekusi satu blok, sedangkan dua yang terakhir melibatkan eksekusi sdk.Msg ( Ekosistem Kosmos Pemrosesan spesifik dari struktur data dasar untuk mengirimkan pesan).

Karena logika implementasi berbagai rantai aplikasi di ekosistem Cosmos dapat didasarkan pada modul dan sampel yang serupa dengan yang ada di Cosmos SDK, saat menganalisis dan memahami kerentanan keamanan di bawah ini, Anda perlu memiliki konsep dasar tentang proses menjalankan modul. SDK Kosmos.

Di ekosistem Cosmos, transaksi awalnya dibuat di agen pengguna, kemudian ditandatangani dan disiarkan ke node dalam blockchain. Node menggunakan metode CheckTx untuk memverifikasi berbagai detail transaksi seperti tanda tangan, saldo pengirim, urutan transaksi, dan bahan bakar yang disediakan. Jika transaksi lolos verifikasi, transaksi tersebut akan ditambahkan ke mempool, menunggu untuk dimasukkan ke dalam blok. Selain itu, jika transaksi gagal verifikasi, pesan kesalahan akan dikirimkan kepada pengguna, menyebabkan transaksi ditolak. Selama eksekusi blok, transaksi diperiksa lebih lanjut, yang dilakukan melalui metode DeliverTx, untuk memastikan konsistensi dan finalitas.

Di Cosmos SDK, siklus hidup suatu transaksi dapat dijelaskan secara singkat sebagai proses berikut:

**1. Pembuatan Transaksi: **Transaksi dibuat di sisi klien menggunakan berbagai alat, CLI atau di front end.

2. Tambahkan ke kumpulan memori: Transaksi ditambahkan ke kumpulan memori tempat node mengirimkan pesan ABCI -CheckTx ke lapisan aplikasi untuk memeriksa validitas dan menerima hasil abci.ResponseCheckTx. Di CheckTx, transaksi didekodekan dari format byte ke format Tx, lalu ValidateBasic() dipanggil di setiap SDK.Msg Tx untuk melakukan pemeriksaan validitas stateless awal. Jika aplikasi memiliki anteHandler yang sesuai, aplikasi akan mengeksekusi logika internalnya terlebih dahulu, kemudian memanggil fungsi runTx, dan terakhir memanggil fungsi RunMsgs() untuk memproses konten spesifik dari sdk.Msg. Jika CheckTx berhasil, pesan akan ditambahkan ke kumpulan memori lokal sebagai kandidat untuk blok berikutnya dan akan disiarkan ke node rekan melalui P2P.

**3 Termasuk dalam blok proposal: **Di awal setiap putaran, pengusul membuat blok yang berisi transaksi terbaru, dan akhirnya node penuh bertanggung jawab atas validator konsensus, setuju untuk menerima blok atau memilih yang kosong potongan zona.

**4. Perubahan status: **DeliverTx dipanggil untuk mengulangi transaksi di blok, serupa dengan CheckTx, namun ia memanggil runTx dalam mode Deliver dan melakukan perubahan status. MsgServiceRouter dipanggil untuk merutekan pesan yang berbeda dalam transaksi ke modul yang berbeda, dan kemudian mengeksekusi setiap pesan terkait di Server Msg. Setelah itu, pemeriksaan dijalankan setelah pesan dijalankan, dan jika ada yang gagal, status akan dipulihkan. Selama eksekusi, gunakan meteran Gas untuk melacak berapa banyak bahan bakar (gas) yang digunakan. Jika terjadi kesalahan bahan bakar (misalnya, bahan bakar rendah), perubahan status akan dikembalikan dengan konsekuensi yang sama seperti setelah kegagalan eksekusi.

5 Kirim blok: Ketika sebuah node menerima cukup suara validator, node tersebut akan mengirimkan blok baru untuk ditambahkan ke blockchain dan menyelesaikan transisi status di lapisan aplikasi.

Diagram siklus hidup transaksi pada ekosistem Cosmos

Berikut ini adalah logika eksekusi spesifik Cosmos SDK, yang dapat dengan mudah dibaca dan dipahami saat menganalisis jalur pemicu kerentanan di bawah ini:

Cosmos SDK berfokus pada logika eksekusi spesifik ABCI

Klasifikasi kerentanan umum

Sebelum memahami klasifikasi kerentanan, kita perlu memiliki klasifikasi dasar tingkat kerentanan. Ini akan membantu mengidentifikasi kerentanan keamanan berbahaya dengan lebih baik dan sebisa mungkin menghindari potensi risiko keamanan.

Mengingat tingkat bahaya dan cakupan dampaknya, kami terutama berfokus pada kerentanan keamanan yang bersifat kritis dan besar, yang biasanya dapat menyebabkan risiko berikut:

1. Rantai berhenti berjalan

2. Hilangnya dana

3. Mempengaruhi status sistem atau pengoperasian normal

Penyebab bahaya ini sering kali disebabkan oleh jenis kerentanan keamanan berikut ini:

1. Penolakan layanan

2. Pengaturan status salah

3. Verifikasi hilang atau tidak masuk akal

4. Masalah keunikan

5. Masalah algoritma konsensus

6. Celah logis dalam implementasi

7. Masalah ciri-ciri bahasa

Analisis Kerentanan

Karena kekhasan modularitas ekologi Cosmos, ada banyak kasus di mana modul saling menggunakan dan memanggil satu sama lain dalam modul dalam berbagai implementasi rantai. Oleh karena itu, ada kasus di mana jalur pemicu kerentanan tidak konsisten dengan jalur yang dapat dikontrol. dari variabel posisi pemicu kerentanan Kami menganalisis kerentanan Saat melihat alasan pemicu spesifik, kita tidak hanya harus fokus pada jalur pemicu, namun juga pada jalur yang dapat dikontrol dari variabel kunci kerentanan. Hal ini dapat membantu kita mendefinisikan dengan lebih baik model kerentanan.

Rantai berhenti berjalan

Dalam kebanyakan kasus, penyebab rantai berhenti berjalan adalah masalah selama eksekusi satu blok. Namun, dalam sejarah perkembangan Cosmos, terdapat juga kerentanan keamanan konsensus yang menyebabkan rantai harus berhenti secara aktif untuk memperbaiki , jadi dampaknya disini Kerentanan keamanan tipe konsensus juga dibahas dalam kaitannya dengan dampak yang menyebabkan rantai berhenti berjalan. Kita akan membahas kedua jenis masalah ini secara terpisah.

Jenis situasi pertama adalah kerentanan jenis penolakan layanan yang umum. Alasan spesifiknya terutama adalah penanganan kerusakan yang tidak tepat dan operasi traversal di mana batas loop dapat dipengaruhi oleh pengguna. Kerentanan seperti itu sering kali menyebabkan rantai terhenti atau memperlambat operasinya.

Seperti disebutkan dalam artikel sebelumnya, Cosmos SDK dan CometBFT adalah infrastruktur utama dalam ekosistem Cosmos. Mereka tidak hanya digunakan oleh rantai dasar di Cosmos, tetapi juga berbagai rantai aplikasi menerapkan logikanya sendiri berdasarkan arsitekturnya, sehingga semuanya mematuhi antarmuka ABCI dari CometBFT. Aturan, Fokus permukaan serangannya juga pada antarmuka ABCI-nya, dan sebagian besar kerentanan keamanan yang dapat menyebabkan Chain Halt adalah masalah yang dapat secara langsung memengaruhi eksekusi kode blok, sehingga jalur kemunculannya pada dasarnya dapat ditelusuri ke antarmuka BeginBlock dan EndBlock.

Jenis situasi kedua adalah kerentanan yang memengaruhi konsensus dan biasanya terkait dengan penerapan berbagai rantai. Saat ini, kerentanan tersebut diketahui umum terjadi pada beberapa masalah verifikasi pemrosesan logika, kalibrasi waktu, dan keacakan. Kerentanan tersebut pada dasarnya akan mempengaruhi prinsip desentralisasi blockchain. Secara intuitif, kerentanan tersebut mungkin tidak berdampak banyak, namun jika dirancang dengan jahat, kerentanan tersebut tetap akan menimbulkan risiko keamanan yang lebih besar.

Kategori 1

• Kasus 1: Proyek SuperNova

Latar belakang kerentanan: Kurangnya verifikasi alamat dalam operasi distribusi koin, mengakibatkan kegagalan operasi dan hilangnya dana. Dalam modul pencetakan, setiap pencetakan token bergantung pada jumlah taruhan. Namun, jika kumpulan tidak ada atau alamat kontrak yang dimasukkan salah, perilaku tak terduga mungkin terjadi pada modul pencetakan, menyebabkan blockchain berhenti berfungsi. Dalam modul kumpulan hadiah, alamat kontrak kumpulan tidak diverifikasi. Jika operasi distribusi gagal, rantai akan berhenti berjalan.

Lokasi kerentanan:

Cuplikan kode yang rentan:

Jalur pemicu kerentanan:

BeginBlocker (/x/mint/keeper/abci.go)

Keeper.DistributeMintedCoin

Keeper.distributeLPIncentivePools

PoolIncentiveKeeper.GetAllIncentivePool (/x/mint/keeper/keeper.go)

Patch kerentanan:

Patch terletak di modul pemrosesan pesan poolincentive (x/poolincentive/types/msgs.go), bukan modul mint.

Verifikasi alamat dilakukan pada pesan saat memproses MsgCreateCandidatePool (yaitu, membuat kumpulan), untuk menghilangkan kemungkinan alamat yang salah dari akar permasalahan.

• Kasus 2: Proyek Keamanan Antarrantai Kosmos

alamat proyek:

Latar belakang kerentanan: Validator dapat memperlambat rantai penyediaan dengan mengirimkan beberapa pesan AssignConsumerKey di blok yang sama. Fungsi AssignConsumerKey yang ditentukan dalam x/ccv/provider/keeper/key_assignment.go memungkinkan validator menetapkan ConsumerKey yang berbeda ke rantai konsumen yang disetujui. Untuk melakukan ini, ConsumerAddrsToPrune AddressList menambahkan elemen. Karena AddressList ini dilintasi di EndBlocker di x/ccv/provider/keeper/relay.go, penyerang dapat menggunakannya untuk memperlambat rantai penyedia. Untuk melakukan serangan ini, pelaku kejahatan dapat membuat transaksi dengan beberapa pesan AssignConsumerKey dan mengirimkan transaksi tersebut ke rantai penyedia. Basis ConsumerAddrsToPrune AddressList akan sama dengan pesan AssignConsumerKey yang dikirim. Akibatnya, eksekusi EndBlocker akan memakan waktu dan sumber daya lebih banyak dari yang diperkirakan, sehingga menyebabkan rantai penyediaan melambat atau bahkan terhenti.

Lokasi kerentanan:/blob/6a856d183cd6fc6f24e856e0080989ab53752102/x/ccv/provider/keeper/key_assignment.go#L378

Cuplikan kode yang rentan:

Jalur pemicu kerentanan:

msgServer.AssignConsumerKey

Keeper.AssignConsumerKey

AppModule.EndBlock

AkhirBlockCIS

MenanganiPaket TerkemukaVSCMatured

MenanganiVSCMaturedPacket

Tugas PruneKey

• Kasus 3: Modul Quicksilver Project-Airdrop

Latar Belakang Kerentanan: BeginBlocker dan EndBlocker adalah metode opsional yang dapat diterapkan oleh pengembang modul dalam modul mereka. Mereka dipicu masing-masing di awal dan akhir setiap blok. Menggunakan crash untuk menangani kesalahan dalam metode BeginBlock dan EndBlock dapat menyebabkan rantai berhenti ketika terjadi kesalahan. EndBlocker melikuidasi airdrop yang belum selesai tanpa mempertimbangkan apakah modul memiliki cukup token untuk memicu crash, menyebabkan rantai berhenti berjalan.

Lokasi kerentanan: ‍60f4047e2f2f403d67701b030e/x/airdrop/keeper/abci.go#L15

Cuplikan kode yang rentan:

Jalur pemicu kerentanan:

AppModule.EndBlock

Penjaga.EndBlocker

Penjaga.EndZoneDrop

Patch kerentanan:

Kode pemrosesan panik langsung dihapus dan diganti dengan pencatatan log kesalahan.

• Kasus 4: Proyek Keamanan Antarrantai Kosmos

alamat proyek:

Latar belakang kerentanan: Seorang penyerang dapat mencapai serangan penolakan layanan dengan mengirimkan beberapa token ke alamat hadiah dari rantai penyedia.

Dalam proses eksekusi EndBlocker pada rantai konsumen, fungsi SendRewardsToProvider yang ditentukan dalam x/ccv/consumer/keeper/distribution.go mendapatkan saldo semua token di tstProviderAddr dan mengirimkannya ke rantai penyedia. Untuk mencapai hal ini, ia harus melakukan iterasi melalui semua token yang ditemukan di alamat hadiah dan mengirimkannya ke rantai penyedia satu per satu melalui IBC. Karena siapa pun dapat mengirim token ke alamat hadiah, penyerang dapat membuat dan mengirim sejumlah besar token dengan denominal berbeda, misalnya menggunakan rantai dengan modul pabrik token, untuk meluncurkan serangan penolakan layanan. Oleh karena itu, eksekusi EndBlocker akan memakan lebih banyak waktu dan sumber daya dari yang diperkirakan, sehingga menyebabkan rantai konsumsi melambat atau bahkan terhenti.

Lokasi kerentanan:/blob/6a856d183cd6fc6f24e856e0080989ab53752102/x/ccv/consumer/keeper/distribution.go#L103

Cuplikan kode yang rentan:

Jalur pemicu kerentanan:

AppModule.EndBlock

Blok Akhir

Blok AkhirRD

KirimRewardsToProvider

Jenis situasi kedua

Masalah konsensus seperti ini mungkin tidak menimbulkan kerugian serius secara intuitif, namun jika kita mempertimbangkan prinsip dan sistem penting dari keseluruhan blockchain, atau melihat kerentanan ini dari skenario tertentu, dampak dan kerugian yang ditimbulkannya belum tentu terlihat jelas. dibandingkan kerentanan konvensional lainnya. Selain itu, jenis kerentanan ini juga memiliki kesamaan.

• Kasus nomor satu

Latar belakang kerentanan: Nangka Penasihat Keamanan Cosmos SDK

Perilaku non-deterministik metode ValidateBasic di modul x/authz Cosmos SDK dapat dengan mudah menyebabkan konsensus terhenti. Struktur pesan MsgGrant pada modul x/authz berisi kolom Hibah yang mencakup waktu kedaluwarsa untuk otorisasi yang ditentukan pengguna yang diberikan. Dalam proses verifikasi ValidateBasic() struktur Grant, bandingkan informasi waktunya dengan informasi waktu lokal dari node, bukan dengan informasi waktu blok. Karena waktu lokal bersifat non-deterministik, stempel waktu setiap node mungkin berbeda, yang mana akan mengarah pada masalah konsensus. .

Pemberitahuan Kerentanan:

Cuplikan kode yang rentan:

Patch kerentanan:

Masalah seperti stempel waktu tidak hanya muncul di komponen dasar seperti Cosmos SDK, namun kerentanan serupa juga muncul di berbagai rantai aplikasi.

• Kasus 2

Latar belakang kerentanan: SuperNova, proyek nova

alamat proyek:

Gunakan time.Now() untuk mengembalikan stempel waktu sistem operasi. Waktu setempat bersifat subyektif dan karenanya non-deterministik. Karena mungkin ada perbedaan kecil dalam stempel waktu masing-masing node, rantai tersebut mungkin tidak mencapai konsensus. Dalam modul ICAControl, fungsi pengiriman transaksi menggunakan time.Now() untuk mendapatkan stempel waktu.

Lokasi kerentanan: _msgs.go#L14

Cuplikan kode yang rentan:

Patch kerentanan:

Berubah dari menggunakan stempel waktu lokal menjadi menggunakan waktu blok.

timeoutTimestamp := waktu.Sekarang().Tambahkan(waktu.Menit * 10).UnixNano() _, err = k.IcaControllerKeeper.SendTx(ctx, chanCap, connectionId, portID, packetData, uint64(timeoutTimestamp))

timeoutTimestamp := uint64(ctx.BlockTime().UnixNano() + 10*time.Minute.Nanoseconds()) _, err = k.IcaControllerKeeper.SendTx(ctx, chanCap, connectionId, portID, packetData, uint64(timeoutTimestamp ))

• Kasus 3

Latar belakang kerentanan: Modul Oracle dari proyek BandChain

alamat proyek:

Komentar dalam basis kode menunjukkan bahwa modul Oracle harus dieksekusi sebelum melakukan staking untuk menerapkan hukuman bagi pelanggar protokol Oracle. Urutan kemunculan kodenya adalah: pada fungsi SetOrderEndBlockers, modul janji berjalan sebelum modul Oracle. Jika modul staking dijalankan sebelum modul Oracle, maka tidak mungkin untuk memberikan penalti kepada validator karena staking, dll. berdasarkan verifikasi yang dilakukan di modul Oracle.

Lokasi kerentanan:

Cuplikan kode yang rentan:

Dapat dilihat bahwa implementasi spesifik dari kerentanan dan anotasi kerentanan sepenuhnya terbalik, dan modul Oracle harus diberi peringkat sebelum modul janji.

• Kasus 4

Latar belakang kerentanan: modul kontrol akses proyek Sei Cosmos

alamat proyek:

Dalam beberapa contoh dari berbagai basis kode Cosmos, iterasi go map menggunakan tipe map dari bahasa go dan melakukan iterasi di atasnya. Karena iterasi peta bahasa Go bersifat non-deterministik, hal ini akan menyebabkan node mencapai status berbeda, yang dapat menyebabkan masalah konsensus dan menyebabkan rantai berhenti berjalan. Pendekatan yang lebih tepat adalah dengan mengurutkan kunci peta menjadi beberapa bagian dan mengulangi kunci yang diurutkan. Jenis masalah ini relatif umum dan disebabkan oleh penerapan fitur bahasa.

Dalam implementasi BuildDependencyDag di x/accesscontrol/keeper/keeper.go, node melakukan iterasi pada anteDepSet. Karena perilaku iterasi peta yang non-deterministik di Go, ValidateAccessOp dapat memiliki dua jenis kesalahan berbeda, yang dapat menyebabkan kegagalan konsensus.

Lokasi kerentanan:/blob/afe957cab74dd05c213d082d50cae02dd4cb6b73/x/accesscontrol/keeper/keeper.go#L314C9-L314C9

Cuplikan kode yang rentan:

Berdasarkan kasus-kasus ini, dapat ditemukan bahwa kerentanan yang menyebabkan rantai berhenti berjalan secara pasif seringkali merupakan yang paling berbahaya, dan hubungan logis antara penyebab kerentanan dapat ditelusuri kembali ke proses eksekusi yang secara langsung mempengaruhi pengoperasian suatu rantai. satu blok di blockchain. Untuk beberapa kerentanan keamanan konsensus, rantai sering kali berhenti berjalan untuk memperbaikinya. Hubungan logis antara penyebab kerentanan dapat ditelusuri kembali ke keseluruhan proses operasi dan status blockchain. Berbeda dengan fokus kerentanan penyebab kerugian modal yang akan kita bahas selanjutnya, kerentanan penyebab kerugian modal biasanya tidak menilai dampak berbahaya secara spesifik berdasarkan jalur logis permasalahannya, namun lebih memperhatikan pemilik dana. , Jumlah dana, ruang lingkup pengaruh dana dan cara pengaruh dana, dll.

Kerugian Dana

Masalah kehilangan dana sering terjadi dalam pemrosesan logis pesan sdk.Msg dan IBC. Tentu saja, ada juga beberapa celah yang dapat menyebabkan rantai berhenti berjalan. Dampak spesifiknya bergantung pada efeknya. Mengenai celah spesifik, kami fokus pada mantan di sini. Selain itu, karena IBC adalah bagian yang sangat penting dari ekosistem Cosmos, hal ini pasti akan melibatkan beberapa kerentanan IBC. Kita akan membahas permukaan serangan spesifik dan kerentanan IBC yang terkait di bab berikutnya.

Kehilangan dana sering terjadi dalam situasi logis seperti konsumsi gas, dana terkunci dan tidak dapat ditarik, dana hilang selama transmisi, kesalahan logika penghitungan yang menyebabkan kehilangan dana, dan ID penyimpanan dana tidak memastikan keunikan.

Di sini kami mengambil proyek SuperNova sebagai contoh untuk menganalisis tiga kerentanan yang terkait dengannya.

• Latar belakang kerentanan: proyek SuperNova

alamat proyek:

Jika angka desimal zona tersebut lebih tinggi dari 18, dana mungkin dikunci. Dalam kode proyek ini, tidak ada batasan atas jumlah tempat desimal suatu wilayah dan dapat melebihi 18 digit. Di ClaimSnMesssage, ClaimShareToken digunakan ketika pengguna ingin mengklaim token berbagi mereka. Namun, jika angka desimal wilayah tersebut lebih tinggi dari 18, maka konversi akan gagal dan aset tidak dapat diambil dari sistem. Oleh karena itu, dengan mengontrol jumlah tempat desimal di area tersebut, kegagalan transaksi dapat dipicu secara langsung.

Lokasi kerentanan:/blob/v0.6.3/x/gal/keeper/claim.go#L167

Cuplikan kode yang rentan:

Jalur pemicu kerentanan:

msgServer.ClaimSnAsset

Penjaga.ClaimShareToken

Keeper.ConvertWAssetToSnAssetDecimal

Pengganda presisi

• Latar belakang kerentanan: proyek SuperNova

alamat proyek:/

Keunikan zona tersebut belum diverifikasi. Pada area terdaftar, gunakan ID area untuk memeriksa keunikan token dasar (BaseDenom). BaseDenom setiap area harus unik. Jika nilai token dasar tidak diatur dengan benar, maka akan mengakibatkan hilangnya dana. Sebelum menetapkan token dasar di RegisterZone, proyek tidak memastikan bahwa BaseDenom unik di semua zona utama. Jika tidak, akan ada kemungkinan pengguna menyimpan dana di zona berbahaya lain yang berisi BaseDenom yang sama, yang mengakibatkan hilangnya dana.

Lokasi kerentanan:/blob/v0.6.3/x/icacontrol/keeper/msg_server.go#L99

Cuplikan kode yang rentan:

Patch kerentanan: Menambahkan pemeriksaan DenomDuplicationCheck

Selain itu, kasus pertama dimana rantai berhenti berjalan adalah karena adanya crash yang mengakibatkan kegagalan pencetakan, yang juga merupakan salah satu bentuk kerugian modal.

• Latar belakang kerentanan: proyek Supernova

alamat proyek:/

Pembaruan status tidak ada. Dalam metode IcaWithdraw(), jika transaksi gagal dan status versi tidak diubah, WithdrawRecord tidak akan dapat diakses dan dana terkait tidak dapat ditarik. Pemahaman yang lebih populer adalah bahwa negara diatur sebelum SendTx, dan negara tidak diubah setelah kegagalan, mengakibatkan penarikan dana gagal dan tidak dapat menarik lagi di waktu berikutnya.

Lokasi kerentanan:/blob/932b23ea391d4c89525c648e4103a3d6ee4531d5/x/gal/keeper/msg_server.go#L356

Cuplikan kode yang rentan:

Berdasarkan bagian kasus ini, dapat ditemukan bahwa logika implementasi operasi terkait dana terutama bergantung pada pemrosesan berbagai pesan.Tentu saja, ada juga kasus seperti jenis kasus pertama – operasi pencetakan yang terlibat dalam proses eksekusi BeginBlock. Kegagalan operasi ini juga dapat mengakibatkan hilangnya dana. Secara keseluruhan, dengan memfokuskan audit kami pada modul kode yang terlibat dalam operasi dana, kami dapat meningkatkan kemungkinan menemukan kerentanan tersebut secara signifikan.

Mempengaruhi status sistem atau pengoperasian normal

Ruang lingkup masalah jenis ini relatif luas. Dua bahaya pertama yang baru saja dibahas sebenarnya dapat dianggap sebagai bagian dari jenis kerentanan yang mempengaruhi status atau operasi normal sistem. Selain itu, yang lebih berbahaya adalah beberapa jenis kerentanan logis. Secara luas, kerentanan tersebut akan menghasilkan risiko keamanan yang berbeda sesuai dengan logika bisnis proyek, namun karena struktur komponen Cosmos SDK Karenanya kesamaan dan modularitas, kesalahan serupa sering dilakukan saat mengimplementasikan kode tertentu.Berikut adalah jenis kerentanan yang umum:

Verifikasi variabel tidak lengkap pada jenis SDK.Msg

Karena berbagai proyek telah mengimplementasikan berbagai tipe turunan berdasarkan sdk.Msg, Cosmos SDK tidak benar-benar mendeteksi elemen dari semua tipe yang ada, sehingga mengakibatkan hilangnya beberapa deteksi variabel kunci yang tertanam, sehingga terdapat risiko keamanan tertentu.

• Kasus 1: Cosmos SDK Security Advisory Barberry

Latar belakang kerentanan: MsgCreatePeriodicVestingAccount.ValidateBasic Mekanisme verifikasi kurang menilai status akun seperti kelangsungan hidup. Dengan PeriodicVestingAccount yang ditentukan dalam x/auth, penyerang dapat menginisialisasi akun korban sebagai akun yang diatribusikan secara jahat dan mengizinkan penyetoran, bukan penarikan. Saat pengguna menyetor dana ke akun mereka, dana tersebut terkunci secara permanen dan tidak dapat ditarik oleh pengguna.

Patch kerentanan:

Cuplikan kode yang rentan:

Selain itu, Cosmos-SDK Security Advisory Elderflower dan Cosmos-SDK Security Advisory Jackfruit sebenarnya adalah masalah yang terjadi pada tautan ValidateBasic. Yang pertama secara langsung kehilangan panggilan ke ValidateBasic, dan yang terakhir adalah tentang variabel stempel waktu di dalam pesan. Masalah verifikasi . Dalam rantai aplikasi, masalah seperti ini bahkan lebih umum terjadi. Proyek seperti ethermint, pstake-native, dan quicksilver semuanya mengalami kerentanan keamanan serupa dalam langkah verifikasi yang digunakan untuk memproses pesan.

Selain jenis verifikasi, dalam logika pemrosesan sdk.Msg, Anda juga akan menemukan operasi loop yang melibatkan konsumsi gas dalam jumlah besar, pemrosesan kerusakan yang tidak masuk akal, dll. Karena rantai pemrosesan pesan memiliki mekanisme pemulihan yang sesuai, derajatnya Risikonya akan lebih rendah dibandingkan jika rantai berhenti berjalan, namun hal ini masih dapat mempengaruhi pengoperasian normal sistem atau menyebabkan hilangnya dana pada rantai.

Jenis kerentanan umum

Selain kerentanan keamanan yang unik pada bisnis proyek, ada juga beberapa model kerentanan yang lebih umum. Misalnya, kasus kehilangan dana yang ketiga adalah operasi yang mengubah keadaan sebelum mengirim pesan. Jenis kerentanan ini sangat mirip dengan kerentanan dalam kontrak pintar. Saat mengirimkan dana, Mengubah keadaan sendiri sebelumnya sering kali menyebabkan masalah seperti status kesalahan masuk kembali atau warisan. Skenario di mana pengaturan status dan transmisi pesan digabungkan secara erat sebenarnya sangat umum di blockchain, dan banyak kerentanan yang menyebabkan bahaya besar Semua berasal dari masalah seperti itu. Selain itu, terdapat juga beberapa kerentanan keamanan komputasi seperti kerentanan pembagian dengan nol, bypass konsumsi gas, penggunaan versi yang rentan, dll. Kerentanan tersebut akan mempengaruhi status sistem atau pengoperasian normal sistem.

Masalah Keunikan

Karena blockchain melibatkan sejumlah besar operasi pencarian dan penyimpanan baca, keunikan penamaan sangat penting dalam implementasi fungsi tertentu. Misalnya kasus capital loss 2 yang disebutkan di atas merupakan masalah keunikan.Selain itu, beberapa variabel tipe string atau byte array yang mewakili faktor kunci dan faktor penting lainnya terkadang memiliki risiko tertentu dalam komposisi awalannya, seperti apakah ada “/” Di akhir setiap penamaan, dll., sedikit kecerobohan dapat menyebabkan nama tersebut dipalsukan menjadi rangkaian dengan arti lain, sehingga menimbulkan serangkaian masalah seperti hilangnya dana, kesalahan konsensus, dll.

Masalah fitur bahasa

Jenis masalah ini lebih umum, tetapi memiliki lebih banyak karakteristik untuk diikuti, sehingga lebih mudah ditemukan, seperti masalah iterasi peta golang, beberapa masalah mekanisme panik yang berkarat, dll. Disarankan agar fitur bahasa ini sendiri dapat menyebabkan masalah sebelumnya menggunakan bahasa yang sesuai. Buat daftar poin-poin yang mengarah pada risiko terkait, dan berikan perhatian individu selama penggunaan atau audit untuk menghindari kesalahan tersebut semaksimal mungkin.

Ringkasan

Berdasarkan eksplorasi kami terhadap isu-isu keamanan yang mendasari ekosistem Cosmos, tidak sulit untuk menemukan bahwa isu-isu tersebut tidak hanya berlaku pada ekosistem Cosmos. Ada banyak model kerentanan yang juga dapat digunakan dalam rantai ekologi lainnya. beberapa penelitian yang relevan mengenai masalah keamanan ekosistem Cosmos.Saran dan Ringkasan:

• **Fokus pada kerentanan infrastruktur: **Komponen inti CometBFT dan Cosmos SDK mungkin juga memiliki kerentanan, sehingga komponen ini perlu diperbarui dan dipelihara secara berkala untuk memastikan keamanan.
• Tinjauan cepat terhadap perpustakaan pihak ketiga: Pengembang Cosmos sering kali menggunakan perpustakaan pihak ketiga untuk memperluas fungsionalitas aplikasi mereka. Namun, perpustakaan ini mungkin mengandung potensi kerentanan, sehingga perpustakaan ini perlu ditinjau dan diperbarui untuk mengurangi risiko.
• Waspadalah terhadap serangan node berbahaya: Di ekosistem Cosmos, node konsensus adalah komponen kunci jaringan. Algoritme Toleransi Kesalahan Bizantium suatu node mungkin rentan terhadap serangan, sehingga node perlu diamankan untuk mencegah perilaku buruk.
• Perhatian terhadap keamanan fisik: Untuk perangkat keras dan server yang menjalankan node Cosmos, tindakan keamanan fisik diperlukan untuk mencegah akses tidak sah dan potensi serangan.
• Peninjauan Kode yang Diperlukan: Karena sifat terbuka dari Cosmos SDK dan ekosistem CometBFT, pengembang dan peninjau harus meninjau kode inti, serta kode yang ditulis dalam modul khusus, untuk mengidentifikasi dan memperbaiki potensi masalah keamanan.
• Hati-hati terhadap alat ekosistem: Ekosistem Cosmos mencakup banyak alat dan aplikasi yang juga memerlukan tinjauan keamanan dan pembaruan rutin untuk memastikan keamanannya.

Panduan Keamanan Protokol IBC

Modul ini akan fokus pada masalah keamanan yang terkait dengan protokol IBC (Protokol Komunikasi Antar-Blockchain). Protokol IBC adalah bagian yang sangat penting dari Cosmos. Perannya adalah untuk membangun jembatan interaktif antara berbagai rantai. Jika jenis jembatan lintas rantai lainnya memberikan solusi untuk beberapa masalah yang relatif independen, maka IBC Protokol dapat dikatakan menyediakan kesatuan solusi dasar dan dukungan teknis yang mendasari untuk masalah interaksi antar rantai. IBC adalah protokol yang memungkinkan blockchain heterogen mengirimkan data apa pun dengan cara yang andal, teratur, dan meminimalkan kepercayaan.

Sejak munculnya Bitcoin, ruang blockchain telah mengalami pertumbuhan yang luar biasa. Jaringan-jaringan baru yang tak terhitung jumlahnya bermunculan, masing-masing memiliki proposisi nilai yang unik, mekanisme konsensus, ideologi, konstituen, dan alasan keberadaannya. Sebelum diperkenalkannya IBC, sebagian besar blockchain ini beroperasi secara independen, seolah-olah berada dalam wadah tertutup dan tidak dapat berkomunikasi satu sama lain. Namun, model tertutup ini pada dasarnya tidak berkelanjutan.

Jika kita menganggap blockchain sebagai negara dengan populasi yang terus bertambah dan penuh dengan aktivitas komersial, beberapa blockchain pandai dalam bidang pertanian, dan ada pula yang unggul dalam peternakan.Mereka tentu ingin melakukan perdagangan dan kerja sama yang saling menguntungkan, dan masing-masing menggunakan kekuatannya sendiri. . Keuntungan. Tidaklah berlebihan untuk mengatakan bahwa IBC membuka dunia baru dengan kemungkinan tak terbatas, memungkinkan berbagai blockchain untuk ** saling beroperasi, memberikan nilai, bertukar aset dan layanan **, dan membangun koneksi tanpa batasan zona berskala besar saat ini. dibatasi oleh masalah skalabilitas yang melekat.

Jadi bagaimana IBC memenuhi kebutuhan ini dan memainkan peran penting? Alasan mendasarnya adalah IBC adalah:

1. Tidak dapat dipercaya

2 Dapat mendukung blockchain yang heterogen

3. Dapat dikustomisasi pada lapisan aplikasi

4 Teknologi yang terbukti dan terbukti

Dasar dari protokol IBC adalah klien ringan dan relayer. Rantai A dan rantai B, yang berkomunikasi melalui IBC, memiliki klien ringan dari buku besar masing-masing. Rantai A tidak perlu mempercayai pihak ketiga dan dapat mencapai konsensus mengenai status rantai B hanya dengan memverifikasi header blok. Rantai yang berinteraksi melalui IBC (khususnya modul) tidak mengirim pesan secara langsung satu sama lain. Sebaliknya, rantai A menyinkronkan beberapa pesan dalam paket ke statusnya. Relai kemudian memeriksa paket-paket ini dan mengirimkannya ke rantai tujuan.

Secara umum protokol IBC dapat dibagi menjadi dua lapisan, yaitu IBC TAO dan IBC APP.

IBC TAO: Standar yang menentukan transmisi, otentikasi, dan pemesanan paket data, lapisan infrastruktur. Di ICS, ini terdiri dari kategori inti, klien, dan relai.

IBC APP: Standar yang mendefinisikan penangan aplikasi untuk paket yang melewati lapisan transport, termasuk namun tidak terbatas pada Fungible Token Transfers (ICS-20), Non-Fungible Token Transfers (ICS-721) dan Chain Interaccount (ICS-27). ) dan dapat ditemukan di ICS dalam kategori Aplikasi.

Bagan IBC (dari Portal Pengembang Cosmos)

Protokol IBC adalah tulang punggung visi Cosmos tentang Internet Blockchain. Dalam hal ini, pilihan desain IBC dipengaruhi oleh spesifikasi TCP/IP. Mirip dengan bagaimana TCP/IP menetapkan standar untuk komunikasi komputer, IBC menetapkan serangkaian abstraksi umum yang dapat diterapkan untuk memungkinkan blockchain berkomunikasi. TCP/IP tidak membatasi isi paket yang disalurkan melalui jaringan, begitu pula IBC. Selain itu, serupa dengan bagaimana protokol aplikasi seperti HTTP dan SMTP dibangun di atas TCP/IP, contoh aplikasi seperti transmisi aset homogen/aset non-homogen atau panggilan kontrak pintar lintas rantai juga menggunakan protokol IBC sebagai lapisan dasar.

Saat ini permasalahan utama yang muncul pada protokol IBC adalah tentang transmisi saluran dan pengolahan paket data.Tentu saja terdapat juga permasalahan besar dalam verifikasi pembuktian dan aspek lainnya, namun permasalahan tersebut relatif sedikit.Artikel ini fokus pada Perjanjian IBC Pertanyaan Umum. Karena desain modular protokol IBC, pengembang aplikasi IBC tidak perlu mengkhawatirkan detail tingkat rendah seperti klien, koneksi, dan verifikasi bukti. Namun, mereka perlu mengimplementasikan antarmuka IBCModule dan metode pemrosesan Keeper yang sesuai. Oleh karena itu, banyak masalah terkait protokol IBC muncul di jalur kode antarmuka IBCModule untuk menerima dan memproses paket data (onRecvPacket, OnAcknowledgementPacket, OnTimeoutPacket, dll.).

Klasifikasi kerentanan umum

Dalam ekosistem Cosmos, protokol IBC berfungsi sebagai hub koneksi. Dalam hal jenis kerentanan, kerentanan yang terkait dengan protokol IBC lebih banyak dan lokasi kerentanan lebih kompleks. Karena penerapan terkait protokol dan modul IBC seperti Cosmos-SDK dan CometBFT, Karena integrasi yang erat, implementasi beberapa modul lain dari ekosistem Cosmos pasti akan disebutkan di bawah. Selain itu, IBC saat ini sebagian besar digunakan di ekosistem Cosmos, sehingga bahasa utamanya masih Golang. Untuk detailnya, silakan lihat dokumen terkait ibc-go.

Karena keterbatasan tempat, kami tidak akan melakukan analisa secara detail terhadap setiap link dan komponen pada protokol IBC disini. Kami hanya akan mengklasifikasikan dan membahas beberapa kerentanan keamanan yang ada. Jika anda ingin mengetahui analisa lebih detail dan komprehensif, silahkan menghubungi CertiK kami insinyur keamanan Pertukaran dan diskusi.

Kategori kerentanan umum:

1. Memberi nama kerentanan

① Kerentanan pemrosesan string

② Kerentanan pemrosesan bytecode

2. Kerentanan dalam proses transmisi

① Kerentanan urutan paket

② Kerentanan batas waktu paket

③ Kerentanan otentikasi paket

④ Kerentanan paket lainnya

3 celah logis

① Kerentanan pembaruan status

② Konsensus pemungutan suara dan celah lainnya

③ Celah logis lainnya

4. Kerentanan konsumsi gas

Protokol IBC yang ada memiliki banyak kesamaan dengan proses audit protokol Web2 dalam proses audit dan analisis keamanannya.Kali ini kita akan menganalisisnya dari sudut pandang proses lengkap perumusan protokol, implementasi dan perluasan aplikasi.Beberapa masalah keamanan dan potensi risiko pada protokol IBC. Karena perumusan protokol sering kali diselesaikan oleh sejumlah kecil orang dan organisasi, untuk berbagai organisasi blockchain, lebih banyak pekerjaan yang dipusatkan pada implementasi dan perluasan penerapan protokol, sehingga artikel ini juga akan fokus membahas keduanya.Pertanyaan Keamanan. Hal ini disebabkan oleh cakupan risiko keamanan protokol IBC yang luas, yang dapat membagi berbagai jenis masalah keamanan pada protokol dengan lebih baik ke dalam tautan dan modul yang sesuai.

Analisis Kerentanan

Perkembangan Perjanjian IBC

• Kasus 1: Protokol ICS-07, kerentanan logika

Latar belakang kerentanan: penggunaan periode tidak mengikat yang salah

Pemeriksaan berikut ada dalam kode:

jika currentTimestamp.Sub(consState.Timestamp) >= clientState.UnbondingPeriod {

Menurut model keamanan Tendermint, validator di blok NextValidators (header) pada waktu t harus dijalankan dengan benar sebelum t+TrustingPeriod, setelah itu mereka mungkin memiliki perilaku lain. Namun yang dicentang disini adalah UnbondingPeriod, bukan TrustingPeriod, dimana UnbondingPeriod>TrustingPeriod. Jika periode consState berada di antara TrustingPeriod dan UnbondingPeriod, maka header tersebut akan diterima sebagai dasar untuk memvalidasi salah satu header yang bertentangan dan merupakan pelanggaran. Selama waktu ini, validator di consState.NextValidators tidak lagi dianggap dapat dipercaya dan mantan validator yang bermusuhan dapat menutup klien tanpa mengambil risiko apa pun.

alamat proyek:

Lokasi kerentanan: #predikat perilaku buruk

_handle.go#L96

Cuplikan kode yang rentan:

Fungsi definisi protokol

Kode

implementasi protokol IBC

Tautan implementasi protokol IBC merupakan tempat yang lebih mungkin terjadi masalah, karena tautan ini berfungsi sebagai penghubung antara masa lalu dan masa depan, hal ini perlu untuk sebisa mungkin menghindari ambiguitas dalam spesifikasi protokol, dan juga perlu memberikan dasar yang lebih mendasar dan nyaman untuk penerapan dan perluasan protokol selanjutnya. Oleh karena itu, berikut ini kami akan membuat klasifikasi kecil mengenai isu-isu utama dalam implementasi protokol IBC, yaitu:

1. Ketidakjelasan dan penyimpangan dalam penerapan protokol

2. Masalah kesalahan pengaturan protokol

Ambiguitas dan ketidakteraturan dalam implementasi protokol

• Kasus 1: Protokol ICS-20, penamaan kerentanan

Latar belakang kerentanan: Konflik alamat hosting. GetEscrowAddress() adalah SHA256 (ID port + ID saluran) dipotong menjadi 20 byte. Ada tiga masalah dengan pendekatan ini:

1. Tidak ada pemisahan domain antara port dan saluran, penggunaan rangkaian string tidak akan memisahkan domain port dan saluran. Misalnya, kombinasi port/saluran (“transfer”, “saluran”) dan (“trans”, “ferchannel”) akan memberikan alamat terkelola yang sama, yaitu SHA256 (“saluran transfer”) yang terpotong. Kerentanan mungkin timbul jika modul tertentu dengan fungsi perpustakaan dapat memilih ID port dan saluran.

2. Konflik antar alamat akun modul. Menggunakan string alfanumerik arbitrer di pra-gambar SHA-256, ukuran pasca-gambar adalah 160 bit. Kombinasi gambar belakang kecil dan fungsi hash cepat membuat serangan ulang tahun mungkin terjadi karena keamanannya hanya dikurangi menjadi 80 bit. Artinya diperlukan sekitar 2^80 tebakan untuk menemukan tabrakan antara dua alamat rekening escrow yang berbeda. Analisis biaya terperinci untuk menyerang pemotongan SHA256 telah dilakukan dalam konteks Tendermint pada tahun 2018, membuktikan bahwa serangan ini layak dilakukan dari sudut pandang biaya, dan menemukan bahwa tabrakan berarti dua akun hosting berbeda dipetakan ke alamat akun yang sama. Hal ini dapat menyebabkan risiko dana dicuri dari rekening escrow, lihat domain pra-gambar ICS20 GetEscrowAddress tumpang tindih dengan kunci publikT:BUG untuk detailnya.

3 Konflik antara alamat akun modul dan non-modul. Alamat akun publik dibuat secara identik dengan 20-byte SHA-256 dari kunci publik Ed25519. Meskipun keamanan 160 bit cukup untuk mencegah serangan tabrakan terhadap alamat publik tertentu, hanya 80 bit keamanan yang tersedia untuk melawan serangan ulang tahun. Situasi ini mirip dengan pola serangan setengah ulang tahun, di mana satu alamat dihasilkan oleh SHA-256 yang cepat dan alamat lainnya dihasilkan oleh penghitungan kunci publik Ed25519 yang relatif lambat. Meskipun skenario ini lebih aman, namun tetap membuka potensi serangan terhadap escrow dan rekening publik.

alamat proyek:

Lokasi kerentanan:

Cuplikan kode yang rentan:

Masalah kesalahan pengaturan protokol

• Kasus 1: IBC Security Advisory Dragonberry, kerentanan proses transmisi

Latar belakang kerentanan: IBC akan menggunakan struktur Paket saat memproses paket data aplikasi.Menurut mekanisme batas waktu, mekanisme konfirmasi sinkron dan asinkron, serta proses verifikasi sertifikasi yang sesuai, paket data akan dibagi menjadi dua proses eksekusi:

1. Situasi normal: Sukses dalam batas waktu

2. Situasi batas waktu: kegagalan batas waktu

Bagan alur transmisi paket aplikasi IBC

Ketika batas waktu terjadi, berarti transmisi gagal, dan protokol IBC akan memulai proses pengembalian dana. Perlu dicatat bahwa IBC memiliki mekanisme batas waktu yang dapat dikonfigurasi pengguna. Kerentanan Dragonberry berasal dari ICS-23 (IBC). Akar penyebab kerentanan ini adalah pengguna dapat memalsukan bukti yang tidak ada dalam proses verifikasi (yaitu, bukti palsu bahwa tidak ada paket data yang diterima), sehingga melewati pemeriksaan keamanan. dan pemalsuan Situasi batas waktu IBC yang “wajar” digunakan untuk menipu protokol IBC, menyebabkan pengulang mengirimkan paket batas waktu dengan sertifikat palsu, dan dapat meningkat menjadi masalah pembelanjaan ganda ICS-20. Proses pemicu spesifik dari kerentanan dapat berupa terlihat pada gambar di bawah ini.

Bagan alur prinsip kerentanan Dragonberry

alamat proyek:

Lokasi kerentanan:

Cuplikan kode yang rentan:

• Kasus 2: IBC Security Advisory Huckleberry, kerentanan proses transmisi

Latar Belakang Kerentanan: UnreceivedPackets hanya membuat respons dengan menemukan tanda terima paket yang sesuai untuk setiap nomor urut yang disertakan dalam kueri. Ini hanya berlaku untuk saluran yang tidak dipesan, karena saluran yang dipesan menggunakan nextSequenceRecv, bukan penerimaan paket. Oleh karena itu, pada saluran yang dipesan, menanyakan nomor seri melalui GetPacketReceipt tidak akan menemukan tanda terima.

Tingkat keparahan masalah ini kecil karena saluran yang ditransmisikan oleh ICS-20 FT sebagian besar rusak dan repeater tidak bergantung pada titik akhir grpc ini untuk menentukan paket batas waktu pemicu. Namun, jika ada sejumlah besar paket dalam rantai target, dan saluran yang dipesan dikonfigurasi untuk transmisi IBC, dan respons grpc tidak di-page, hal ini akan menimbulkan risiko penurunan kinerja atau bahkan crash pada node layanan. Proses pemicuan secara spesifik dapat dilihat pada gambar di bawah ini.

Bagan alur prinsip kerentanan Huckleberry

alamat proyek:

Lokasi kerentanan:keeper/grpc_query.go#L408

Cuplikan kode yang rentan:

Aplikasi dan ekstensi protokol IBC

• Kasus 1: kerentanan serangan udara, kerentanan logika

Latar belakang kerentanan: TryUpdateAirdropClaim Fungsi ini mengubah alamat pengirim paket IBC menjadi alamat Stride bernama senderStrideAddress, dan mengekstrak airdropId dan alamat airdrop baru newStrideAddress dari metadata paket. Kemudian panggil UpdateAirdropAddress untuk memperbarui senderStrideAddress dan ClaimRecord. Dengan pembaruan ClaimRecord, newStrideAddress akan dapat menerima airdrop. Namun, fungsi pembaruan di sini hanya memverifikasi apakah alamat yang diminta oleh pengirim kosong, dan tidak memverifikasi AlamatStride baru. Karena ibc mengizinkan mesin solo untuk terhubung ke rantai yang mengimplementasikan berkemampuan IBC, ada kemungkinan untuk memperbarui akun lain alamat sebagai alamat airdrop Risiko Keamanan.

alamat proyek:

Lokasi kerentanan: _ibc.go#L119

Cuplikan kode yang rentan:

• Kasus 2: kerentanan modul neutron ibc, kerentanan konsumsi gas

Latar belakang kerentanan: Biaya yang dibayarkan oleh kontrak pintar untuk konfirmasi/batas waktu peristiwa IBC tidak cukup diverifikasi, dan kontrak pintar berbahaya dapat mengeksploitasi ini untuk menyebabkan kerusakan ErrorOutOfGas selama pemrosesan pesan OnAcknowledgementPacket dan OnTimeoutPacket. Kerusakan ini tidak akan dipulihkan dengan eksekusi outOfGasRecovery, yang berarti bahwa transaksi tidak akan disertakan dalam blok dan akan menyebabkan relai IBC mengirimkan pesan berulang kali, yang pada akhirnya dapat menyebabkan relai kehilangan dana dan jaringan membuang terlalu banyak paket. menyakiti.

alamat proyek:

Lokasi kerentanan:

x/interchaintxs/keeper/ibc_handlers.go#L62

Cuplikan kode yang rentan:

Ringkasan

Berdasarkan penelitian dan analisis masalah keamanan protokol IBC di atas, tidak sulit untuk menemukan bahwa masalah keamanan protokol IBC tersebar luas dan beragam, namun permasalahan utama masih terjadi pada implementasi dan perluasan aplikasi protokol IBC. Protokol IBC**. Sementara rantai aplikasi besar secara bertahap memperkaya dan meningkatkan fungsionalitas modul tradisional mereka, untuk memenuhi kebutuhan bisnis mereka sendiri dan mengoptimalkan efek pengoperasian, mereka juga menambahkan implementasi kode yang berbeda ke modul IBC yang sesuai.

Selain masalah keamanan pada tautan IBC yang disebutkan di atas, masalah keamanan lainnya seperti middleware IBC juga muncul.Saya yakin di masa depan, masalah keamanan pada modul IBC akan menjadi bagian penting dari keamanan ekologis Cosmos.

Ringkaslah

Dalam proses mengeksplorasi dan meneliti keamanan ekosistem Cosmos, kami telah melalui audit yang kompleks, pekerjaan ringkasan dan klasifikasi, membahas masalah keamanan protokol Cosmos SDK dan IBC, yang paling penting dalam ekosistem Cosmos, dan melalui banyak hal pengalaman praktis, merangkum sejumlah besar pengalaman audit umum.

Laporan ini menyoroti tantangan yang dihadapi ketika menghadapi jaringan heterogen yang mendukung interaksi lintas rantai. Karena kompleksitas dan penyebaran elemen penyusunnya, melakukan audit keamanan pada komponen-komponen ini juga merupakan tantangan yang sama. Kita tidak hanya perlu menggunakan yang sudah ada pengalaman keamanan untuk memecahkan beberapa risiko keamanan yang melekat, Anda juga harus terus-menerus menghadapi skenario keamanan baru dan menganalisis masalah keamanan baru.

Meskipun demikian, kami masih percaya bahwa melalui beberapa skenario umum dan masalah keamanan yang dirangkum dalam laporan ini, keamanan keseluruhan ekosistem jaringan heterogen Cosmos dapat ditingkatkan secara bertahap.