Khi xuất hiện tin một bridge crypto bị hack, con số được công bố đầu tiên thường chưa phải thiệt hại cuối cùng. Dòng tiền quan sát trên blockchain có thể bao gồm tài sản bị rút khỏi hợp đồng, token được đúc trái phép, giao dịch chuyển tiếp giữa các ví, giao dịch hoán đổi và phần tiền đã bị đóng băng hoặc thu hồi.
Để đánh giá đúng sự cố, cần đối chiếu bốn lớp thông tin: thông báo ban đầu của dự án, giao dịch on-chain, phạm vi tài sản thực sự bị ảnh hưởng và báo cáo hậu kiểm. Đặc biệt, phải tách riêng số tiền bị dịch chuyển, thiệt hại đã xác nhận, tài sản đã thu hồi và cam kết bồi thường chưa hoàn tất.
Bridge crypto bị hack cần kiểm chứng những gì?
Bridge hay cầu nối blockchain cho phép chuyển giá trị hoặc thông điệp giữa các mạng. Tùy thiết kế, cầu nối có thể khóa tài sản ở chuỗi nguồn rồi phát hành token đại diện ở chuỗi đích, sử dụng các bể thanh khoản hoặc dựa vào một nhóm trình xác thực để xác nhận thông điệp liên chuỗi.
Vì vậy, cụm từ bridge crypto bị hack có thể chỉ nhiều tình huống khác nhau:
- Hợp đồng thông minh có lỗi khiến kẻ tấn công rút tài sản khỏi kho lưu ký.
- Cơ chế xác thực thông điệp bị vượt qua, dẫn đến việc đúc token không có tài sản bảo chứng.
- Khóa quản trị hoặc khóa của trình xác thực bị lộ.
- Tài khoản triển khai, giao diện hoặc hệ thống ký giao dịch bị xâm nhập.
- Người dùng bị dẫn tới trang giả mạo và ký cấp quyền cho hợp đồng độc hại.
- Dự án chủ động tạm dừng bridge vì phát hiện dấu hiệu bất thường nhưng chưa xác nhận có thất thoát.
Do đó, thông báo tạm dừng cầu nối không đồng nghĩa bridge đã mất toàn bộ tài sản. Ngược lại, việc bridge hoạt động trở lại cũng không tự động chứng minh mọi khoản thiếu hụt đã được xử lý.
Một bản tin đáng tin cậy nên trả lời được các câu hỏi sau:
- Sự cố xảy ra trên chuỗi, hợp đồng và phiên bản bridge nào?
- Giao dịch nào được xác định là điểm bắt đầu?
- Tài sản nào bị rút, đúc hoặc chuyển trái phép?
- Số tiền được tính theo lượng token hay giá trị quy đổi tại thời điểm nào?
- Khoản nào vẫn do kẻ tấn công kiểm soát, khoản nào đã bị chặn hoặc thu hồi?
- Dự án đã bồi thường thực tế hay mới công bố kế hoạch?
- Nguyên nhân gốc đã được xác nhận trong post-mortem hay vẫn đang điều tra?
Phân biệt tiền bị dịch chuyển, thiệt hại và bồi thường
Sai lệch phổ biến trong tin tức crypto là dùng một con số duy nhất cho toàn bộ sự cố. Để tránh cộng trùng hoặc đánh đồng cam kết với kết quả, nên chia dữ liệu thành bốn nhóm.
Số tiền bị dịch chuyển
Đây là tổng tài sản xuất hiện trong các giao dịch liên quan đến sự cố. Con số này có thể lớn hơn thiệt hại thực vì cùng một lượng token được chuyển qua nhiều ví, đổi sang tài sản khác hoặc đưa qua nhiều blockchain.
Ví dụ, một khoản token bị rút khỏi bridge rồi chuyển qua hai địa chỉ khác không tạo ra ba khoản thiệt hại. Mỗi lần chuyển chỉ là một bước trong đường đi của cùng tài sản. Tương tự, giá trị ở chuỗi nguồn và token đại diện được phát hành ở chuỗi đích có thể là hai phía của cùng một nghĩa vụ, không nên mặc nhiên cộng lại.
Thiệt hại đã xác nhận
Thiệt hại bridge crypto chỉ nên được ghi nhận là đã xác nhận khi có đủ căn cứ cho thấy tài sản bị rút hoặc phát hành trái phép và nằm ngoài quyền kiểm soát hợp pháp của giao thức hoặc người dùng.
Khi quy đổi sang tiền pháp định hoặc stablecoin, báo cáo cần nói rõ thời điểm định giá. Giá token biến động có thể khiến các bài viết đưa ra con số khác nhau dù cùng dựa trên một lượng tài sản. Nếu nguồn không công bố phương pháp định giá, nên ưu tiên ghi số lượng token và mô tả giá trị quy đổi là ước tính.
Thiệt hại của giao thức và thiếu hụt của người dùng cũng không phải lúc nào giống nhau. Giao thức có thể chịu tổn thất từ kho dự trữ nhưng vẫn thanh toán đầy đủ cho người dùng; ngược lại, tài sản trong hợp đồng có thể còn đó nhưng token đại diện đã mất khả năng quy đổi theo tỷ lệ ban đầu.
Tài sản đã thu hồi
Khoản thu hồi là tài sản đã quay lại địa chỉ do dự án, đơn vị giám sát hoặc cơ chế quản trị hợp pháp kiểm soát. Tài sản chỉ bị theo dõi, đưa vào danh sách chặn hoặc nằm tại một địa chỉ được cho là của sàn giao dịch chưa nên được gọi là đã thu hồi.
Cần phân biệt các trạng thái:
- Đã xác định vị trí: biết tài sản đang ở đâu nhưng chưa kiểm soát được.
- Đã đóng băng: tài sản chưa thể di chuyển nhưng thủ tục xử lý có thể chưa hoàn tất.
- Đã hoàn trả: tài sản đã được gửi về địa chỉ tiếp nhận hợp pháp.
- Đã phân phối: khoản thu hồi đã được trả cho người dùng hoặc đưa vào quỹ xử lý thiếu hụt.
Các trạng thái này không thể thay thế cho nhau khi tính số tiền còn thiếu.
Cam kết bồi thường chưa hoàn tất
Cam kết bồi thường là kế hoạch, không phải khoản tiền đã thu hồi. Dự án có thể đề xuất dùng quỹ dự phòng, doanh thu tương lai, token mới hoặc khoản vay để bù đắp, nhưng chỉ nên ghi nhận là đã bồi thường khi người dùng thực sự nhận được tài sản theo điều kiện được công bố.
Một kế hoạch bồi thường cần được kiểm tra về nguồn tiền, đối tượng đủ điều kiện, cách xác định số dư, loại tài sản thanh toán, tiến độ và các giới hạn áp dụng. Token bồi thường có thanh khoản thấp hoặc bị khóa cũng không tương đương hoàn toàn với tài sản ban đầu.
Vì vậy, không nên lấy thiệt hại đã xác nhận rồi tự động trừ cam kết bồi thường. Báo cáo nên trình bày riêng số đã thu hồi, số đã chi trả và nghĩa vụ còn lại.
Cách đối chiếu thông báo ban đầu với dữ liệu on-chain
Thông báo đầu tiên thường được phát hành khi đội ngũ vẫn đang điều tra. Mục tiêu của thông báo này có thể chỉ là cảnh báo người dùng, tạm dừng hợp đồng hoặc ngăn dòng tiền tiếp tục thoát ra. Các con số ban đầu vì thế có thể được điều chỉnh trong những bản cập nhật sau.
Bước 1: Xác minh nguồn thông báo
Ưu tiên website chính thức, trang trạng thái, tài khoản mạng xã hội đã được dự án công bố từ trước, kho mã nguồn và diễn đàn quản trị. Không nên tin ảnh chụp màn hình nếu chưa tìm thấy nội dung gốc.
Cần ghi nhận chính xác cách dự án diễn đạt. Các cụm từ đang điều tra, hoạt động bất thường, nghi bị khai thác và đã xác nhận sự cố thể hiện mức độ chắc chắn khác nhau. Nếu thông báo chưa nêu số tiền, không nên dùng ước tính của bên thứ ba như số liệu chính thức.
Bước 2: Xác định chuỗi và hợp đồng liên quan
Một bridge có thể triển khai nhiều hợp đồng trên nhiều mạng. Sự cố ở một hợp đồng không nhất thiết ảnh hưởng toàn bộ hệ thống. Hãy đối chiếu địa chỉ hợp đồng trong thông báo với tài liệu dự án, kho mã nguồn hoặc lịch sử triển khai đã được xác thực.
Khi phân tích địa chỉ, cần xem cả giao dịch gọi hợp đồng, sự kiện phát ra, luồng token và mối liên hệ giữa các ví. Hướng dẫn về cách đọc địa chỉ hoạt động on-chain có thể giúp tránh kết luận chỉ dựa trên số lượng giao dịch hoặc số dư hiện tại.
Bước 3: Kiểm tra giao dịch khởi đầu
Với mỗi giao dịch nghi vấn, nên kiểm tra:
- Trạng thái thành công, thất bại hay đang chờ xác nhận.
- Thời điểm và số khối.
- Địa chỉ gửi, địa chỉ nhận và hợp đồng được gọi.
- Hàm hợp đồng, dữ liệu đầu vào và sự kiện phát ra.
- Token, số lượng và địa chỉ hợp đồng token.
- Các lệnh gọi nội bộ hoặc giao dịch con.
- Phí gas và tài khoản trả phí nếu có cơ chế tài trợ giao dịch.
Trạng thái thành công chỉ cho biết giao dịch đã được blockchain thực thi, không chứng minh giao dịch đó hợp pháp. Nếu explorer chưa ghi nhận hoàn tất, nên kiểm tra thêm nguyên nhân giao dịch blockchain bị pending trước khi đưa nó vào tổng dòng tiền.
Bước 4: Theo dõi dòng tiền mà không cộng trùng
Bắt đầu từ giao dịch gốc, lập danh sách tài sản rời khỏi hợp đồng hoặc được phát hành bất thường. Sau đó theo dõi các lần chuyển, hoán đổi, cung cấp thanh khoản, gửi vào sàn hoặc chuyển qua một bridge khác.
Không cộng toàn bộ giá trị của mọi giao dịch liên tiếp. Cần nhận diện khi cùng một tài sản chỉ đổi địa chỉ, khi token A được đổi thành token B và khi một phần tiền được tách thành nhiều ví. Nếu tài sản đi vào sàn giao dịch, dữ liệu on-chain chỉ chứng minh khoản tiền đã vào địa chỉ được gắn nhãn; nó không chứng minh sàn đã đóng băng hoặc hoàn trả tài sản.
Bước 5: Đối chiếu hai phía của cầu nối
Đối với mô hình khóa và đúc, hãy so sánh lượng tài sản bị khóa ở chuỗi nguồn với nguồn cung token đại diện ở chuỗi đích. Một giao dịch đúc trái phép có thể tạo ra nghĩa vụ không được bảo chứng ngay cả khi kho tài sản ở chuỗi nguồn chưa bị rút.
Các bridge dựa trên bể thanh khoản cần kiểm tra số dư từng pool, khoản nợ giữa các chuỗi và khả năng rút thực tế. Với bridge truyền thông điệp, lỗi có thể ảnh hưởng nhiều ứng dụng sử dụng cùng lớp xác thực chứ không chỉ giao diện chuyển token.
Xác định phạm vi tài sản bị ảnh hưởng
Phạm vi sự cố không nên được suy ra từ tổng giá trị đang khóa của toàn bộ giao thức. Cần xác định cụ thể blockchain, hợp đồng, tài sản và khoảng thời gian bị ảnh hưởng.
Tài sản trực tiếp
Đây là token bị rút khỏi hợp đồng, bị đúc trái phép hoặc mất tài sản bảo chứng. Mỗi token phải được xác minh bằng địa chỉ hợp đồng, vì ticker giống nhau có thể đại diện cho các tài sản khác nhau.
Token đại diện trên chuỗi đích
Ngay cả khi token đại diện vẫn còn trong ví người dùng, nó có thể chịu rủi ro nếu tài sản bảo chứng đã thiếu hụt hoặc cơ chế quy đổi bị tạm dừng. Giá giảm trên thị trường thứ cấp là tín hiệu rủi ro, nhưng không tự động bằng giá trị thất thoát của bridge.
Tài sản trong bể thanh khoản
Nhà cung cấp thanh khoản có thể chịu ảnh hưởng khác với người chỉ chuyển tài sản qua cầu nối. Cần kiểm tra pool nào bị rút, việc nạp rút có bị dừng và token LP còn được bảo chứng bởi những tài sản nào.
Phí, kho bạc và tài sản không liên quan
Ví thu phí, kho bạc quản trị hoặc hợp đồng khác của cùng dự án không mặc nhiên bị ảnh hưởng. Chỉ nên đưa chúng vào phạm vi khi có giao dịch hoặc xác nhận rõ ràng. Việc một địa chỉ có liên hệ với dự án không đủ để kết luận toàn bộ số dư của địa chỉ đó đã mất.
Thiệt hại do thị trường
Giá token bridge hoặc token đại diện có thể giảm sau tin hack. Đây là tác động thị trường, khác với tài sản bị lấy khỏi hợp đồng. Báo cáo nên tách tổn thất kỹ thuật của giao thức khỏi biến động giá và khoản lỗ chưa thực hiện của người nắm giữ.
Cách đọc báo cáo hậu kiểm của crypto bridge
Post-mortem crypto bridge là báo cáo được công bố sau khi dự án đã có thêm thời gian điều tra. Một báo cáo hậu kiểm hữu ích không chỉ mô tả hậu quả mà phải giải thích chuỗi sự kiện, nguyên nhân gốc và biện pháp ngăn tái diễn.
Dòng thời gian
Dòng thời gian nên bao gồm thời điểm giao dịch khai thác đầu tiên, lúc hệ thống phát hiện bất thường, thời điểm bridge bị tạm dừng, các biện pháp khẩn cấp và quá trình khôi phục. Mốc thời gian cần gắn với múi giờ hoặc số khối để có thể đối chiếu.
Nguyên nhân gốc
Báo cáo cần chỉ ra lỗi nằm ở hợp đồng, cơ chế xác thực, quản lý khóa, cấu hình, quy trình vận hành hay giao diện người dùng. Mô tả có thể được cập nhật khi điều tra tiếp diễn, vì vậy nên phân biệt nguyên nhân đã xác nhận với giả thuyết ban đầu.
Việc dự án từng được kiểm toán không chứng minh phiên bản bị khai thác đã an toàn. Cần kiểm tra phạm vi kiểm toán, phiên bản mã nguồn, thay đổi sau kiểm toán và liệu lỗi có nằm trong phần đã được đánh giá hay không.
Bằng chứng on-chain
Một báo cáo sự cố cầu nối blockchain nên cung cấp địa chỉ hợp đồng, giao dịch gốc, địa chỉ liên quan và phương pháp tính thiệt hại. Nếu chỉ đưa ra con số tổng mà không có cách đối chiếu, người đọc nên xem đó là tuyên bố của dự án thay vì kết quả đã được kiểm chứng độc lập.
Biện pháp khắc phục
Các biện pháp có thể gồm nâng cấp hợp đồng, thay khóa, điều chỉnh số lượng người ký, thêm giới hạn rút, tăng thời gian chờ hoặc triển khai hệ thống giám sát. Cần đánh giá liệu biện pháp xử lý đúng nguyên nhân gốc hay chỉ giảm hậu quả tạm thời.
Kế hoạch phục hồi và bồi thường
Báo cáo phải tách rõ tài sản đã thu hồi, nguồn vốn bổ sung, khoản đã trả cho người dùng và phần còn chờ xử lý. Nếu bồi thường phụ thuộc vào biểu quyết quản trị, đàm phán hoặc doanh thu tương lai, trạng thái phù hợp vẫn là đề xuất hoặc cam kết chưa hoàn tất.
Người dùng nên làm gì sau sự cố?
Nếu đã tương tác với bridge bị nghi khai thác, người dùng nên dừng gửi thêm tài sản cho đến khi có xác nhận chính thức về việc khôi phục. Không truy cập liên kết nhận bồi thường từ tin nhắn riêng, bình luận mạng xã hội hoặc quảng cáo tìm kiếm.
Hãy kiểm tra lịch sử ví để xác định mình đã cấp quyền cho hợp đồng nào. Nếu quyền không còn cần thiết hoặc dự án khuyến cáo hủy, có thể thực hiện thu hồi quyền truy cập ví crypto bằng công cụ phù hợp với đúng blockchain. Việc thu hồi quyền không đảo ngược giao dịch đã hoàn tất và không khôi phục tài sản đã bị chuyển đi.
Trước mọi yêu cầu xác minh ví, nhận hoàn tiền hoặc di chuyển token, cần đọc kỹ tên miền, mạng, hợp đồng, loại chữ ký và quyền được yêu cầu. Quy trình kiểm tra chữ ký ví trước khi ký đặc biệt quan trọng vì kẻ gian thường lợi dụng thời điểm hỗn loạn sau sự cố để phát tán trang giả mạo.
Người dùng cũng nên lưu lại hash giao dịch, địa chỉ ví, số lượng tài sản và thời điểm tương tác. Những dữ liệu này có thể cần thiết nếu dự án mở cổng khai báo tổn thất. Không nên công khai seed phrase, khóa riêng tư hoặc ký thông điệp chỉ để chứng minh quyền sở hữu ví.
Checklist đánh giá tin bridge crypto bị hack
Trước khi chia sẻ một con số thiệt hại, có thể kiểm tra nhanh theo danh sách sau:
- Tin xuất phát từ nguồn chính thức hay chỉ là tài khoản tổng hợp?
- Dự án xác nhận bị khai thác hay mới thông báo đang điều tra?
- Địa chỉ hợp đồng và giao dịch gốc đã được công bố chưa?
- Con số đang nói đến dòng tiền dịch chuyển hay thiệt hại đã xác nhận?
- Có cộng trùng tài sản qua nhiều ví, nhiều giao dịch hoặc hai phía của bridge không?
- Giá trị quy đổi được tính tại thời điểm nào?
- Tài sản bị ảnh hưởng trực tiếp hay chỉ giảm giá trên thị trường?
- Khoản được gọi là thu hồi đã nằm trong quyền kiểm soát hợp pháp chưa?
- Bồi thường đã được thanh toán hay mới là đề xuất?
- Post-mortem đã xác nhận nguyên nhân gốc và biện pháp khắc phục chưa?
Kết luận đáng tin cậy thường cần nhiều hơn một thông báo hoặc một giao dịch. Dữ liệu blockchain giúp xác minh dòng tiền, nhưng không phải lúc nào cũng chứng minh được danh tính, quyền sở hữu pháp lý hay nguyên nhân kỹ thuật. Vì vậy, khi đưa tin bridge crypto bị hack, cách trình bày an toàn nhất là ghi rõ nguồn, thời điểm cập nhật và mức độ xác nhận của từng con số thay vì gộp mọi thông tin thành một ước tính duy nhất.
