Latar Belakang

Pada 18 Juni 2026, kontrak RollupProcessor dari protokol privasi Layer2 Ethereum, Aztec Connect, mengalami serangan. Penyerang memanfaatkan mekanisme Escape Hatch untuk mengeksploitasi celah kepercayaan akibat tidak adanya verifikasi pemisahan dana dan batas penarikan di layer Solidity, serta kurangnya batasan sirkuit terkait, mengajukan bukti escape hatch yang diterima oleh TurboVerifier, dan langsung menarik 1.158 ETH (sekitar 2,06 juta dolar AS) dari saldo kontrak, serta mencuri 150.000 DAI dan 0,47 renBTC melalui mekanisme yang sama, dengan total kerugian sekitar 2,22 juta dolar AS.

Ikhtisar Serangan

Transaksi serangan:

Akar masalah

Kekurangan batas kepercayaan dalam escapeHatch()

Fungsi pintu masuk publik RollupProcessor escapeHatch() hanya memeriksa apakah status escape hatch diaktifkan, kemudian langsung masuk ke processRollupProof(), tanpa melakukan pemeriksaan izin pemanggil:

Sebaliknya, jalur pemrosesan rollup biasa processRollup() akan memverifikasi otorisasi rollupProviders[provider] dan memverifikasi tanda tangan provider. Namun, serangan ini memanggil escapeHatch(), dengan signatures = 0x dan viewingKeys = 0x, sepenuhnya menghindari proses otorisasi provider.

verifyProofAndUpdateState() terhadap kepercayaan buta Verifier

Setelah masuk ke processRollupProof(), kontrak memanggil TurboVerifier.verify(proofData, 0):

TurboVerifier berperilaku benar—ia menyelesaikan verifikasi matematis dari bukti Plonk. Masalah sebenarnya adalah RollupProcessor menganggap keberhasilan verifikasi matematis setara dengan legalitas bisnis, tanpa melakukan pemeriksaan independen tambahan di lapisan Solidity.

processDepositsAndWithdrawals() secara tidak bersyarat melakukan penarikan

Logika eksekusi inti setelah Verifier mengembalikan sukses:

Fungsi akhir untuk mengalihkan dana:

Sirkuit zkSNARK hilang gerbang kendala kesetaraan (akar penyebab)

Dalam sirkuit pembuktian join-split Aztec, old_data_root dibagi menjadi dua jalur independen:

  • Saksi internal A: Dikirim ke sub-sirkuit join-split untuk memverifikasi kelayakan Merkle dari catatan pribadi

  • Input publik B: Diekspos sebagai input publik di lapisan Solidity, untuk membandingkan validateMerkleRoots() dengan dataRoot on-chain

Kekurangan kendala A == B dalam sirkuit, memungkinkan keduanya diberikan nilai secara independen:

  • A dapat berupa akar Merkle yang dipalsukan oleh penyerang (berisi catatan dengan jumlah berapa pun)

  • B bisa jadi dataRoot chain yang nyata (sehingga mendapatkan pemeriksaan Solidity)

Karena sistem kendala mengizinkan A ≠ B, seluruh bukti zkSNARK tetap valid.

Proses serangan

Tahap persiapan: Memalsukan pohon Merkle dan bukti

Penyerang membangun pohon Merkle data yang dipalsukan secara lokal, menyisipkan catatan pribadi:

  • Nilai: 1158 ETH (kontrak pada saat itu memegang sekitar 1158.7598 ETH)

  • Pemilik: Penyerang memegang kunci privat yang sesuai

Penyerang membangun bukti zkSNARK:

  • Saksi internal A (old_data_root) = akar pohon palsu

  • Input publik B (old_data_root) = dataRoot nyata on-chain = 0x184bea7d9493cd9a5efb6b679d04066a8c92a34ac8ec150e9635133c6010977b

Tahap pertama: Membangun transaksi serangan

Penyerang EOA 0x6952d9246e9aFE8B887B2877225163436F78E97F langsung memanggil RollupProcessor (0x737901bea3eeb88459df9ef1be8ff3ae1b42a2ba):

  • Tanda tangan fungsi: escapeHatch(bytes,bytes,bytes)

  • msg.value = 0

  • signatures = 0x

  • viewingKeys = 0x

Data buktinya mengandung input publik kunci:

Tahap kedua: Menghindari pemeriksaan izin

