Ekosistem Cosmos, yang terkenal secara global sebagai salah satu jaringan blockchain terbesar dan paling terkemuka, memprioritaskan interoperabilitas blockchain. Fokus ini adalah kunci untuk memfasilitasi komunikasi yang lancar di antara blockchain yang beragam. Ekosistem ini menjadi rumah bagi beberapa proyek unggulan seperti Celestia dan dYdX v4, semuanya dikembangkan menggunakan Cosmos SDK dan protokol IBC. Peningkatan preferensi pengembang untuk komponen Cosmos telah menyebabkan dampak yang diperbesar dari masalah keamanan dalam ekosistem tersebut. Sebagai contoh adalah kerentanan Dragonfruit dalam Cosmos SDK, yang mengganggu operasi di banyak blockchain publik mainstream.

Dengan sifat terdesentralisasi dari komponen inti Cosmos, para pengembang seringkali harus menyesuaikan dan memperluas komponen-komponen ini berdasarkan kebutuhan fungsional spesifik. Hal ini mengakibatkan fragmentasi tantangan keamanan dalam ekosistem Cosmos. Akibatnya, ada kebutuhan mendesak untuk pendekatan terstruktur dalam memahami dan mengatasi masalah keamanan ini. Artikel ini bertujuan untuk menyediakan analisis komprehensif dari lanskap keamanan saat ini dalam ekosistem Cosmos dan untuk menguraikan strategi respons yang efektif.

Tim CertiK bertekad untuk memperkuat keamanan jaringan Cosmos dan ekosistem Web3 yang lebih luas melalui penelitian dan pengembangan yang berkelanjutan. Kami senang untuk berbagi temuan dan wawasan kami dengan Anda melalui laporan keamanan reguler dan pembaruan penelitian teknis. Jika Anda memiliki pertanyaan, tim kami selalu tersedia untuk dihubungi.

Berikut adalah teks lengkap dari "Panduan Keamanan Ekosistem Kosmos" 👇 .

Gambaran Cosmos

Dikagumi sebagai salah satu ekosistem blockchain paling terkemuka di dunia, Cosmos menonjol dengan kemampuan jaringan open-source, scalable, dan lintas-rantai. Dikembangkan oleh tim CometBFT, yang awalnya dikenal sebagai Tendermint, Cosmos bertujuan untuk menghilangkan silo informasi dan memfasilitasi interoperabilitas di antara blockchain yang beragam. Di era di mana berbagai jaringan blockchain berdampingan, kebutuhan akan interaksi lintas-rantai lebih mendesak dari sebelumnya.

Cosmos membedakan diri dengan menawarkan model cross-chain yang efisien, terutama bermanfaat untuk rantai publik dengan fokus vertikal spesifik. Infrastruktur blockchain modularnya memberdayakan pengembang aplikasi, memberi mereka fleksibilitas untuk memilih dan memanfaatkan rantai publik yang sesuai dengan persyaratan khusus mereka.

Di jantung ekosistem Cosmos adalah Protokol Komunikasi Antar-Blockchain (IBC), yang menghubungkan aplikasi dan protokol di berbagai blockchain independen. Hal ini tidak hanya memfasilitasi transfer aset dan data tanpa hambatan, tetapi juga sejalan dengan visi Cosmos untuk menciptakan 'internet blockchain.' Konsep ini memvisualisasikan jaringan blockchain otonom dan mudah dikembangkan yang saling terhubung untuk ekspansi dan interaksi.

Keterlibatan dan Penelitian CertiK dalam Keamanan Cosmos

Untuk jangka waktu yang lebih lama, CertiK telah sangat terlibat dalam penelitian ekosistem Cosmos. Tim kami telah mendapatkan pengalaman yang substansial dalam mengatasi tantangan keamanan dalam lingkungan ini. Dalam laporan ini, kami akan berbagi wawasan dan penemuan kami tentang keamanan ekosistem Cosmos, berfokus pada empat area kunci: keamanan Cosmos SDK, keamanan protokol IBC, keamanan CometBFT, dan keamanan CosmWasm. Diskusi kami akan mencakup segala hal mulai dari komponen fundamental ekosistem Cosmos hingga rantai-rantai dasar dan aplikasinya. Dengan memeriksa dan mengekstrapolasi isu-isu terkait, kami bertujuan untuk menyajikan analisis menyeluruh, dari bawah ke atas, mengenai aspek keamanan kritis dalam ekosistem Cosmos.

Dengan kompleksitas dan keragaman ekosistem Cosmos, itu menghadapi berbagai tantangan keamanan. Laporan ini terutama berkonsentrasi pada ancaman paling karakteristik dan signifikan terhadap rantai ekologis Cosmos. Untuk informasi lebih lanjut atau diskusi tentang aspek keamanan lainnya, kami mendorong Anda untuk menghubungi insinyur keamanan CertiK.

Latar Belakang

CometBFT: Meningkatkan Skalabilitas Cross-Chain pada Inti-Nya

Di jantung skalabilitas Interchain terletak CometBFT, algoritma konsensus canggih yang sangat penting untuk menjamin keamanan, desentralisasi, dan integritas ekosistem Interchain. Algoritma ini adalah gabungan dari dua komponen utama: inti CometBFT, berfungsi sebagai mesin konsensus fundamental, dan antarmuka blockchain aplikasi universal (ABCI). Dengan menggabungkan elemen-elemen PBFT (Practical Byzantine Fault Tolerance) dan Bonded Proof of Stake (PoS), CometBFT menyinkronkan node untuk menjaga catatan transaksi yang akurat, sehingga memainkan peran penting dalam konsensus validator dalam lingkungan Interchain.

Cosmos SDK: Mempercepat Pengembangan Blockchain dengan Modularitas

Cosmos SDK berdiri sebagai toolkit yang powerful yang menyederhanakan dan mempercepat pengembangan blockchain. Desain modular dan fitur yang dapat dipasang memungkinkan pengembang untuk membangun blockchain mereka sendiri atau komponen fungsional di atas algoritma konsensus CometBFT. Pendekatan ini tidak hanya memudahkan pengembangan tetapi juga secara signifikan mempersingkat siklus pengembangan. Efektivitas SDK ini terbukti dengan adopsinya dalam banyak proyek, termasuk Cronos, Kava, dan dYdX V4 yang baru diluncurkan. Ke depan, Cosmos SDK berencana untuk meningkatkan modularitasnya dan memperkenalkan fitur-fitur baru, memungkinkan penciptaan aplikasi yang lebih canggih dan modular, sehingga membantu mengembangkan ekosistem yang lebih luas dan kuat.

Protokol IBC: Mendorong Interoperabilitas dan Skalabilitas di Seluruh Blockchain

Protokol Komunikasi Antar-Blockchain (IBC) sangat penting dalam memfasilitasi transfer data yang aman, terdesentralisasi, dan tanpa izin antar blockchain dalam jaringan Cosmos. Mengingat bahwa Cosmos adalah jaringan terdesentralisasi yang terdiri dari beberapa blockchain independen dan paralel yang terhubung melalui teknologi relay, peran protokol IBC dalam meningkatkan skalabilitas dan interoperabilitas sangat sentral. Fokus saat ini dari Interchain Foundation adalah meningkatkan aspek-aspek protokol IBC ini, dengan tujuan untuk memperkuat interaksi yang mulus di antara blockchain, aplikasi, dan kontrak pintar dalam ekosistem Cosmos.

CosmWasm: Memfasilitasi Penyebaran Aplikasi Terdesentralisasi

CosmWasm (Cosmos WebAssembly) adalah kerangka kontrak pintar yang disesuaikan untuk ekosistem Cosmos. Berdasarkan pada WebAssembly, ini memungkinkan pengembang untuk mendeploy aplikasi terdesentralisasi tanpa memerlukan izin khusus. Kerangka kerja ini memungkinkan pengembang blockchain untuk memisahkan pengembangan produk dari pengembangan blockchain, mengurangi beban pada upgrade validator. Fitur-fitur CosmWasm termasuk arsitektur modular, integrasi dengan Cosmos SDK, dan kemampuan komunikasi lintas-rantai. Cosmos SDK dan protokol IBC, yang relatif matang, banyak digunakan dalam ekosistem Cosmos saat ini.

