Web3 Cảnh báo an ninh: Trò chơi mới của Mèo và Chuột trên Chuỗi, Bot Bắn Súng Nhắm Mục Tiêu vào Người Đóng Thuế

Nền tảng

Trong một bài viết trước đó của CertiK có tiêu đề "Tiết lộ một Kế hoạch Lừa đảo Quy mô Lớn Nhắm vào Các Robot Mới trên Chuỗi," đã tiết lộ một địa chỉ máy thu hoạch tự động 0xdf1a cho một kế hoạch lừa đảo quy mô lớn (được gọi là RugPull) đã hoàn thành hơn 200 lần RugPull chỉ trong khoảng hai tháng. Tuy nhiên, nhóm này không chỉ sử dụng một kỹ thuật RugPull.

Bài viết trước đó đã sử dụng token MUMI làm ví dụ để mô tả kỹ thuật RugPull của nhóm đứng sau địa chỉ đó: bằng cách trực tiếp sửa đổi số dư token của địa chỉ thu thuế thông qua một lỗ hổng mã, mà không thay đổi tổng nguồn cung token hoặc gửi một sự kiện Chuyển khoản, khiến cho người dùng xem etherscan không thể phát hiện hành vi đào token bí mật của nhóm dự án.

Bài viết hôm nay phân tích một kỹ thuật RugPull khác của nhóm sử dụng token "ZhongHua" làm ví dụ: che giấu chức năng chuyển giao có thể được sử dụng cho RugPull với logic chức năng thuế phức tạp. Tiếp theo, chúng ta sẽ phân tích chi tiết về một kỹ thuật RugPull khác của địa chỉ 0xdf1a thông qua trường hợp token "ZhongHua".

Sâu vào Vụ lừa đảo

Trong trường hợp này, nhóm dự án đã trao đổi tổng cộng 9,99 nghìn tỷ ZhongHua cho khoảng 5,884 WETH, làm cạn kiệt thanh khoản của hồ bơi. Để đào sâu vào vụ lừa đảo RugPull toàn diện, hãy xem xét lại các sự kiện từ đầu.

Triển khai Token

Lúc 1:40 sáng ngày 18 tháng 1 (giờ UTC, tương tự ở dưới), địa chỉ tấn công (😈0x74fc) triển khai một token ERC20 mang tên ZhongHua (🪙0x71d7) và đào trước 10 tỷ token để gửi cho địa chỉ tấn công (😈0x74fcfc).

Số lượng token đào trước khớp với số lượng được xác định trong mã nguồn hợp đồng.

Thêm Thanh khoản

Lúc 1:50 (10 phút sau khi tạo token), địa chỉ tấn công (😈0x74fc) cấp quyền cho Bộ định tuyến Uniswap V2 cho token ZhongHua để chuẩn bị thêm thanh khoản.

Một phút sau đó, địa chỉ tấn công (😈0x74fc) gọi hàm addLiquidityETH trong Bộ định tuyến để thêm thanh khoản tạo hồ bơi thanh khoản ZhongHua-WETH (🦄0x5c8b), thêm tất cả các token đào trước và 1,5 ETH vào hồ bơi thanh khoản, cuối cùng thu được khoảng 1,225 LP token.

Từ các bản ghi chuyển token trên, chúng ta có thể thấy rằng một chuyển giao là địa chỉ tấn công (😈0x74fc) gửi 0 token đến chính hợp đồng token ZhongHua.

Chuyển giao này không phải là chuyển giao thông thường để thêm thanh khoản. Bằng cách kiểm tra mã nguồn hợp đồng token, đã phát hiện rằng có một hàm _getAmount chịu trách nhiệm trừ tiền từ địa chỉ người gửi và tính phí sẽ được thu, sau đó gửi phí đến địa chỉ token, và kích hoạt sự kiện Chuyển khoản chỉ ra rằng địa chỉ token đã nhận được phí.

Hàm _getAmount sẽ kiểm tra xem người gửi của chuyển giao có phải là _owner không, và nếu đúng, nó sẽ đặt phí là 0. _owner được gán khi hợp đồng Ownable được triển khai bởi tham số đầu vào của hàm constructor.

