Keuangan Desentralisasi Keamanan: Kerentanan Keamanan Umum dan Langkah Pencegahan

Baru-baru ini, seorang ahli keamanan membagikan konten terkait keamanan DeFi, meninjau peristiwa keamanan besar dalam industri Web3 selama lebih dari setahun terakhir, membahas penyebab terjadinya peristiwa-peristiwa ini serta cara untuk menghindarinya, merangkum celah keamanan umum dalam kontrak pintar dan langkah-langkah pencegahannya, serta memberikan beberapa saran keamanan kepada pengembang proyek dan pengguna.

Jenis-jenis kerentanan DeFi yang umum biasanya meliputi pinjaman kilat, manipulasi harga, masalah hak akses fungsi, pemanggilan eksternal sembarangan, masalah fungsi fallback, kerentanan logika bisnis, kebocoran kunci pribadi, dan reentrancy. Artikel ini akan fokus pada tiga jenis: pinjaman kilat, manipulasi harga, dan serangan reentrancy.

Pinjaman Kilat

Pinjaman kilat sendiri adalah inovasi dalam Keuangan Desentralisasi, tetapi ketika dimanfaatkan oleh peretas, mereka tidak perlu mengeluarkan biaya apapun untuk meminjam uang, setelah menyelesaikan seluruh proses arbitrase, mereka mengembalikannya, bagian yang tersisa adalah keuntungan dari arbitrase, mereka hanya perlu membayar biaya Gas yang kecil untuk mendapatkan keuntungan besar.

Serangan yang umum sering disertai dengan pinjaman kilat, penyerang suka meminjam sejumlah besar dana melalui pinjaman kilat, memanipulasi harga, dan menyerang logika bisnis, dll. Pengembang perlu mempertimbangkan apakah fungsi kontrak akan mengalami gangguan karena dana yang besar, atau melalui dana yang besar berinteraksi dengan beberapa fungsi dalam kontrak dalam satu transaksi untuk mendapatkan imbalan dalam skenario-skenario ini.

Seringkali kita dapat melihat nilai jumlah Token dalam kontrak digunakan untuk menghitung hadiah, atau menggunakan jumlah Token dalam pasangan perdagangan DEX untuk berpartisipasi dalam berbagai perhitungan. Karena pengembang tidak mempertimbangkan bahwa penyerang dapat memanfaatkan pinjaman kilat untuk memanipulasi variabel ini saat merancang fungsi-fungsi tersebut, menyebabkan dana kontrak dicuri.

Dalam dua tahun terakhir, pinjaman kilat mengalami banyak masalah. Banyak proyek DeFi tampak menghasilkan keuntungan yang tinggi, tetapi sebenarnya kualitas tim proyek bervariasi. Misalnya, kode mungkin dibeli, bahkan jika kode itu sendiri tidak memiliki kerentanan, secara logika masih bisa ada masalah. Contohnya, pernah ada proyek yang memberikan hadiah berdasarkan jumlah token yang dimiliki pemegang pada waktu tertentu, tetapi diretas oleh penyerang yang menggunakan pinjaman kilat untuk membeli sejumlah besar token, sehingga sebagian besar hadiah mengalir ke penyerang saat hadiah diberikan. Selain itu, ada juga beberapa proyek yang menghitung harga melalui Token, yang dapat dipengaruhi oleh pinjaman kilat, sebagai pihak proyek harus lebih waspada terhadap masalah ini.

Manipulasi Harga

Masalah manipulasi harga sangat terkait dengan pinjaman kilat, masalah ini terutama disebabkan oleh beberapa parameter dalam perhitungan harga yang dapat dikendalikan oleh pengguna, ada dua jenis masalah yang sering muncul.

• Salah satunya adalah menggunakan data pihak ketiga saat menghitung harga, tetapi cara penggunaan yang tidak benar atau kurangnya pemeriksaan menyebabkan harga dapat dimanipulasi secara jahat.
• Selain itu, jenis lain adalah karena penggunaan jumlah Token dari beberapa alamat sebagai variabel perhitungan, dan saldo Token di alamat-alamat ini dapat meningkat atau menurun sementara.

Serangan Reentrancy

Salah satu bahaya utama dari memanggil kontrak eksternal adalah bahwa mereka dapat mengambil alih aliran kontrol dan melakukan perubahan yang tidak terduga pada data Anda.

