[SHARING] Scam Berbasis Smart Contract, Bagikan Di Sini!

[masulum]

.

INTRO
Transaksi menggunakan smart contract adalah hal yang sering kita lakukan. Tak sedikit pula dari kita yang terjebak dengan transaksi penipuan yang membuat kita kehilangan aset yang kita miliki. Maka dari itu, thread ini dibuat untuk kita berbagi informasi mengenai metode scam yang akan muncul di masa depan, atau trik lama yang digunakan kembali di masa depan. Sehingga member sudah memiliki pengetahuan untuk menghindarinya.


TUJUAN
Tujuan utama dari thread ini adalah untuk memberikan list/daftar pola scam berbasis smart contract yang dapat membuat Anda menjadi korban. Dengan adanya thread ini diharapkan nantinya, member SFI menjadi lebih berhati-hati dan yang terpenting adalah teredukasi karena mendapatkan informasi penting untuk mengamankan aset, berapa pun nilainya saat ini.

Untuk member SFI yang ingin berbagi informasi, bisa dengan format berikut:

Code:

Update Kasus:
Metode Scam:

Tujuannya agar lebih mudah untuk dikenali kalau ada kasus baru yang belum saya atau member SFI temukan sebelumnya.

Berikut adalah contoh singkat berdasarkan 1 kasus dengan metode lama, dan yang ke-2 merupakan kasus yang terjadi dalam beberapa hari terakhir berdasarkan informasi yang didapat dari member forum yang menjadi korban. Thread dari korban bisa dilihat di sini

KASUS 1: Approval Token Scam
Metode Scam: Metode scam ini adalah scammer melakukan pencurian aset melalui approval/izin yang diberikan oleh user dengan sadar ketika menggunakannya untuk keperluan trading menggunakan AMM (Pancakeswap, Uniswap dll), dengan approval yang diberikan terhadap token scam ini, artinya Anda telah memberikan izin terhadap smart contract untuk melakukan transaksi out melalui akun Anda. Contoh kasus:
- Anda memiliki token scam A, dan scammer menambahkan liquidy di AMM
- Anda melakukan transaksi jual token scam A melalui AMM Uniswap dan memberikan izin sebagai konfirmasi untuk melakukan penukaran
- Token berhasil ditukarkan dari Token A ke USDT
- karena token A ini masih memiliki izin, dengan kemampuan coding yang dirancang oleh scammer, maka smart contract token A ini melakukan penarikan aset secara otomatis meskipun ketika Anda sedang offline.


KASUS 2: Pengiriman bernilai 0 (nol)
Metode Scam: Ini adalah metode scam yang baru dan terjadi beberapa hari terakhir seperti yang saya sebutkan pada desktipsi tujuan thread. metode scam yang dilakukan oleh scammer adalah mengirimkan token bernilai 0 ke address serupa dengan address aslinya. Tujuannya adalah untuk mengelabuhi pengguna untuk menyalin address palsu tersebut. Berikut adalah detail kasusnya:

- Scammer dapat mengirimkan transaksi bernilai 0 dari wallet pengguna ke wallet palsu ^{(masih belum diketahui caranya kenapa bisa mengirimkan token dari wallet korban)} dengan transaksi berikut ini
https://bscscan.com/tx/0xc797622c27e35f89898bf43121a36b1f6e29d64769c7aca0917c85f1b764c7f3
Jika kita lihat, address tersebut memiliki banyak pengiriman terjadi. Untuk kemudahan, ini adalah address milik korban
0xb410e3d622D1072eE3E1cc6cdc90120E657977F7
- Dari wallet korban 0xb410e3d622D1072eE3E1cc6cdc90120E657977F7 ia mengirimkan token senilai 0 ke alamat 0x27feAAFD9b46B74bee510a0A538615d2FF639871
- Alamat 0x27feAAFD9b46B74bee510a0A538615d2FF639871 ini adalah merupakan alamat palsu yang menyerupai alamat 0x2704664F03efBfF1E394aBBfD8a7b9f6CC039871

Sepintas, ini akan membingungkan, jadi kalau disatukan akan menjadi seperti ini:
Alamat tujuan palsu: 0x27feAAFD9b46B74bee510a0A538615d2FF639871
Alamat tujuan sebenarnya: 0x2704664F03efBfF1E394aBBfD8a7b9f6CC039871

