Caterpillar Coin, một dự án tài chính phi tập trung (DeFi) trên Binance Smart Chuỗi, đã bị khai thác vào ngày 10 tháng 9 năm 2024, gây ra thiệt hại ước tính khoảng 1,4 triệu đô la.
Kẻ khai thác đã thực hiện cuộc tấn công vào dự án trong ba giao dịch:
https://bscscan.com/tx/0x6262c0f15c88aed6f646ed1996eb6aae9ccc5d5704d5faccd1e1397dd047bc8a
https://bscscan.com/tx/0xce6e474dc9555ef971473fee19f87716f38ba01a0df39e78207b71eda134c420
https://bscscan.com/tx/0x2c123d08ca3d50c4b875c0b5de1b5c85d0bf9979dffbf87c48526e3a67396827
Tổng quan
Trong phần phân tích của mình, chúng tôi sẽ tập trung vào cuộc tấn công gây ra tổn thất lớn nhất - cuộc tấn công thứ ba:
https://bscscan.com/tx/0x2c123d08ca3d50c4b875c0b5de1b5c85d0bf9979dffbf87c48526e3a67396827
Kẻ tấn công:
https://bscscan.com/address/0x560a77bc06dcc77eee687acb65d46b580a63eb45
Hợp đồng dễ bị tổn thương:
https://bscscan.com/address/0x7057f3b0f4d0649b428f0d8378a8a0e7d21d36a7
Phân tích khai thác
Cuộc tấn công có vẻ như đã tuân theo một mô hình đơn giản: kẻ tấn công đã sử dụng Khoản vay nhanh để vay USDT từ cặp USDT-WBNB, sau đó chạy một vòng lặp để tạo ra một số hợp đồng với logic tấn công chính đang chạy trong trình xây dựng. Trước khi tạo ra mỗi hợp đồng, kẻ khai thác đã chuyển một lượng lớn USDT để logic trong trình xây dựng sử dụng.
Chúng ta hãy đi sâu vào logic bên trong hàm tạo.
Khi gửi USDT đến hợp đồng trước khi tạo, hợp đồng mới sẽ hoán đổi một phần trong số đó để lấy token CUT.
Hợp đồng sau đó sử dụng các token CUT và USDT đã mua để thêm thanh khoản vào hợp đồng cặp. Đổi lại việc cung cấp thanh khoản, hợp đồng nhận được một số Token của người cung cấp thank khoản (LP Tokens) tương ứng đại diện cho phần của nó trong Bể thanh khoản.
Ở bước tiếp theo, hợp đồng sử dụng số token CUT còn lại (mà chúng ta biết là một số lượng đáng kể) để thực hiện một lần hoán đổi khác, lần này chuyển đổi token CUT trở lại thành USDT.
Sau đó, kẻ tấn công đốt Token của người cung cấp thank khoản (LP Tokens). Hành động này sẽ loại bỏ tính thanh khoản mà họ cung cấp khỏi nhóm, cho phép họ rút phần tài sản cơ bản tương ứng của mình.
Lặn sâu vào bước này,
Quan sát thấy số dư CUT của hợp đồng 0x34be bằng 0 trước khi đốt, nhưng lại nhận được 269.661 token CUT sau khi đốt mặc dù hợp đồng PAIR chỉ chuyển 60.652 token, cho thấy có sự bất thường hoặc khai thác trong cơ chế đốt.
Với số lượng lớn token CUT thu được thông qua khai thác rõ ràng trong quá trình đốt, kẻ tấn công có thể thực hiện thêm các lần hoán đổi, chuyển đổi các token CUT này trở lại thành USDT. Điều này có thể cho phép chúng khuếch đại đáng kể lợi nhuận của mình.
Hơn nữa, kẻ tấn công dường như đã lặp lại quy trình tạo hợp đồng, lặp lại hành vi khai thác nhiều lần để rút một lượng lớn dự trữ USDT trong hợp đồng cặp.
Đi sâu vào các bước addLiquidity và removeLiquidity trong mã Token CUT để làm rõ lỗi trong hành động ghi.
Đối với mỗi người dùng mới thêm thanh khoản, Token CUT sẽ ghi lại ID đơn hàng cho mục đích thưởng, bao gồm giá trị USDT tương đương với số tiền CUT được thêm vào.
Và khi loại bỏ thanh khoản, Token CUT sẽ tính toán phần thưởng dựa trên logic của hợp đồng _transferFunDealTypeContractAddress . Điều này được gọi là cơ chế bảo vệ giá.
Đây là hợp đồng mã chưa được xác minh; chúng tôi sẽ phân tích mã nguồn đã biên dịch ngược.
Hàm valuePreservationByRmoveLP được biên dịch ngược trong hàm 0x70f88861 .
Trong hàm này, hợp đồng chuyển đổi số tiền CUT mà người dùng nhận được từ bước removeLiquidity và tính toán giá trị USDT tương ứng dựa trên giá CUT hiện tại. Sau đó, nó tính toán sự thay đổi về giá trị so với dữ liệu được lưu trữ trong orderInfo . Sự thay đổi về giá trị USDT này sau đó được chuyển đổi trở lại thành một số token CUT bằng cách sử dụng giá hiện tại và các token này được thưởng cho người dùng.
Với logic này, kẻ tấn công có thể dễ dàng thao túng giá (thổi giá và Xả) để tạo ra sự khác biệt đáng kể giữa giá trị ban đầu được ghi lại trong orderID và giá trị CUT sau đó trong cùng một giao dịch.
Sau khi phân tích quá trình tấn công, chúng ta có thể thấy lỗ hổng chính trong hợp đồng nằm ở việc dự án sử dụng giá theo thời gian thực để tính toán phần thưởng.
Việc hoàn toàn phụ thuộc vào giá theo thời gian thực để tính toán có thể rất rủi ro. Kẻ tấn công có thể lợi dụng điều này bằng cách thao túng giá để có lợi cho chúng. Để bảo vệ tính toàn vẹn của dự án, nên kết hợp giá oracle để tính toán thay thế.