Menyesuaikan dan Menyesuaikan dalam Ekosistem Cosmos

Bagi pengembang rantai dalam ekosistem Cosmos, Cosmos SDK memenuhi kebutuhan kustomisasi paling. Selama kegiatan lintas-rantai, pengembang rantai mungkin menyesuaikan modul IBC mereka untuk operasi khusus atau optimisasi kinerja. Sementara beberapa rantai memodifikasi mesin dasar seperti CometBFT Core, batasan ruang mencegah diskusi rinci tentang modifikasi tersebut dalam laporan ini. Oleh karena itu, penelitian ini terutama berfokus pada nuansa teknis dan pertimbangan keamanan dari Cosmos SDK dan protokol IBC.

Panduan Keamanan Cosmos SDK

Panduan Keamanan Cosmos SDK menyediakan gambaran komprehensif tentang aspek keamanan Cosmos SDK, sebuah kerangka kerja canggih untuk mengembangkan aplikasi blockchain dan protokol terdesentralisasi. Diciptakan oleh Interchain Foundation, kerangka kerja ini sangat penting bagi jaringan Cosmos, yang merupakan jaringan yang tersebar dari blockchain yang saling terhubung.

Pada intinya, Cosmos SDK dirancang untuk menyederhanakan pembuatan aplikasi blockchain yang disesuaikan sementara memfasilitasi interaksi yang lancar di antara blockchain yang beragam. Fitur-fitur unggulannya meliputi struktur modular, kemampuan kustomisasi yang luas, integrasi dengan CometBFT Core untuk konsensus, dan implementasi antarmuka IBC, semuanya berkontribusi pada daya tariknya bagi para pengembang. Kelebihan kunci Cosmos SDK adalah ketergantungannya pada mesin konsensus CometBFT Core, yang menyediakan langkah-langkah keamanan yang kuat. Mesin ini memainkan peran penting dalam membela jaringan dari serangan berbahaya dan melindungi aset dan data pengguna. Sifat modular SDK memberdayakan pengguna untuk membuat modul-modul khusus dengan mudah. Namun, para pengembang harus waspada karena kerentanan keamanan masih bisa muncul saat melakukan implementasi aplikasi menggunakan Cosmos SDK.

Dari sudut pandang pemeriksaan keamanan, sangat penting untuk menilai ancaman keamanan potensial dari berbagai perspektif. Sebaliknya, dalam penelitian keamanan, penekanan beralih ke penentuan kerentanan yang bisa memiliki dampak signifikan. Pendekatan ini bertujuan untuk mengurangi ancaman keamanan utama dengan cepat, sehingga menawarkan bantuan yang lebih efektif kepada layanan yang mengintegrasikan SDK. Sangat penting untuk mengidentifikasi dan menyelidiki kerentanan yang menimbulkan risiko serius dan memiliki implikasi luas.

Titik fokus dalam Cosmos SDK adalah antarmuka ABCI, yang merupakan bagian integral dari ekosistem Cosmos. Antarmuka ini terdiri dari empat komponen kunci: BeginBlock, EndBlock, CheckTx, dan DeliverTx. BeginBlock dan EndBlock secara langsung terlibat dalam logika eksekusi blok individual. Sebaliknya, CheckTx dan DeliverTx berurusan dengan pemrosesan sdk.Msg, struktur data dasar untuk transmisi pesan dalam ekosistem Cosmos.

Untuk memahami dan mengatasi kerentanan keamanan yang disebutkan, seseorang harus terlebih dahulu memahami siklus hidup transaksi dalam ekosistem Cosmos. Transaksi berasal dari agen pengguna, di mana mereka dibuat, ditandatangani, dan kemudian disiarkan ke simpul blockchain. Metode CheckTx digunakan oleh simpul untuk memvalidasi rincian transaksi seperti tanda tangan, saldo pengirim, urutan transaksi, dan gas yang disediakan. Transaksi valid diantre di mempool, menunggu disertakan dalam blok, sementara yang invalid ditolak, dengan pesan kesalahan dikirimkan kepada pengguna. Selama pemrosesan blok, metode DeliverTx diterapkan untuk memastikan konsistensi transaksional dan determinisme.

Dalam SDK Cosmos, siklus hidup transaksi adalah proses multi-tahap, meliputi penciptaan, validasi, inklusi dalam blok, perubahan status, dan komitmen akhir. Proses ini dapat diuraikan dalam langkah-langkah berikut:

1. Pembuatan Transaksi: Pengguna menghasilkan transaksi menggunakan berbagai alat seperti Antarmuka Baris Perintah (CLI) atau klien frontend.

2. Penambahan ke Mempool: Begitu dibuat, transaksi masuk ke mempool. Di sini, node mengirim pesan ABCI (Application BlockChain Interface), yang dikenal sebagai CheckTx, ke lapisan aplikasi untuk pemeriksaan validitas. Transaksi mengalami dekoding dari format byte ke format Tx. Setiap sdk.Msg dalam transaksi tersebut tunduk pada pemeriksaan primitif tanpa status oleh fungsi ValidateBasic(). Selain itu, jika aplikasi termasuk anteHandler, logikanya dieksekusi sebelum fungsi runTx, yang mengarah ke fungsi RunMsgs() untuk memproses konten sdk.Msg. Hasil CheckTx yang berhasil mengakibatkan transaksi diantre di mempool lokal, siap untuk disertakan dalam blok berikutnya, dan sekaligus disiarkan ke node rekan melalui P2P.

3. Inklusi dalam Blok yang Diusulkan: Selama awal setiap putaran, proposer mengumpulkan blok yang berisi transaksi terkini. Validator, yang bertanggung jawab untuk menjaga konsensus, entah menyetujui blok ini atau memilih blok kosong.

4. Perubahan Status: Mirip dengan CheckTx, proses DeliverTx melalui transaksi blok. Namun, beroperasi dalam mode 'Deliver', melakukan perubahan status. MsgServiceRouter mengarahkan pesan transaksi yang berbeda ke modul-modul yang sesuai, di mana setiap pesan diproses di Server Pesan. Setelah eksekusi pesan, pemeriksaan lebih lanjut memastikan kevalidan transaksi. Jika ada pemeriksaan yang gagal, status dikembalikan ke kondisi sebelumnya. Meter Gas melacak gas yang dikonsumsi selama eksekusi. Kesalahan terkait gas, seperti gas yang tidak mencukupi, menyebabkan pengembalian perubahan status, mirip dengan kegagalan eksekusi.

5. Komitmennya Blok: Setelah menerima suara validator yang cukup, sebuah node mengirimkan blok baru ke blockchain. Tindakan ini mengonfirmasi transisi status di lapisan aplikasi, menandai penyelesaian proses transaksi.

)

Bagian ini mencakup diagram yang menggambarkan siklus hidup transaksi dalam ekosistem Cosmos.

Bagian berikut menyediakan logika eksekusi spesifik dari kunci ABCI dalam Cosmos SDK, berguna untuk memahami dan menganalisis kerentanan yang dibahas nanti.

)

Kategori Kerentanan Umum

Sebelum memahami klasifikasi kerentanan, kita perlu memiliki pembagian dasar tingkat bahaya kerentanan. Hal ini membantu dalam mengidentifikasi kerentanan keamanan berisiko tinggi dan menghindari potensi risiko keamanan.

)

Mempertimbangkan tingkat bahaya dan cakupan dampaknya, kami terutama berfokus pada kerentanan keamanan dengan peringkat Kritis dan Mayor, yang biasanya dapat menyebabkan risiko-risiko berikut:

1. Operasi penghentian rantai
2. Kerugian keuangan
3. Mempengaruhi keadaan sistem atau operasi normal

