Lompat ke konten

Risiko pemilik dan pemulihan akun pintar

Audit siapa yang dapat mengendalikan akun pintar, bagaimana pemulihan mengganti pemilik, penundaan dan hak pembatalan yang berlaku, serta apakah modul atau peningkatan membuat jalur pengambilalihan tersembunyi.

Diperbarui

Hanya untuk tujuan edukasi; bukan nasihat investasi, hukum, atau keamanan. Kesalahan pemulihan atau konfigurasi dapat memindahkan kendali akun pintar atau menguncinya secara permanen.

Jawaban langsung

Akun pintar dikendalikan oleh logika otorisasi yang diterapkan untuk akun tersebut, bukan selalu oleh satu kunci privat. Pemilik atau validator dapat menyetujui operasi biasa, sedangkan wali, modul pemulihan, eksekutor, atau administrator peningkatan dapat memiliki jalur terpisah untuk mengganti pemilik atau menjalankan transaksi.

Pemulihan mengurangi kemungkinan satu kunci yang hilang membuat akun tidak dapat digunakan, tetapi menambah permukaan pengambilalihan. Audit setiap jalur yang dapat mengotorisasi eksekusi, mengubah validator atau pemilik, memasang modul, meningkatkan kode, atau membatalkan dan menyelesaikan pemulihan. Label antarmuka seperti “pemilik” dan “wali” bukan bukti kewenangan kontrak yang sebenarnya.

Catat hasilnya sebagai tabel izin: alamat on-chain yang tepat, peran, tindakan yang dapat dipanggil, ambang, penundaan, kewenangan pembatalan, kedaluwarsa, cakupan belanja, kewenangan peningkatan, dan domain kendali independen. Periksa ulang setelah setiap perubahan dan pada setiap chain tempat akun berada.

Cara kerja

  1. Identifikasi akun dan kode. Verifikasi chain ID dan alamat akun, lalu tentukan implementasi, proxy atau beacon, factory, dan versi. Untuk proxy ERC-1967, baca slot implementasi, beacon, dan administrator alih-alih memercayai lencana antarmuka.
  2. Daftar semua jalur otorisasi. Baca pemilik dan ambang, validator ERC-4337, validator, eksekutor, hook, dan fallback handler ERC-7579, modul dan guard bergaya Safe, kunci sesi, kontrak pemulihan, serta administrator darurat atau peningkatan. Eksekutor atau modul Safe dapat berjalan tanpa ambang pemilik biasa.
  3. Uraikan mesin status pemulihan. Tentukan siapa yang mengusulkan pemilik pengganti, cara persetujuan wali dihitung dan kedaluwarsa, kapan penundaan dimulai, siapa yang membatalkan dan menyelesaikan, serta apa yang terjadi jika pemulihan diganti atau diulang. Jangan menganggap semua kontrak “pemulihan sosial” memakai urutan sama.
  4. Uji independensi dan ketersediaan. Alamat berbeda tidak independen jika dikendalikan perangkat, orang, akun cloud, brankas kata sandi, kustodian, atau administrator yang sama. Pastikan ambang tetap tercapai setelah satu kegagalan yang diperkirakan tanpa memberi satu domain kuasa mengambil alih.
  5. Tinjau kewenangan konfigurasi. Tentukan siapa yang dapat menambah atau menghapus wali, validator, eksekutor, hook, modul, atau fallback handler; mengubah ambang atau penundaan; menangguhkan pembatalan; atau meningkatkan kode akun dan pemulihan. Timelock berguna hanya jika peran lain tidak dapat melewati penundaan dan pembatalannya.
  6. Pantau dan verifikasi. Berlangganan atau periksa secara independen perubahan pemulihan, pemilik, modul, ambang, implementasi, dan administrator. Setelah operasi, uraikan transaksi dan verifikasi tanda terima, event, storage, dan pemilik akhir di chain yang benar; notifikasi sukses tidak cukup.

Contoh

Anggap akun memiliki pemilik O dan tiga wali G1, G2, dan G3. Wali mana pun sebanyak 2-of-3 dapat mengusulkan pemilik baru N; penundaan 24-hour lalu dimulai; O dapat membatalkan selama penundaan; dan siapa pun dapat menyelesaikan setelah berakhir. Modul pemulihan dapat memanggil fungsi penggantian pemilik tanpa persetujuan O pada transaksi akhir.

