Slow Mist: Phân tích chi tiết và đề xuất phòng vệ nền tảng DeFi Lendf.Me bị hack

Ghi chú của biên tập viên Rhythmic BlockBeats: Vào sáng sớm ngày 20 tháng 4, dForce Network đã đưa ra thông báo chính thức cho biết cuộc tấn công của hacker chủ yếu sử dụng tiêu chuẩn ERC777 của tài sản imBTC. dễ bị tổn thương trước các cuộc tấn công tái xâm nhập. Cơ chế gọi lại cho phép tin tặc liên tục cho vay imBTC giả làm tài sản thế chấp, khiến tài sản có giá trị thị trường khoảng 25 triệu USD bị rút khỏi hợp đồng. Để biết chi tiết, hãy xem "dForce Yang Mindao : Zhengyu Nền tảng giao dịch hợp tác với công an và liên lạc với tin tặc để thu hồi số tiền bị đánh cắp".

Tiêu đề gốc: "Slow Mist: Phân tích chi tiết về việc nền tảng DeFi Lendf.Me bị tấn công và đề xuất phòng vệ"
Nguồn gốc: Công nghệ Slow Mist

Lời nói đầu

Theo thông tin của SlowMist Zone, nền tảng Ethereum DeFi Lendf. Tôi đang gặp phải lỗ hổng khi tái nhập. Sau khi nhận được thông tin tình báo, đội ngũ bảo mật SlowMist ngay lập tức phân tích cuộc tấn công và nhanh chóng xác định được vấn đề.

Theo phân tích thống kê sơ bộ về hệ thống chống rửa tiền (AML) của SlowMist Technology, khoản lỗ lũy kế của Lendf.Me từ cuộc tấn công xấp xỉ 24.696.616 USD, cụ thể Số tiền và số tiền bị đánh cắp là:

WETH: 55159.02134,
WBTC: 9.01152,
CHAI: 77930.93433,
HBTC: 320.27714,
HUSD: 432162.90569,
BUSD: 480787.88767,
PAX: 587014.60367,
TUSD: 459794.38763,
USDC: 698 916.40348,
USDT: 7180525.08156,
USDx: 510868.16067,
imBTC: 291.3471

Sau đó, kẻ tấn công tiếp tục đổi số tiền bị đánh cắp thành ETH và các token khác thông qua các nền tảng DEX như 1inch.exchange, ParaSwap và Tokenlon.

Sau đây là quá trình phân tích chi tiết.

Chi tiết tấn công

Địa chỉ của kẻ tấn công thực hiện cuộc tấn công vào Lendf.Me lần này là 0xa9bf70a420d364e923c74448d9d817d3f2a77822. Kẻ tấn công đã triển khai hợp đồng 0x538359785a8d5ab1a741a0ba94f26a800759d91d chống lại Lendf .Me. để tấn công.

Bằng cách xem một trong các giao dịch của kẻ tấn công trên Etherscan: https://etherscan.io/tx/0xae7d664bdfcc54220df4f18d339005c6faf6e62c9ca79c56387bc0389274363b



Chúng tôi phát hiện ra rằng kẻ tấn công lần đầu gửi 0,00021593 imBTC, nhưng đã rút thành công khỏi Lendf.Me 0,00043188 imBTC và số tiền đã rút gần gấp đôi số tiền gửi. Vậy làm thế nào mà kẻ tấn công có được số dư gấp đôi chỉ từ một giao dịch? Điều này đòi hỏi chúng ta phải phân tích sâu sắc mọi hành động trong giao dịch để xem điều gì đang thực sự diễn ra.

Bằng cách xem giao dịch trên bloxy.info, chúng tôi có thể biết toàn bộ quy trình giao dịch



Qua phân tích quá trình giao dịch, không khó để nhận ra kẻ tấn công đã thực hiện hai lệnh gọi hàm Supply() tới Lendf.Me, nhưng hai lệnh gọi này độc lập và không gọi lại hàm Supply() trong hàm Supply() trước đó.

Tuần tự, trong lệnh gọi thứ hai của hàm cung cấp(), kẻ tấn công đã sửa đổi Lendf. trong hợp đồng của chính hắn. Tôi rút tiền() function bắt đầu cuộc gọi và cuối cùng rút tiền mặt



Ở đây, không khó để chúng ta phân tích điều đó, Lệnh gọi rút() của kẻ tấn công xảy ra trong hàm transferFrom, tức là khi Lendf.Me gọi hàm hook tokenToSend() của người dùng thông qua transferFrom. Rõ ràng, kẻ tấn công đã nhập lại hợp đồng Lendf.Me thông qua hàm Supply(), gây ra một cuộc tấn công vào lại. Vậy chi tiết cuộc tấn công cụ thể là gì? Hãy cùng theo dõi mã hợp đồng của Lendf.Me nhé.