Penyebab bahaya ini sering kali adalah jenis kerentanan keamanan berikut:

1. Penolakan Layanan
2. Pengaturan negara yang tidak benar
3. Kekurangan atau verifikasi yang tidak wajar
4. masalah keunikan
5. masalah algoritma konsensus
6. Kesalahan logis dalam implementasi
7. Masalah fitur bahasa

Analisis Kerentanan dalam Ekosistem Cosmos

Ekosistem Cosmos, dikenal karena strukturnya yang modular, sering mengalami penggunaan modul dan pemanggilan antarmodul dalam rantainya. Kompleksitas ini mengarah pada skenario di mana jalur pemicu kerentanan dan variabel lokasi tidak konsisten. Dalam memahami kerentanan ini, penting tidak hanya mempertimbangkan jalur pemicunya tetapi juga jalur yang dapat dikendalikan dari variabel kritis kerentanan tersebut. Fokus ganda ini membantu dalam mendefinisikan dan mengategorikan model kerentanan dengan lebih baik.

Operasi Penghentian Rantai: Penyebab dan Jenis

Berhenti rantai biasanya disebabkan oleh masalah yang dihadapi selama eksekusi satu blok. Namun, sejarah Cosmos mencakup contoh di mana kerentanan keamanan konsensus memerlukan penghentian rantai aktif untuk perbaikan. Masalah ini terbagi menjadi dua kategori yang berbeda.

Tipe pertama umumnya terlihat dalam Kerentanan Layanan Penolakan: Ini seringkali merupakan hasil dari penanganan crash yang tidak memadai dan operasi batas loop yang dipengaruhi pengguna. Kerentanan seperti itu dapat menyebabkan rantai berhenti atau melambat secara signifikan.

Cosmos SDK dan CometBFT, infrastruktur kunci dalam ekosistem Cosmos, tidak hanya digunakan oleh rantai dasar di Cosmos tetapi juga oleh berbagai rantai aplikasi berdasarkan arsitektur mereka. Mereka semua mengikuti aturan antarmuka ABCI dari CometBFT. Fokus permukaan serangan mereka juga pada antarmuka ABCI mereka, dan sebagian besar kerentanan keamanan yang dapat menyebabkan Chain berhenti adalah masalah yang dapat secara langsung memengaruhi eksekusi kode blok. Oleh karena itu, jalur kejadian mereka umumnya dapat dilacak kembali ke antarmuka BeginBlock dan EndBlock.

Jenis situasi kedua melibatkan Kerentanan yang Mempengaruhi Konsensus: Ini sering terkait dengan implementasi di berbagai rantai dan mencakup masalah dalam validasi pemrosesan logika, kalibrasi waktu, dan keacakan. Kerentanan ini melukai prinsip desentralisasi blockchain secara mendasar. Meskipun mereka mungkin tidak terlihat parah pada awalnya, dalam tangan pelaku jahat, mereka menimbulkan ancaman keamanan yang substansial.

Contoh-contoh Jenis Pertama

Contoh 1: Analisis Kerentanan Proyek SuperNova

Latar belakang kerentanan: Dalam proses pencetakan distribusi dalam Proyek SuperNova, masalah kritis muncul dari tidak adanya verifikasi alamat. Pengawasan ini dapat menyebabkan kegagalan operasi dan, akibatnya, kerugian finansial. Secara khusus, modul pencetakan, yang sangat penting untuk pembuatan token, bergantung pada jumlah yang dipertaruhkan. Namun, proses ini rentan terhadap kesalahan. Misalnya, jika kumpulan yang ditunjuk tidak ada atau jika ada entri alamat kontrak yang salah, itu dapat menyebabkan kegagalan fungsi dalam modul pencetakan. Kesalahan semacam itu berpotensi menghentikan seluruh operasi blockchain. Selain itu, dalam modul kumpulan hadiah, ada kurangnya verifikasi untuk alamat kontrak kumpulan. Pengawasan ini berarti bahwa setiap kegagalan dalam operasi distribusi dapat menyebabkan penghentian langsung blockchain.

Lokasi kerentanan: SuperNova GitHub Link

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:

https://github.com/Carina-labs/nova/commit/538abc771dea68e33fd656031cbcf2b8fe006be0

Patching terletak di modul penanganan pesan poolincentive (x/poolincentive/types/msgs.go), bukan modul mint. Ini menambahkan verifikasi alamat ke pesan MsgCreateCandidatePool untuk menghilangkan kemungkinan alamat yang salah dari root.

Contoh 2: Proyek Keamanan Antar Rantai Cosmos

Alamat proyek: Link Keamanan Antar Rantai Cosmos GitHub

Latar belakang kerentanan: Validator dapat melambatkan rantai penyedia dengan mengirimkan beberapa pesan AssignConsumerKey dalam blok yang sama. Di file x/ccv/provider/keeper/key_assignment.go, fungsi AssignConsumerKey memungkinkan validator untuk memberikan consumerKeys yang berbeda ke rantai konsumen yang disetujui. AddressList consumerAddrsToPrune bertambah satu elemen untuk melakukan operasi ini. Karena AddressList ini diiterasi di EndBlocker di x/ccv/provider/keeper/relay.go, penyerang dapat mengeksploitasinya untuk melambatkan rantai penyedia. Untuk serangan ini, pelaku jahat dapat membuat transaksi dengan beberapa pesan AssignConsumerKey dan mengirimkannya ke rantai penyedia. Kardinalitas AddressList consumerAddrsToPrune akan sama dengan pesan AssignConsumerKey yang dikirim. Oleh karena itu, eksekusi EndBlocker akan memakan waktu dan sumber daya lebih banyak dari yang diharapkan, memperlambat atau bahkan menghentikan rantai penyedia.

Lokasi kerentanan: Tautan GitHub Keamanan Antar Rantai Cosmos

Segment Kode Kerentanan:

Jalur pemicu kerentanan:

msgServer.AssignConsumerKey

Keeper.TetapkanKunciKonsumen

AppModule.EndBlock

EndBlockCIS

Mengatasi Paket yang Telah Matang VSC

HandleVSCMaturedPacket

PruneKeyAssignments

Contoh 3: Proyek Quicksilver - Modul Airdrop

Latar belakang kerentanan: BeginBlocker dan EndBlocker adalah metode opsional yang dapat diimplementasikan oleh pengembang modul dalam modul mereka. Mereka dipicu pada awal dan akhir setiap blok, masing-masing. Menggunakan crash untuk menangani kesalahan dalam metode BeginBlock dan EndBlock dapat menyebabkan rantai berhenti dalam kasus kesalahan. EndBlocker tidak mempertimbangkan apakah modul memiliki cukup token untuk menyelesaikan airdrop yang belum selesai, yang dapat memicu crash dan menghentikan rantai.

Lokasi kerentanan: Quicksilver GitHub Link

Segment Kode Kerentanan:

Patch kerentanan: AppModule.EndBlock

Keeper.EndBlocker

Keeper.EndZoneDrop

Patch kerentanan: https://github.com/quicksilver-zone/quicksilver/blob/20dc658480b1af1cb323b4ab4a8e5925ee79a0ed/x/airdrop/keeper/abci.go#L16

Kode penanganan panik telah dihapus dan diganti dengan logging error.

Contoh 4: Proyek Keamanan Interchain Cosmos

Alamat proyek: Tautan GitHub Keamanan Antar Rantai Cosmos

Latar belakang kerentanan: Penyerang dapat melakukan serangan Denial of Service dengan mengirimkan beberapa token ke alamat imbalan rantai penyedia. Dalam alur eksekusi EndBlocker rantai konsumen, fungsi SendRewardsToProvider yang didefinisikan di x/ccv/consumer/keeper/distribution.go mengambil saldo semua token di tstProviderAddr dan mengirimkannya ke rantai penyedia. Untuk mencapai ini, harus mengulang semua token yang ditemukan di alamat imbalan dan mengirim masing-masing melalui IBC ke rantai penyedia. Karena siapa pun dapat mengirimkan token ke alamat imbalan, penyerang dapat membuat dan mengirimkan sejumlah besar token denom yang berbeda, misalnya, menggunakan rantai dengan modul pabrik token, untuk memulai serangan Denial of Service. Oleh karena itu, eksekusi EndBlocker akan memakan lebih banyak waktu dan sumber daya dari yang diharapkan, memperlambat atau bahkan menghentikan rantai konsumen.

