Re-entrancy Attack: Bug Klasik Smart Contract yang Curi $60 Juta

Q: Apa itu re-entrancy attack dalam smart contract?

Re-entrancy attack terjadi ketika contract A memanggil contract B, dan contract B memanggil kembali (re-enter) ke contract A sebelum eksekusi pertama selesai. Jika contract A belum update saldo sebelum mengirim dana, hacker bisa menarik dana berulang kali dalam satu transaksi.

Q: Bagaimana cara mencegah re-entrancy attack?

Ada dua pola utama: Checks-Effects-Interactions (update state sebelum kirim dana, bukan sesudah) dan ReentrancyGuard (mutex lock yang mencegah contract dipanggil ulang saat sedang berjalan). Keduanya adalah standar wajib dalam audit smart contract modern.

Re-entrancy attack adalah serangan di mana hacker mengeksploitasi urutan operasi yang salah dalam smart contract — menarik dana berulang kali sebelum contract sempat mencatat bahwa penarikan pertama sudah terjadi. Ini bukan celah di blockchain, melainkan bug logika di kode contract itu sendiri.

Cara Kerja: Analogi Sederhana

Bayangkan ATM yang bekerja seperti ini:

Cek saldo (saldo = Rp 1 juta)
Keluarkan uang
Update saldo di database (saldo = 0)

Jika seseorang bisa memotong proses di antara langkah 2 dan 3 — mengambil lagi sebelum database diupdate — mereka bisa terus mengambil hingga ATM kosong, sementara database masih menganggap saldo masih ada.

Re-entrancy bekerja persis seperti itu, tapi di dalam kode Solidity.

The DAO Hack: Contoh Nyata

Juni 2016, hacker mengeksploitasi re-entrancy di smart contract The DAO dan berhasil menguras 3,6 juta ETH (senilai ~$60 juta saat itu). Ini memaksa komunitas Ethereum melakukan hard fork untuk mengembalikan dana — keputusan kontroversial yang membelah chain menjadi Ethereum (ETH) dan Ethereum Classic (ETC).

Kode bermasalah (disederhanakan):

function withdraw(uint amount) {
  require(balances[msg.sender] >= amount);
  // KIRIM DULU
  msg.sender.call{value: amount}("");
  // UPDATE SALDO BELAKANGAN — celah ada di sini
  balances[msg.sender] -= amount;
}

Contract hacker memanggil withdraw(), menerima ETH, lalu dari fungsi receive() miliknya langsung memanggil withdraw() lagi sebelum baris balances[msg.sender] -= amount sempat dieksekusi. Siklus ini berulang sampai contract korban kehabisan ETH.

Pola Pencegahan yang Benar

Checks-Effects-Interactions (CEI)

Urutan yang benar: cek kondisi → update state → baru kirim dana.

function withdraw(uint amount) {
  require(balances[msg.sender] >= amount);
  // UPDATE SALDO DULU
  balances[msg.sender] -= amount;
  // BARU KIRIM
  msg.sender.call{value: amount}("");
}

Dengan urutan ini, bahkan jika contract hacker coba re-enter, saldo sudah tercatat 0 dan require akan gagal.

ReentrancyGuard (Mutex Lock)

OpenZeppelin menyediakan modifier nonReentrant yang memblokir eksekusi ulang secara eksplisit — setiap fungsi yang pakai modifier ini tidak bisa dipanggil dua kali dalam satu call stack. Ini adalah standar industri saat ini.

Cara User Menilai Risiko

Sebagai pengguna DeFi, Anda tidak perlu membaca kode Solidity. Tapi perhatikan:

Apakah contract sudah diaudit oleh firm terpercaya (Trail of Bits, OpenZeppelin, Certik)?
Sudah berapa lama protocol berjalan tanpa insiden?
Apakah ada bug bounty aktif yang memberi insentif ke peneliti keamanan untuk melaporkan celah?

Protocol yang audit-nya kosong atau baru diluncurkan membawa risiko re-entrancy dan exploit lain yang jauh lebih tinggi. Lihat juga artikel Smart Contract Audit untuk cara membaca laporan audit.

💡 Mau praktik langsung, bukan hanya teori? Di kelas WhaleX, Anda belajar hands-on — setup wallet, yield strategy, dan navigasi protokol DeFi nyata. Coba kelas Web3 gratis →

⚠️ Disclaimer: Informasi ini bersifat edukatif. Interaksi dengan smart contract yang belum diaudit membawa risiko kehilangan dana yang tidak dapat dipulihkan.