Sampul SSP Academy: pembajakan front-end dan DNS

Pembajakan front-end: saat situs web asli berbalik melawan Anda

Sebagian besar saran soal phishing bermuara pada satu aturan: pastikan Anda berada di situs yang asli. Ketik alamatnya sendiri, gunakan bookmark, abaikan tautan di pesan. Itu saran yang bagus, tetapi punya titik buta. Terkadang situs yang asli, di alamat yang asli, mulai menyajikan sesuatu yang berbahaya.

Itulah pembajakan front-end. Smart contract di balik sebuah dApp bisa saja sepenuhnya aman, sementara situs web yang Anda gunakan untuk mengaksesnya telah diganti secara diam-diam, dan setiap transaksi yang diminta untuk Anda tandatangani dirancang untuk menguras dompet Anda.

Situs web adalah hal yang terpisah dari protokol

Aplikasi terdesentralisasi terdiri dari dua bagian:

Kontrak di blockchain, yang menyimpan dana dan menegakkan aturan.
Front-end — yaitu situs webnya — yang membaca data, menyusun transaksi, lalu mengirimkannya ke dompet Anda untuk ditandatangani.

Kontrak biasanya sudah diaudit, bersifat publik, dan sulit diubah. Front-end adalah situs web biasa, di-hosting di infrastruktur biasa, dan dialah yang menentukan persis apa yang muncul di hadapan Anda untuk ditandatangani. Jika penyerang menguasai situs web, mereka sama sekali tidak perlu menyentuh kontrak. Mereka hanya perlu Anda menandatangani transaksi mereka alih-alih transaksi yang asli.

Bagaimana front-end dibajak

Pembajakan DNS. Penyerang mengambil alih pengaturan domain — sering kali melalui registrar domain atau akun yang mengelolanya — dan mengarahkan alamat asli ke server milik mereka. URL di browser Anda benar; situsnya tidak.
Hosting atau deployment yang disusupi. Penyerang yang punya akses ke hosting proyek, pipeline build, atau kunci deployment mendorong versi situs yang sudah dimodifikasi.
Dependensi berbahaya. Skrip atau pustaka pihak ketiga yang dimuat oleh situs — analitik, komponen antarmuka, paket koneksi dompet — disusupi, dan setiap situs yang menggunakannya mulai menyajikan kode penyerang.
Skrip yang disisipkan. Sebuah kerentanan memungkinkan penyerang menyisipkan kode ke halaman yang sebenarnya sah.

Dalam setiap kasus, semua hal dalam kunjungan tersebut tampak normal. URL yang sama, desain yang sama, alur yang sama — hingga muncul permintaan transaksi.

Seperti apa serangannya

Front-end yang dibajak biasanya mengincar salah satu dari beberapa permintaan bernilai tinggi:

Persetujuan token tanpa batas ke alamat penyerang, yang dikemas sebagai langkah biasa "setujui untuk melanjutkan".
"Persetujuan untuk semua" pada NFT, yang disajikan sebagai listing atau klaim.
Tanda tangan off-chain — permit atau order marketplace — yang bisa diajukan belakangan untuk memindahkan dana tanpa permintaan konfirmasi lagi.
Transfer langsung yang disamarkan sebagai deposit, klaim, atau migrasi.

Tanda bahayanya adalah ketidaksesuaian antara apa yang sedang Anda lakukan dan apa yang diminta untuk Anda tandatangani. Menukar jumlah kecil seharusnya tidak memerlukan persetujuan allowance tanpa batas ke alamat yang tidak Anda kenal. Mengklaim hadiah seharusnya tidak memerlukan transfer seluruh aset.

Cara melindungi diri

Anda tidak bisa mendeteksi server yang dibajak hanya dengan melihat halamannya. Pertahanan Anda adalah langkah penandatanganan, karena di situlah niat penyerang harus terlihat.

Baca setiap permintaan di dompet Anda, bukan di situs web. Halaman bisa menampilkan apa saja; dompet menunjukkan apa yang sebenarnya Anda tandatangani.
Periksa pihak pembelanja (spender) dan jumlahnya pada persetujuan. Alamat yang tidak dikenal dan allowance tanpa batas layak dihentikan seketika.
Curigai perubahan alur yang tiba-tiba. Situs yang tidak pernah meminta tanda tangan atau persetujuan pada langkah tertentu lalu tiba-tiba memintanya adalah tanda peringatan.
Gunakan simulasi jika tersedia. Melihat pratinjau apa yang akan dilakukan sebuah transaksi dapat menangkap permintaan yang efek sebenarnya berbeda dari labelnya.
Pantau pengumuman. Proyek yang mendeteksi front-end mereka disusupi biasanya segera memberi peringatan di kanal resmi mereka. Jika ada yang terasa janggal, periksa dulu sebelum menandatangani.
Cabut setelahnya jika Anda ragu. Jika Anda menyetujui sesuatu selama periode ketika sebuah situs sedang disusupi, cabut persetujuan tersebut segera.

Ini melengkapi saran klasik tentang phishing, bukan menggantikannya. Memeriksa alamat melindungi Anda dari situs palsu; membaca permintaan melindungi Anda dari situs asli yang sudah berubah jahat.

Di mana SSP membantu

Saat sebuah dApp yang terhubung melalui WalletConnect meminta SSP untuk menandatangani, permintaan tersebut menampilkan situs mana yang meminta, jaringan, dan alamatnya, dan SSP mendekode panggilan umum sebelum Anda menyetujui: transfer, persetujuan, dan permintaan persetujuan untuk semua NFT diberi label, dengan peringatan eksplisit pada yang lebih berisiko. Pesan ditampilkan sebagai teks yang mudah dibaca bila memungkinkan, dengan data mentah tersedia untuk diperiksa.

Setelah itu, setiap permintaan memerlukan persetujuan kedua di SSP Key, pada perangkat terpisah. Hal ini tidak mencegah situs yang dibajak meminta sesuatu yang berbahaya — tetapi memberi Anda dua kesempatan jelas untuk melihat permintaan itu apa adanya, dan tidak satu pun berada di halaman yang dikuasai penyerang.

Untuk tim, vault SSP Enterprise menambahkan simulasi transaksi dan peringatan risiko sebelum para penanda tangan menyetujui, sehingga proposal yang dibuat melalui front-end yang disusupi mendapat tinjauan kedua yang independen dari setiap orang yang harus menandatanganinya.

Ringkasan jujurnya

Pembajakan front-end mengubah situs web tepercaya menjadi alat penyerang tanpa menyentuh kontrak maupun URL. Anda tidak bisa mendeteksinya dengan memeriksa bilah alamat.

Yang bisa Anda lakukan adalah memperlakukan setiap permintaan tanda tangan sebagai antarmuka yang sebenarnya: baca di dompet Anda, periksa spender, jumlah, dan penerimanya, lalu tolak apa pun yang tidak sesuai dengan apa yang ingin Anda lakukan.