Pada alamat dari yang palsu dan yang asli memiliki kemiripan 4 karakter awal dan 4-5 karakter akhir (pada contoh 5 karakter). Kebanyakan pengguna akan mengcopy address dari transaksi terakhir, serta melakukan pengecekan dengan berdasarkan beberapa karakter awal dan beberapa karakter di akhir. kebiasaan ini dimanfaatkan oleh scammer untuk mengelabuhi korban. Ketika, ia melihat karakter awal dan akhir sama, dan diambil dari transaksi akhir yang sejatinya transaksi terakhir merupakan dari wallet scammer, maka user akan menyalin wallet palsu tersebut.


PENUTUP
Semoga thread ini memberikan manfaat untuk jangka panjang. Karena kita sadar bahwa kita harus selalu mengingat betapa pentingnya waspada. Scam melalui smart contract ini akan lahir dengan berbagai macam cara. Maka dari itu, saya harap thread ini selain menjadi tempat sharing kasus baru, juga menjadi wadah edukasi. Untuk saat ini, saya hanya bisa memberikan 2 contoh tersebut, jika ada yang mau menambahkan, silakan tinggalkan komentar Anda. Setiap kasus baru akan saya tambahkan di post reply #2

[1715137562]

1715137562

[1715137562]

1715137562

[1715137562]

1715137562

[1715137562]

1715137562

[1715137562]

1715137562

[masulum]

res u/ update

[mu_enrico]

Kasus Ngasih Tau Private Key
Metode Scam: Ini scam yang paling bangke yang ane ingat karena tiba-tiba dapat private key yang berisi token-token yang kalau dijual duitnya lumayan, hanya saja tidak ada ETH untuk biaya transaksi transfer token. Newbie lalu senang dong, dan transfer ETH ke alamat private key tersebut dengan tujuan untuk gas fee transfer token. Eh tiap kali transfer ETH kok ilang... ternyata ETHnya diforward ke alamat lain.

Ternyata alamat pada private key tersebut adalah smart contract yang auto transfer ETH yang dikirim ke alamat tersebut.

Lebih lanjut: https://hackernoon.com/heres-my-private-key-scam-in-crypto-how-it-traps-unsuspecting-users

[len01]

Kasus serupa seperti yang di katakan agan @masulum Someone sent ERC20 from my cold storage
sepertinya kasus seperti ini baru trend dan jika saya lihat cara hacker seperti menyusupi menggunakan alamat yang hampir sama.
Ini bisa jadi peringatan untuk orang orang yang ingin mentransfer koin/token harap hati hati jangan biasakan menyalin alamat dari transaksi sebelumnya. Walaupun sudah berkali kali transaksi dengan alamat yang sama tapi jika kejadian ini terjadi dan sering menyalin dari transaksi sebelumnya pastinya bakal kena serangan seperti itu.

Dan ini ada penjelasan yang lebih detailnya Address Poisoning Attack, A continuing Threat

Kasus Ngasih Tau Private Key
Metode Scam: Ini scam yang paling bangke yang ane ingat karena tiba-tiba dapat private key yang berisi token-token yang kalau dijual duitnya lumayan, hanya saja tidak ada ETH untuk biaya transaksi transfer token. Newbie lalu senang dong, dan transfer ETH ke alamat private key tersebut dengan tujuan untuk gas fee transfer token. Eh tiap kali transfer ETH kok ilang... ternyata ETHnya diforward ke alamat lain.

Ternyata alamat pada private key tersebut adalah smart contract yang auto transfer ETH yang dikirim ke alamat tersebut.

Lebih lanjut: https://hackernoon.com/heres-my-private-key-scam-in-crypto-how-it-traps-unsuspecting-users

Metode seperti ini kalau tidak salah dulu trend di tahun 2017/2018 khususnya yang sering ikut bounty dan iseng lihat lihat isi spreadsheet nemu privatkey.
saya sendiri sudah pernah ngerasain kena serangan seperti itu. Nyoba ngirim 0.1 eth baru 2detik langsung auto transfer ke alamat lain.
Dan sepertinya metode scam macam ini masih ada di beberapa spreadsheet bounty.

[masulum]

Dan ini ada penjelasan yang lebih detailnya Address Poisoning Attack, A continuing Threat

Penjelasan yang sangat rumit haha. cuma sepintas yang saya perhatikan adalah pemanfaatan fungsi