Lokasi kerentanan: Tautan GitHub Keamanan Antar Rantai Cosmos

Segment Kode Kerentanan:

Jalur pemicu kerentanan:

AppModule.EndBlock

EndBlock

EndBlockRD

KirimHadiahKePenyedia

Jenis Kedua Situasi

Masalah konsensus semacam ini mungkin tidak membawa kerusakan parah secara langsung, tetapi ketika mempertimbangkan prinsip-prinsip dasar dan sistem blockchain secara keseluruhan, atau melihat kerentanannya dari skenario-skenario tertentu, dampak dan kerusakannya mungkin tidak kalah dengan kerentanan konvensional lainnya. Selain itu, kerentanan-kerentanan ini memiliki karakteristik umum.

Contoh 1

Latar belakang kerentanan: Cosmos SDK Security Advisory Jackfruit

Perilaku non-deterministik dalam metode ValidateBasic dari modul x/authz di Cosmos SDK dapat dengan mudah menyebabkan berhentinya konsensus. Struktur pesan MsgGrant dalam modul x/authz termasuk bidang Grant, yang berisi waktu kedaluwarsa yang diberikan oleh otorisasi yang ditentukan pengguna. Dalam proses validasi ValidateBasic() dalam struktur Grant, ia membandingkan informasi waktunya dengan informasi waktu lokal node bukan informasi waktu blok. Karena waktu lokal bersifat non-deterministik, timestamp dapat berbeda antara node, menyebabkan masalah konsensus.

Pengumuman kerentanan:

• Tautan Forum Cosmos 1

• Tautan Forum Cosmos 2

• Tautan Informasi Keamanan GitHub Cosmos SDK

Segment Kode Kerentanan:

Pembaruan kerentanan: Tautan Perbandingan Cosmos SDK GitHub

Masalah seperti penanda waktu tidak hanya muncul dalam komponen fundamental seperti Cosmos SDK tetapi juga telah terjadi di berbagai rantai aplikasi.

Contoh 2

Latar Belakang Kerentanan: SuperNova, proyek nova

Alamat proyek: SuperNova GitHub Link

Menggunakan time.Now() mengembalikan cap waktu sistem operasi. Waktu lokal bersifat subyektif dan oleh karena itu tidakdeterministik. Karena mungkin ada perbedaan kecil dalam cap waktu dari node individu, rantai mungkin tidak mencapai konsensus. Pada modul ICAControl, fungsi pengiriman transaksi menggunakan time.Now() untuk mendapatkan cap waktu.

Lokasi kerentanan: https://github.com/Carina-labs/nova/blob/932b23ea391d4c89525c648e4103a3d6ee4531d5/x/icacontrol/keeper/send_msgs.go#L14

Segment Kode Kerentanan:

Pembaruan kerentanan:

Berubah dari menggunakan timestamp lokal menjadi menggunakan waktu blok.

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

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

Kasus Ketiga:

Latar Belakang Kerentanan: Modul Oracle dalam Proyek BandChain

URL Proyek: Repositori GitHub BandChain

Komentar-komentar di repositori kode menunjukkan bahwa modul oracle harus dijalankan sebelum melakukan staking untuk menerapkan langkah-langkah hukuman bagi pelanggar protokol oracle. Namun, dalam kode, urutannya terbalik: dalam fungsi SetOrderEndBlockers, modul staking dijalankan sebelum modul oracle. Jika modul staking dijalankan sebelum modul oracle, akan tidak mungkin untuk memberlakukan hukuman berdasarkan verifikasi yang diselesaikan di modul oracle.

Lokasi Kerentanan: Potongan Kode GitHub BandChain

Segment Kode Kerentanan:

Kerentanan terletak pada implementasi sebenarnya dan komentar yang bertentangan, di mana modul oracle harus ditempatkan sebelum modul staking.

Kasus Empat:

Latar belakang kerentanan: modul Accesscontrol di proyek Sei Cosmos

URL Proyek: Repositori GitHub Sei Cosmos

Dalam beberapa contoh di seluruh repositori kode terkait Cosmos, ada penggunaan jenis peta bahasa Go dan iterasi di atasnya. Karena sifat non-deterministik dari iterasi peta Go, ini dapat menyebabkan node mencapai status yang berbeda, berpotensi menyebabkan masalah konsensus dan akibatnya menghentikan rantai dari operasi. Metode yang lebih tepat adalah mengurutkan kunci peta menjadi irisan dan mengulangi kunci yang diurutkan. Masalah seperti itu biasa terjadi, yang berasal dari penerapan fitur bahasa.

Dalam implementasi BuildDependencyDag di x/accesscontrol/keeper/keeper.go, terdapat iterasi node anteDepSet. Karena perilaku non-deterministik dari iterasi peta di Go, ValidateAccessOp bisa menghasilkan dua jenis kesalahan yang berbeda, yang berpotensi menyebabkan kegagalan konsensus.

Lokasi Kerentanan: Potongan Kode GitHub Sei Cosmos

Segment Kode Kerentanan:

Dari kasus-kasus ini, jelas bahwa kerentanan yang menyebabkan rantai berhenti berjalan secara pasif seringkali yang paling berbahaya. Logika penyebab mereka dapat ditelusuri kembali ke pengaruh langsung terhadap alur eksekusi blok-blok individu dalam blockchain. Sebaliknya, kerentanan keamanan konsensus biasanya mengakibatkan rantai secara aktif berhenti untuk menerapkan perbaikan, dengan logika penyebab mereka ditelusuri kembali ke pengaruh terhadap alur operasional secara keseluruhan dan keadaan blockchain. Hal ini berbeda dari fokus kerentanan yang menyebabkan kerugian keuangan, di mana dampak berbahaya spesifik tidak dinilai berdasarkan jalur logika terjadinya masalah tetapi lebih berfokus pada pemilik dana, jumlah uang yang terlibat, ruang lingkup, dan metode yang memengaruhi dana.

kehilangan dana

Masalah kehilangan modal sering terjadi dalam penanganan logis sdk.Msg dan pesan IBC. Tentu saja, ada juga beberapa kerentanan yang dapat menyebabkan kehilangan modal di antara alasan yang dapat menghentikan operasi blockchain. Dampak spesifik bergantung pada kerentanan tertentu, dan di sini kita fokus pada yang pertama. Selain itu, karena IBC adalah komponen yang sangat penting dari ekosistem Cosmos, ini tidak terhindarkan melibatkan beberapa kerentanan dalam IBC. Rincian tentang permukaan serangan IBC dan kerentanan yang sesuai akan dibahas dalam bab berikutnya.

Kerugian modal umumnya terjadi dalam skenario seperti konsumsi gas, dana yang terkunci dan tidak dapat ditarik, kehilangan dana saat transfer, kesalahan dalam logika komputasi yang menyebabkan kerugian dana, dan kegagalan memastikan keunikan ID penyimpanan dana.

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

Latar Belakang Kerentanan: Proyek SuperNova

URL Proyek: https://github.com/Carina-labs/nova

Jika tempat desimal dalam suatu zona melebihi 18, dana dapat terkunci. Dalam kode proyek ini, tidak ada batas atas pada tempat desimal dari suatu zona, yang dapat melebihi 18. Pada ClaimSnMessage, ketika pengguna ingin mengklaim token bagian mereka, ClaimShareToken digunakan. Namun, jika tempat desimal dari zona melebihi 18, konversi akan gagal, dan akan tidak mungkin untuk mengekstrak aset dari sistem. Dengan demikian, dengan mengendalikan tempat desimal dari suatu zona, adalah mungkin untuk secara langsung memicu kegagalan dan kegagalan transaksi.

