Ngày 07/10/2022 vừa qua, cộng đồng crypto trên toàn thế giới được một phen rúng động khi BNB Chain bị tấn công vào cầu nối BSC Token Hub giữa BNB Beacon Chain (BEP2) và BNB Chain (BEP20 hay BSC). Theo ước tính ban đầu, hacker khai thác được 2 triệu token BNB (khoảng 600 triệu USD) và đã chuyển ra khỏi BNB Chain số tiền mã hoá trị giá gần 90 triệu USD.
Chia sẻ trên Diễn Đàn Phổ Cập Blockchain, ông Nguyễn Lê Thành, Chủ tịch HĐQT không điều hành tại Verichains và Polaris Infosec, cho biết, do BNB Chain sao chép đoạn code của blockchain Cosmos để xây dựng nền tảng, nên lỗi mà BNB Chain gặp phải nằm ở trên nền tảng blockchain Cosmos và bị hacker khai thác lỗ hổng.
Cần lưu ý việc khai thác không chỉ có thể xảy ra trên BNB Chain. Hacker đã khai thác lỗi IAVL Proof trong Tendermint Core và bất kỳ chuỗi nào sử dụng Tendermint Core, cụ thể là IAVL Proof, đều có thể bị tấn công.
“Những dự án hiện đang sao chép code của Cosmos để xây dựng cần đánh giá lại những phần code được sử dụng có gặp các lỗ hổng tương tự hay không, nếu phát hiện phải có biện pháp khắc phục ngay”, ông Thành lưu ý.
Đánh giá sơ bộ
Giao tiếp giữa chuỗi chéo BNB Chain và BNB Smart Chain dựa trên kỹ thuật light customer. Một hợp đồng thông minh được triển khai trên BNB Smart Chain để theo dõi trạng thái đồng thuận của BNB Chain bao gồm appHash (tương tự như stateRoot của Ethereum), về cơ bản là gốc của một kho lưu trữ key-value có thể xác minh được thực hiện dưới dạng cây AVL. Tin nhắn đến từ BNB Chain sẽ được xác minh dựa trên appHash để đảm bảo tính toàn vẹn của chúng.
Kho cho phép các cặp key-value liên tiếp được chứng minh hàng loạt (hiệu suất tốt hơn chứng minh từng cặp riêng lẻ). Tuy nhiên, logic xác minh bằng chứng phạm vi của nó chứa một lỗi nghiêm trọng có thể được khai thác để chứng minh tư cách thành viên của các cặp key-value tùy ý do kẻ tấn công chọn.
Theo ông Thành, Binance đang sử dụng và vận hành hai chain khác nhau, BNB Chain đang sao chép code của Cosmos, trong khi BNB Smart Chain đang dựa trên nền tảng Ethereum, BNB Chain hiện đóng vai trò như một cầu nối (bridge) giữa các chain này. Khi bridge xảy ra sự cố, họ đã đóng bridge để khắc phục. Đây là lỗi nền tảng nên các dự án sẽ không thể can thiệp.
Bằng chứng IAVl
Kẻ tấn công đã khai thác việc chứng thực của IAVL (tương tự như Merkle Proof). Một giao dịch hợp lệ phải gửi bằng chứng có chứa “a verification path”, “a list of leaves” và danh sách “InnerNodes”. Một giao dịch được xác minh nếu:
- Giá trị băm gốc (the root hash): tính từ bằng chứng bằng với giá trị băm gốc trên chuỗi.
- Tất cả các kiểm tra đệ quy đều hợp lệ.
Đường dẫn xác minh là một mảng có hai trường (left, right), mỗi trường là 32 byte. Leaf có thể băm, InnerNodes tương tự như các đường dẫn xác minh nhưng để kiểm tra đệ quy.
Bây giờ sẽ phải học cách tính toán hàm băm gốc từ “a path” và “leaf”.
Gốc được tính bằng cách băm nhiều lần (giống như trong Merkle Proof) như trong mã giả bên dưới.
Các bạn có thể đã thấy logic lỗi ở đây: “Điều gì sẽ xảy ra nếu cả bên trái và bên phải đều tồn tại?”. Nếu cả hai “left” và “right” tồn tại, thông báo sẽ bỏ qua right. Do đó, nếu đường dẫn xác minh chứa tất cả các mục có cả “left” và “right”, gốc là không thay đổi với bất kỳ giá trị right tùy ý nào (sử dụng cùng một leaf). Đây là một yếu tố cần được khai thác.
Một yếu tố khác nằm trong kiểm tra đệ quy. Hãy bắt đầu giải thích từ khi bắt đầu quy trình xác minh.
Giả sử có một cây có 4 leaf: leaf 1, leaf 2, leaf 3, leaf 4. Và khi muốn tạo ra một chứng thực phạm vi cho leaf 2 và leaf 3. Bắt đầu bằng việc tính toán phần gốc/root. Sau đó, nó tiếp tục từ leaf 2 cho đến khi tồn tại right và tính toán giá trị băm của cả cây với gốc là right. Trong hình minh họa, A.right giữ phần gốc của cây mới có chứa leaf 3. Đối với nút leaf 3, nó tính toán giá trị băm gốc và chỉ xác thực nếu nó bằng A.right.
Vậy vấn đề gì đã xảy ra với quy trình kiểm tra đệ quy này? Bản thân nó không sai. Nhưng nếu kết hợp điều này với yếu tố trên, nơi các giá trị right hoàn toàn không được sử dụng khi tính toán băm gốc, nó sẽ trở thành một vấn đề nghiêm trọng và khiến cuộc tấn công có thể xảy ra.
Lỗi
Đối với bất kỳ bằng chứng nào, bằng cách giữ các giá trị left trong đường dẫn xác minh và chính hãng trước, có thể chèn một nút lá đáp ứng việc xác minh miễn là có kiểm tra đệ quy với giá trị InnerNodes bằng right tại một số điểm trong đường dẫn xác minh. Như đã nêu ở trên, gốc không thay đổi trong khi các giá trị right được thay đổi. Vì vậy, có thể thay đổi các giá trị right thỏa mãn lá mới được chèn vào. Trong payload của kẻ tấn công, họ đã sử dụng InnerNodes = {}[nil]. Điều này là để làm cho giá trị right dễ dàng sửa đổi hơn khi giá trị băm gốc cho InnerNodes, leaf là hash(leaf).
Đề xuất cho các bản sửa lỗi
Chủ tịch Verichain Labs chia sẻ, lỗ hổng này sẽ được khắc phục, tuy nhiên những dự án hiện đang xây dựng dựa trên blockchain Cosmos đều có nguy cơ bị khai thác với hình thức tương tự.
Cách khắc phục đơn giản nhất là loại bỏ tất cả các bằng chứng bao gồm bất kỳ mục nào tồn tại cả hai giá trị “left” và “right”. Xác nhận chỉ nên đủ điều kiện hoặc “(nil, right)” hoặc “(left, nil)”. Ngoài ra, thiết kế có thể được thay đổi để sử dụng hết tất cả giá trị “left” và “right” các giá trị để tạo ra hàm băm gốc.
“BNB Chain là một đối tác của Verichains, hiện tại chúng tôi đang phối hợp tích cực với họ để đưa ra những biện pháp kịp thời nhằm khắc phục sự cố”, ông Thành nói thêm.
Kết luận
Vụ tấn công vào BNB Chain là một tổn thất nghiêm trọng khác đối với các nhà phát triển chuỗi và Binance. Điều nguy hiểm hơn là việc khai thác nằm trong Tendermint Core, được sử dụng trong nhiều chuỗi trong hệ sinh thái Cosmos. Verichains Labs khuyên tất cả các chuỗi sử dụng Tendermint nên kiểm tra sơ bộ và áp dụng cách khắc phục đơn giản để ngăn chặn cuộc tấn công n-day.
Được biết, sau khi BNB Chain đưa ra bản vá lỗi, Verichains sẽ đánh giá lại và công bố sau.