Karena saldo pengguna diatur menjadi 0 hanya pada akhir fungsi, panggilan kedua ( dan panggilan ) setelahnya masih akan berhasil, dan saldo akan ditarik berulang kali.

Terkait dengan berbagai kontrak, ada banyak cara untuk melakukan reentrancy, yang dapat menggabungkan fungsi kontrak yang berbeda atau fungsi dari beberapa kontrak yang berbeda untuk menyelesaikan serangan reentrancy. Oleh karena itu, saat kita menyelesaikan masalah reentrancy, kita perlu memperhatikan hal-hal berikut:

1. Tidak hanya mencegah masalah reentrancy pada fungsi tunggal;
2. Mengkode mengikuti pola Checks-Effects-Interactions;
3. Gunakan modifier pencegah reentrancy yang telah teruji oleh waktu.

Sebenarnya yang paling ditakuti adalah mengulang menciptakan roda, perlu apa pun harus ditulis sendiri, di dalam lingkaran ini ada banyak praktik keamanan terbaik, kita tinggal menggunakannya, tidak perlu mengulang menciptakan roda. Ketika Anda menciptakan sebuah roda, itu belum melalui verifikasi yang memadai, pada saat itu, probabilitas terjadinya masalah, jelas jauh lebih besar dibandingkan dengan menggunakan sesuatu yang sudah sangat matang dan teruji.

Kisah di Balik Kerentanan Omni Protocol --- Pertarungan Antara Empat Peretas

Mempool Ethereum terus-menerus dipantau oleh banyak peretas, yang terus menganalisis transaksi dan melakukan serangan mendahului pada transaksi yang menguntungkan untuk mendapatkan keuntungan. Transaksi serangan yang diajukan oleh penemu kerentanan Omni Protocol ditangkap oleh dua peretas, yang menggunakan robot mendahului untuk menyerang transaksi yang diterbitkan oleh flashbot dan mengambil 1200 ETH dari protokol Omni Protocol, sementara penyerang yang menemukan kerentanan hanya mendapatkan 480 ETH. Selama periode ini, ada satu peretas lain yang menemukan transaksi serangan yang diajukan oleh peretas mendahului di flashbot, memanfaatkan karakteristik transaksi serangan yang memerlukan pembelian token Doodle ERC20, dan melakukan serangan sandwich, menghasilkan keuntungan sebesar 151 ETH.

Orang yang menemukan celah tidak selalu mendapatkan keuntungan terbesar, tetapi pemburu lain di hutan gelap yang lebih banyak mendapat keuntungan. Dalam ekosistem ini terdapat banyak pemburu, dan pemburu bisa saling menjadi mangsa. Bahkan jika pelaku serangan adalah pemula, mereka mungkin tidak bisa mengambil sebagian besar uang dari proyek ini, kecuali jika mereka mengambilnya sekaligus. Banyak orang juga akan menggunakan biaya Gas yang lebih tinggi untuk segera mengeksekusi transaksi, dan dalam proses berpacu, jika melibatkan jual beli token di DEX, akan ada risiko serangan sandwich, yang sangat membingungkan.

Saran Keamanan

Terakhir adalah saran keamanan untuk pihak proyek dan pengguna biasa.

Tips Keamanan Proyek

Satu, pengembangan kontrak mengikuti praktik keamanan terbaik.

Dua, Kontrak Dapat Ditingkatkan dan Dihentikan: Banyak serangan bukanlah tindakan sekali jalan untuk mengambil semua koin, melainkan dilakukan dalam beberapa transaksi. Jika ada mekanisme pemantauan yang relatif baik, hal itu dapat terdeteksi. Setelah terdeteksi, jika kontrak dapat dihentikan, maka dapat secara efektif mengurangi kerugian.

Tiga, menggunakan kunci waktu: Seperti dalam beberapa kasus, jika ada kunci waktu, misalnya harus diselesaikan dalam 48 jam, pada saat itu banyak orang dapat menemukan bahwa pencipta telah memperbarui metode mint, dan siapa pun dapat menggunakannya, orang yang memantau akan mengetahui bahwa proyek tersebut kemungkinan telah diretas, sehingga dapat memberi tahu pihak proyek untuk melakukan perubahan, bahkan jika diasumsikan bahwa pemberitahuan telah dilakukan tetapi tidak ada yang peduli, setidaknya mereka dapat menarik bagian uang mereka sendiri terlebih dahulu, untuk memastikan keuntungan mereka tidak terpengaruh. Jadi, jika sebuah proyek tidak memiliki kunci waktu, secara teoritis akan meningkatkan kemungkinan terjadinya masalah.