Code:

transferFrom()

yang mana, dengan memakai fungsi ini, hacker secara otomatis dapat menjalankan fungsi approval dan dan transfer.

Pada paragraf ini disebutkan

In a transaction where the attacker calls the attack contract, the attack contract only calls the transferFrom() function of BSC-USD, and by filling the parameters with sender, recipient, and amount, it can manipulate the 0 USD transfer between any addresses, and at the same time generate the events of AuthorizeApproval() and TransferTransfer().

Artinya, fungsi ini memiliki celah serius untuk mengirimkan uang senilai 0, (umumnya, pengiriman uang 0 ini juga digunakan untuk menyelesaikan proses pending transfer). Namun, fasilitas ini dapat dimanfaatkan oleh scammer/hacker dengan 4 parameter. Yang mengerikan adalah authorizeApproval(), kita tau, saat kita akan melakukan transaksi , kita butuh approval, namun si scammer bisa menemukan celah tersebut. karena yang dikirimkan oleh scammer token eksis yang sudah diapprove secar sadar oleh user, jadi wallet pengirim tidak butuh approval token lagi, ia hanya butuh approval pengiriman.

[joniboini]

Yang mengerikan adalah authorizeApproval(), kita tau, saat kita akan melakukan transaksi , kita butuh approval, namun si scammer bisa menemukan celah tersebut. karena yang dikirimkan oleh scammer token eksis yang sudah diapprove secar sadar oleh user, jadi wallet pengirim tidak butuh approval token lagi, ia hanya butuh approval pengiriman.

Ane masih agak bingung dengan bagian ini. Dari hasil bacaan ane, yang ane pahami adalah fungsi" token ini dipanggil oleh si penyerang secara remote, tanpa ada input dari user. Pemanfaatan fungsi transferfrom ini juga digunakan untuk menghasilkan error supaya transfer token dengan nilai 0 usd ini bisa dilakukan, jadi kalau misalnya ane ga pernah transaksi USDT, ane nangkepnya masih bisa jalan.

Ane mendapatkan pemahaman ini dari penjelasan bagian ini:

The _approve() function also excludes the full zero address and modifies the authorization value. The focus of this function is in the parameter calculation of the transferFrom call to approve, which uses_allowances[sender][_msgSender()].sub(amount, "BEP20: transfer amount exceeds allowance") , to subtract the number of existing authorization tokens from the transfer The remaining authorization amount is put into approve and re-authorized. The subtraction function sub() used here is OpenZeppelin's safemath library, and overflow will report an error revert; however, if the parameter amount of the whole process is zero, no detection mechanism can reject the transaction, which also leads to a large number of $0 transfers on the chain that can be sent normally, and the hacker only needs to pay a fee to reap a significant return.

Sepertinya metode scam ini cukup berhasil, banyak korban ane lihat di beberapa hari terakhir bikin thread sampai mengira ini bug di jaringan ETH/BSC. Mungkin perubahan di metode penolakan transaksi bisa membantu menghentikan model serangan ini, selain kewaspadaan user tentunya. Ref selain beberapa thread di atas:
https://bitcointalk.org/index.php?topic=5425022.0
https://ethereum.stackexchange.com/questions/140214/fake-0-token-transaction-on-bsc

[masulum]

Ane masih agak bingung dengan bagian ini. Dari hasil bacaan ane, yang ane pahami adalah fungsi" token ini dipanggil oleh si penyerang secara remote, tanpa ada input dari user. Pemanfaatan fungsi transferfrom ini juga digunakan untuk menghasilkan error supaya transfer token dengan nilai 0 usd ini bisa dilakukan, jadi kalau misalnya ane ga pernah transaksi USDT, ane nangkepnya masih bisa jalan.

Kalau dari pemahaman ane secara sekilas mengenai approval ini, ketika kita melakukan pengiriman perdana kita pasti butuh 2 approval.
1. Approval out token (pertama kali dari address)
2. Approval untuk konfirmasi transaksi
Nah, fungsi AuthorizeAprroval tersebut, sepertinya dimaksudkan pada bagian ini mas. Jadi, karena pengguna sudah sering melakukan transaksi out untuk token misal USDT, BUSD, artinya user sudah tidak butuh lagi approval ulang. Hal ini dimanfaatkan oleh scammer untuk melakukan hal tersebut memanfaatkan fungsi transferForm yang disebutkan sudah bisa menghandle fungsi AuthorizeApproval() & TransferTransfer().

