Mỗi dòng code đều kể một câu chuyện rủi ro. Và tuần này, USENIX Security '26 đã mở ra một cuốn truyện dài 65.340 trang – mỗi trang là một địa chỉ crypto có nguy cơ bị lạm dụng, với tổng thiệt hại hơn 574 triệu USD. Nhưng điều làm tôi giật mình không phải con số đó. Mà là: hai vector tấn công chủ động mới được mô tả chỉ chiếm 2,7% – khoảng 15,7 triệu USD. Phần còn lại đi đâu? Và tại sao chúng ta lại mải mê với những kẻ tấn công tinh vi mà quên mất kẻ thù nằm ngay trong dòng code của chính mình?
Hãy cùng tôi lật từng lớp của nghiên cứu này – không chỉ để hiểu chuyện gì đã xảy ra, mà để thấy rõ hơn bức tranh bảo mật mà chúng ta đang sống cùng.
Context: Khi GitHub trở thành mỏ vàng cho kẻ trộm
Nhóm nghiên cứu đã đào sâu vào 63.004 kho lưu trữ GitHub từ tháng 1/2015 đến tháng 5/2025, kết hợp với kho lưu trữ Stack Exchange tháng 4/2025. Họ trích xuất hơn 16,3 triệu private key đã được khử trùng lặp từ GitHub. Từ đó, họ suy ra địa chỉ và kết hợp với các quy tắc mẫu giao dịch cũng như thực thi ký hiệu nhẹ trên Ethereum và BNB Smart Chain. Kết quả: 65.340 địa chỉ rủi ro, với 126.982,94 ETH và 17.726,7 BNB bị mất, ước tính hơn 574,8 triệu USD theo giá tham chiếu tháng 5/2025 (4.408 USD/ETH, 847 USD/BNB).
Điều đáng nói: precision 99,11% – nghĩa là gần như mọi địa chỉ được gắn nhãn 'rủi ro' đều thực sự có vấn đề. Nhưng precision này đo độ chính xác của phát hiện, không phải nguyên nhân trực tiếp của toàn bộ 574 triệu USD. Hai vector tấn công chủ động mới chỉ giải thích 3.472,23 ETH và 465,24 BNB – tương đương 2,7%.
Core: Hai con quỷ trong chi tiết kỹ thuật
Vector 1 – Contract-account misuse: Bẫy từ địa chỉ deterministic
Hãy tưởng tượng: Một kẻ tấn công triển khai hợp đồng thông minh trên testnet tại một địa chỉ cụ thể. Sau đó, hắn đợi người dùng – vì lý do nào đó – gửi tiền vào địa chỉ đó trên mainnet, nơi chưa có code. Giao dịch thành công như một chuyển khoản đơn giản, nhưng không thực thi chức năng nào. Tiền nằm im đó. Kẻ tấn công sau đó tận dụng tính năng deterministic contract addressing (địa chỉ hợp đồng được xác định trước dựa trên nonce và địa chỉ deployer) để triển khai một hợp đồng độc hại tại cùng địa chỉ đó trên mainnet, cho phép rút tiền. Nghiên cứu xác định 469 hợp đồng độc hại liên quan đến 3.446,37 ETH và 431,79 BNB bị mất.
Đây không phải lỗi của giao thức. Đây là lỗi của người dùng không kiểm tra chain ID, hoặc của các dApp hiển thị sai địa chỉ. Nhưng cũng là lỗi của thiết kế: tính deterministic vốn là tính năng, nhưng khi kết hợp với sự bất cẩn, nó trở thành lỗ hổng.
Vector 2 – Exposed key + EIP-7702: Tấn công trong một giao dịch
Khi private key bị lộ (thường từ GitHub, mã nguồn mở, hoặc ví bị tấn công), bất kỳ ai cũng có thể kiểm soát tài khoản. Các bot sweep tự động có thể chạy đua để rút tiền đến. Nhưng vector thứ hai còn nguy hiểm hơn: sử dụng EIP-7702 (cho phép một EOA ủy quyền cho code hợp đồng). Kẻ tấn công dùng key bị lộ để ủy quyền tài khoản cho một hợp đồng độc hại, và trong cùng một giao dịch, số tiền gửi vào sẽ được chuyển thẳng đến địa chỉ của kẻ tấn công. Phân tích chi tiết xác định hơn 17.200 địa chỉ được ủy quyền và thiệt hại 25,86 ETH cùng 33,45 BNB.
EIP-7702 là một cải tiến cho UX, nhưng khi private key đã lộ, nó trở thành công cụ hoàn hảo cho kẻ trộm. Một lần nữa: không phải lỗi của EIP, mà là lỗi của quản lý khóa.
Contrarian: 97,3% còn lại – Kẻ thù là sự bất cẩn
Điều tôi thấy phản trực giác nhất: hai vector chủ động chỉ chiếm 2,7% tổn thất. Vậy 97,3% kia đến từ đâu? Đó là contract-account misuse và exposed-key misuse ở dạng thụ động – tiền bị mắc kẹt tại các địa chỉ không có code, hoặc bị rút từ từ bởi các bot sweep. Nhưng gốc rễ vẫn là một: private key bị lộ trên GitHub, hoặc người dùng gửi tiền nhầm chain.
Trong 13 năm quan sát ngành, tôi chưa bao giờ thấy một con số nào nói rõ hơn về sự lười biếng của chúng ta. Chúng ta xây dựng zk-rollup, sharding, cross-chain bridges, nhưng lại để private key trong mã nguồn mở. Chúng ta nói về bảo mật L2, nhưng quên rằng lớp bảo mật đầu tiên là thói quen của người dùng và nhà phát triển.
Lớp 2 không chỉ là mở rộng, mà còn là bảo vệ – nhưng bảo vệ bắt đầu từ việc không hardcode key trong GitHub. Tôi đã từng audit Kyber Network năm 2018, thấy lỗi tương tự: một dòng code testnet lọt vào production. Kết quả? 5 ETH thưởng cho tôi, nhưng bài học đắt hơn nhiều.
Takeaway: Dự báo lỗ hổng và câu hỏi cho tương lai
Nghiên cứu này là hồi chuông cảnh tỉnh. Khi hệ sinh thái L2 phát triển, deterministic addressing sẽ càng trở nên phổ biến (ví dụ: địa chỉ hợp đồng trên Optimism, Arbitrum đều được tính toán giống nhau). Kẻ tấn công có thể dễ dàng triển khai bẫy trên nhiều chain. EIP-7702 cũng sẽ được áp dụng rộng rãi hơn, và nếu private key vẫn lộ, hậu quả sẽ nhân lên.
Câu hỏi cho chúng ta: Bạn có biết private key của mình đã từng xuất hiện trên GitHub không? Bạn có kiểm tra chain ID trước mỗi giao dịch không? Nếu câu trả lời là 'không', thì 574 triệu USD kia chỉ là phần nổi của tảng băng. Và tảng băng đó, mỗi ngày một lớn hơn.