Lokasi Kerentanan: https://github.com/Carina-labs/nova/blob/v0.6.3/x/gal/keeper/claim.go#L167

Kerentanan Kode Fragment:

Jalur pemicu kerentanan:

msgServer.MengklaimAsetSn

Keeper.ClaimShareToken

Keeper.ConvertWAssetToSnAssetDecimal

precisionMultiplier

• Latar belakang kerentanan: Proyek SuperNova

Alamat proyek: https://github.com/Carina-labs/nova/

Keunikan zona tidak diverifikasi. Pada wilayah yang terdaftar, gunakan ID wilayah untuk memeriksa keunikan token dasar (BaseDenom). BaseDenom untuk setiap wilayah harus unik. Jika nilai token dasar disetel dengan tidak benar, itu akan mengakibatkan kerugian dana. Sebelum menetapkan token dasar di RegisterZone, proyek tidak memastikan bahwa BaseDenom unik di semua zona utama. Jika tidak, ada kemungkinan pengguna menyimpan dana di zona jahat lain yang mengandung BaseDenom dengan nama yang sama, yang mengakibatkan kerugian dana.

Lokasi kerentanan: https://github.com/Carina-labs/nova/blob/v0.6.3/x/icacontrol/keeper/msg_server.go#L99

Cuplikan kode yang rentan:

Perbaikan bug: Menambahkan pemeriksaan DenomDuplicateCheck

Selain itu, kasus pertama di mana rantai berhenti berjalan disebabkan oleh kecelakaan yang menyebabkan kegagalan pencetakan, yang juga merupakan bentuk kerugian modal.

• Latar belakang kerentanan: Proyek Supernova

Alamat proyek: https://github.com/Carina-labs/nova/

Pembaruan status hilang. Pada metode IcaWithdraw(), jika transaksi gagal dan status versi tidak diubah, WithdrawRecord akan tidak dapat diakses dan dana yang sesuai tidak dapat ditarik. Pemahaman yang lebih umum adalah bahwa status diatur sebelum SendTx, dan status tidak diubah setelah kegagalan, menyebabkan penarikan dana gagal dan tidak dapat ditarik kembali di kesempatan berikutnya.

Lokasi kerentanan: https://github.com/Carina-labs/nova/blob/932b23ea391d4c89525c648e4103a3d6ee4531d5/x/gal/keeper/msg_server.go#L356

Potongan kode yang rentan:

Berdasarkan cuplikan ini, kita dapat membedakan bahwa logika utama dari operasi terkait dana terutama bergantung pada penanganan berbagai pesan. Tentu, ada juga kasus seperti skenario pertama yang melibatkan operasi pencetakan dalam proses eksekusi BeginBlock. Ketika operasi-operasi ini gagal, mereka juga dapat menyebabkan kerugian keuangan. Secara keseluruhan, dengan memfokuskan audit kita pada modul kode yang melibatkan operasi keuangan, kita dapat secara signifikan meningkatkan kemungkinan menemukan kerentanan semacam itu.

Mempengaruhi Status Sistem atau Operasi Normal

Rentang kategori masalah ini cukup luas. Dua jenis risiko pertama yang kita bahas juga dapat dianggap sebagai subset dari kerentanan yang memengaruhi keadaan sistem atau operasi normal. Selain itu, lebih berbahaya adalah berbagai kerentanan logis. Secara besar-besaran, kerentanan ini menghasilkan berbagai risiko keamanan yang berbeda sesuai dengan logika bisnis proyek. Namun, karena kesamaan dalam konstruksi komponen Cosmos SDK dan sifat modular mereka, kesalahan serupa sering terjadi dalam implementasi kode tertentu. Di sini kita daftar beberapa jenis kerentanan umum:

- Validasi variabel yang tidak lengkap dalam tipe sdk.Msg:

Karena berbagai proyek telah menerapkan berbagai jenis turunan berdasarkan sdk.Msg, tidak semua elemen tipe yang ada telah diperiksa dengan benar di Cosmos SDK. Hal ini telah menyebabkan pengabaian pemeriksaan variabel tertanam yang kritis, sehingga menimbulkan risiko keamanan tertentu.

Studi Kasus: Pengumuman Keamanan Barberry Cosmos SDK

Latar belakang kerentanan: MsgCreatePeriodicVestingAccount.ValidateBasic kurang memiliki mekanisme untuk menilai status sebuah akun, seperti apakah aktif. Pada x/auth ditentukan PeriodicVestingAccount, seorang penyerang bisa menginisialisasi akun korban ke akun yang dimiliki dengan jahat. Akun ini memungkinkan deposit namun melarang penarikan. Ketika pengguna melakukan deposit dana ke akun mereka, dana-dana ini akan terkunci secara permanen, dan pengguna tidak akan bisa menariknya.

Patch kerentanan:

https://forum.cosmos.network/t/cosmos-sdk-security-advisory-barberry/10825

https://github.com/cosmos/cosmos-sdk/security/advisories/GHSA-j2cr-jc39-wpx5

https://github.com/cosmos/cosmos-sdk/compare/v0.47.3-rc.0...v0.47.3

https://github.com/cosmos/cosmos-sdk/pull/16465

Potongan kode rentan:

Selain itu, masalah dalam tahap ValidateBasic juga ada dalam Cosmos-SDK Security Advisory Elderflower dan Cosmos-SDK Security Advisory Jackfruit. Yang pertama mengalami penghilangan langsung dari panggilan ValidateBasic, sementara yang terakhir melibatkan masalah dengan verifikasi variabel timestamp dalam pesan. Dalam rantai aplikasi, masalah seperti ini bahkan lebih umum. Proyek-proyek seperti ethermint, pstake-native, dan quicksilver semuanya mengalami kerentanan keamanan serupa dalam langkah-langkah verifikasi pemrosesan pesan mereka.

Selain jenis verifikasi, ada juga isu yang dihadapi dalam logika penanganan sdk.Msg, seperti operasi yang melibatkan konsumsi gas yang luas, perulangan, dan penanganan crash yang tidak masuk akal. Karena rantai pemrosesan pesan memiliki mekanisme pemulihan yang sesuai, tingkat bahaya mereka agak lebih rendah daripada penutupan rantai lengkap. Namun, mereka masih dapat mempengaruhi operasi normal sistem atau menyebabkan kerugian dana pada rantai.

Jenis Kerentanan Umum

Kecuali kerentanan yang unik untuk operasi proyek tertentu, ada beberapa model kerentanan yang lebih umum. Misalnya, kasus ketiga kehilangan dana adalah operasi yang mengubah keadaan sebelum mengirim pesan. Jenis kerentanan ini mirip dengan yang ada di kontrak pintar, di mana mengubah keadaan sebelum mentransfer dana dapat menyebabkan masalah seperti re-entrance atau keadaan yang salah bertahan. Skenario di mana pengaturan keadaan sangat terkait dengan transmisi pesan cukup umum dalam blockchain, dan banyak kerentanan signifikan berasal dari masalah semacam itu. Selain itu, ada kerentanan keamanan komputasi seperti kesalahan pembagian nol, penghindaran konsumsi gas, dan penggunaan versi dengan kerentanan yang diketahui, yang semuanya dapat mempengaruhi keadaan atau operasi normal sistem.

Masalah Keunikan

Karena banyak operasi baca dan tulis pada blockchain, keunikan dalam penamaan sangat penting dalam beberapa fungsionalitas. Sebagai contoh, kasus kedua kehilangan dana yang disebutkan sebelumnya adalah masalah keunikan. Selain itu, komposisi awalan dalam variabel yang mewakili kunci, seperti string atau larik byte, dapat menimbulkan risiko. Sebuah kelalaian kecil bisa mengakibatkan nama-nama tersebut disalahartikan, menyebabkan masalah seperti kehilangan dana atau kesalahan konsensus.

Masalah Fitur Bahasa

