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ế

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.

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.