Binance Chain đã bị tấn công với gần 600 triệu USD giá trị tài sản và khoảng 90 triệu USD được chuyển ra khỏi hệ sinh thái Binance. Dưới đây chúng tôi đã viết một bài phân tích về cách các khai thác được sử dụng đồng thời đưa ra các đề xuất bản sửa lỗi.
Vào ngày 7 tháng 10 năm 2022, Binance Chain đã bị tấn công với gần 600 triệu USD giá trị tài sản và khoảng 90 triệu USD được chuyển ra khỏi hệ sinh thái Binance. Vụ hack được thực hiện trong một giao dịch mà Binance Bridge gửi một lượng lớn BNB native.
Xem thêm: Binance xác nhận vụ hack BNB cross chain và mạng đã phải tạm dừng
Mặc dù biết về vụ hack bridge hơi muộn nhưng nhóm của chúng tôi đã nhanh chóng điều tra nguyên nhân gốc rễ của vụ tấn công và tìm ra cách khai thác hoạt động sau 2 giờ xem xét việc triển khai các mã liên quan. Bài viết đã được gửi đến nhóm Binance và chúng tôi đang làm việc với BNB Chain để khắc phục sự cố.
Chúng tôi cần lưu ý rằng việc khai thác không độc quyền trên Binance 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 bị tấn công.
Sơ bộ
Quá trình giao tiếp cross-chain từ BC đến BSC dựa trên kỹ thuật light client. Một smart contract được triển khai trên BSC để theo dõi trạng thái đồng thuận của BC bao gồm appHash (tương tự như stateRoot của Ethereum), về cơ bản nó là gốc của kho lưu trữ key-value có thể xác minh được dưới dạng AVL tree. Thông báo đến từ BC sẽ được xác minh dựa trên appHash để có thể đảm bảo tính toàn vẹn của chúng.
Cửa hàng 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 mà kẻ tấn công có thể xâm nhập vào và chứng minh tư cách thành viên của các cặp key-value tùy ý.
IAVl Proof
Kẻ tấn công đã khai thác bằng chứng phạm vi của IAVL Proof (tương tự như Merkel Proof). Một giao dịch hợp lệ phải gửi bằng chứng có chứa đường dẫn xác minh (verification path), danh sách các leaves (list of leaves) và danh sách của InnerNodes. Một giao dịch được xác minh nếu:
1. Giá trị hash (tính từ bằng chứng) bằng với giá trị hash trên chuỗi.
2. Tất cả các kiểm tra đều phải hợp lệ
Đường dẫn xác minh là một mảng có hai trường (trái, phải), mỗi trường là 32 byte. Leaf có thể hash, các InnerNodes tương tự như các đường dẫn xác minh nhưng để kiểm tra đệ quy.
Bây giờ chúng ta học cách tính toán hash từ một path và leaf.
Gốc được tính bằng cách hash nhiều lần (giống như trong Merkel proof) như trong mã giả (pseudocode) bên dưới:
Độc giả 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 tồn tại cả left và right, thông báo sẽ bỏ qua trường right. Do đó, nếu đường dẫn xác minh chứa tất cả các mục có cả left và right, thì phần gốc sẽ 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 giải thích kể từ khi bắt đầu quy trình xác minh.
Giả sử chúng ta có một cây có 4 leaves, leaf 1, leaf 2, leaf 3, leaf 4. Chúng ta muốn thực hiện một chứng minh phạm vi cho lá 2 và lá 3. Bắt đầu bằng cách tính gốc. Sau đó, nó đi lên từ leaf 2 cho đến khi right tồn tại và bắt đầu tính toán đệ quy giá trị hash root của cây có right root. Trong hình minh họa, A.right giữ gốc của cây mới chứa leaf 3. Đối với leaf 3, nó tính toán root hash và chỉ xác thực nếu nó bằng A.right.
Vậy điều gì có thể xảy ra trong các lần kiểm tra đệ quy này? Bản thân nó không sai. Nhưng nếu chúng ta kết hợp điều này với yếu tố trên trong đó các giá trị right hoàn toàn không được sử dụng khi tính toán root hash, 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.
The Bug
Đố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à genuine first leaf, chúng ta có thể đưa vào leaf node thỏa mãn việc xác minh miễn là chúng ta có thể kiểm tra đệ quy với một InnerNodes bằng giá trị right tại một số điểm trong đường dẫn xác minh. Như đã nêu ở trên, root không thay đổi khi các giá trị right được thay đổi. Vì vậy, chúng tôi có thể thay đổi các giá trị right thỏa mãn các leaf mới được chèn vào. Trong tải trọng 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 như là giá trị root hash cho InnerNodes, leaf là hash (leaf).
Đề xuất cho các bản sửa lỗi
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ả giá trị left và right. Xác nhận chỉ khi đủ điều kiện (nil, right) hoặc (left, nil). Ngoài ra, thiết kế có thể được thay đổi để sử dụng hết các giá trị left và right để tạo ra hàm root hash.
Kết luận
Vụ tấn công vào Binance Chain là một tổn thất nghiêm trọng khác đối với các nhà phát triển và Binance. Điều nguy hiểm hơn nữa 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. Chúng tôi 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ùng WETAG cập nhật các diễn biến tiếp theo sớm nhất tại đây. Đừng quên theo dõi TAG News để không bỏ lỡ các kèo Airdrop xịn mùa downtrend nhé!!!
https://t.me/TAGNewsVN
Nguồn: WETAG tổng hợp
Binance Chain đã bị tấn công với gần 600 triệu USD giá trị tài sản và khoảng 90 triệu USD được chuyển ra khỏi hệ sinh thái Binance. Dưới đây chúng tôi đã viết một bài phân tích về cách các khai thác được sử dụng đồng thời đưa ra các đề xuất bản sửa lỗi.
Vào ngày 7 tháng 10 năm 2022, Binance Chain đã bị tấn công với gần 600 triệu USD giá trị tài sản và khoảng 90 triệu USD được chuyển ra khỏi hệ sinh thái Binance. Vụ hack được thực hiện trong một giao dịch mà Binance Bridge gửi một lượng lớn BNB native.
Mặc dù biết về vụ hack bridge hơi muộn nhưng nhóm của chúng tôi đã nhanh chóng điều tra nguyên nhân gốc rễ của vụ tấn công và tìm ra cách khai thác hoạt động sau 2 giờ xem xét việc triển khai các mã liên quan. Bài viết đã được gửi đến nhóm Binance và chúng tôi đang làm việc với BNB Chain để khắc phục sự cố.
Chúng tôi cần lưu ý rằng việc khai thác không độc quyền trên Binance 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 bị tấn công.
Sơ bộ
Quá trình giao tiếp cross-chain từ BC đến BSC dựa trên kỹ thuật light client. Một smart contract được triển khai trên BSC để theo dõi trạng thái đồng thuận của BC bao gồm appHash (tương tự như stateRoot của Ethereum), về cơ bản nó là gốc của kho lưu trữ key-value có thể xác minh được dưới dạng AVL tree. Thông báo đến từ BC sẽ được xác minh dựa trên appHash để có thể đảm bảo tính toàn vẹn của chúng.
Cửa hàng 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 mà kẻ tấn công có thể xâm nhập vào và chứng minh tư cách thành viên của các cặp key-value tùy ý.
IAVl Proof
Kẻ tấn công đã khai thác bằng chứng phạm vi của IAVL Proof (tương tự như Merkel Proof). Một giao dịch hợp lệ phải gửi bằng chứng có chứa đường dẫn xác minh (verification path), danh sách các leaves (list of leaves) và danh sách của InnerNodes. Một giao dịch được xác minh nếu:
1. Giá trị hash (tính từ bằng chứng) bằng với giá trị hash trên chuỗi.
2. Tất cả các kiểm tra đều phải hợp lệ
Đường dẫn xác minh là một mảng có hai trường (trái, phải), mỗi trường là 32 byte. Leaf có thể hash, các InnerNodes tương tự như các đường dẫn xác minh nhưng để kiểm tra đệ quy.
Bây giờ chúng ta học cách tính toán hash từ một path và leaf.
Gốc được tính bằng cách hash nhiều lần (giống như trong Merkel proof) như trong mã giả (pseudocode) bên dưới:
Độc giả 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 tồn tại cả left và right, thông báo sẽ bỏ qua trường right. Do đó, nếu đường dẫn xác minh chứa tất cả các mục có cả left và right, thì phần gốc sẽ 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 giải thích kể từ khi bắt đầu quy trình xác minh.
Giả sử chúng ta có một cây có 4 leaves, leaf 1, leaf 2, leaf 3, leaf 4. Chúng ta muốn thực hiện một chứng minh phạm vi cho lá 2 và lá 3. Bắt đầu bằng cách tính gốc. Sau đó, nó đi lên từ leaf 2 cho đến khi right tồn tại và bắt đầu tính toán đệ quy giá trị hash root của cây có right root. Trong hình minh họa, A.right giữ gốc của cây mới chứa leaf 3. Đối với leaf 3, nó tính toán root hash và chỉ xác thực nếu nó bằng A.right.
Vậy điều gì có thể xảy ra trong các lần kiểm tra đệ quy này? Bản thân nó không sai. Nhưng nếu chúng ta kết hợp điều này với yếu tố trên trong đó các giá trị right hoàn toàn không được sử dụng khi tính toán root hash, 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.
The Bug
Đố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à genuine first leaf, chúng ta có thể đưa vào leaf node thỏa mãn việc xác minh miễn là chúng ta có thể kiểm tra đệ quy với một InnerNodes bằng giá trị right tại một số điểm trong đường dẫn xác minh. Như đã nêu ở trên, root không thay đổi khi các giá trị right được thay đổi. Vì vậy, chúng tôi có thể thay đổi các giá trị right thỏa mãn các leaf mới được chèn vào. Trong tải trọng 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 như là giá trị root hash cho InnerNodes, leaf là hash (leaf).
Đề xuất cho các bản sửa lỗi
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ả giá trị left và right. Xác nhận chỉ khi đủ điều kiện (nil, right) hoặc (left, nil). Ngoài ra, thiết kế có thể được thay đổi để sử dụng hết các giá trị left và right để tạo ra hàm root hash.
Kết luận
Vụ tấn công vào Binance Chain là một tổn thất nghiêm trọng khác đối với các nhà phát triển và Binance. Điều nguy hiểm hơn nữa 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. Chúng tôi 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ùng WETAG cập nhật các diễn biến tiếp theo sớm nhất tại đây. Đừng quên theo dõi TAG News để không bỏ lỡ các kèo Airdrop xịn mùa downtrend nhé!!!
https://t.me/TAGNewsVN
Nguồn: WETAG tổng hợp