Chi tiết kỹ thuật: Trò chơi vòng trong đặt cược trên chuỗi, giải mã thủ đoạn Rug Pull quy mô lớn
Tuyển chọn TechFlowTuyển chọn TechFlow
Chi tiết kỹ thuật: Trò chơi vòng trong đặt cược trên chuỗi, giải mã thủ đoạn Rug Pull quy mô lớn
Bài viết này sẽ lấy một trong các trường hợp làm ví dụ, phân tích chi tiết về vụ lừa đảo rút tiền này.
Chuyên sâu báo cáo Web3Tác giả: CertiK
Gần đây, nhóm chuyên gia an ninh CertiK đã phát hiện liên tiếp nhiều vụ lừa đảo "rút lui" (exit scam) với cùng một thủ pháp, còn được gọi phổ biến là Rug Pull.
Sau khi đào sâu điều tra, chúng tôi phát hiện ra rằng nhiều sự kiện sử dụng cùng một phương thức đều truy ngược về một nhóm tội phạm duy nhất, liên kết đến hơn 200 token bị thực hiện hành vi rút lui. Điều này cho thấy có thể chúng tôi đã phát hiện ra một đội hacker quy mô lớn đang tự động hóa việc thu hoạch tài sản thông qua các vụ lừa đảo kiểu "Rug Pull".
Trong những vụ lừa đảo này, kẻ tấn công sẽ tạo một token ERC20 mới và dùng lượng token khai thác trước lúc khởi tạo cộng thêm một lượng WETH nhất định để tạo nhóm thanh khoản Uniswap V2.
Khi các bot săn coin mới trên chuỗi hoặc người dùng mua token mới trong nhóm thanh khoản này đủ số lần nhất định, kẻ tấn công sẽ dùng lượng token được tạo ra từ hư không để rút sạch lượng WETH trong nhóm thanh khoản.
Do lượng token do kẻ tấn công tạo ra không xuất hiện trong tổng cung (totalSupply), cũng không kích hoạt sự kiện Transfer, nên sẽ không hiển thị trên Etherscan, khiến bên ngoài rất khó nhận biết.
Kẻ tấn công không chỉ tính toán kỹ yếu tố ngụy trang mà còn dựng lên một cục diện phức tạp nhằm đánh lừa những người dùng có kiến thức kỹ thuật cơ bản, biết xem Etherscan, bằng cách che giấu mục đích thật sự của họ đằng sau một lỗi nhỏ…
Đi sâu vào vụ lừa đảo
Chúng ta hãy lấy một ví dụ cụ thể để phân tích chi tiết vụ Rug Pull này.
Thực tế, điều mà chúng tôi phát hiện là giao dịch mà kẻ tấn công dùng lượng lớn token (được mint bí mật) rút sạch nhóm thanh khoản và thu lợi nhuận. Trong giao dịch này, bên phát hành đã dùng 416.483.104.164.831 (khoảng 416 nghìn tỷ) token MUMI để đổi được khoảng 9,736 WETH, làm cạn kiệt hoàn toàn thanh khoản trong nhóm.
Tuy nhiên, giao dịch này chỉ là vòng cuối cùng của toàn bộ âm mưu. Để hiểu rõ toàn bộ kế hoạch, chúng ta cần truy ngược lại các bước ban đầu.
Triển khai token
Vào lúc 7 giờ 52 phút sáng ngày 6 tháng 3 (giờ UTC, các thời điểm sau đây cũng theo múi giờ này), địa chỉ tấn công (0x8AF8) đã triển khai token ERC20 tên MUMI (tên đầy đủ là MultiMixer AI, địa chỉ 0x4894), đồng thời khai thác trước 420.690.000 (khoảng 420 triệu) token và phân bổ toàn bộ cho chính người triển khai hợp đồng.
Số lượng token khai thác trước khớp với mã nguồn hợp đồng.
Thêm thanh khoản
Lúc 8 giờ đúng (8 phút sau khi tạo token), địa chỉ tấn công (0x8AF8) bắt đầu thêm thanh khoản.
Địa chỉ tấn công (0x8AF8) gọi hàm openTrading trong hợp đồng token, thông qua uniswap v2 factory tạo nhóm thanh khoản MUMI-WETH, đưa toàn bộ token đã khai thác trước và 3 ETH vào nhóm thanh khoản, cuối cùng nhận được khoảng 1,036 token LP.
Từ chi tiết giao dịch có thể thấy, trong tổng số 420.690.000 (khoảng 420 triệu) token dùng để thêm thanh khoản, có 63.103.500 (khoảng 63 triệu) token lại được gửi trở về hợp đồng token (địa chỉ 0x4894). Khi kiểm tra mã nguồn hợp đồng, ta thấy rằng hợp đồng token sẽ thu một phần phí giao dịch cho mỗi lần chuyển tiền, và địa chỉ thu phí này chính là bản thân hợp đồng token (thực hiện cụ thể trong hàm '_transfer').
Điều kỳ lạ là, mặc dù hợp đồng đã thiết lập sẵn địa chỉ thuế 0x7ffb (địa chỉ thu phí giao dịch), nhưng cuối cùng phí lại được gửi về chính hợp đồng token.
Do đó, số lượng token MUMI thực tế được thêm vào nhóm thanh khoản là 357.586.500 (khoảng 357 triệu), sau khi đã trừ đi phí, chứ không phải 420.690.000 (khoảng 420 triệu).
Khóa thanh khoản
Vào lúc 8 giờ 1 phút (1 phút sau khi tạo nhóm thanh khoản), địa chỉ tấn công (0x8AF8) đã khóa toàn bộ 1,036 token LP nhận được từ việc thêm thanh khoản.
Sau khi token LP bị khóa, về mặt lý thuyết, tất cả token MUMI mà địa chỉ tấn công (0x8AF8) sở hữu đã bị khóa trong nhóm thanh khoản (trừ phần làm phí), do đó địa chỉ này không còn khả năng rút thanh khoản để thực hiện Rug Pull.
Để khiến người dùng yên tâm mua token mới ra mắt, nhiều dự án thường khóa LP, như một lời cam kết: "Tôi sẽ không chạy đâu, mọi người cứ yên tâm mua!". Nhưng liệu sự thật có đúng như vậy? Rõ ràng là không, trường hợp này là một minh chứng điển hình, hãy cùng phân tích tiếp.
Rug Pull
Vào lúc 8 giờ 10 phút, xuất hiện một địa chỉ tấn công thứ hai (0x9DF4), người này đã triển khai địa chỉ thuế 0x7ffb – địa chỉ đã được khai báo trong hợp đồng token.
Có ba điểm đáng chú ý ở đây:
1. Địa chỉ triển khai địa chỉ thuế và địa chỉ triển khai token không giống nhau, điều này có thể cho thấy nhóm phát hành cố tình giảm thiểu mối liên hệ giữa các thao tác để tăng độ khó trong việc truy vết.
2. Hợp đồng địa chỉ thuế không mở mã nguồn, nghĩa là có thể chứa các thao tác mà họ không muốn tiết lộ.
3. Hợp đồng thuế được triển khai muộn hơn hợp đồng token, nhưng địa chỉ thuế đã được ghi cứng trong hợp đồng token. Điều này có nghĩa là nhóm phát hành có thể dự đoán trước địa chỉ của hợp đồng thuế. Vì lệnh CREATE sẽ tạo địa chỉ hợp đồng xác định nếu biết trước địa chỉ người triển khai và nonce, nên nhóm phát hành đã mô phỏng trước để tính toán ra địa chỉ hợp đồng.
Thực tế, nhiều vụ Rug Pull xảy ra thông qua địa chỉ thuế, và đặc điểm triển khai của địa chỉ thuế phù hợp với hai điểm nêu trên.
Vào lúc 11 giờ sáng (3 giờ sau khi tạo token), địa chỉ tấn công thứ hai (0x9DF4) thực hiện Rug Pull. Anh ta gọi phương thức 'swapExactETHForTokens' trong hợp đồng thuế (0x77fb), dùng 416.483.104.164.831 (khoảng 416 nghìn tỷ) token MUMI trong địa chỉ thuế để đổi được khoảng 9,736 ETH, làm cạn kiệt toàn bộ thanh khoản trong nhóm.
Do hợp đồng thuế (0x77fb) không mở mã nguồn, chúng tôi đã tiến hành phản biên dịch mã bytecode, kết quả như sau:
https://app.dedaub.com/decompile?md5=01e2888c7691219bb7ea8c6b6befe11c
Sau khi xem xét mã nguồn phản biên dịch của hàm 'swapExactETHForTokens' trong hợp đồng thuế (0x77fb), chúng tôi phát hiện chức năng chính của hàm này thực chất là thông qua router uniswapV2, chuyển đổi một lượng token MUMI ('xt' - do người gọi chỉ định) thuộc sở hữu của hợp đồng thuế (0x77fb) thành ETH, rồi gửi đến địa chỉ '_manualSwap' đã được khai báo trong hợp đồng thuế.
Địa chỉ _manualSwap nằm tại vị trí storage 0x0. Sử dụng lệnh getStorageAt của json-rpc để truy vấn, ta thấy địa chỉ tương ứng với _manualSwap chính là người triển khai hợp đồng thuế (0x77fb): kẻ tấn công thứ hai (0x9DF4).
Tham số đầu vào xt của giao dịch Rug Pull này là 420.690.000.000.000.000.000.000, tương ứng với 420.690.000.000.000 (khoảng 420 nghìn tỷ) token MUMI (token MUMI có decimal là 9).
Nói cách khác, cuối cùng nhóm phát hành đã dùng 420.690.000.000.000 (khoảng 420 nghìn tỷ) token MUMI để rút sạch WETH trong nhóm thanh khoản, hoàn thành toàn bộ âm mưu Rug Pull.
Tuy nhiên, có một câu hỏi cực kỳ quan trọng: Làm sao mà hợp đồng thuế (0x77fb) lại có được nhiều token MUMI đến vậy?
Từ phần trước, ta biết rằng tổng cung token MUMI khi triển khai hợp đồng là 420.690.000 (khoảng 420 triệu). Sau khi vụ Rug Pull kết thúc, khi truy vấn tổng cung trong hợp đồng token MUMI, ta vẫn thấy con số là 420.690.000 (trong hình dưới hiển thị là 420.690.000.000.000.000, cần trừ đi số 0 tương ứng với decimal, decimal là 9). Số lượng token khổng lồ (420.690.000.000.000, khoảng 420 nghìn tỷ) trong hợp đồng thuế (0x77fb) dường như xuất hiện từ hư không. Cần lưu ý rằng, như đã nói ở trên, 0x77fb với tư cách là địa chỉ thuế thậm chí không nhận phí từ các giao dịch chuyển token MUMI – phí đã được gửi về chính hợp đồng token.
Tiết lộ thủ đoạn
Token từ đâu mà có ở hợp đồng thuế?
Để tìm hiểu nguồn gốc token của hợp đồng thuế (0x7ffb), chúng tôi đã xem lịch sử sự kiện chuyển nhượng ERC20 của nó.
Kết quả cho thấy trong tổng số 6 sự kiện chuyển nhượng liên quan đến 0x77fb, chỉ có các sự kiện chuyển ra khỏi hợp đồng thuế (0x7ffb), mà không hề có bất kỳ sự kiện nào ghi nhận việc token MUMI được gửi vào. Nhìn sơ qua, token trong hợp đồng thuế (0x7ffb) dường như thực sự xuất hiện từ hư không.
Do đó, lượng lớn token MUMI xuất hiện từ hư không trong địa chỉ hợp đồng thuế (0x7ffb) có hai đặc điểm:
1. Không ảnh hưởng đến totalSupply của hợp đồng MUMI
2. Việc tăng số dư token không kích hoạt sự kiện Transfer
Như vậy, hướng suy nghĩ rất rõ ràng: chắc chắn phải có cửa hậu trong hợp đồng token MUMI, cửa hậu này trực tiếp sửa biến balance, đồng thời không cập nhật totalSupply và không kích hoạt sự kiện Transfer.
Nói cách khác, đây là một triển khai ERC20 không chuẩn, hoặc nói đúng hơn là ác ý, khiến người dùng không thể nhận biết được việc nhóm phát hành đang bí mật mint token thông qua sự thay đổi totalSupply hay các sự kiện.
Tiếp theo, để kiểm chứng giả thuyết trên, chúng tôi tìm kiếm trực tiếp từ khóa 'balance' trong mã nguồn hợp đồng MUMI.
Chúng tôi phát hiện một hàm private tên là 'swapTokensForEth', nhận tham số tokenAmount kiểu uint256. Tại dòng thứ 5 của hàm này, nhóm phát hành trực tiếp thay đổi số dư MUMI của _taxWallet (tức là hợp đồng thuế 0x7ffb) thành tokenAmount * 10**_decimals, tức là gấp 1.000.000.000 (khoảng 1 tỷ) lần tokenAmount, sau đó dùng lượng tokenAmount này để đổi lấy ETH từ nhóm thanh khoản và giữ ETH trong hợp đồng token (0x4894).
Tiếp tục tìm kiếm từ khóa 'swapTokenForEth'.
Hàm 'swapTokenForEth' được gọi trong hàm '_transfer'. Khi xem kỹ điều kiện gọi, ta thấy:
1. Khi địa chỉ nhận 'to' là nhóm thanh khoản MUMI-WETH.
2. Khi có địa chỉ khác mua token MUMI trong nhóm thanh khoản vượt quá_preventSwapBefore (5 lần), hàm 'swapTokenForEth' mới được gọi.
3. Tham số tokenAmount được truyền vào là giá trị nhỏ hơn giữa số dư token MUMI hiện có tại địa chỉ token và_maxTaxSwap.
Nói cách khác, khi hợp đồng phát hiện người dùng đã dùng WETH đổi lấy token MUMI trong nhóm vượt quá 5 lần, nó sẽ bí mật mint một lượng lớn token cho địa chỉ thuế, đồng thời đổi một phần token lấy ETH và lưu trữ trong hợp đồng token.
Một mặt, nhóm phát hành biểu hiện việc thu thuế và định kỳ tự động đổi một lượng nhỏ ETH vào hợp đồng – điều này để người dùng nhìn thấy, tạo cảm giác rằng đây là nguồn lợi nhuận của dự án.
Mặt khác, điều họ thực sự làm là khi số lần giao dịch đạt 5 lần, trực tiếp sửa số dư tài khoản để rút sạch toàn bộ nhóm thanh khoản.
Cách thức thu lợi
Sau khi thực hiện xong hàm 'swapTokenForEth', hàm '_transfer' còn thực hiện sendETHToFee để gửi lượng ETH thu được từ phí vào hợp đồng thuế (0x77fb).
Lượng ETH trong hợp đồng thuế (0x77fb) có thể được rút ra thông qua hàm 'rescue' được triển khai trong hợp đồng.
Bây giờ hãy quay lại xem bản ghi đổi thưởng trong giao dịch lợi nhuận cuối cùng của toàn bộ vụ Rug Pull.
Trong giao dịch lợi nhuận này có hai lần đổi: lần đầu là 4.164.831 (khoảng 4,16 triệu) token MUMI đổi lấy 0,349 ETH; lần hai là 416.483.100.000.000 (khoảng 416 nghìn tỷ) token MUMI đổi lấy 9,368 ETH. Lần đổi thứ hai chính là giao dịch khởi tạo bên trong hàm 'swapExactETHForTokens' của hợp đồng thuế (0x7ffb). Lý do số lượng không khớp với tham số đầu vào 420.690.000.000.000 (khoảng 420 nghìn tỷ) là vì một phần token đã được gửi làm phí đến hợp đồng token (0x4894), như hình dưới:
Còn lần đổi đầu tiên tương ứng với việc khi token được gửi từ hợp đồng thuế (0x7ffb) đến hợp đồng router, điều kiện kích hoạt hàm cửa hậu trong hợp đồng token được thỏa mãn, dẫn đến việc gọi hàm 'swapTokensForEth', không phải thao tác chính.
Con dao lớn phía sau
Từ nội dung trên có thể thấy, từ khi triển khai token MUMI, tạo nhóm thanh khoản đến thực hiện Rug Pull, toàn bộ chu kỳ lừa đảo chỉ mất khoảng 3 giờ, nhưng đã thu được 9,7 ETH với chi phí chưa tới 6,5 ETH (3 ETH dùng để thêm thanh khoản, 3 ETH dùng để đổi lấy token MUMI nhằm dụ dỗ, chưa tới 0,5 ETH dùng để triển khai hợp đồng và thực hiện giao dịch), lợi nhuận vượt quá 50%.
Có 5 giao dịch mà kẻ tấn công dùng ETH đổi lấy MUMI, nhưng chưa được đề cập ở phần trước, thông tin như sau:
-
https://etherscan.io/tx/0x62a59ba219e9b2b6ac14a1c35cb99a5683538379235a68b3a607182d7c814817
-
https://etherscan.io/tx/0x0c9af78f983aba6fef85bf2ecccd6cd68a5a5d4e5ef3a4b1e94fb10898fa597e
-
https://etherscan.io/tx/0xc0a048e993409d0d68450db6ff3fdc1f13474314c49b734bac3f1b3e0ef39525
-
https://etherscan.io/tx/0x9874c19cedafec351939a570ef392140c46a7f7da89b8d125cabc14dc54e7306
-
https://etherscan.io/tx/0x9ee3928dc782e54eb99f907fcdddc9fe6232b969a080bc79caa53ca143736f75
Sau khi phân tích các địa chỉ EOA thực hiện thao tác trong nhóm thanh khoản, chúng tôi phát hiện phần lớn các địa chỉ này là các "bot săn coin mới" trên chuỗi. Kết hợp với đặc điểm nhanh tiến nhanh thoái của âm mưu này, chúng tôi có cơ sở để tin rằng đối tượng bị nhắm đến chính là các bot, script săn coin mới rất năng động trên chuỗi.
Do đó, dù là thiết kế hợp đồng có vẻ không cần thiết nhưng phức tạp, quy trình triển khai hợp đồng, khóa thanh khoản, hay hành vi đáng ngờ của các địa chỉ liên quan đến kẻ tấn công chủ động dùng ETH đổi lấy token MUMI, đều có thể được hiểu là những lớp ngụy trang nhằm đánh lừa chương trình chống gian lận của các bot săn coin mới trên chuỗi.
Sau khi truy vết dòng tiền, chúng tôi phát hiện toàn bộ lợi nhuận thu được từ vụ tấn công cuối cùng đều được địa chỉ tấn công thứ hai (0x9dF4) gửi đến một địa chỉ tích tụ vốn (0xDF1a).
Thực tế, nhiều vụ Rug Pull gần đây mà chúng tôi phát hiện đều có nguồn vốn ban đầu và đích đến cuối cùng trỏ về địa chỉ này. Do đó, chúng tôi đã tiến hành phân tích và thống kê sơ bộ các giao dịch của địa chỉ này.
Cuối cùng phát hiện địa chỉ này bắt đầu hoạt động từ khoảng 2 tháng trước, đến nay đã thực hiện hơn 7.000 giao dịch, và đã tương tác với hơn 200 token.
Chúng tôi đã phân tích khoảng 40 giao dịch token, và thấy rằng hầu như tất cả các token này, trong nhóm thanh khoản cuối cùng đều có một giao dịch đổi với số lượng đầu vào vượt xa tổng cung token, làm cạn kiệt ETH trong nhóm, và chu kỳ Rug Pull đều rất ngắn.
Một số giao dịch triển khai token (ví dụ: "Ming Yan Zhong Hua") như sau:
https://etherscan.io/tx/0x324d7c133f079a2318c892ee49a2bcf1cbe9b20a2f5a1f36948641a902a83e17
https://etherscan.io/tx/0x0ca861513dc68eaef3017e7118e7538d999f9b4a53e1b477f1f1ce07d982dc3f
Do đó, chúng tôi có thể khẳng định địa chỉ này thực chất là một cỗ máy "Rug Pull" tự động quy mô lớn, chuyên săn các bot săn coin mới trên chuỗi.
Hiện tại địa chỉ này vẫn đang hoạt động.
Lời kết
Nếu một token khi được mint mà không cập nhật totalSupply tương ứng, cũng không kích hoạt sự kiện Transfer, thì chúng ta sẽ rất khó nhận biết việc nhóm phát hành có đang bí mật mint token hay không. Điều này càng làm trầm trọng thêm thực trạng "độ an toàn của token hoàn toàn phụ thuộc vào sự tự giác của nhóm phát hành".
Do đó, chúng ta có thể cần xem xét cải tiến cơ chế token hiện tại hoặc giới thiệu một giải pháp kiểm tra hiệu quả về tổng cung token, nhằm đảm bảo tính công khai, minh bạch trong việc thay đổi số lượng token. Hiện tại, chỉ dựa vào event để bắt trạng thái token là chưa đủ.
Hơn nữa, chúng ta cần cảnh tỉnh: dù ý thức phòng tránh lừa đảo của mọi người đang được nâng cao, nhưng các thủ đoạn chống phòng tránh lừa đảo của kẻ tấn công cũng ngày càng tinh vi. Đây là một cuộc đấu tranh không ngừng nghỉ, chúng ta cần tiếp tục học hỏi và suy ngẫm không ngừng để có thể tự bảo vệ mình trong cuộc chơi này.
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
CertiK