CMIIW

[vv181]

Ane masih agak bingung dengan bagian ini. Dari hasil bacaan ane, yang ane pahami adalah fungsi" token ini dipanggil oleh si penyerang secara remote, tanpa ada input dari user. Pemanfaatan fungsi transferfrom ini juga digunakan untuk menghasilkan error supaya transfer token dengan nilai 0 usd ini bisa dilakukan, jadi kalau misalnya ane ga pernah transaksi USDT, ane nangkepnya masih bisa jalan.

Kalau dari pemahaman ane secara sekilas mengenai approval ini, ketika kita melakukan pengiriman perdana kita pasti butuh 2 approval.
1. Approval out token (pertama kali dari address)
2. Approval untuk konfirmasi transaksi
Nah, fungsi AuthorizeAprroval tersebut, sepertinya dimaksudkan pada bagian ini mas. Jadi, karena pengguna sudah sering melakukan transaksi out untuk token misal USDT, BUSD, artinya user sudah tidak butuh lagi approval ulang. Hal ini dimanfaatkan oleh scammer untuk melakukan hal tersebut memanfaatkan fungsi transferForm yang disebutkan sudah bisa menghandle fungsi AuthorizeApproval() & TransferTransfer().

Untuk fungsi dari events AuthorizeApproval() dan TransferTransfer() ini apakah ada referensi dokumentasinya? Ane cari di Google, OpenZeppelin, dan di kode token-nya langsung ga nemu.

Menurut sepemahaman ane, sebagaimana:

The _approve() function also excludes the full zero address and modifies the authorization value. The focus of this function is in the parameter calculation of the transferFrom call to approve, which uses _allowances[sender][_msgSender()].sub(amount, "BEP20: transfer amount exceeds allowance") , to subtract the number of existing authorization tokens from the transfer The remaining authorization amount is put into approve and re-authorized. The subtraction function sub() used here is OpenZeppelin's safemath library, and overflow will report an error revert; however, if the parameter amount of the whole process is zero, no detection mechanism can reject the transaction

* bold dari ane

Jadi, walaupun sebelumnya seorang user belum pernah berinteraksi dengan token ini, celah keamanan ini masih bisa tetap dijalankan. Dikarenakan, token approval yang mana mengakibatkan allowance, tidak akan berpengaruh apa-apa karena parameter yang diuji di fungsi ini bernilai 0.

Sedikit nambah penjelasan @joniboini, kalkulasi di parameter _allowances() yang mana terdapat dalam fungsi panggilan _approve() di fungsi transferFrom(), jika bernilai 0, bukannya jadi error, akan tetapi, hasil inilah yg mengakibatkan transaksi ini bisa berjalan.

Contoh langsung bisa lihat di https://bscscan.com/address/0x5b6cfe53229bdcaed3701c9731c51bed6e8a103d#tokentxns. Address tersebut belum pernah melakukan transaksi sama sekali, akan tetapi, metode scam-nya masih bisa dijalankan.

[masulum]

Untuk fungsi dari events AuthorizeApproval() dan TransferTransfer() ini apakah ada referensi dokumentasinya? Ane cari di Google, OpenZeppelin, dan di kode token-nya langsung ga nemu.

Makasih mas atas koreksinya, saya juga ga begitu paham fungsi pada smartcontract. Pada apa yang saya post diatas juga berdasarkan penjelasan mengenai fungsi tersebut. Mungkin juga itu adalah kesalahan ketik atau itu merujuk pada data yang ditandai ini

Source: https://mirror.xyz/x-explore.eth/cL3d_CyNujXq8XY7ueP4omNXx_IY1EG5Dz0FD0vJ90M
https://phalcon.blocksec.com/tx/bsc/0x825a3281e1897239c01797e590d3d62c1f9ab4c323bd8484c142541ac77ad73e

tapi, saya tidak paham betul dengan fungsi tersebut. Karena saya pikir fungsi tersebut ada, jadi saya menjelaskan pada post #6 juga melalui gambaran bagaimana seharusnya sistem approval tersebut berjalan.

Saya juga sudah melakukan pencarian setelah mendapatkan respon dari mas, dan saya juga tidak menemukan fungsi tersebut.
CMIIW