Ini lebih luas tetapi memiliki karakteristik yang mudah dikenali, sehingga lebih mudah dideteksi. Contohnya termasuk masalah dengan iterasi peta di Golang atau mekanisme panic di Rust. Disarankan untuk mencantumkan faktor risiko khusus bahasa ini dan memberikan perhatian khusus pada mereka selama penggunaan atau audit untuk meminimalkan kesalahan seperti itu.

Ringkasan

Dari penjelajahan kami terhadap masalah keamanan mendasar dalam ekosistem Cosmos, jelas bahwa masalah-masalah ini tidak unik untuk Cosmos dan dapat diterapkan pada ekosistem blockchain lainnya juga. Berikut adalah beberapa rekomendasi dan kesimpulan mengenai masalah keamanan dalam ekosistem Cosmos:

• Perhatikan kerentanan infrastruktur: Komponen inti seperti CometBFT dan Cosmos SDK mungkin juga memiliki kerentanan, jadi pembaruan dan pemeliharaan reguler diperlukan untuk keamanan.

• Periksa pustaka pihak ketiga segera: Pengembang Cosmos sering menggunakan pustaka pihak ketiga untuk memperluas fungsionalitas aplikasi mereka. Pustaka ini mungkin mengandung kerentanan potensial, sehingga memerlukan tinjauan dan pembaruan untuk mengurangi risiko.

• Berhati-hatilah terhadap serangan node jahat: Node konsensus sangat penting dalam ekosistem Cosmos. Algoritma toleransi kesalahan Byzantine dari node-node ini mungkin rentan terhadap serangan, oleh karena itu memastikan keamanan node penting untuk mencegah perilaku jahat.

• Pertimbangkan keamanan fisik: Tindakan keamanan fisik diperlukan untuk hardware dan server yang menjalankan node Cosmos untuk mencegah akses tidak sah dan potensi serangan.

• Melakukan tinjauan kode yang diperlukan: Mengingat keterbukaan ekosistem Cosmos SDK dan CometBFT, pengembang dan pemeriksa harus meninjau baik kode inti maupun kode yang ditulis dalam modul kustom untuk mengidentifikasi dan memperbaiki potensi masalah keamanan.

• Perhatikan alat-alat ekosistem: Ekosistem Cosmos mencakup banyak alat dan aplikasi, yang juga perlu melalui tinjauan keamanan dan pembaruan rutin untuk memastikan keamanannya.

Panduan Keamanan Protokol IBC

Modul ini fokus pada aspek keamanan dari protokol Komunikasi Antar-Blockchain (IBC), komponen penting dalam ekosistem Cosmos. Protokol IBC berfungsi sebagai jembatan untuk interaksi antara blockchain yang berbeda. Sementara jembatan lintas-rantai lainnya menyediakan solusi untuk isu-isu tertentu yang terisolasi, protokol IBC menawarkan solusi dasar yang terpadu dan dukungan teknis yang mendasar untuk interaksi lintas-rantai. IBC adalah protokol yang memungkinkan blockchain heterogen untuk mentransfer data apa pun secara dapat diandalkan, teratur, dan dengan kepercayaan minimal.

Sejak munculnya Bitcoin, bidang blockchain telah mengalami pertumbuhan yang sangat pesat. Banyak jaringan baru muncul, masing-masing dengan proposisi nilai uniknya, mekanisme konsensus, ideologi, pendukung, dan alasan keberadaan. Sebelum diperkenalkannya IBC, blockchain ini beroperasi secara independen, seperti dalam wadah tertutup, tidak dapat berkomunikasi satu sama lain, model yang pada dasarnya tidak dapat dipertahankan.

Jika blockchain dilihat sebagai negara dengan populasi yang berkembang dan aktivitas komersial yang ramai, beberapa unggul dalam pertanian, yang lain dalam peternakan. Secara alami, mereka mencari perdagangan dan kerjasama yang saling menguntungkan, memanfaatkan kekuatan masing-masing. Tidak berlebihan untuk mengatakan bahwa IBC telah membuka dunia baru dengan kemungkinan yang tak terbatas, memungkinkan berbagai blockchain untuk beroperasi, mentransfer nilai, pertukaran aset dan layanan, serta membangun koneksi, tanpa terhalang oleh isu-isu skalabilitas bawaan dari jaringan blockchain besar saat ini.

Jadi, bagaimana IBC memenuhi kebutuhan ini dan memainkan peran yang sangat penting? Alasan mendasarnya adalah bahwa IBC:

1. Minimalkan kepercayaan

2. Mampu mendukung blockchain heterogen

3. Dapat disesuaikan di lapisan aplikasi

4. Teknologi yang matang dan teruji

Dasar protokol IBC terletak pada klien ringan dan penerus. Rantai A dan B berkomunikasi melalui IBC masing-masing memiliki klien ringan dari buku besar yang lain. Rantai A, tanpa perlu mempercayai pihak ketiga, dapat mencapai konsensus tentang status Rantai B dengan memverifikasi header bloknya. Rantai yang berinteraksi melalui IBC (terutama modul) tidak langsung mengirim pesan satu sama lain. Sebaliknya, Rantai A menyelaraskan pesan tertentu dalam paket data ke statusnya. Selanjutnya, penerus mendeteksi paket-paket data ini dan mentransfernya ke rantai target.

Secara keseluruhan, protokol IBC dapat dibagi menjadi dua lapisan: IBC TAO dan IBC APP.

• IBC TAO: Mendefinisikan standar untuk transmisi paket data, otentikasi, dan penataan, pada dasarnya lapisan infrastruktur. Dalam ICS (Standar Antar Rantai), ini terdiri dari kategori inti, klien, dan pengantar.

• IBC APP: Mendefinisikan standar untuk pengendali aplikasi dari paket data yang ditransmisikan melalui lapisan transport. Ini meliputi, namun tidak terbatas pada, transfer token yang dapat dipertukarkan (ICS-20), transfer token yang tidak dapat dipertukarkan (ICS-721), dan akun antar-rantai (ICS-27), dan dapat ditemukan dalam kategori aplikasi dari ICS.

Protokol IBC (Dari Portal Pengembang Cosmos)

Protokol IBC (Inter-Blockchain Communication) adalah landasan visi ekosistem Cosmos tentang "Internet of Blockchains". Dalam konteks ini, pilihan desain IBC dipengaruhi oleh standar TCP/IP. Sama seperti TCP/IP menetapkan standar untuk komunikasi komputer, IBC menentukan serangkaian abstraksi universal yang memungkinkan blockchain berkomunikasi satu sama lain. Sama seperti TCP/IP tidak membatasi konten paket data yang diteruskan melalui jaringan, IBC beroperasi dengan cara yang sama. Selain itu, mirip dengan protokol aplikasi seperti HTTP dan SMTP yang dibangun di atas TCP/IP, aplikasi seperti transfer aset homogen/nft atau panggilan kontrak pintar lintas rantai juga menggunakan protokol IBC sebagai lapisan dasar.

Masalah utama yang saat ini terlihat dengan protokol IBC terkait dengan transmisi saluran dan pemrosesan paket. Ada masalah signifikan dalam verifikasi bukti, tetapi ini relatif lebih jarang. Artikel ini berfokus pada masalah umum protokol IBC. Berkat desain modular protokol IBC, pengembang aplikasi IBC tidak perlu memperhatikan detail-detail mendasar seperti klien, koneksi, dan verifikasi bukti. Namun, mereka perlu mengimplementasikan antarmuka IBCModule dan metode penanganan Keeper yang sesuai. Oleh karena itu, banyak masalah terkait protokol IBC muncul dalam jalur kode antarmuka IBCModule untuk menerima dan memproses paket (onRecvPacket, OnAcknowledgementPacket, OnTimeoutPacket, dll.).

Klasifikasi Kerentanan Umum

