tiêu đề phụ

tóm tắt sự kiện

Vào lúc 4 giờ sáng ngày 5 tháng 8, một số người dùng đã báo cáo trên diễn đàn opyn rằng số dư tài khoản của họ biến mất không rõ lý do và một số người dùng đã tìm thấy thông tin giao dịch đáng ngờ, như trong hình bên dưới:

Bên dự án Opyn đã trả lời sau khi phân tích sơ bộ tình hình và cho biết: tiền đã được chuyển và nguyên nhân của vấn đề đang được tìm kiếm

Tính đến thời điểm viết bài, quan chức này đã đưa ra phản hồi về vụ việc: nó đã bị tấn công và tài sản có thể bị tấn công đã được chuyển đi, nhưng lỗ hổng này chỉ liên quan đến hợp đồng ETH và không ảnh hưởng đến các hợp đồng khác. Như hình dưới đây:

0xe7870231992ab4b1a01814fa0a599115fe94203f

0xb837531bf4eb8ebfa3e20948bd14be067c18cbd3

0xb72e60ea1d0c04605f406c158dce9ac6ae6d224c

Thành Đô Lianan-Security Lab lần đầu tiên theo dõi và phân tích sự cố này. Sau đây là địa chỉ hợp đồng của kẻ tấn công mà hệ thống nhận thức tình huống đã phát hiện hành vi trộm cắp:

Phương thức tấn công của kẻ tấn công được khôi phục:

1. Kẻ tấn công gọi hợp đồng để gửi n USDC đến hợp đồng để tăng khoản thế chấp và lấy đồng tiền hợp đồng oETH

3. Kẻ tấn công chuộc lại ETH đã thế chấp của mình.

Như hình dưới đây:

tiêu đề phụ

phân tích kỹ thuật

phân tích kỹ thuật

Lấy giao dịch 0x56de6c4bd906ee0c067a332e64966db8b1e866c7965c044163a503de6ee6552a làm ví dụ, kẻ tấn công sử dụng hợp đồng 0xe7870231992ab4b1a01814fa0a599115fe94203f để hợp đồng 0x951D5 1bAe Fb72319d9FBE941E1615938d89ABfe2 đã phát động cuộc tấn công và kiếm được tổng lợi nhuận là $9907 trong giao dịch này. Như hình dưới đây:

Đầu tiên, kẻ tấn công gọi hàm addERC20CollateralOption và gửi 9900 USDC vào hợp đồng, như thể hiện trong hình bên dưới:

addERC20Collateral(msg.sender, amtCollateral); trong chức năng này chịu trách nhiệm chuyển giao USDC cho đại lý; issueOTOkens(amtToCreate, receiver); trong chức năng này chịu trách nhiệm đúc oETH. Giao dịch này đúc 30 oETH và gửi chúng cho kẻ tấn công, như minh họa trong hình bên dưới:

Sau khi hoàn thành việc này, các tham số vault của kẻ tấn công sẽ bị thay đổi. vault.oTokensIssued và vault.collateral được cập nhật lần lượt là 300000000 và 9900000000, như thể hiện trong hình bên dưới:

Sau đó, kẻ tấn công đã tiến hành trao đổi oETH.

Gọi tập thể dục, tham số xây dựng oTokensToExercise là 60 và vaultsToExerciseFrom là hai địa chỉ, một trong số đó là địa chỉ của người khác cũng đáp ứng các điều kiện. Như hình dưới đây:

Hàm Exercise chạy nhánh _exercise(vault.oTokensIssued, vaultOwner); và gửi USDC tương ứng với 30oETH cho người gọi, như thể hiện trong hình bên dưới:

Hãy nhìn lại vòng lặp for trong bài tập. Đầu vào của oTokensToExercise của kẻ tấn công là 60, vì vậy khi hợp đồng xác minh rằng địa chỉ thứ hai đáp ứng các điều kiện, nó vẫn sẽ chuyển số dư cho msg.sender, chính là kẻ tấn công. Điều này cho phép kẻ tấn công lấy được USDC hai lần, do đó kiếm được lợi nhuận.

tiêu đề phụ

lời khuyên tóm tắt

Trong sự cố này, kẻ tấn công đã lợi dụng lỗ hổng logic của chức năng thực hiện. Chức năng này không xác minh xem người gọi có quyền đổi USDC của địa chỉ này trước khi thực hiện chuyển khoản cuối cùng hay không mà chỉ xác minh xem địa chỉ có thể được đổi hay không. Đó là một lỗ hổng logic trong lớp mã và theo phản hồi chính thức, hợp đồng này đã trải qua một cuộc kiểm toán bảo mật. Thành Đô Liên Nam xin nhắc nhở tất cả các bên dự án:

1. Nên tiến hành kiểm toán bảo mật đầy đủ và hiệu quả trước khi dự án được đưa vào trực tuyến, tốt nhất là kiểm toán nhiều bên

2. Đối với hợp đồng, các chức năng như tạm dừng giao dịch hợp đồng nên được thiết lập để đảm bảo an toàn cho tiền trong trường hợp xảy ra sự cố bảo mật