Sedikit nambah penjelasan @joniboini, kalkulasi di parameter _allowances() yang mana terdapat dalam fungsi panggilan _approve() di fungsi transferFrom(), jika bernilai 0, bukannya jadi error, akan tetapi, hasil inilah yg mengakibatkan transaksi ini bisa berjalan.

Sebentar mas, bukannya transaksi bernilai 0 ini memang ada sejak lama, dan memang tidak terjadi error. karena saya sering melakukan pengiriman 0 ke alamat sendiri ketika terjadi masalah pending transaksi. misalnya ini https://bitcointalk.org/index.php?topic=5184484.msg52451444#msg52451444

Lalu, apakah parameter yang mas sebutkan memang untuk membuat transaksi 0 tidak bisa dijalankan?

[vv181]

Sedikit nambah penjelasan @joniboini, kalkulasi di parameter _allowances() yang mana terdapat dalam fungsi panggilan _approve() di fungsi transferFrom(), jika bernilai 0, bukannya jadi error, akan tetapi, hasil inilah yg mengakibatkan transaksi ini bisa berjalan.

Sebentar mas, bukannya transaksi bernilai 0 ini memang ada sejak lama, dan memang tidak terjadi error. karena saya sering melakukan pengiriman 0 ke alamat sendiri ketika terjadi masalah pending transaksi. misalnya ini https://bitcointalk.org/index.php?topic=5184484.msg52451444#msg52451444

Lalu, apakah parameter yang mas sebutkan memang untuk membuat transaksi 0 tidak bisa dijalankan?

Mengenai itu, maksudnya saya itu koreksi sedikit pernyataan agan @joniboini.

Pemanfaatan fungsi transferfrom ini juga digunakan untuk menghasilkan error supaya transfer token dengan nilai 0 usd ini bisa dilakukan, jadi kalau misalnya ane ga pernah transaksi USDT, ane nangkepnya masih bisa jalan.

Lalu, apakah parameter yang mas sebutkan memang untuk membuat transaksi 0 tidak bisa dijalankan?

Justru sebaliknya.

Gambaran kalkulasi atas paramater (_allowances[sender][_msgSender()].sub(amount, "BEP20: transfer amount exceeds allowance")) atau a.sub(b, "message") sebagai berikut.