Dalam ekosistem Cosmos, protokol IBC berfungsi sebagai pusat koneksi. Jenis kerentanan yang terkait dengan protokol IBC bervariasi dan kompleks karena integrasi erat implementasinya dengan modul seperti Cosmos-SDK dan CometBFT. Selain itu, karena IBC terutama digunakan dalam ekosistem Cosmos, bahasa pemrograman utamanya adalah Golang, seperti yang dijelaskan dalam dokumentasi ibc-go.

Karena keterbatasan ruang, artikel ini tidak menyelami analisis rinci dari setiap aspek dan komponen protokol IBC. Sebagai gantinya, itu mengklasifikasikan beberapa kerentanan keamanan yang ada. Untuk analisis yang lebih rinci dan komprehensif, Anda dipersilakan menghubungi insinyur keamanan CertiK kami untuk diskusi.

Klasifikasi Kerentanan Umum:

1. Kerentanan Penamaan

   ① Kerentanan Penanganan String

   ② Kerentanan Penanganan Bytecode

2. Kerentanan Proses Transmisi

   ① Kerentanan Pesanan Paket

   Kerentanan Time Out Paket

   ③ Kerentanan Otentikasi Paket

   ④ Kerentanan Paket Lainnya

3. Kerentanan logis

   ① Pembaruan Kerentanan Negara

   ② Voting and Consensus Kerentanan

   ③ Kerentanan Logis Lainnya

4. Kerentanan Konsumsi Gas

Protokol IBC yang ada, dalam hal pemeriksaan dan analisis keamanannya, memiliki banyak kesamaan dengan proses audit protokol Web2. Analisis ini akan membedah beberapa masalah keamanan dan risiko potensial dari protokol IBC dari sudut pandang pembentukan protokol, implementasi, dan ekspansi aplikasi. Karena formulasi protokol seringkali diselesaikan oleh beberapa individu dan organisasi, bagi berbagai organisasi blockchain, lebih banyak pekerjaan berkaitan dengan implementasi dan ekspansi aplikasi protokol. Oleh karena itu, artikel ini akan fokus pada masalah keamanan dari aspek-aspek tersebut. Pendekatan ini berasal dari pertimbangan berbagai risiko keamanan yang dicakup oleh protokol IBC, memungkinkan pengkategorian yang lebih baik dari berbagai jenis masalah keamanan ke dalam tahapan dan modul yang sesuai.

Analisis Kerentanan

Penyusunan Protokol IBC

Studi Kasus 1: Protokol ICS-07, Kerentanan Logis

Latar Belakang Kerentanan: Penggunaan Periode Pelonggaran yang Tidak Benar

Dalam kode, validasi berikut ada:

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

Menurut model keamanan Tendermint, untuk sebuah blok (header) pada waktu t, para validator di NextValidators perlu beroperasi dengan benar sebelum t+PeriodePercaya. Setelah itu, mereka mungkin menunjukkan perilaku lain. Namun, pemeriksaan di sini adalah untuk PeriodePemutusan, bukan PeriodePercaya, di mana PeriodePemutusan > PeriodePercaya. Jika batas waktu consState berada di antara PeriodePercaya dan PeriodePemutusan, maka header ini akan diterima sebagai patokan untuk memvalidasi salah satu dari header yang konflik yang merupakan pelanggaran. Selama periode ini, para validator di consState.NextValidators tidak lagi dianggap dapat dipercaya, dan mantan validator yang bermusuhan dapat mematikan klien tanpa risiko apa pun.

Alamat Proyek: https://github.com/cosmos/ibc/tree/e01da1d1346e578297148c9833ee4412e1b2f254/spec/ics-007-tendermint-client

Lokasi Kerentanan:

• https://github.com/cosmos/ibc/tree/e01da1d1346e578297148c9833ee4412e1b2f254/spec/ics-007-tendermint-client#misbehaviour-predicate

• https://github.com/cosmos/cosmos-sdk/blob/6344d626db1fbdba5e0f67425703c1584021bf5b/x/ibc/light-clients/07-tendermint/types/misbehaviour_handle.go#L96

Kode Rentan:

fungsi definisi protokol

Kode

Implementasi Protokol IBC

Tahap implementasi protokol IBC adalah fase di mana masalah rentan muncul, karena memainkan peran jembatan kritis. Tidak hanya perlu menghindari ambiguitas dalam spesifikasi protokol tetapi juga perlu menyediakan antarmuka dasar dan nyaman untuk aplikasi berikutnya dan ekspansi protokol. Oleh karena itu, masalah utama dalam tahap implementasi protokol IBC dapat dikategorikan lebih lanjut menjadi:

1. Ketidakpastian dan masalah non-standar dalam implementasi protokol.

2. Kesalahan dalam pengaturan protokol.

Ambiguitas dan Masalah Non-Standard dalam Implementasi Protokol

Studi Kasus 1: Protokol ICS-20, Kerentanan Penamaan

Latar Belakang Kerentanan: Konflik alamat kustodian. TheDapatkanAlamatEscrow()fungsi menghasilkan SHA256 yang dipangkas 20 byte (ID Port + ID Saluran). Metode ini memiliki tiga masalah:

1. Kurangnya pemisahan domain antara port dan saluran. Metode penggabungan string tidak memisahkan domain dari port dan saluran. Misalnya, kombinasi port/saluran ("transfer", "channel") dan ("trans", "ferchannel") akan menghasilkan alamat kustodian yang sama, yaitu SHA256 yang dipotong ("transferchannel"). Jika modul tertentu dengan fungsi pustaka diizinkan untuk memilih ID port dan saluran, kerentanan dapat muncul.

2. Konflik antara alamat akun modul. String alfanumerik sembarangan digunakan dalam pre-image dari SHA-256, dengan ukuran post-image sebesar 160 bit. Post-image kecil ini dikombinasikan dengan fungsi hash yang cepat membuat serangan ulang tahun menjadi memungkinkan, karena keamanannya hanya berkurang menjadi 80 bit. Ini berarti sekitar 2^80 tebakan diperlukan untuk menemukan kolisi antara dua alamat akun kustodian yang berbeda. Pada tahun 2018, analisis biaya terperinci terhadap serangan pemotongan SHA256 dalam konteks Tendermint dilakukan, membuktikan bahwa serangan semacam itu memungkinkan dari perspektif biaya. Menemukan kolisi berarti bahwa dua akun kustodian yang berbeda memetakan ke alamat akun yang sama. Hal ini dapat menyebabkan risiko dana dicuri dari akun kustodian. Untuk lebih rincian, lihat ICS20 GetEscrowAddress pre-image domain tumpang tindih dengan kunci publikT:BUG.

3. Konflik antara alamat akun modul dan non-modul. Konstruksi alamat akun publik sama dengan 20 byte SHA-256 dari kunci publik Ed25519. Meskipun keamanan 160 bit sudah cukup untuk mencegah serangan tabrakan pada alamat publik tertentu, keamanan terhadap serangan ulang tahun hanya 80 bit. Situasi ini mirip dengan mode serangan semi-ulang tahun, di mana satu alamat dihasilkan oleh SHA-256 yang cepat, dan alamat lain dihasilkan oleh perhitungan kunci publik Ed25519 yang relatif lebih lambat. Meskipun situasi ini lebih aman, tetap ada potensi serangan pada akun kustodian dan akun publik.

Alamat proyek: https://github.com/cosmos/ibc/tree/e01da1d1346e578297148c9833ee4412e1b2f254/spec/ics-020-fungible-token-transfer

Lokasi kerentanan: https://github.com/cosmos/cosmos-sdk/blob/6cbbe0d4ef90f886dfc356979b89979ddfcd00d8/x/ibc/applications/transfer/types/keys.go#L40-L47

https://github.com/cosmos/cosmos-sdk/blob/6cbbe0d4ef90f886dfc356979b89979ddfcd00d8/x/ibc/applications/transfer/keeper/relay.go

Potongan kode rentan:

Masalah pengaturan protokol kesalahan

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

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

1. Kondisi normal: Berhasil dalam batas waktu

2. Timeout situation: kegagalan waktu habis

Diagram alur transmisi paket aplikasi IBC

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

