Nguồn gốc: Fairyproof
Giao dịch bằng robot Sandwich là một hành vi giao dịch rất phổ biến trong các giao dịch hàng ngày trong hệ sinh thái blockchain. Giao dịch thông qua robot không chỉ có thể cải thiện đáng kể hiệu quả giao dịch mà còn khám phá các cơ hội chênh lệch giá trong giao dịch càng nhanh càng tốt.
Kinh doanh robot an toàn chắc chắn có thể đạt được các mục tiêu trên, nhưng buôn bán robot không an toàn có thể “ăn trộm gà mất gạo”. Vào lúc 06:04:39 UTC ngày 29 tháng 8, một robot giao dịch bánh sandwich đã bị tấn công trên chuỗi BNB Chain.
Robot giao dịch bị tấn công trong trường hợp này đã mất tổng cộng 207 WBNB, 184.900 BSC-USD và 158.900 BUSD. , cùng với tổng tài sản trị giá khoảng 390.000 USD.
Fairyproof đã phân tích vụ việc ngay lập tức và phát hiện ra rằng nguyên nhân của cuộc tấn công bị nghi ngờ là do không đủ khả năng xác minh quyền gọi chức năng.
Thông thường trong các giao dịch on-chain trên DEX (sàn giao dịch phi tập trung), để tiết kiệm gas, robot giao dịch sẽ tương tác trực tiếp với cặp giao dịch mà không cần thông qua Hợp đồng Bộ định tuyến của DEX. Trong DEX được triển khai dựa trên logic giao dịch Uniswap, cặp giao dịch của nó được vay trước rồi trả lại, nghĩa là chức năng gọi lại cụ thể của nhà giao dịch (pancakeV3SwapCallback trong trường hợp này) được gọi để thông báo cho nhà giao dịch rằng mã thông báo đã được cho vay và nhà giao dịch cần để thực hiện Hoạt động có liên quan để trả lại mã thông báo đã cho vay.
Do đó, trong hợp đồng mua bán cần phải xác minh rằng người gọi hàm gọi lại pancakeV3SwapCallback (msg.sender) là cặp giao dịch thực và quyền của người khởi tạo (tx.origin). Do việc xác minh msg.sender tương đối phức tạp (đôi khi tính tương thích với Uniswap V2 được xem xét, dẫn đến logic xác minh phức tạp), nên hầu hết các hợp đồng chỉ xác minh tx.origin.
Thường thì không có vấn đề gì khi thực hiện việc này. Tuy nhiên, nếu một bước nhất định của giao dịch liên quan đến hợp đồng độc hại (trong trường hợp này là hợp đồng mã thông báo tấn công), sẽ có rủi ro, vì khi hợp đồng độc hại gọi pancakeV3SwapCallback, tx.origin có thể vượt qua xác minh quyền.
Trong sự cố này, chính xác là do người ta chưa xác minh được liệu msg.sender có phải là nhóm giao dịch pancakeV3 hay không mà mã thông báo tấn công đã bị tấn công gọi trực tiếp hàm pancakeV3SwapCallback và giả mạo các tham số giao dịch, từ đó vượt qua xác minh tx.origin và đánh cắp tài sản.
Trong cuộc tấn công này, các giá trị băm có liên quan của các giao dịch sandwich như sau:
p>

Địa chỉ hợp đồng của Sandwich Robot như sau:
· Hợp đồng thực thi (dễ bị tổn thương): 0x5C936E535Bb591C979a7c8D36C48a6B31808Cef9
· Hợp đồng kho tiền: 0x6E47b1123ddcF74E853516F934f5296cEb17D404
Địa chỉ hợp đồng của mã thông báo tấn công: 0xb4864E14467B0D1a2AfB1F70b3f04D4aC d635e06
Địa chỉ của cặp giao dịch mã thông báo tấn công: 0xf61F401041a1AF03875B0E0d4AAa9749a57AEB93
Địa chỉ của kẻ tấn công: 0x30BA49Ca659B70d3723E3cA6ed96EA4EF0249893
Quy trình giao dịch nội bộ chính của cuộc tấn công này được thể hiện trong hình bên dưới:

