Lưu ý của biên tập viên: Bài viết này đến từCông nghệ phun sương chậm (ID: SlowMist)Công nghệ phun sương chậm (ID: SlowMist)

lời tựa

tiêu đề phụ

lời tựa

Theo Lianwen, vào ngày 18 tháng 4, Tokenlon đã thông báo tạm dừng chuyển imBTC vì phát hiện ra rằng kẻ tấn công đã sử dụng lỗ hổng đăng nhập lại ERC777 trong hợp đồng thanh khoản Uniswap để phân xử chu kỳ nhóm ETH-imBTC. Phương thức tấn công lần này là một lỗ hổng đã biết tồn tại trong Uniswap v1, lỗ hổng được Consensys phát hiện lần đầu tiên vào tháng 4 năm 2019. Khi đó, Consensys mới chỉ phát hiện ra rủi ro và chưa tìm thấy token có thể sử dụng phương thức này để tấn công. Sau đó, sau khi imBTC được ra mắt trên Uniswap, vì imBTC được triển khai dựa trên ERC777, bằng cách kết hợp các đặc điểm của ERC777 và các sự cố trong mã Uniswap, kẻ tấn công có thể đạt được chênh lệch giá thông qua các lỗ hổng đăng nhập lại. Tiếp theo, chúng tôi sẽ phân tích các phương pháp tấn công và các chi tiết cụ thể của chênh lệch giá này trong tương lai.

tiêu đề phụ

chuẩn bị kiến ​​thức

Giao thức ERC777 là một giao thức tiêu chuẩn mã thông báo trên Ethereum. Giao thức này là phiên bản cải tiến của giao thức ERC20 trên Ethereum. Các cải tiến chính như sau:

1. Sử dụng khái niệm tương tự như gửi ether để gửi mã thông báo, phương thức là: gửi (đích, giá trị, dữ liệu)

2. Cả hợp đồng và địa chỉ thông thường đều có thể kiểm soát và từ chối gửi mã thông báo nào bằng cách đăng ký hàm hook tokensToSend (việc từ chối gửi được thực hiện bằng cách hoàn nguyên trong hàm hook tokensToSend)"4. tokenReceived có thể gửi token và thông báo hợp đồng chấp nhận token trong một giao dịch thông qua chức năng hook, không giống như ERC20, chức năng này phải được hoàn thành thông qua hai lệnh gọi (approve/transferFrom)"Và"5. Người giữ có thể"ủy quyền

Và

thu hồi

nhà khai thác (nhà khai thác: có thể gửi mã thông báo thay mặt cho chủ sở hữu) Những nhà khai thác này thường là sàn giao dịch (phi tập trung), bộ xử lý kiểm tra hoặc hệ thống thanh toán tự động

Ở đây, chúng ta cần đặc biệt chú ý đến điểm thứ hai, đó là chức năng tokenToSend trong tiêu chuẩn ERC777.Theo định nghĩa của giao thức ERC777, token token theo tiêu chuẩn này sẽ cố gắng gọi token mỗi khi chuyển token xảy ra Hàm người gửi tokensToSend và chủ sở hữu mã thông báo có thể đăng ký hợp đồng của riêng họ trong hợp đồng đăng ký ERC1820 và xác định một số thao tác trong chức năng hook này để xử lý các quy trình nhất định trong quá trình chuyển mã thông báo, chẳng hạn như từ chối gửi mã thông báo hoặc các hoạt động khác.

phân tích chi tiết

Hiểu được những điểm mấu chốt này sẽ giúp chúng ta hiểu được phương pháp tấn công cụ thể của cuộc tấn công này. Từ giờ trở đi, chúng ta có thể tăng tốc một chút và xem điều gì đã xảy ra với Uniswap lần này?

tiêu đề phụ

phân tích chi tiết

Truy vấn một trong các giao dịch của kẻ tấn công qua Etherscan 0x32c83905db61047834f29385ff8ce8cb6f3d24f97e24e6101d8301619efee96e

Có thể thấy rằng kẻ tấn công đã chuyển imBTC sang hợp đồng Uniswap hai lần, với cùng số tiền là 0,00823084, sau đó nhận được hai ETH từ Uniswap, đây tưởng chừng là hai giao dịch rất bình thường, nhưng thực chất chúng là hoạt động ngầm và những bí ẩn khác. Để hiểu rõ hơn về chi tiết của toàn bộ giao dịch, chúng ta cần xem chi tiết cụ thể của giao dịch thông qua bloxy.info.