Prinsip kerentanan Dragonberry alur diagram aliran

Alamat proyek: https://github.com/cosmos/ibc-go/tree/00a680cda52690a4ba835bf37f53acc41c01bc7a/modules/core/04-channel

Lokasi kerentanan: https://github.com/cosmos/ibc-go/blob/00a680cda52690a4ba835bf37f53acc41c01bc7a/modules/core/04-channel/keeper/timeout.go#L117C28-L117C54

Potongan kode 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 urutan yang disertakan dalam pertanyaan. Ini hanya berfungsi untuk saluran di luar urutan, karena saluran yang diurutkan menggunakan nextSequenceRecv alih-alih tanda terima paket. Oleh karena itu, pada saluran yang diurutkan, menanyakan nomor urutan melalui GetPacketReceipt tidak akan menemukan tanda terima di dalamnya.

Keparahan masalah ini adalah ringan karena saluran yang ditransmisikan oleh ICS-20 FT sebagian besar rusak dan pengulang tidak bergantung pada ujung grpc ini untuk menentukan paket mana yang memicu waktu habis. Namun, jika ada sejumlah besar paket dalam rantai target, dan saluran terurut dikonfigurasi untuk transmisi IBC, dan tanggapan grpc tidak dipaginasi, ini akan menciptakan risiko menyebabkan kinerja node layanan menurun atau bahkan crash. Proses pemicu spesifik dapat dilihat pada gambar di bawah ini.

Prinsip kerentanan Huckleberry alur diagram

Alamat proyek: https://github.com/cosmos/ibc-go/blob/11297aaa61e651c16e6d4147a15be24ce55ba7cc/modules/core/04-channel/

Lokasi kerentanan: https://github.com/cosmos/ibc-go/blob/11297aaa61e651c16e6d4147a15be24ce55ba7cc/modules/core/04-channel/keeper/grpc_query.go#L408

Potongan kode yang rentan:

Aplikasi dan perluasan protokol IBC

• Kasus 1: kerentanan airdrop stride, kerentanan logika

Latar Belakang Kerentanan: Fungsi CobaUpdateKlaimAirdropmengonversi alamat pengirim paket IBC menjadi alamat Stride bernamaalamat Stride pengirim, dan mengekstrak airdropIddan alamat airdrop baru newStrideAddressdari metadata paket. Kemudian memanggilPerbaruiAlamatAirdrop untuk memperbarui alamatStridePengirimdanKlaimRekamanDengan pembaruan dari KlaimRekaman, newStrideAddressakan dapat mengklaim airdrop. Namun, fungsi pembaruan ini hanya memverifikasi apakah alamat pengirim permintaan kosong, dan tidak memvalidasinewStrideAddress. Karena IBC memungkinkan koneksi mesin solo untuk mengimplementasikan rantai yang mendukung IBC, ini menghadirkan risiko keamanan di mana dimungkinkan untuk memperbarui alamat akun lain sebagai alamat airdrop.

Alamat proyek: https://github.com/Stride-Labs/stride/tree/3a5c7bfcc3b8c5e7dd870f01bebeb9d949492203/x/autopilot

Lokasi kerentanan: https://github.com/Stride-Labs/stride/blob/3a5c7bfcc3b8c5e7dd870f01bebeb9d949492203/x/autopilot/module_ibc.go#L119

https://github.com/Stride-Labs/stride/blob/3a5c7bfcc3b8c5e7dd870f01bebeb9d949492203/x/autopilot/keeper/airdrop.go#L17

Potongan kode rentan:

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

Latar belakang kerentanan: Dalam konteks kontrak pintar, ada masalah dengan cara biaya diverifikasi untuk mengonfirmasi atau waktu habis peristiwa IBC (Komunikasi Antar Blockchain). Kekurangan ini memungkinkan kontrak pintar jahat untuk memicu kegagalan 'ErrorOutOfGas'. Kegagalan ini terjadi selama pemrosesan pesan 'OnAcknowledgementPacket' dan 'OnTimeoutPacket'. Ketika kesalahan ini terjadi, tidak mungkin untuk menyelesaikannya melalui metode 'outOfGasRecovery' biasa. Akibatnya, transaksi yang terpengaruh gagal disertakan dalam blok blockchain. Kegagalan ini dapat menyebabkan pengulang IBC berulang kali mencoba mengirimkan pesan-pesan ini. Pengiriman ulang seperti itu dapat menyebabkan kerugian keuangan bagi pengulang dan membebani jaringan dengan jumlah paket yang tidak diproses (‘ditinggalkan’) yang berlebihan, yang mengancam stabilitas jaringan.

Alamat proyek: https://github.com/neutron-org/neutron/blob/64868908b21f648ad5e8a9b48179134619544e2a/

Lokasi kerentanan:

https://github.com/neutron-org/neutron/blob/64868908b21f648ad5e8a9b48179134619544e2a/x/interchaintxs/keeper/ibc_handlers.go#L62

Potongan kode yang rentan:

Ringkasan

Analisis dan diskusi tentang masalah keamanan yang berkaitan dengan protokol Komunikasi Antar-Blockchain (IBC), seperti yang disajikan dalam teks sebelumnya, menyoroti sifat yang luas dan beragam dari kekhawatiran ini. Tantangan utama tampaknya berasal terutama dari fase implementasi dan ekspansi aplikasi yang menggunakan protokol IBC. Saat berbagai rantai aplikasi secara progresif meningkatkan dan menyempurnakan fungsionalitas modul tradisional mereka, mereka sekaligus menggabungkan beragam implementasi kode ke dalam modul IBC mereka. Hal ini dilakukan untuk meningkatkan kinerja dan memenuhi persyaratan bisnis tertentu.

Selain masalah keamanan yang disebutkan sebelumnya dalam komponen IBC, tantangan baru muncul, terutama dalam middleware IBC. Persoalan-persoalan yang berkembang ini diperkirakan akan menjadi semakin signifikan di masa depan, terutama mengenai keseluruhan keamanan ekosistem Cosmos. Perubahan ini menunjukkan penekanan yang semakin besar pada memastikan langkah-langkah keamanan yang kuat dalam modul IBC.

Kesimpulan

Penyelidikan kami terhadap keamanan ekosistem Cosmos, melibatkan audit mendetail, ringkasan, dan kategorisasi, berpusat pada dua komponen paling kritisnya: Cosmos SDK dan protokol IBC. Berdasarkan pengalaman praktis kami yang luas, kami telah menyusun kumpulan keahlian audit umum yang komprehensif.

Laporan ini menekankan tantangan unik yang dihadapi oleh jaringan heterogen seperti Cosmos, terutama mengingat dukungannya untuk interaksi lintas rantai. Kompleksitas dan sifat tersebar dari komponennya membuat tugas memastikan keamanan mereka sulit. Hal ini memerlukan tidak hanya menerapkan pengetahuan kita yang sudah ada tentang risiko keamanan tetapi juga beradaptasi dengan skenario keamanan baru untuk mengatasi isu-isu yang muncul.

Meskipun ada rintangan ini, kami optimis. Dengan mendokumentasikan dan menganalisis skenario umum dan tantangan keamanan, seperti yang telah kami lakukan dalam laporan ini, kami sedang membuka jalan untuk secara progresif meningkatkan kerangka keamanan keseluruhan dalam ekosistem Cosmos yang beragam.

Disclaimer：

1. Artikel ini dicetak ulang dari [Gate.io]CertiK]. Semua hak cipta adalah milik penulis asli [CertiK]. Jika ada keberatan terhadap cetak ulang ini, silakan hubungi Gate Belajartim, dan mereka akan menanganinya dengan cepat.
2. Penyangkalan Tanggung Jawab: Pandangan dan opini yang terdapat dalam artikel ini semata-mata milik penulis dan tidak merupakan nasihat investasi apa pun.
3. Terjemahan artikel ke dalam bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, menyalin, mendistribusikan, atau menjiplak artikel yang diterjemahkan dilarang.