Labelnya tampak menunjukkan pemulihan terdistribusi, tetapi G1 dan G2 adalah aplikasi yang dicadangkan ke akun cloud sama. Kebocoran kredensial cloud memberi satu penyerang ambang efektif 2-of-3. Penyerang mengusulkan N; jika pemantauan atau pembatalan gagal selama 24 hours, penyelesaian memindahkan kendali walau kunci privat O tidak dicuri.

Audit karena itu menandai G1 dan G2 sebagai satu domain, memverifikasi alamat dan kode modul, menguji pembatalan dari perangkat aman, memastikan event pemulai penundaan, dan memeriksa apakah administrator dapat segera mengganti modul. Audit tidak melakukan pemulihan nyata pada akun beraset kecuali tersedia proses uji terdokumentasi yang dapat dibalik dengan aman.

Risiko dan kendali

  • Wali berkorelasi: gunakan perangkat, kredensial, orang, atau kustodian yang benar-benar independen; uji prosedur tanpa mengumpulkan frasa seed.
  • Modul atau eksekutor terlalu berkuasa: periksa kode terpasang dan cakupan tepatnya. Hapus modul tak terpakai melalui jalur terdokumentasi dan verifikasi on-chain.
  • Ambang lemah: nilai ketahanan pengambilalihan dan ketersediaan. Ambang nominal tinggi tidak membantu jika penanda tangan berbagi domain; ambang tak tercapai dapat mengunci akun.
  • Penundaan hilang atau dapat dilewati: periksa on-chain penundaan, event pemulainya, siapa yang dapat memperpendek, dan semua jalur penggantian langsung.
  • Pembatalan tidak efektif: latih deteksi dan pembatalan, simpan gas native serta jalur pengiriman independen jika perlu, dan periksa apakah pembatalan memerlukan pemilik lama, kuorum, atau peran lain.
  • Pengambilalihan melalui peningkatan: pantau implementasi, beacon, dan administrator. Administrator yang dapat meningkatkan tanpa penundaan dapat mengubah semua aturan terdokumentasi.
  • Antarmuka berbahaya atau usang: verifikasi chain, akun, modul, calon pemilik, ambang, penundaan, dan calldata secara independen. Jangan pernah berikan frasa seed atau kunci privat kepada layanan “pemulihan”.
  • Penyelesaian palsu: setelah pembatalan atau penyelesaian, konfirmasi tanda terima dan storage akhir. Pastikan pemilik serta modul yang dimaksud aktif dan usulan tak diinginkan tidak dapat dieksekusi.

Jika pemulihan tanpa izin muncul, hentikan penandatanganan permintaan tak terkait dan simpan ID usulan, hash transaksi, calldata, blok, alamat modul, dan status kini. Dari perangkat aman, verifikasi peringatan melalui RPC independen, gunakan jalur pembatalan terdokumentasi bila tersedia, dan pantau penyelesaian, peningkatan, perubahan modul, serta transfer aset. Jika kendali mungkin hilang, ikuti rencana insiden tertulis dan hanya gunakan kontak terautentikasi; transfer dadakan dapat di-front-run atau mengungkap tujuan.

Kesalahpahaman umum

  • “Hanya pemilik yang dapat memindahkan aset.” Validator, eksekutor, modul, kontrak pemulihan, atau kode yang ditingkatkan dapat memberi jalur tambahan.
  • “Tiga wali berarti tiga pihak independen.” Kontrak menghitung persetujuan alamat; kontrak tidak mendeteksi perangkat, cadangan, atau administrator bersama.
  • “Penundaan 24-hour menjamin waktu untuk bereaksi.” Pemantauan, kewenangan pembatalan yang dapat dipakai, gas, dan inklusi juga diperlukan; jalur istimewa lain dapat melewatinya.
  • “Menghapus wali mengakhiri aksesnya.” Konfirmasi konfigurasi akhir on-chain dan periksa peran, modul, kunci sesi, serta pemulihan tertunda lain yang terkait.
  • “Dukungan dapat memulihkan semua akun pintar.” Hanya kewenangan yang dikodekan atau dikonfigurasi sebelumnya on-chain dapat mengubah akun swakustodi. Tanpa pemilik atau jalur pemulihan valid, akses dapat hilang permanen.

Topik terkait

Sumber

Navigasi

Cari di wiki...