Empat, Tingkatkan Investasi Keamanan, Bangun Sistem Keamanan yang Komprehensif: Keamanan bukanlah suatu titik, juga bukan suatu garis, keamanan adalah sebuah sistem. Jangan berpikir bahwa sebagai pihak proyek, jika kontrak telah diaudit oleh banyak perusahaan, maka tidak ada masalah, hasilnya hacker mencuri kunci privat, bahkan jika itu multisignature, semua kunci privat bisa dicuri. Atau bisa juga karena ada masalah dalam model ekonomi, masalah dalam model bisnis... Ada ribuan cara yang dapat menyebabkan kehilangan uang, tergantung pada apakah risiko keamanan dapat dihindari sebelumnya. Usahakan untuk melakukan pemodelan risiko, kemudian secara bertahap menghindari sebagian besar risiko, sisa risiko juga harus risiko yang dapat diterima, dalam batas yang dapat ditanggung. Keamanan dan efisiensi tidak mungkin dicapai sekaligus, harus ada pengorbanan tertentu. Tetapi jika sama sekali tidak memperhatikan keamanan, tanpa investasi dalam keamanan, maka diserang adalah hal yang sangat wajar.

Lima, Meningkatkan Kesadaran Keamanan Semua Karyawan: Meningkatkan kesadaran keamanan tidak memerlukan banyak teknologi. Di Twitter, kita sering melihat banyak orang kehilangan NFT karena phishing, sebenarnya cara phishing adalah memanfaatkan kelemahan manusia, mungkin dengan sedikit lebih berhati-hati, kita tidak akan terkena. Dalam lingkungan Web3 ini, dengan sedikit lebih banyak bertanya mengapa, sedikit lebih banyak berpikir, kita bisa menghindari banyak masalah.

Enam, mencegah tindakan jahat internal, sambil meningkatkan efisiensi dan memperkuat kontrol risiko: Mari kita ambil beberapa contoh. Pertama, pemilik kontrak adalah satu tanda tangan dan bukan multi-tanda tangan, jika kunci pribadi hilang maka seluruh proyek akan terkontrol; kedua, tidak menggunakan penguncian waktu, beberapa pembaruan operasi kunci langsung diperbarui, tidak ada yang tahu, ini sangat tidak adil bagi semua peserta dalam protokol; selanjutnya adalah tindakan jahat internal, mekanisme keamanan internal tidak berfungsi sama sekali.

Bagaimana protokol di blockchain dapat meningkatkan keamanan sambil menjaga efisiensi? Beberapa alat keamanan dapat menunjuk seseorang untuk melakukan suatu tindakan, seperti tanda tangan multi pihak tiga dari lima; dapat menunjuk alamat tertentu untuk melakukan suatu tindakan, misalnya memberikan tugas pemantauan risiko keamanan kepada node yang sangat tepercaya, jika ditemukan bahwa protokol sedang diserang dan dana secara bertahap berpindah ke alamat peretas, jika kontrak itu sendiri memiliki fungsi penghentian, maka kita akan memberikan fungsi penghentian itu kepada seseorang, dia dapat melakukan tindakan tersebut.

Misalnya, untuk penyedia likuiditas DEX, jika tidak membatasi hak Owner, Owner bisa mentransfer uang ke alamat lain, membatasi alamat yang dapat digunakan untuk mentransfer koin, membatasi hanya pada pasangan koin tertentu yang dapat dioperasikan, dan mengatur agar uang hanya bisa ditarik ke alamat tertentu. Sambil meningkatkan efisiensi, hal ini juga menjamin tingkat keamanan tertentu.