Bằng cách truy vấn các chi tiết của giao dịch, chúng tôi phát hiện ra rằng trước tiên kẻ tấn công đã trao đổi một số imBTC cho Uniswap thông qua chức năng ethToTokenSwapInput, sau đó lần đầu tiên trao đổi imBTC lấy ETH thông qua chức năng tokenToEthSwapInput, sau đó Uniswap lần đầu tiên chuyển ETH cho kẻ tấn công. và sau đó được gọi là hàm transferFrom của imBTC, vì imBTC triển khai tiêu chuẩn ERC777 nên khi gọi hàm transferFrom của imBTC, imBTC sẽ gọi hàm tokensToSend của kẻ tấn công. Sau đó, trong chức năng tokensToSend của kẻ tấn công, kẻ tấn công sẽ đổi imBTC lấy ETH lần thứ hai, sau đó quá trình kết thúc.

Từ các chi tiết giao dịch, dường như không có vấn đề gì ở đây và chúng tôi tiếp tục tuân theo mã của UniSwap.

Đoạn mã trên là mã của hàm ethToTokenSwapInput của Uniswap. Theo phân tích mã, hàm ethToTokenSwapInput của Uniswap sẽ gọi hàm ethToTokenInput, sau đó trước tiên lấy số lượng eth có thể đổi lấy mã thông báo thông qua getInputPrice, sau đó gửi eth cho người dùng thông qua chức năng gửi và cuối cùng là Chuyển mã thông báo vào hợp đồng thông qua transferFrom. Hãy chuyển sang hàm getInputPrice.

Qua việc phân tích hàm getInputPrice, chúng ta có thể biết được công thức tính số ETH thu được là

Theo công thức này, trong quá trình trao đổi imBTC bình thường lấy ETH, dự trữ imBTC làm mẫu số sẽ tăng sau khi trao đổi và dự trữ ETH tương ứng sẽ giảm.

Nhưng xem lại phương thức hoạt động của kẻ tấn công, khi kẻ tấn công gửi imBTC đến ETH lần đầu tiên, Uniswap sẽ gửi ETH cho kẻ tấn công trước, lúc này dự trữ ETH trong Uniswap giảm xuống, sau đó Uniswap gọi hàm transferFrom, ( lưu ý là tại thời điểm này imBTC của kẻ tấn công chưa bị khấu trừ), và sau đó khi kẻ tấn công gọi ethToTokenSwapInput lần thứ hai trong hàm transferFrom, công thức để lấy số ETH đã trao đổi thông qua getInputPrice sẽ như sau:

• Lưu ý rằng trong phép tính trao đổi thứ hai, chỉ có lượng dự trữ của ETH giảm mà lượng dự trữ của imBTC không tăng, dẫn đến so với việc gọi riêng hàm ethToTokenSwapInput, kẻ tấn công có thể sử dụng imBTC để trao đổi trong quá trình này. ETH lần thứ hai, tử số của công thức tính đã thay đổi, nhưng mẫu số của công thức sẽ không thay đổi. So với trao đổi thông thường, trao đổi thứ hai do kẻ tấn công thực hiện thông qua phương thức nhập lại sẽ thu được một khoản lợi nhuận nhỏ, dẫn đến lợi nhuận. Bằng cách lặp lại quy trình này, có thể thu được nhiều ETH hơn thông qua cùng một lượng imBTC, dẫn đến việc các nhà khai thác kinh doanh Uniswap bị lỗ.

• tiêu đề phụ

phương pháp phòng thủ

• Thêm cơ chế khóa vào các phương thức vận hành kinh doanh chính, chẳng hạn như: OpenZeppelin's ReentrancyGuard

• Khi phát triển hợp đồng, hãy sử dụng phong cách viết trước tiên thay đổi các biến của hợp đồng này, sau đó thực hiện các cuộc gọi bên ngoài

• Trước khi dự án được triển khai trực tuyến, một nhóm bảo mật xuất sắc của bên thứ ba được mời tiến hành kiểm tra bảo mật toàn diện để khám phá các vấn đề bảo mật tiềm ẩn nhiều nhất có thể

• Khi nhiều hợp đồng được kết nối, cũng cần kiểm tra bảo mật mã và bảo mật kinh doanh của hợp đồng nhiều bên và xem xét đầy đủ các vấn đề bảo mật trong sự kết hợp của các tình huống kinh doanh khác nhau

• Khi nhiều hợp đồng được kết nối, cũng cần kiểm tra bảo mật mã và bảo mật kinh doanh của hợp đồng nhiều bên và xem xét đầy đủ các vấn đề bảo mật trong sự kết hợp của các tình huống kinh doanh khác nhau

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

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

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

tiêu đề phụ

suy nghĩ cuối cùng