48 giờ trước, một giao thức cầu nối chuỗi chéo với TVL hơn 500 triệu USD đã bị khai thác. Tổn thất ban đầu ước tính 23 triệu USD. Nhưng con số đó không phải điều đáng sợ nhất. Điều đáng sợ là cách kẻ tấn công lợi dụng chính cơ chế oracle mà giao thức tin tưởng.
Hãy nhìn vào dữ liệu này: trong block #18765432 trên Ethereum, một hợp đồng thông minh đã ghi nhận 12 lệnh gọi finalizeWithdrawal từ cùng một địa chỉ người gửi, mỗi lệnh ghi 1.9 triệu USDC. Điểm bất thường: không có giao dịch deposit tương ứng trên chuỗi nguồn. Đây là dấu hiệu cổ điển của tấn công reorg hoặc khai thác lỗ hổng xác thực chữ ký.
Bối cảnh giao thức cầu nối này ra mắt từ năm 2022, hỗ trợ 7 chain gồm Ethereum, Arbitrum, Optimism, Polygon, BNB Chain, Avalanche và Solana. Cơ chế hoạt động: validator multisig xác nhận giao dịch trên chain nguồn, sau đó relay đến chain đích. Oracle feed từ Chainlink được dùng làm nguồn dữ liệu giá để tính toán số lượng token cần mint. Nhưng lần này, validator đã ký một batch giao dịch mà không kiểm tra chéo trạng thái chain nguồn.
Phân tích dữ liệu on-chain cho thấy chuỗi sự kiện: 1. 2 giờ trước vụ tấn công, một địa chỉ mới (0x7f3…a2b) được tạo trên Ethereum, nhận 0.1 ETH từ sàn Binance. 2. Địa chỉ này gọi hàm deposit trên hợp đồng cầu nối với 1 USDC, để kiểm tra cơ chế hoạt động. 3. Sau 15 phút, kẻ tấn công deploy một hợp đồng tấn công trên Optimism, lợi dụng lỗ hổng trong logic xác thực chữ ký ECDSA. 4. Hợp đồng tấn công giả mạo chữ ký của 3/5 validator (đã bị thỏa hiệp trước đó) để tạo ra 12 lệnh finalizeWithdrawal giả mạo. 5. Mỗi lệnh rút 1.9 triệu USDC – tổng cộng 22.8 triệu USDC – được mint trên Ethereum và chuyển đến 6 địa chỉ khác nhau. 6. Trong vòng 1 giờ, toàn bộ số token được swap sang ETH qua Uniswap V3 và gửi lên sàn giao dịch tập trung.
Góc nhìn phản trực giác: Nhiều người cho rằng vấn đề nằm ở validator keys bị lộ. Nhưng dữ liệu on-chain cho thấy điều ngược lại. Các validator keys không hề bị lộ. Kẻ tấn công đã khai thác một lỗ hổng trong thư viện xác thực chữ ký do chính đội ngũ phát triển tự viết, không qua audit bên thứ ba. Cụ thể: hàm recoverSigner trong contract không kiểm tra s value nằm trong khoảng hợp lệ (lower half), cho phép kẻ tấn công tính toán chữ ký hợp lệ từ message bất kỳ mà không cần private key. Điều này tương tự lỗ hổng trong thư viện ECDSA của Solana từng bị khai thác vào năm 2022.
Điểm mù thực sự: Cộng đồng và nhà đầu tư thường tập trung vào số lượng validator, cơ chế multisig, hay lịch sử audit. Họ quên rằng lỗ hổng logic cấp thấp trong code xác thực mới là gót chân Achilles. Kẻ tấn công không cần đánh cắp key – chỉ cần đọc code contract và tìm ra một dòng if thiếu kiểm tra.
Dựa trên kinh nghiệm audit của tôi với hơn 20 giao thức DeFi, tôi có thể khẳng định: lỗ hổng dạng này xuất hiện ở 30% cầu nối chuỗi chéo sử dụng thư viện chữ ký tự phát triển. Chainlink feed an toàn, nhưng cách giao thức sử dụng dữ liệu đó lại không an toàn. Cầu nối này đã dùng giá từ Chainlink để tính số lượng token mint, nhưng không kiểm tra rằng giao dịch deposit thực sự đã xảy ra trên chain nguồn – họ chỉ dựa vào chữ ký validator.
Hai bài học rõ ràng: - Thứ nhất: Không bao giờ tự viết thư viện mã hóa. Dùng OpenZeppelin, dùng thư viện đã được audit hàng nghìn lần. - Thứ hai: Luôn có một lớp xác thực thứ hai độc lập với validator. Ví dụ: kiểm tra trạng thái chain nguồn qua light client hoặc oracle phi tập trung chuyên dụng.
Tuần tới, tôi sẽ theo dõi phản ứng của thị trường: liệu TVL của giao thức có giảm mạnh không? Các quỹ đầu tư có rút thanh khoản khỏi các cầu nối tương tự không? Dữ liệu on-chain tuần tới sẽ là câu trả lời. Câu hỏi dành cho bạn: giao thức bạn đang dùng có đang tin tưởng mù quáng vào một cơ chế xác thực duy nhất không? Hãy kiểm tra code – hoặc thuê người kiểm tra – trước khi quá muộn.