Lưu ý, ảnh trên được chụp Vì tại đây
p>
Từ quy trình trên, chúng ta có thể phân tích các bước tấn công giao dịch cụ thể như sau:
Bước 1: Kẻ tấn công đã triển khai hợp đồng mã thông báo tấn công và thực hiện các bước chuẩn bị liên quan, bắt đầu giao dịch mua hàng và để lộ giao dịch đó cho robot giao dịch bánh sandwich.
Bước 2: Robot sandwich gọi hàm hoán đổi của nhóm giao dịch PancakeV3 0xf61F401041a1AF03875B0E0d4AAa9749a57AEB93 trong FrontRun để lấy mã thông báo tấn công.
Bước 3: Nhóm giao dịch 0xf61F401041a1AF03875B0E0d4AAa9749a57AEB93 chuyển mã thông báo tấn công sang robot sandwich (cơ chế mượn đầu tiên của chuỗi Uniswap). Quá trình này sẽ gọi chức năng chuyển của mã thông báo tấn công.
Bước 4: Hàm truyền của mã thông báo tấn công gọi hàm pancakeV3SwapCallback() của robot sandwich với các tham số yêu cầu giả mạo.
Bước 5: Chức năng pancakeV3SwapCallback() của robot sandwich tx.origin được xác minh và sau đó tài sản được chuyển từ kho tiền sang kho tiền tấn công Trong hợp đồng mã thông báo (vì hàm pancakeV3SwapCallback thường gửi nội dung đến msg.sender).
Bước 6: Tiếp theo là quy trình giao dịch bánh sandwich thông thường. Sandwich Bot kiếm được lợi nhuận khoảng 25 USDC.
Bước 7: Kẻ tấn công rút nhiều tài sản bị đánh cắp khỏi hợp đồng mã thông báo. Tài sản bị đánh cắp bị trích xuất được hiển thị bên dưới, bao gồm WBNB, BSC-USD và BUSD:

Lưu ý, ảnh trên được lấy từ tại đây
Cuộc tấn công này cảnh báo các nhà phát triển hợp đồng rằng giao diện hợp đồng phải xác minh quyền hạn của người gọi, nghĩa là xác minh msg.sender, chỉ Xác minh tx .origin là không đủ.
Trong các trường hợp tương tự, Fairyproof khuyên bạn nên xác minh tx.origin trước, sau đó xác minh một trong hai trường hợp sau:
1. Khi lần đầu gọi giao diện bên ngoài của hợp đồng cho một giao dịch, hãy ghi địa chỉ cặp giao dịch vào hợp đồng và xác minh điều này trong chức năng gọi lại. Các thông số của cặp giao dịch sẽ được đặt lại sau khi giao dịch được thực hiện. Mặc dù hoạt động như vậy sẽ tiêu tốn thêm gas nhưng nó có thể cải thiện đáng kể tính bảo mật.
2. Lưu trữ cố định địa chỉ Nhà máy trong hợp đồng, tính toán địa chỉ cặp giao dịch tương ứng trong chức năng gọi lại và thực hiện xác minh tương ứng.
Ngoài ra, việc kiểm toán hợp đồng là bước cần thiết để đảm bảo an toàn cho dự án. Sự cố bảo mật trong ví dụ này có thể đã được phát hiện và tránh được thông qua kiểm tra bảo mật.
Fairyproof cung cấp các dịch vụ bảo mật chuyên nghiệp, đầy đủ và nghiêm ngặt cho hệ sinh thái blockchain, bao gồm kiểm toán hợp đồng, tư vấn bảo mật, giải pháp bảo mật, giám sát thời gian thực và theo dõi tài sản bị đánh cắp Chờ đợi. Chúng tôi luôn cam kết hợp tác với các đối tác trong hệ sinh thái để tạo ra môi trường sinh thái an toàn và bảo vệ tài sản mã hóa của người dùng.
Bài viết này là từ một bài gửi và không thể hiện quan điểm của BlockBeats
Chào mừng bạn tham gia cộng đồng chính thức của BlockBeats:
Nhóm Telegram đăng ký: https://t.me/theblockbeats
Nhóm Telegram thảo luận: https://t.me/BlockBeats_App
Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia