BTC
$96,000
5.73%
ETH
$3,521.91
3.97%
HTX
$0.{5}2273
5.23%
SOL
$198.17
3.05%
BNB
$710
3.05%
lang
简体中文
繁體中文
English
Tiếng Việt
한국어
日本語
ภาษาไทย
Türkçe
Trang chủ
AI AI
Tin nhanh
Bài viết
Sự kiện
BlockBeats Pro
Thêm
Thông tin tài chính
Chuyên đề
Hệ sinh thái chuỗi khối
Mục nhập
Podcast
Data
OPRR

Mất 200 triệu USD, truy tìm hacker tấn công Euler Finance

Đọc bài viết này mất 24 phút
Bài viết này phân tích và truy tìm nguồn gốc của cuộc tấn công Euler Finance xảy ra vào ngày 13 tháng 3 năm 2023.
Tiêu đề gốc: " Thiệt hại 200 triệu USD, truy tìm cuộc tấn công của hacker Euler Finance 》
Tác giả gốc: 0xNorman


Bài viết này chủ yếu về 2023.3 Phân tích và theo dõi nguồn gốc của cuộc tấn công Euler Finance xảy ra vào ngày 13. Tôi hy vọng nó sẽ đóng vai trò như một lời cảnh báo và phản ánh cho các bên dự án, nhà đầu tư, kỹ sư bảo mật và toàn bộ ngành công nghiệp blockchain.


Phân tích


Yếu tố chính khiến Euler Finance bị tấn công là biến healthScore. Biến này được sử dụng Một biến để đo lường mức độ sức khỏe của tài sản người dùng. Trong phương trình hàm transferFrom() tổng quát, biến này sẽ được sử dụng làm giới hạn để ngăn chặn các khoản nợ xấu. Nhưng trong eIP-14. Điều này có nghĩa là người dùng có thể quyên góp cho Euler theo ý muốn và gây ra các khoản nợ xấu cho tài khoản của họ.


Ngoài ra, quy trình thanh lý của Euler bao gồm chiết khấu thanh lý. Khi người thanh lý thanh lý một tài khoản mất khả năng thanh toán, khoản chiết khấu sẽ được áp dụng dựa trên điểm trạng thái của tài khoản. Điểm trạng thái càng cao Điểm trạng thái càng thấp giá trị thì mức giảm giá càng lớn.


Nếu tình trạng mất khả năng thanh toán nghiêm trọng, người thanh lý có thể lấy được tài sản thế chấp mà không phải trả bất kỳ khoản nợ nào.


Khả năng truy xuất nguồn gốc tại Etoken.donateToReserves() thiếu tính năng đánh giá điểm sức khỏe, điều này khiến người dùng rơi vào tình trạng vỡ nợ.



Trongliquidate() được thiết kế để sử dụng điểm số sức khỏe cho chiết khấu thanh lý để bất kỳ ai cũng có thể thanh lý một tài khoản mất khả năng thanh toán và nhận tài sản thế chấp mà không cần trả nợ và chuyển đổi thành tiền mặt.   



Chi tiết tấn công


Bạn có thể xem chi tiết giao dịch của kẻ tấn công trên Etherscan. Sau đây là quá trình khôi phục .


Bước 1: Tạo tài khoản mất khả năng thanh toán


Chuyển 2.000 Gửi 10.000 DAI dưới dạng eDAI


Dùng 20 triệu eDAI làm tài sản thế chấp và cho vay 200 triệu eDAI


Trả lại 10 triệu DAI ( dùng để cải thiện điểm sức khỏe và vay lại)


Cho vay thêm 200 triệu eDAI


Quyên góp 100 triệu eDAI, do đó tài sản và nợ phải trả lần lượt là 320 triệu eDAI và 390 triệu dDAI.


Kẻ tấn công trước tiên tạo một tài khoản với thế chấp và nợ khổng lồ. Thế chấp là 420 triệu eDAI (gửi 20 triệu, vay gấp đôi 2 tỷ), nợ là 390 triệu dDAI (vay 400 triệu, trả 10 triệu).


Sau đó, kẻ tấn công đã quyên góp 100 triệu eDAI, dẫn đến 70 triệu khoản nợ khó đòi (320 triệu eDAI-390 triệu dDAI) và tài khoản hiện tại bị mất khả năng thanh toán.


Bước 2: Thanh lý tài khoản


Gọi hàm Liquidation.liquidate()


RiskManager.computeLiquidity() được gọi để tính chiết khấu thanh lý


Do phá sản sâu Tài khoản Nợ, mức chiết khấu thanh lý hiệu quả là 20%.


Bằng cách giả sử khoản nợ 254 triệu dDAI, người thanh lý nhận được 317 triệu eDAI (2,54/3,17==0,8).


Người thanh lý đã rút 38,9 triệu eDAI (số tiền tối đa có thể rút) mà không trả được nợ.


Thông qua thanh lý, thế chấp và nợ của tài khoản phá sản được chuyển vào tài khoản của người thanh lý, nhưng nợ phải trả được chiết khấu, nhưng thế chấp thì không. Bằng cách này, bảy mươi triệu khoản nợ xấu đã biến thành sáu mươi triệu lợi nhuận. Tất nhiên là do Euler Finance thua lỗ.


Kẻ tấn công đã sử dụng các loại mã thông báo khác để khởi động Một số cuộc tấn công tương tự đã được thực hiện được thực hiện, cuối cùng khiến Euler Finance bị thua lỗ nặng nề.


Tóm tắt


Cuộc tấn công này chủ yếu là do chức năng quyên góp không được thiết kế dành cho điểm số sức khỏe, tạo cơ hội cho kẻ tấn công Ke Cheng đã tạo ra các tài khoản nợ xấu và đưa ra mức giá thân thiện cho các khoản nợ. Có thể nói, phần thưởng đã đưa hệ thống tài chính Euler đi xuống.


Từ góc độ thiết kế giao thức phi tập trung, Khi giới thiệu giao thức mới mã và logic nghiệp vụ, cần phải xem xét sự phù hợp với mã trước đó, nếu không, việc đóng góp dường như vô hại có thể biến thành lỗ hổng có rủi ro cao.


Từ góc độ bảo mật, mã mới được giới thiệu đã được kiểm tra bởi một số kỹ sư bảo mật hàng đầu trên nền tảng Sherlock. Tuy nhiên, kiểm tra không có nghĩa là không có lỗ hổng, ngay cả bởi những người mạnh nhất Do đó, tác giả khuyến cáo nhóm dự án luôn hợp tác với công ty kiểm toán bảo mật khi phát triển và nâng cấp dự án, đồng thời giám sát hợp đồng xem có hành vi bất thường nào không, sẽ tốt hơn nếu có thể thiết lập một khoản tiền thưởng lỗi thông thường . Thêm một đôi mắt, thêm một sự bảo mật .


Biến thế giới này thành một nơi tốt đẹp hơn bằng một cam kết mỗi lần  


Liên kết gốc


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áo lỗi/Báo cáo
Chọn thư viện
Thêm mới thư viện
Hủy
Hoàn thành
Thêm mới thư viện
Chỉ mình tôi có thể nhìn thấy
Công khai
Lưu
Báo lỗi/Báo cáo
Gửi