escapeHatch() hanya memeriksa getEscapeHatchStatus() mengembalikan true sebelum langsung memanggil processRollupProof(). Jalur ini tidak menjalankan pemeriksaan otorisasi rollupProviders[provider] di dalam processRollup() biasa, dan tidak memverifikasi tanda tangan provider. Tidak ada hubungan apa pun antara identitas pemanggil dan penerima penarikan.

Tahap ketiga: Verifikasi matematis Verifier

RollupProcessor melakukan STATICCALL ke TurboVerifier (0x48cb7ba00d087541dc8e2b3738f80fdd1fee8ce8):

Karena rollup_size = 0, TurboVerifier memilih EscapeHatchVk (vk.num_inputs = 26) untuk verifikasi matematis bukti Plonk melalui VerificationKeys.getKeyById(0). Verifier hanya memverifikasi konsistensi matematis antara bukti dan input publik, tidak membaca status RollupProcessor, dan tidak memeriksa kepemilikan saldo.

Dalam transaksi ini, pemanggilan verifier berhasil kembali, menunjukkan bahwa bukti escape hatch yang diajukan penyerang secara matematis benar.

Tahap keempat: Melakukan penarikan

Setelah Verifier mengembalikan sukses, RollupProcessor memperbarui status rollup:

Kemudian masuk ke processDepositsAndWithdrawals(), dalam mode escape hatch rollupSize == 0 tetap diproses sebagai 1 transaksi dalam.

Langsung memanggil withdraw(1158 ETH, alamat penyerang, 0), mengalihkan dana melalui receiverAddress.call{value: 1158 ETH}("").

Tahap kelima: Serangan dengan pola yang sama pada DAI dan renBTC

Penyerang menggunakan jalur kerentanan yang sama pada periode yang sama, membangun bukti escape hatch untuk aset ERC20 (assetId ≠ 0), mencuri 150.000 DAI dan 0.47 renBTC dari RollupProcessor. Fungsi withdraw() dalam cabang assetId ≠ 0 menjalankan transfer() untuk menyelesaikan transfer.

Pendapatan bersih dari tiga serangan:

Pelacakan dana

Analisis terhadap EOA penyerang 0x6952d9246e9aFE8B887B2877225163436F78E97F menggunakan sistem pelacakan anti-pencucian uang SlowMist MistTrack:

Sumber dana: Gas awal yang digunakan alamat yang dibuat penyerang berasal dari 0x963737c550e70ffe4d59464542a28604edb2ef9a (alamat entitas unionchain.ai). Alamat ini pertama kali aktif pada 18 Juni 2026 02:21:11 UTC, tepat pada saat serangan dimulai, dan merupakan alamat sekali pakai yang dibuat khusus untuk serangan ini.

Tujuan dana: Distribusi dana yang dicuri saat ini adalah sebagai berikut:

  • 802 ETH token masih tersisa di alamat utama penyerang 0x6952d9246e9aFE8B887B2877225163436F78E97F, 150.000 DAI dan 0.47 renBTC juga masih belum ditransfer

  • 300 ETH telah ditransfer ke 0x15930a0fef3421f48c6553b5691682cc1b22edb3 (MistTrack menandai sebagai alamat jahat terkait Aztec Exploiter)

  • Sekitar 56 ETH telah ditransfer ke alamat jahat lain (juga ditandai sebagai terkait dengan Aztec Exploiter)

  • 0x33d6a0d9bc210e823e043d604179cd844eb467df skor risiko AML 100/100 (Severe), juga terlibat dalam insiden Aztec Exploiter

Ringkasan

Pelajaran inti dari serangan ini adalah: "matematis benar" zkSNARK sirkuit ≠ "aman secara bisnis". Verifier hanya dapat membuktikan "kamu tahu bukti yang memenuhi kendala tertentu", jika kendala itu sendiri salah (atau hilang), sistem pembuktian menjadi mesin pemalsuan yang sah. Tim keamanan SlowMist merekomendasikan agar proyek melakukan audit khusus terhadap semua jalur kendala bukti nol pengetahuan untuk memastikan keamanan sirkuit.

Artikel ini ditulis oleh tim intelijen ancaman SlowMist yang dipadukan dengan sistem intelijen ancaman MistEye, platform pelacakan MistTrack dan analisis berbasis AI SlowMist Agent. Jika ada pertanyaan, jangan ragu untuk menghubungi kami.