Tujuh, Keamanan Pihak Ketiga: Sebagai bagian dari ekosistem, setiap proyek memiliki hulu dan hilirnya sendiri. Dalam hal keamanan, ada prinsip "default hulu dan hilir tidak aman". Baik untuk hulu maupun hilir, verifikasi harus dilakukan. Untuk pihak ketiga, kita sangat sulit mengontrolnya, sehingga risiko keamanan sebenarnya sangat besar, jadi perlu sangat hati-hati dalam melibatkan pihak ketiga. Kontrak adalah sumber terbuka, bisa diambil dan dipanggil; jika kontrak tidak sumber terbuka, maka tidak boleh dirujuk. Karena kita tidak tahu logika di dalamnya, atau mungkin kontrak ini sendiri adalah kontrak yang dapat diupgrade, penggunaan normal mungkin tidak ada masalah, tetapi kita tidak dapat memprediksi apakah suatu hari nanti akan diupgrade menjadi kontrak yang jahat, ini tidak dapat dikendalikan.

Bagaimana pengguna/LP menentukan apakah kontrak pintar itu aman?

Untuk pengguna biasa, kami menilai keamanan proyek terutama berdasarkan enam poin berikut:

Satu, Apakah Kontrak Sumber Terbuka: Semua proyek yang tidak memiliki kontrak sumber terbuka, tidak akan kami sentuh, karena kami tidak tahu apa yang tertulis dalam kontrak tersebut.

Kedua, Apakah Pemilik Menggunakan Multi-Signature dan Apakah Multi-Signature Tersebut Terdesentralisasi: Jika tidak menggunakan multi-signature, kita tidak dapat menilai logika dan isi bisnis proyek. Jika terjadi insiden keamanan, kita tidak dapat menentukan apakah itu disebabkan oleh hacker. Meskipun menggunakan multi-signature, kita juga perlu menilai apakah multi-signature tersebut terdesentralisasi.

Tiga, Situasi Perdagangan Kontrak yang Sudah Ada: Terutama karena banyak proyek penipuan phishing di pasar, mungkin ada kontrak yang sangat mirip. Pada saat itu, kita harus melihat waktu penerapan kontrak, jumlah interaksi, dan sebagainya. Ini semua adalah standar pengukuran untuk menentukan apakah kontrak tersebut aman.

Empat, Apakah kontrak merupakan kontrak agen, apakah dapat diupgrade, apakah ada kunci waktu: Jika kontrak sama sekali tidak dapat diupgrade, itu terlalu kaku, tetap disarankan bahwa kontrak proyek dapat diupgrade. Namun, peningkatan harus memperhatikan metode, ketika ada konten peningkatan, perubahan parameter penting, harus ada kunci waktu, harus memberikan kepada semua orang jendela waktu untuk menilai apakah peningkatan yang nyata merugikan atau menguntungkan bagi pengguna, ini juga merupakan cara yang terbuka dan transparan.

Lima, Apakah kontrak telah diaudit oleh beberapa lembaga ( Jangan mempercayai perusahaan audit secara buta ), Apakah hak Owner terlalu besar: Pertama, jangan hanya percaya pada satu perusahaan audit, karena perusahaan audit yang berbeda dan auditor yang berbeda memiliki sudut pandang yang berbeda dalam melihat masalah. Jika sebuah proyek memiliki hasil audit dari beberapa lembaga dan menemukan masalah yang berbeda, serta pihak proyek telah melakukan perbaikan, maka lebih aman dibandingkan hanya diaudit oleh satu perusahaan audit saja. Sebuah pihak proyek yang bertanggung jawab akan mencari beberapa lembaga audit untuk melakukan audit silang.

Kedua, perlu dilihat apakah hak akses Owner terlalu besar. Misalnya, ada beberapa proyek piton, Owner dapat sepenuhnya mengontrol dana pengguna. Jika jumlah token yang dibeli sedikit, maka dapat diperdagangkan dengan normal, tetapi jika jumlah pembelian token sangat besar, Owner dapat segera mengontrol untuk mengunci dan tidak dapat diperdagangkan. Ada juga beberapa proyek NFT yang sama. Pada proyek yang normal, hak akses Owner pasti dapat dikontrol, sehingga tidak akan ada terlalu banyak operasi berisiko tinggi, dan operasi juga akan menggunakan metode kunci waktu, sehingga pengguna tahu apa yang sedang dioperasikan. Terutama saat kondisi pasar tidak baik, ada berbagai macam proyek yang melarikan diri, jadi semua orang harus memperhatikan hak akses Owner.

Enam, Perhatikan Oracle: Jika proyek menggunakan oracle terkemuka di pasar, pada dasarnya tidak akan ada masalah besar, tetapi jika menggunakan oracle yang dibangun sendiri, atau menggunakan beberapa token yang sembarangan di-stake ke dalamnya.