Giải thích chi tiết về lỗ hổng Akropolis: Hacker tái hiện “cuộc tấn công tái nhập kinh điển” và đánh cắp 2,03 triệu DAI
Tiêu đề gốc: "Giải thích chi tiết về lỗ hổng Akropolis của giao thức DeFi: Tin tặc đã tái tạo "Cuộc tấn công Reentrancy cổ điển" và bắt cóc 2,03 triệu DAI"
Nguồn gốc: PeckShield
Vào lúc 19:50 tối hôm qua, giao thức DeFi Akropolis đã bị tin tặc tấn công.
Nhân viên bảo mật của công ty bảo mật blockchain PeckShield nhanh chóng xác định rằng vấn đề là hợp đồng SavingsModule của dự án Akropolis có một số lỗ hổng trong việc xử lý tài sản lưu trữ của người dùng . , hacker đã sử dụng lỗ hổng này để thực hiện 17 cuộc tấn công tái nhập liên tiếp, dẫn đến mất 2,03 triệu DAI trong nhóm quỹ YCurve và sUSD của mình.
Tóm tắt kỹ thuật
Lý do của cuộc tấn công này như sau:
Hợp đồng không đưa vào danh sách trắng các mã thông báo được người dùng lưu trữ và chức năng gửi tiền chính không bảo vệ chống lại Bảo vệ
Nói một cách đơn giản: tin tặc đã lợi dụng lỗ hổng xác minh tài sản lưu trữ trong dự án Akropolis để thực hiện nhiều cuộc tấn công tái nhập liên tiếp vào hợp đồng, khiến hợp đồng Akropolis thất bại. Với việc đưa vào tài sản mới, một số lượng lớn pooltoken đã được phát hành bất ngờ và những pooltoken này sau đó được sử dụng để trích xuất DAI từ nhóm YCurve và sUSD, cuối cùng dẫn đến thua lỗ 2,03 triệu DAI trong hợp đồng dự án.
Giải thích chi tiết quá trình tấn công
Sao chép quá trình tấn công:
Bằng cách phân tích hàm băm giao dịch của cuộc tấn công của hacker
(0xe1f375a47172b5612d96496a4599247049f07c9a7d518929fbe296b0c281e04d)
Chúng tôi phát hiện ra rằng cuộc tấn công đến từ Dựa trên địa chỉ hợp đồng ERC20 độc hại
(0xe2307837524Db8961C4541f943598654240bd62f)
Hợp đồng độc hại này thực hiện chức năng hook, khiến cho hàm trong transferFrom() (chữ ký hàm: 0x23b872dd) sẽ được thực thi khi được gọi.
Đầu tiên, kẻ tấn công gọi SavingsModule.sol và chuyển vào hợp đồng độc hại mà bạn đã viết bắt đầu bằng 0xe230 làm địa chỉ mã thông báo sẽ được lưu trữ. Khi hàm transferFrom() của mã thông báo độc hại của nó được gọi, hàm hook của nó sẽ gọi lại hàm Deposit() và gửi tài sản DAI thực.
Bởi vì số lượng phát hành thêm pooltokens được tính bằng chênh lệch giữa số dư trước và sau khi gửi token. Do đó, tài sản DAI thực của lần gửi tiền thứ hai sẽ được tính hai lần và được sử dụng để đúc pooltoken. Lần đầu tiên là khi hợp đồng độc hại 0xe230 được lưu trữ và lần thứ hai là khi DAI được lưu trữ. Nghĩa là, nếu 25K DAI được gửi trong lần gửi tiền thứ hai, thì tổng số token khai thác được sẽ tăng gấp đôi hoặc 50K DAI do một cuộc tấn công tái tổ chức.
Tương tự, hacker đã thực hiện tổng cộng 17 cuộc tấn công tái xâm nhập và thu được tổng cộng 2.030.841,0177 tài sản DAI.
Điều đáng chú ý là khi bắt đầu cuộc tấn công, kẻ tấn công cũng đã sử dụng dYdX Chức năng cho vay nhanh.
Giải thích chi tiết về các lỗ hổng cốt lõi
Tiếp theo, chúng tôi phân tích logic lưu trữ mã thông báo dễ bị tấn công. Người dùng Akropolis có thể lưu trữ mã thông báo vào Nhóm tiết kiệm Delphi và nhóm sẽ đúc các mã thông báo nhóm tương ứng cho người dùng. Logic cốt lõi nằm trong SavingsModule::deposit() (dòng 1.944).
Bước 1: Kẻ tấn công gọi hàm Deposit() và cung cấp tham số _tokens. Hàm này tính toán số dư mã thông báo trước và sau một lệnh gọi tiếp theo tới DepositToProtocol(_protocol,_tokens,_dnAmounts) và sử dụng các thay đổi trong số dư mã thông báo để xác định số lượng poolTokens sẽ được đúc (dòng 1.970). Hàm DepositToProtocol() gọi hàm safeTransferFrom() của mã thông báo đích để chuyển mã thông báo (dòng 2.004). Tuy nhiên, hàm Deposit() không phát hiện các cuộc tấn công reentrancy cũng như không kiểm tra xem các token được gửi có phải là token độc hại hay không;
Bước 2: Trong phần độc hại Khi Hàm transferFrom() của token được gọi, hàm hook được kích hoạt, từ đó gọi lại hàm Deposit();
Bước 3: Vì lệnh gọi thứ hai Khi sử dụng hàm Deposit(), kẻ tấn công gửi mã thông báo DAI thực, điều này khiến số dư mã thông báo của nhóm thay đổi, do đó kẻ tấn công có thể lấy được poolTokens do nhóm vốn tạo ra;
Bước 4: Khi lệnh gọi hàm Deposit() thứ hai kết thúc, luồng thực thi mã sẽ quay trở lại ngữ cảnh của lệnh gọi hàm DepositToProtocol() đầu tiên để lưu trữ mã thông báo. Lúc này, những thay đổi trong số dư token sẽ được tính lại. Thay đổi về số dư mã thông báo tại thời điểm này cũng giống như thay đổi về số dư mã thông báo khi hàm Deposit() được gọi lần thứ hai. Do đó, kẻ tấn công có thể lấy lại số lượng poolTokens tương ứng.
Tài sản bị đánh cắp
Tài sản bị đánh cắp trong cuộc tấn công này hiện được lưu trữ trong ví 0x9f26 In. CoinHolmes, một nền tảng theo dõi tài sản kỹ thuật số thuộc sở hữu của PeckShield, đang tiến hành giám sát toàn diện địa chỉ và phân tích khóa sâu hơn cũng như theo dõi dòng vốn của nó để hỗ trợ các bên dự án thu hồi tài sản bị đánh cắp.
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
Bài viết liên quan