Hợp đồng token ZhongHua kế thừa hợp đồng Ownable và gán msg.sender của người triển khai làm tham số đầu vào của hàm constructor của Ownable khi triển khai.

Do đó, địa chỉ tấn công (😈0x74fc) là _owner của hợp đồng token. Số 0 token

Trong quá trình thêm thanh khoản, việc chuyển giao trong hàm _getAmount được thực hiện vì hàm _getAmount được gọi trong các hàm transfer và transferFrom.

Khoá Thanh Khoản Vĩnh Viễn

Lúc 1:51 (trong vòng 1 phút sau khi tạo hồ bơi thanh khoản), địa chỉ của kẻ tấn công (😈0x74fc) đã trực tiếp chuyển gửi tất cả 1.225 token LP thu được từ việc thêm thanh khoản đến địa chỉ 0xdead để khoá vĩnh viễn các token LP.

Tương tự như trường hợp token MUMI, khi LP bị khoá, lý thuyết thì địa chỉ của kẻ tấn công (😈0x74fc) sẽ không còn khả năng thực hiện RugPull bằng cách rút thanh khoản. Trong vụ lừa đảo RugPull nhắm vào các robot mới do địa chỉ 0xdf1a dẫn đầu, bước này chủ yếu được sử dụng để đánh lừa các kịch bản chống gian lận của các robot mới.

Cho đến nay, từ góc nhìn của người dùng, tất cả token được đào trước đã được sử dụng để thêm vào hồ bơi thanh khoản, và không có tình huống bất thường nào xảy ra.

RugPull

Lúc 2:10 sáng (khoảng 30 phút sau khi tạo token ZhongHua), địa chỉ của kẻ tấn công 2 (👹0x5100) triển khai một hợp đồng tấn công (🔪0xc403) dành riêng cho RugPull.

Tương tự như trường hợp token MUMI, nhóm dự án không sử dụng địa chỉ tấn công đã triển khai hợp đồng token ZhongHua, và hợp đồng tấn công được sử dụng cho RugPull không phải là mã nguồn mở. Mục đích là tăng độ khó trong việc truy vết bởi nhân viên kỹ thuật, một đặc điểm phổ biến trong hầu hết các vụ lừa đảo RugPull.

Lúc 7:46 sáng (khoảng 6 giờ sau khi hợp đồng token được tạo), địa chỉ của kẻ tấn công 2 (👹0x5100) thực hiện RugPull.

Bằng cách gọi phương thức "swapExactETHForTokens" của hợp đồng tấn công (🔪0xc403), họ đã trao đổi khoảng 9.99 nghìn tỷ token ZhongHua cho khoảng 5.884 ETH và tiêu tốn hầu hết thanh khoản trong hồ bơi.

Vì hợp đồng tấn công (🔪0xc403) không phải là mã nguồn mở, chúng tôi đã giải mã bytecode của nó, và kết quả như sau:

https://app.dedaub.com/ethereum/address/0xc40343c5d0e9744a7dfd8eb7cd311e9cec49bd2e/decompiled

Chức năng chính của phương thức "swapExactETHForTokens" trong hợp đồng tấn công (🔪0xc403) là trao quyền chuyển giao tối đa của token ZhongHua cho UniswapV2 Router, sau đó trao đổi số lượng cụ thể "xt" token ZhongHua (do hợp đồng tấn công (🔪0xc403) sở hữu) cho ETH thông qua Router và gửi đến địa chỉ "rescue" được khai báo trong hợp đồng tấn công (🔪0xc403).

<img src="https://img.bitgetimg.com/multiLang/image/888f490a178</p> </div></div></div><p>Bạn có thể thấy rằng địa chỉ tương ứng với " _rescue" chính là người triển khai hợp đồng tấn công (🔪0xc403): địa chỉ của kẻ 2 (👹0x5100).< p>

Tham số đầu vào xt của giao dịch RugPull này là 999,000,000,000,000,000,000, tương ứng với 9.99 tỷ token ZhongHua (số thập phân của ZhongHua là 9).

Cuối cùng, bên dự án đã sử dụng 9.99 tỷ token ZhongHua để tiêu tốn WETH trong hồ bơi thanh khoản, hoàn tất RugPull.