Note: "- the caller must have allowance for `sender`'s tokens of at least `amount`" (https://github.com/bnb-chain/bsc-genesis-contract/blob/8cfa94e657670d60ac1ff0563cddcf4664f77227/contracts/bep20_template/BEP20Token.template#L444-L445)

Smart contract BUSD/BUSD-T Stablecoin = A.
_msgSender() = caller/(siapa yang)pemanggil kontrak A. Yaitu 0x7cebeb6035b231a73cb5fb4119c2fbbc04ec6fd1, ini adalah alamat smart contract si scammer. Anggap sebagai X.
Sender ini adalah target address yang mau di-scam. Sender = 0x578a45295e2a91632ab8732b9e52901a34852467. Anggap sebagai Y.

Y ini belum pernah berinteraksi dengan X. Sehingga allowance terhadap X pada Y atas kontrak A adalah 0. Pada proses inilah yg bisa dirubah dengan cara yang agan maksud:

1. Approval out token (pertama kali dari address)

Pada proses transaksi ini yang digunakan saat agan mengatur berapa jumlah token yg boleh diakses suatu contract(allowance). Contoh: https://metamask.zendesk.com/hc/en-us/articles/6055177143579-How-to-customize-token-approvals-allowances-with-custom-spend-limit#h_01G3E1JE4CPVP1VH8PFS4FH25P.

Lalu, mengenai amount atau nominal transaksi = 0.

Jadi a.sub(b, "message") ini itu, allowance-nominal transaksi atau a-b. Kalau hasil negatif, berarti, keluar tuh error "BEP20: transfer amount exceeds allowance". Sesuai dengan transaksi sebenarnya yaitu hasilnya 0 - 0 = 0 dan juga pada fungsi lainnya tidak ada address 0, oleh karena itu, transaksi ini merupakan transaksi valid.

[mu_enrico]

Sedikit tanya nih agan-agan, ane jadi ikutan penasaran ama Address Poisoning di atas:
- Yang bisa transfer token 0 itu cuma kontrak BSC-USD saja kah? Ane belum pernah coba di transfer token 0 BUSD atau USDT (BEP20/TRC/dll).
- Yang pakai call fungsi the_transfer() sama approve() cuma ada di BSC-USD saja ya?

Kalau yang lain paling via phising aja kan pakai address yg mirip-mirip depan dan belakangnya? Dengan harapan salah copas dan dapat transferan.

[vv181]

- Yang bisa transfer token 0 itu cuma kontrak BSC-USD saja kah?
- Yang pakai call fungsi the_transfer() sama approve() cuma ada di BSC-USD saja ya?

Sepertinya kontrak yang mengikuti standar implementasi token ERC20, bisa dilakukan transfer 0 ini, gan. Lalu, fungsi transfer() dan approve() juga merupakan standarisasi ERC20, jadi token apapun yang mengacu pada standar ini, akan bisa terkena Address Poisoning.

Informasi mengenai kontrak mana saja yang kena beserta pada chain apa saja bisa lihat di infografik yang di sediakan dari artikel yang bahas address poisoining: https://dune.com/opang/first-and-last-address-construction

Pada chain BNB, ada token: BSC-USD, BUSD, ETH, USDC. Untuk di chain ETH: BUSD, DAI, USDC, USDT.

[MAAManda]

Sebenarnya ini bahas yang mana sih? "Approval Token Scam" atau "Pengiriman bernilai 0 (nol)" ? soalnya bahasan yang cukup panjang ini diawali dengan postingan om @len01 yang bahas tentang address poisoning, lalu kemudian tiba-tiba membahas kontrak, apakah pembahasan address poisoning sangat erat kaitannya kepada kontrak secara spesifik? summon om @masulum selaku OP.

[joniboini]

Sebenarnya ini bahas yang mana sih? "Approval Token Scam" atau "Pengiriman bernilai 0 (nol)" ? soalnya bahasan yang cukup panjang ini diawali dengan postingan om @len01 yang bahas tentang address poisoning, lalu kemudian tiba-tiba membahas kontrak, apakah pembahasan address poisoning sangat erat kaitannya kepada kontrak secara spesifik?

Kalau agan merujuk ke post OP, itu membahas dua jenis scam. Diskusi yang ada di bawahnya yang agan rujuk itu adalah diskusi mengenai address poisoning (pengiriman nol), yang mau tidak mau harus membahas juga pemahaman tentang smart contract khususnya mengenai allowance dst supaya kita bisa memahami lebih detail bagaimana serangan tersebut terjadi. Dengan kata lain, jenis scam kedua yang ada di post OP dan yang dipost agan len itu merujuk ke realitas yang sama. Pada diskusi yang berlangsung tidak ada pembahasan mengenai jenis scam "approval token" yang di list di post OP agan masulum.

CMIIW.

[MAAManda]

Kalau agan merujuk ke post OP, itu membahas dua jenis scam. Diskusi yang ada di bawahnya yang agan rujuk itu adalah diskusi mengenai address poisoning (pengiriman nol), yang mau tidak mau harus membahas juga pemahaman tentang smart contract khususnya mengenai allowance dst supaya kita bisa memahami lebih detail bagaimana serangan tersebut terjadi. Dengan kata lain, jenis scam kedua yang ada di post OP dan yang dipost agan len itu merujuk ke realitas yang sama. Pada diskusi yang berlangsung tidak ada pembahasan mengenai jenis scam "approval token" yang di list di post OP agan masulum.

Ohhh begitu toh, saya hanya bingung saja diawal, kenapa address poisoning malah kemudian membahas tentang kode perintah pada kontrak, padahal menurut saya pribadi, secara sederhana ya address poisoning itu meracuni sejarah transfer calon korban dengan harapan calon korban melakukan human error karena habit buruk orang-orang di ranah kripto yang hanya melihat/mengingat awal dan akhir dari sebuah address untuk keperluan transfer, seperti yang sudah dijelaskan pada OP. Buat yang belum tahu, saya buatin skenario-nya biar kita sama-sama lebih aware tentang hal ini.

Skenario Address Poisoning

1. Pelaku me-monitor transaksi pada blockchain, kemudian mereka mendapatkan calon target, kita ambil contoh address yang di provide om @masulum (0x2704664F03efBfF1E394aBBfD8a7b9f6CC039871) sebagai address yang sering di transfer oleh si calon korban.
2. Setelah mendapatkan target-nya, pelaku kemudian men-generate address yang sangat mirip dengan address yang sering di transfer oleh si calon korban menggunakan address generator (disini saya menggunakan VANITY-ETH).

Sumber Gambar: VANITY-ETH

3. Setelah berhasil men-generate address yang sangat mirip, kemudian pelaku mengirimkan token dengan nominal 0 (dari address yang sudah di generate), sebagai contohnya 0 $BUSD ke address calon korban, dan setelahnya mereka (pelaku) berharap agar calon korban melakukan human error.

Catatan: Perlu diketahui bahwa dengan men-generate address, kita sebagai user bisa membuat address secara spesifik, jadi tidak hanya depan dan belakang saja seperti yang om @masulum contohkan, even kita bisa membuat address yang bahkan hanya berbeda 1 angka/huruf ditengah address dari address aslinya, namun tentu itu akan membuat tingkat kesulitan generate akan semakin meningkat.

Contohnya:

0x2704664F03efBfF1E394aBBfD8a7b9f6CC039871
0x2704664F03efBfF1E394aaBfD8a7b9f6CC039871

Saran:
Para penjuday biasanya hanya diberikan 1 address saja untuk melakukan deposit, tentu, dengan keadaan yang seperti itu, artinya penjuday hanya dan terus mengingat address itu, jadi karena adanya address poisoning ini, mereka sangat beresiko tinggi menjadi seorang korban. Jadi saran saya buat orang-orang yang secara reguler mengirimkan dana ke address tertentu (misalnya ke exchange, situs juday), pastikan jangan ambil dari sejarah transaksi, tapi ambil/copy lah address tujuan itu dari situsnya secara langsung.
Oh iya, cara ini juga bisa digunakan untuk temen yang suka show off, jadi kalo kalian kesal sama temen kalian ya kerjain aja awkawkwak, tapi balikin lagi duitnya ntar (bukan saran, tidak untuk di praktikan).

[joniboini]

Ohhh begitu toh, saya hanya bingung saja diawal, kenapa address poisoning malah kemudian membahas tentang kode perintah pada kontrak, padahal menurut saya pribadi, secara sederhana ya address poisoning itu meracuni sejarah transfer calon korban

Diskusi tersebut hanya memperdalam bagaimana attacker bisa melakukan serangan tersebut, karena sebelum model serangan ini familiar kita jarang menemukan sebuah token yang bisa melakukan transaksi tanpa ada input dari user sama sekali. Karena dari segi transfer yang tidak diizinkan oleh user ini agak mirip dengan kasus smart contract scam di exchange" scam, makanya diskusi tersebut terjadi. Jadi, kalau dari yang ane pahami sih, semuanya kurang lebih sepakat dengan deskripsi model serangan address poisoning tersebut, hanya pengen tahu lebih dalam saja.

Perlu diketahui bahwa dengan men-generate address, kita sebagai user bisa membuat address secara spesifik, jadi tidak hanya depan dan belakang saja seperti yang om @masulum contohkan, even kita bisa membuat address yang bahkan hanya berbeda 1 angka/huruf ditengah address dari address aslinya, namun tentu itu akan membuat tingkat kesulitan generate akan semakin meningkat.

Beberapa user baik didalam atau diluar forum sempat teledor ketika mengecek address memang. Saran ane sih jangan kopas address terakhir dari history transaksi wallet agan meskipun address tersebut mirip. Ane ingat ada user yang menjadi korban karena dia pakai wallet Android yang tidak menampilkan alamat address sepenuhnya di riwayat transaksi, jadinya dia kopas saja ketika melihat awalan address tersebut sama. Dikopas saja dari menu wallet utama agan, atau kalau pakai explorer bisa lebih mudah karena biasanya address bar mengandung alamat yang agan kunjungi. Alternatif lain adalah menggunakan kontak kalau wallet agan mendukung fitur tersebut, bisa sekaligus melindungi dari malware yang merekam apa yang agan salin di clipboard.

[mu_enrico]

Sebenarnya ini bahas yang mana sih? "Approval Token Scam" atau "Pengiriman bernilai 0 (nol)" ? soalnya bahasan yang cukup panjang ini diawali dengan postingan om @len01 yang bahas tentang address poisoning, lalu kemudian tiba-tiba membahas kontrak, apakah pembahasan address poisoning sangat erat kaitannya kepada kontrak secara spesifik? summon om @masulum selaku OP.

Tadinya ane mengira address poisoning ya cuma seperti yang agan jelaskan di sini

Skenario Address Poisoning

Tetapi ada hal unik yang bikin heboh, begini ceritanya:
- Ada 3 address, 1. Ane (pengirim), 2. MAAM (penerima), 3. ROY (hacker)
- Ketika Ane mengirim 200 BUSD ke MAAM, ROY juga mengirim 0 BUSD ke MAAM menggunakan alamat yang mirip.
Kalau sampai di sini saja kelar ini kasus tidak perlu melibatkan smart contract, tertulis ada dua transaksi dari dua alamat (200 BUSD dari Ane + 0 BUSD dari ROY)
- Akan tetapi dalam waktu bersamaan (hash yang sama dengan 0 BUSD dari ROY ke MAAM) secara ajaib ane juga akan mengirim 0 BUSD ke ROY tanpa seizin ane. Nah inilah yang menjadi heboh... Bagaimana bisa ada 0 BUSD keluar dari alamat wallet ane?!

Di sinilah smart contract yang bermain yang dijelaskan pada link mirror.xyz tsb.
Hal ini membuat potensial korbannya ada dua, yaitu Ane dan MAAM, sedangkan kalau tidak ada outgoing tx/ga nongol di history ane, potensial korbannya hanya MAAM.
Adanya outgoing tx juga membuat success rate scam meningkat.

[masulum]

Dimention beberapa hari yang lalu sama mas @MAAManda tapi sudah dijelaskan oleh mas @joniboini dan @mu_enrico, jadi saya memilih untuk ngintip saja 

BTW, Address Poisoning ini masih terjadi, sepertinya belum ada solusi untuk menyelesaikan masalah ini kecuali fungsi transfer 0 ini dihapuskan. Jika pun dihapuskan, harus > 0, scammer mungkin masih bisa mengatasinya dengan pengiriman 0,xxx, tapi ini akan menjadi lebih mudah terdeteksi. saya rasa ini akan meningkatkan aware pengguna. Bener ga sih, ya ibaratnya kalau kita tidak merasa mengirim 0,xxx ke address b, maka transaksi tersebut adalah dari scammer.

Metamask sedang mencari strategi untuk meningkatkan kesadaran terhadap address palsu ini, semoga saja penyedia wallet lain juga bisa menemukan solusi agar tidak ada lagi yang menjadi korban serupa di masa yang akan datang. Karena ini bisa menjadi kasus panjang sih.

[dansus021]

ane yang sering lihat dust attack sama approval smart contract dan ini menurut ane penting banget kalau misalnya mau approve smart contract musti ngecek dulu dan harus sering sering check unrekt kalau ane pribadi https://bitcointalk.org/index.php?topic=5372831.0 thread ini menurut ane mungkin membantu

terus lagi ane mo share pengalaman jadi dulu sempet dikirimin token palsu tapi dia lewat smart contract binance charity address ane nggak begitu paham mungkin disini juga ada yang bisa jelasin https://bscscan.com/tx/0x6eea82339a5926c019d0dd067f0bcf0c573917558d07f5b05eff16c2fdd10164 jadi kayak dia ngerouting lewat tuh SC  

[masulum]

ane yang sering lihat dust attack sama approval smart contract dan ini menurut ane penting banget kalau misalnya mau approve smart contract musti ngecek dulu dan harus sering sering check unrekt kalau ane pribadi https://bitcointalk.org/index.php?topic=5372831.0 thread ini menurut ane mungkin membantu
-snip-

Unrekt.net tidak membantu apa pun mas untuk menghindari dust attack. Karena ini akan mengirimkan pada address yang melakukan transaksi. Ini seperti auto berdasarkan periode tertentu (hanya pengirim yang paham pastinya dan mekanismenya). Sedangkan Unrekt.net adalah layanan untuk memutus approval yang sudah kita lakukan. Ini mungkin bisa mencegah pengiriman 0, tapi saya masih belum yakin terkait hal ini. Jika memang efektif untuk menghentikan pengiriman 0, bisa dicoba dengan membayara sedikit fee demi keamanan aset. Karena saya lihat kembali pada wallet korban di post pertama, saya lihat ada jarak lebih dari 1 jam sebelum pengiriman terjadi ke wallet palsu.