Bởi: yudan@đội an ninh sương mù chậm

tiêu đề phụ

Phân tích chi tiết cuộc tấn công

BurgerSwap là một dự án AMM giống Uniswap, nhưng nó khác với kiến ​​trúc Uniswap. Kiến trúc BurgerSwap thường được chia thành [Đại biểu -> lpPlatForm -> Cặp]. Lớp Đại biểu quản lý tất cả thông tin Cặp và chịu trách nhiệm tạo lớp lpPlatForm. Sau đó, lớp lpPlatForm đi xuống để tạo hợp đồng Cặp tương ứng. Xuyên suốt kiến ​​trúc, lớp lpPlatForm hoạt động như một bộ định tuyến trong Uniswap, chịu trách nhiệm chuyển tiếp dữ liệu giao dịch được tính toán và mã thông báo sẽ được trao đổi sang hợp đồng Cặp để hoàn tất quá trình trao đổi.

Căn nguyên của sự cố này nằm ở vấn đề của cấu trúc này. Bằng cách phân tích từng bước hành vi giao dịch của kẻ tấn công, chúng tôi sẽ khôi phục cốt lõi của toàn bộ quá trình tấn công:

Cuộc tấn công này bắt đầu bằng khoản vay chớp nhoáng của Pancake. Kẻ tấn công đã mượn một lượng lớn WBNB từ Pancake, sau đó chuyển đổi những WBNB này thành mã thông báo Burger thông qua BurgerSwap. Sau khi hoàn thành các thao tác trên, kẻ tấn công sử dụng mã thông báo mà anh ta kiểm soát (chính hợp đồng tấn công) và mã thông báo Burger để tạo một cặp giao dịch thông qua lớp Đại biểu và thêm thanh khoản để chuẩn bị cho các cuộc tấn công tiếp theo.

Sau khi hoàn thành việc tạo và chuẩn bị mã thông báo, kẻ tấn công ngay lập tức bắt đầu trao đổi thông qua chức năng hoán đổiExactTokensForTokens của lớp PaltForm và đường dẫn trao đổi là [mã thông báo do kẻ tấn công kiểm soát -> Burger -> WBNB]

Tiếp theo là hoạt động quan trọng nhất.

Do kẻ tấn công đã sử dụng token do chính mình kiểm soát khi tạo cặp giao dịch nên trong quá trình trao đổi token, hàm _innerTransferFrom sẽ gọi hợp đồng token do kẻ tấn công kiểm soát, vì vậy kẻ tấn công có thể nhập lại hàm swapExactTokensForTokens trong hàm _innerTransferFrom. Tại sao một kẻ tấn công sẽ làm điều này?

Bằng cách phân tích mã của hàm swapExactTokensForTokens của lớp PlatForm, không khó để thấy rằng hợp đồng trước tiên sẽ tính toán dữ liệu trao đổi của người dùng khi gọi hàm _innerTransferFrom, sau đó sử dụng dữ liệu được tính toán trước để chuyển tiếp đến lớp dưới cùng sau khi hoạt động của chức năng _innerTransferFrom.trao đổi mã thông báo. Từ góc độ của chức năng này, ngay cả khi kẻ tấn công nhập lại chức năng swapExactTokensForTokens, chức năng hoán đổi được gọi bởi lớp bên dưới cũng độc lập, thoạt nhìn thì không có vấn đề gì, nhưng một hành vi trên chuỗi đã thu hút sự chú ý của nhóm bảo mật SlowMist:

Chúng tôi rất ngạc nhiên khi thấy rằng trong quá trình mua lại, số lượng trao đổi không giảm do trượt giá. Lý do là gì? Có vẻ như mấu chốt là vấn đề của hợp đồng Cặp cơ bản. Chúng tôi đã phân tích thêm về hợp đồng Cặp được gọi bởi lớp dưới cùng, mã như sau:

tóm tắt

tóm tắt

Cuộc tấn công này là một vấn đề trong kiến ​​trúc BurgerSwap. Do lớp Pair hoàn toàn tin tưởng dữ liệu trong lớp PaltForm và không tự thực hiện kiểm tra khác nên cuộc tấn công đã xảy ra. Gần đây, các sự cố bảo mật DeFi thường xuyên xảy ra. Trước các cuộc tấn công DApp ngày càng dữ dội, nhóm bảo mật SlowMist khuyến nghị rằng các nhà phát triển DApp cần hiểu đầy đủ về kiến ​​trúc của giao thức ghép khi ghép mã từ các giao thức khác và xem xét đầy đủ giao thức chuyển và các dự án riêng.Khả năng tương thích, và nó cần phải vượt qua cuộc kiểm toán của một tổ chức kiểm toán bảo mật chuyên nghiệp trước khi đưa lên mạng để tránh tổn thất tài chính.

Tham khảo giao dịch tấn công:

https://bscscan.com/tx/0xac8a739c1f668b13d065d56a03c37a686e0aa1c9339e79fcbc5a2d0a6311e333