Tương tự như trường hợp MUMI trong bài viết trước, chúng ta cần xác nhận nguồn gốc của token ZhongHua trong hợp đồng tấn công (🔪0xc403). Từ văn bản trước đó, chúng ta biết rằng tổng cung của token ZhongHua là 1 tỷ. Tuy nhiên, sau vụ RugPull, chúng ta phát hiện rằng tổng cung của token ZhongHua được truy vấn trong khối explorer vẫn là 1 tỷ, nhưng số lượng token được bán bởi hợp đồng tấn công (🔪0xc403) là 9,99 tỷ, tức là gấp 999 lần tổng cung ghi nhận trong hợp đồng. Những token này, vượt quá tổng cung, đã đến từ đâu?

Chúng tôi đã kiểm tra lịch sử sự kiện chuyển token ERC20 của hợp đồng và phát hiện rằng, tương tự như trường hợp RugPull của token MUMI, trong trường hợp token ZhongHua, hợp đồng tấn công (🔪0xc403) cũng không có bất kỳ sự kiện chuyển token ERC20 nào.

<img src="https://img.bitgetimg.com/multiLang/image/2d1e1f6fb5a36d86524073f15ec0955d1715406172432.png</p> Trong trường hợp MUMI, token của hợp đồng thuế được trực tiếp từ việc sửa đổi số dư trong hợp đồng token, cho phép hợp đồng thuế sở hữu trực tiếp các token vượt quá tổng cung. Vì hợp đồng token MUMI không tương ứng sửa đổi totalSupply của token khi sửa đổi số dư, cũng không kích hoạt sự kiện Transfer, nên chúng tôi không thể thấy được bản ghi chuyển token vào hợp đồng thuế trong trường hợp MUMI, như là những token được hợp đồng thuế sử dụng cho RugPull xuất hiện từ hư vô. Quay trở lại trường hợp ZhongHua này, các token ZhongHua trong hợp đồng tấn công (🔪0xc403) cũng dường như đã xuất hiện từ hư vô, vì vậy chúng tôi cũng tìm kiếm từ khóa " balance" trong hợp đồng token ZhongHua.

Kết quả cho thấy chỉ có ba sự sửa đổi biến số dư trong toàn bộ hợp đồng token, tương ứng trong các hàm "_getAmount", "_transferFrom", và "_transferBasic". Trong đó, "_getAmount" được sử dụng để xử lý logic thu phí chuyển giao, trong khi "_transferFrom" và "_transferBasic" được sử dụng để xử lý logic chuyển giao, mà không có bất kỳ câu lệnh nào sửa đổi trực tiếp số dư một cách rõ ràng như trong trường hợp token MUMI được hiển thị trong hình dưới đây.

Quan trọng hơn, trong hợp đồng token ZhongHua, cho dù trong các hàm "_getAmount", "_transferFrom", hoặc "_transferBasic", sau khi sửa đổi số dư, chúng đều kích hoạt đúng sự kiện Transfer. Điều này xung đột với tình huống mà chúng tôi không thể tìm thấy sự kiện Transfer chuyển token liên quan đến hợp đồng tấn công (🔪0xc403) khi truy vấn các sự kiện Transfer. Có thể có khả năng, khác với trường hợp MUMI, lần này các token trong hợp đồng tấn công (🔪0xc403) thực sự xuất hiện từ hư vô?

Phương pháp Tiết lộ

Tokens trong Hợp Đồng Tấn Công Đến Từ Đâu

Trong quá trình phân tích vụ việc, khi chúng tôi phát hiện rằng mỗi sửa đổi số dư trong hợp đồng ZhongHua đều kích hoạt đúng sự kiện Transfer, nhưng vẫn không thể tìm thấy bất kỳ bản ghi hoặc sự kiện Transfer nào liên quan đến việc chuyển token đến hợp đồng tấn công (🔪0xc403), chúng tôi cần phải tìm một phương pháp phân tích mới. Chúng tôi đã tìm kiếm qua một lượng lớn các bản ghi chuyển giao và thậm chí xem xét hàm "performZhongSwap" trong hợp đồng như một điểm bứt phá. Hàm này chịu trách nhiệm bán các token trong hợp đồng token, và trong nhiều trường hợp RugPull khác mà chúng tôi phân tích, có nhiều trường hợp mà các hàm như vậy phục vụ như cửa sau RugPull. Mặc dù kiểm tra các hàm khác, chúng tôi vẫn không tìm thấy gì. Vì vậy, chúng tôi bắt đầu tập trung vào chính hàm "transfer" chức năng. Bất kể kẻ tấn công thực hiện RugPull như thế nào, logic thực thi của hàm "transfer" phải chứa thông tin quan trọng nhất.

