

Lưu ý của biên tập viên: Bài viết này là của Digital Comet Technology và được xuất bản với sự cho phép.
Để giải quyết vấn đề về lỗ hổng của EOS cách đây một thời gian, bài viết này sẽ xem xét chi tiết tổng thể, mong mọi người nâng cao nhận thức về bảo mật nhưng đừng quá hoang mang và có cái nhìn đúng đắn về các vấn đề bảo mật.
1. Tổng quan sự kiện
Vào đầu giờ ngày 22 tháng 6, cộng đồng chính thức của EOS đã đưa ra một thông báo nói rằng một lỗ hổng EOS đã được phát hiện và các mã thông báo mà người dùng đã cam kết bỏ phiếu không thể đổi được cho đến khi lỗ hổng được khắc phục. Sau đó, chúng tôi đã xác minh lỗ hổng bảo mật theo thông tin liên quan và xác nhận rằng lỗ hổng này tồn tại và trước khi lỗ hổng được khắc phục, thông qua một cuộc tấn công được xây dựng cẩn thận, tài sản cụ thể của người dùng đã được thế chấp vô thời hạn và không thể mua lại được.
Chúng tôi biết rằng EOS áp dụng cơ chế đồng thuận DPoS, duy trì mạng EOS bằng cách bầu 21 siêu nút thông qua bỏ phiếu cộng đồng và cung cấp sức mạnh tính toán, băng thông và hỗ trợ lưu trữ cho mạng EOS. Người dùng không cần tiêu dùng EOS để bỏ phiếu, nhưng EOS sẽ bị khóa. Người dùng có thể đăng ký đổi EOS thế chấp bất kỳ lúc nào và khoản tín dụng sẽ đến sau 72 giờ kể từ khi đăng ký đổi. Đồng thời, phiếu bầu sẽ bị trừ.
Lỗ hổng này xảy ra trong quá trình đổi thưởng của EOS. Như đã đề cập ở trên, cuộc tấn công được xây dựng cẩn thận về mặt lý thuyết khiến tài sản của người dùng được chỉ định bị thế chấp vô thời hạn, gây thiệt hại nghiêm trọng cho người dùng.
2. Quy trình tấn công lỗ hổng
1. Giả sử rằng người dùng bị tấn công sở hữu 0,0005 EOS và đang trong quá trình mua lại.
2. Tại thời điểm này, kẻ tấn công thế chấp 0,0001 EOS cho người dùng chuộc.
3. Sau khi giao dịch có hiệu lực, chúng tôi thấy rằng số dư của kẻ tấn công không thay đổi và 0,0001 EOS mà người dùng chuộc đang trên đường chuộc lại buộc phải thế chấp lại.
3. Phân tích các nguyên tắc dễ bị tổn thương
Các lệnh tấn công trong lưu đồ tấn công như sau:
cleos --wallet-url http://localhost:6666 --url http://mainnet.genereos.io:80 system delegatebw (attacker) (victim) "0.0001 EOS" "0.0000 EOS" --transfer
Vì kẻ tấn công đã thêm tham số --transfer khi gọi lệnh, hàm changbw sẽ được gọi khi hàm thế chấp delegatebw được gọi và chuyển đổi là đúng tại thời điểm này
Khi biến truyền là đúng, địa chỉ từ trở thành địa chỉ của đối tượng bị tấn công,
Tiếp theo, dữ liệu của đối tượng bị tấn công được sửa đổi và EOS được thế chấp lại.
4. Kế hoạch giảm thiểu tổn thương
Dựa trên phân tích trên, bài viết này khuyến nghị sửa đổi một số logic kinh doanh để giảm bớt và sửa chữa lỗ hổng thế chấp.
1. Bất kể thông số chuyển nhượng có đúng hay không, nó phải được khấu trừ trực tiếp vào số dư của người khởi xướng thế chấp (quá trình mua lại không bị hạn chế này);
2. Sắp xếp logic nghiệp vụ có liên quan và kiểm tra xem có những sơ hở tương tự hay không.
V. Tóm tắt phân tích lỗ hổng
Qua phân tích trên, các cuộc tấn công được xây dựng cẩn thận khiến tài sản cụ thể của người dùng bị thế chấp vô thời hạn và không thể mua lại. Vá mã bằng các biện pháp giảm thiểu có thể giảm thiểu và khắc phục lỗ hổng này một cách hiệu quả.