Phân tích mã

Sau một loạt quy trình, hàm cung cấp () của Lendf.Me sẽ gọi hàm doTransferIn để gửi loại tiền do người dùng cung cấp. Nhập hợp đồng và sau đó gán một số thông tin cho biến thị trường. Nhìn lại quá trình tấn công vừa đề cập, kẻ tấn công gọi hàm draw() để rút tiền thông qua reentrancy trong hàm Supply() thứ 2. Tức là ở hàm Supply() thứ 2, sau dòng 1590 thì thao tác sẽ không được thực thi trước khi rút(). Sau khi rút() được thực thi, mã sau dòng 1590 sẽ tiếp tục thực thi. Hoạt động ở đây dẫn đến sự gia tăng số dư có thể rút của kẻ tấn công.

Hãy phân tích sâu hơn về hàm Supply()



Theo hình trên, bạn có thể thấy rằng khi kết thúc hàm Supply(), số dư thị trường và số dư người dùng sẽ được cập nhật. Trước đó, số dư của người dùng sẽ được cập nhật trước -set ở đầu hàm. Lấy và lưu nó trong localResults.userSupplyCurrent, như sau:



Bằng cách gán giá trị cho biến localResults, người dùng Thông tin được truyền sẽ được lưu tạm thời trong biến này, sau đó kẻ tấn công thực thi hàmrút().Chúng ta hãy xem mã của hàmrút():




Có hai điểm chính ở đây:

1 . Khi bắt đầu hàm, hợp đồng trước tiên nhận được các biến thị trường và cung cấp của bộ lưu trữ.

2. Ở cuối hàmrút tiền(), logic tương tự tồn tại để cập nhật thông tin số dư của người dùng thị trường (supplyBalance). Giá trị cập nhật là số dư sau khi trừ số tiền rút của người dùng.

Theo logic rút tiền thông thường, khi pull() được thực hiện một mình, số dư của người dùng sẽ bị trừ và cập nhật bình thường. Tuy nhiên, vì Kẻ tấn công nhúng draw() vào Supply(), sau khi hàm draw() cập nhật số dư của người dùng (supplyBalance), đoạn mã tiếp theo sẽ được thực thi bởi hàm Supply(), tức là sau dòng 1590, số dư của người dùng sẽ là được cập nhật lại và giá trị được sử dụng để cập nhật sẽ là khoản tiền gửi ban đầu của người dùng được lưu trong localResults khi bắt đầu hàm cung cấp () trước đó cộng với giá trị của lệnh gọi tiền gửi đầu tiên của kẻ tấn công tới hàm cung cấp ().

Trong thao tác như vậy, mặc dù số dư của người dùng đã bị trừ sau khi rút tiền, nhưng hàm cung cấp () tiếp theo sẽ ghi đè lên giá trị khi người dùng chưa trừ số tiền rút, kết quả là mặc dù kẻ tấn công thực hiện thao tác rút nhưng số dư không bị trừ mà tăng lên. Bằng cách này, kẻ tấn công có thể rút số tiền theo cấp số nhân cho đến khi Lendf.Me hoàn toàn trống rỗng.

Gợi ý phòng thủ

Để đối phó với cuộc tấn công này, nhóm bảo mật SlowMist khuyến nghị:

1. Thêm cơ chế khóa vào các phương thức hoạt động kinh doanh chính, chẳng hạn như: ReentrancyGuard của OpenZeppelin

2. Khi phát triển hợp đồng, sử dụng kiểu viết thay đổi các biến của hợp đồng trước rồi thực hiện các lệnh gọi bên ngoài

3. Dự án trực tuyến Vui lòng yêu cầu nhóm bảo mật xuất sắc của bên thứ ba tiến hành kiểm tra bảo mật toàn diện trước để phát hiện nhiều nhất có thể các vấn đề bảo mật tiềm ẩn
Khi có nhiều hợp đồng được kết nối, Cần kiểm tra tính bảo mật mã và bảo mật kinh doanh của hợp đồng nhiều bên, đồng thời xem xét toàn diện các vấn đề bảo mật trong các tình huống kinh doanh khác nhau

4. Hợp đồng nên thiết lập công tắc tạm dừng càng nhiều càng tốt để khi xảy ra sự kiện "thiên nga đen" có thể phát hiện và ngăn chặn kịp thời

5. Bảo mật rất linh hoạt và mỗi bên dự án cũng cần nắm bắt kịp thời thông tin về mối đe dọa có thể liên quan đến dự án của mình và điều tra kịp thời các rủi ro bảo mật tiềm ẩn

Tệp đính kèm:OpenZeppelin ReentrancyGuard: https: //github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/utils/ReentrancyGuard.sol

Liên kết nguồn: weixin.qq.com

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