<str

Chuyển giao chết người </str

Hàm "transfer" trong hợp đồng token trực tiếp gọi hàm "_transferFrom".

Có vẻ như hàm "transfer" thực hiện các hoạt động chuyển giao token, và sau khi chuyển giao hoàn tất, nó kích hoạt sự kiện Transfer.

Tuy nhiên, trước khi thực hiện chuyển giao token, hàm "transfer" trước tiên sử dụng hàm "_isNotTax" để kiểm tra xem người gửi của chuyển giao có phải là địa chỉ được miễn thuế không: nếu không phải, nó sử dụng hàm "_getAmount" để thu thuế; nếu phải, không thu thuế, và token được gửi trực tiếp đến người nhận. Và đây là nơi mà vấn đề nằm.

Như đã đề cập trước đó, trong việc thực thi "_getAmount", hợp đồng token xác minh số dư của người gửi, trừ số tiền từ người gửi, sau đó gửi phí cho hợp đồng token.

Vấn đề là "_getAmount" chỉ được gọi khi người gửi không phải là địa chỉ được miễn thuế. Khi người gửi là địa chỉ được miễn thuế, số dư của người nhận được tăng trực tiếp bằng số tiền.

Tại điểm này, vấn đề trở nên rất rõ ràng: khi một địa chỉ được miễn thuế hành động như người gửi cho một chuyển giao, hợp đồng token không xác minh xem số dư của người gửi có đủ không, hoặc thậm chí không trừ số tiền từ số dư của người gửi. Điều này có nghĩa là miễn là hợp đồng token xác định một địa chỉ là được miễn thuế, nó có thể gửi bất kỳ số lượng token nào đến bất kỳ địa chỉ nào. Đây là lý do tại sao hợp đồng tấn công (🔪0xc403) có thể chuyển ra token lên đến 999 lần tổng cung.

Sau khi kiểm tra, được phát hiện rằng hợp đồng token chỉ đặt _taxReceipt là một địa chỉ được miễn thuế trong hàm khởi tạo, và _taxReceipt tương ứng với địa chỉ của hợp đồng tấn công (🔪0xc403).

Điều này xác nhận phương pháp RugPull cho token ZhongHua: Kẻ tấn công đã sử dụng logic cụ thể để bypass kiểm tra số dư của các địa chỉ đặc quyền, cho phép địa chỉ đặc quyền chuyển token ra khỏi không khí, hoàn tất RugPull.

Làm thế nào để Lợi nhuận

Sử dụng lỗ hổng trên, địa chỉ kẻ tấn công 2 (👹0x5100) trực tiếp gọi hợp đồng tấn công với đặc quyền (🔪0xc403) để thực thi "swapExactETHForTokens" và hoàn tất RugPull. Trong hàm "swapExactETHForTokens", hợp đồng tấn công (🔪0xc403) cấp quyền chuyển token cho Uniswap V2 Router, sau đó trực tiếp gọi hàm trao đổi token của Router, trao đổi 9,99 tỷ token ZhongHua cho 5,88 ETH từ hồ bơi.

Ngoài giao dịch RugPull được đề cập ở trên, nhóm dự án cũng bán token 11 lần thông qua hợp đồng tấn công (🔪0xc403), tích lũy 9,64 ETH. Bao gồm giao dịch RugPull cuối cùng, tổng cộng thu được 15,52 ETH. Chi phí chỉ là 1,5 ETH để thêm thanh khoản, một số lượng nhỏ phí cho việc triển khai hợp đồng, và một số lượng nhỏ ETH tiêu cho việc kích thích giao dịch robot mới và các sàn giao dịch hoạt động.

Tại một thời điểm, nhóm dự án thậm chí đã sử dụng các địa chỉ EOA khác nhau để gọi hợp đồng tấn công (🔪0xc403) để bán token, làm cho nó trở nên như là các người gửi khác nhau đang bán token để che giấu ý định rút tiền liên tục của họ.

Tóm tắt

Phản ánh về toàn bộ trường hợp RugPull của token Zh

Token ongHua, phương pháp này khá đơn giản, chỉ cần hủy kiểm tra số dư token của các địa chỉ đặc quyền. Tuy nhiên, tại sao không mượt mà khi phân tích trường hợp này? Có thể có hai lý do chính:

1. Quan điểm khác nhau về bảo vệ an ninh và tấn công. Đối với các chuyên gia an ninh, việc kiểm tra số dư trong mã là biện pháp an ninh cơ bản nhất cần phải hoàn thành. Do đó, hầu hết các chuyên gia an ninh tự động giả định rằng chức năng "chuyển" sẽ tự động xác minh số dư người dùng, làm giảm sự cảnh giác của họ đối với các lỗ hổng như vậy (hoặc tin rằng các lỗ hổng như vậy quá cơ bản để kẻ tấn công khai thác).

Tuy nhiên, từ quan điểm của kẻ tấn công, phương pháp tấn công hiệu quả nhất thường là đơn giản nhất: không xác minh số dư như một kỹ thuật RugPull trực tiếp và dễ bị bỏ qua, không có lý do gì để không sử dụng nó. Trên thực tế, ít nhất từ việc đặc điểm hóa trường hợp, dấu vết mà phương pháp RugPull để lại trong trường hợp token ZhongHua là tối thiểu, khiến việc truy vết khó khăn hơn nhiều so với các loại RugPull khác, cuối cùng đòi hỏi kiểm tra mã thủ công để xác định lỗ hổng.

2. Nhóm dự án chủ động giấu mã lỗ hổng mà các địa chỉ đặc quyền không cần phải xác minh số dư. Nhóm dự án thậm chí đã thực hiện một logic tính toán chuyển giao thuế hoàn chỉnh cho các địa chỉ không đặc quyền, cũng như logic rút và tái đầu tư token, khiến cho logic chuyển giao phức tạp của token trở nên hợp lý. Khi các địa chỉ thông thường thực hiện chuyển giao, không thể phân biệt được hành vi bình thường, và nếu không xem xét mã cẩn thận, không thể tìm thấy dấu hiệu.

So sánh các phương pháp RugPull của nhóm cho token MUMI và token ZhongHua, cả hai đều sử dụng các phương pháp tương đối che giấu để cho phép các địa chỉ đặc quyền kiểm soát một lượng lớn token.

Trong trường hợp RugPull của token MUMI, nhóm dự án trực tiếp sửa đổi số dư mà không thay đổi totalSupply hoặc kích hoạt sự kiện Transfer, khiến người dùng không nhận ra rằng các địa chỉ đặc quyền đã có một lượng lớn token.

Trong trường hợp của token ZhongHua, điều đó còn tinh tế hơn, bằng cách không xác minh số dư của các địa chỉ đặc quyền trực tiếp, khiến việc phát hiện thông qua bất kỳ phương tiện nào khác ngoài việc xem mã nguồn rằng các địa chỉ đặc quyền có số lượng token không giới hạn (một truy vấn balanceOf cho địa chỉ đặc quyền sẽ hiển thị số dư là 0, nhưng vẫn có thể chuyển giao một lượng token vô hạn).

Trường hợp RugPull của token ZhongHua phản ánh các vấn đề an ninh tiềm ẩn trong các tiêu chuẩn token. Tiêu chuẩn token ERC20 chỉ có thể hạn chế những người đúng đắn và không thể ngăn chặn những kẻ xấu. Kẻ tấn công thường giấu cửa sau không thể nhận thấy trong khi triển khai logic kinh doanh tuân thủ tiêu chuẩn. Bằng cách chuẩn hóa hành vi token, mặc dù linh hoạt bị giảm, khả năng có cửa sau ẩn được tránh, cung cấp nhiều biện pháp bảo mật hơn.