Sự cố bảo mật Liquid Network: Lỗ hổng rangeproof khiến 4.000 LBTC bị đúc khống, thiệt hại gần 602 BTC chưa thu hồi

Công nghệ24 tháng 9, 2026·10 phút đọc

Blockstream vừa công bố báo cáo chi tiết về sự cố bảo mật nghiêm trọng trên Liquid Network xảy ra ngày 6/9/2026, khi kẻ tấn công khai thác lỗ hổng trong bộ nhớ đệm xác minh rangeproof của Elements để tạo ra khoảng 4.000 LBTC không được bảo chứng. Hậu quả là khoảng 4.000 BTC bị rút khỏi quỹ dự trữ, trong đó 3.400 BTC đã được hoàn trả nhưng vẫn còn khoảng 602 BTC chưa thu hồi.

Sự cố bảo mật Liquid Network: Lỗ hổng rangeproof khiến 4.000 LBTC bị đúc khống, thiệt hại gần 602 BTC chưa thu hồi

Sự cố bảo mật Liquid Network: Khi lỗ hổng rangeproof khiến 4.000 LBTC bị đúc khống

Blockstream vừa công bố báo cáo điều tra đầy đủ về sự cố bảo mật nghiêm trọng nhất trong lịch sử Liquid Network, xảy ra vào ngày 6/9/2026. Kẻ tấn công đã khai thác một lỗ hổng trong bộ nhớ đệm xác minh rangeproof của Elements, cho phép một giao dịch vượt qua kiểm tra đồng thuận dù giá trị đầu ra không được bảo chứng bởi đầu vào. Khoảng 4.000 LBTC đã bị đúc khống, sau đó được chuyển đổi thành BTC thật qua quy trình peg-out, gây ảnh hưởng trực tiếp tới quỹ dự trữ của mạng lưới.

Kiến trúc Liquid và các bất biến bảo mật bị vi phạm

Liquid là sidechain Bitcoin được xây dựng trên Elements, nền tảng blockchain mã nguồn mở do Blockstream phát triển. Mạng lưới vận hành với 15 nút functionary phân bố địa lý, yêu cầu tối thiểu 11 chữ ký để xác nhận một block. Ba đặc tính kiến trúc đóng vai trò then chốt trong việc hiểu sự cố này:

  • Bảo chứng 1:1 với BTC: BTC khóa trên chuỗi Bitcoin qua peg-in được khớp 1:1 với LBTC phát hành trên Liquid. BTC chỉ được giải phóng khi có LBTC bị đốt tương ứng.
  • Giao dịch bảo mật và xác minh rangeproof: Liquid che giấu số lượng và loại tài sản bằng Pedersen commitment. Mỗi đầu ra bảo mật đi kèm một rangeproof zero-knowledge chứng minh giá trị nằm trong khoảng hợp lệ mà không tiết lộ con số cụ thể.
  • Ủy quyền peg-out qua PAK: Mỗi thành viên Federation sở hữu một Peg-out Authorization Key gồm khóa offline (kiểm soát địa chỉ nhận BTC) và khóa online (ký yêu cầu peg-out).

Về nguyên tắc, khóa offline tồn tại như một lưới an toàn cho các thất bại ở tầng trên. Nếu đồng thuận vô tình chấp nhận LBTC giả, ví nhận tiền thực sự offline vẫn giữ được BTC đã giải phóng — nhưng cần thao tác thủ công để rút khỏi kho lạnh, và độ trễ đó tạo ra khoảng thời gian cho Federation phát hiện và xử lý.

Phân tích lỗ hổng: Bug A và Bug B

Sự cố bắt nguồn từ hai vấn đề riêng biệt: lỗ hổng đồng thuận trong Elements (Bug A và Bug B) và lỗ hổng trong cấu hình quy trình ký PAK của một thành viên.

Bug A: Khóa cache thiếu trường ngữ cảnh

Bug A xuất phát từ một commit tháng 4/2018, được hợp nhất vào Elements v0.14.1. Thay đổi này đơn giản hóa khóa cache rangeproof bằng cách loại bỏ asset commitment và scriptPubKey khỏi khóa:

SHA256(nonce ‖ rangeproof ‖ value_commitment)

Hệ quả là một cặp (rangeproof, value commitment) đã được cache thành công có thể bị coi là hợp lệ trong ngữ cảnh khác, với asset commitment hoặc script hoàn toàn khác. Điều này tạo ra sự bất đồng thuận giữa các nút có cache nóng và cache lạnh, có thể làm tách chuỗi hoặc đình trệ sản xuất block.

Đáng chú ý, lỗi này tồn tại từ 2018 và được mang nguyên vẹn vào triển khai xác thực Confidential Assets trong đợt tái cấu trúc năm 2019, rồi gần như không thay đổi cho tới năm 2026.

Bug B: Lỗi ghép byte thiếu tiền tố độ dài

Bản vá cho Bug A mở rộng khóa cache để bao gồm asset commitment và scriptPubKey — nhưng vấn đề nằm ở cách các trường được kết hợp. Đoạn code ghi trực tiếp byte thô của từng trường vào hash mà không có tiền tố độ dài hay dấu phân cách.

Hai trường có độ dài cố định 33 byte (value commitment và asset commitment), trong khi rangeproof và scriptPubKey có độ dài thay đổi. Vì rangeproof chứa header mã hóa độ dài của chính nó, kẻ tấn công có thể cắt ngắn hoặc kéo dài rangeproof, đồng thời điều chỉnh scriptPubKey để bù trừ, tạo ra chuỗi byte trùng khớp hoàn toàn với một entry đã được cache hợp lệ trước đó. Do cache hit bỏ qua toàn bộ bước xác minh, rangeproof giả mạo không bao giờ cần thực sự hợp lệ.

Không một reviewer nào — nội bộ hay bên ngoài — phát hiện rủi ro này trước khi bị khai thác. Ba luồng kiểm tra độc lập đã chạy, mỗi luồng đều kèm đánh giá thủ công của kỹ sư nội bộ, nhưng đều bỏ sót lớp lỗ hổng này.

Diễn biến sự cố

Minh họa dòng thời gian sự cố bảo mật Liquid NetworkMinh họa dòng thời gian sự cố bảo mật Liquid Network

Dòng thời gian chính của sự cố:

  • 13:53:10 ngày 6/9/2026: Giao dịch tấn công được xác nhận trong block Liquid 4.050.336, tạo ra khoảng 4.000 LBTC không được bảo chứng.
  • 14:00: Kẻ tấn công thử nghiệm đường thoát với lệnh peg-out nhỏ 2,5 LBTC; SideSwap thanh toán 2,49749857 BTC từ kho riêng một phút sau đó.
  • 14:05: Kẻ tấn công nạp khoảng 4.000 LBTC vào dịch vụ peg-out của SideSwap.
  • 14:28:56: Các signer của Federation giải phóng 3.996,02 BTC trên mainnet Bitcoin; SideSwap chuyển tiếp 3.995,99999857 BTC trong cùng block.
  • 18:26: Blockstream phối hợp dừng các nút bridge của Liquid; mạng lưới bị tạm dừng.
  • 18:30:10: Kẻ tấn công đăng thông điệp on-chain: "we are whitehats. contact us on chain."
  • 16:09:25 ngày 7/9: Kẻ tấn công hoàn trả 3.400 BTC vào ví peg của Federation.
  • 21:05:10 ngày 9/9: Sản xuất block được khôi phục trên chuỗi Liquid đã sửa, với block thay thế 4.050.336.

Tổng cộng, quỹ dự trữ Liquid giảm từ khoảng 4.205 BTC xuống còn 197 BTC sau các lệnh peg-out nhỏ hơn được xác nhận trước khi mạng lưới bị dừng.

Vai trò của SideSwap và quy trình kiểm soát peg-out

SideSwap — một thành viên Federation nắm giữ PAK — không bị xâm phạm, giả mạo hay đánh cắp khóa. Lệnh peg-out hoàn tất vì nút của SideSwap và các nút functionary đã chấp nhận LBTC không bảo chứng là hợp lệ trước khi yêu cầu peg-out được đánh giá. Cơ chế PAK chỉ xác thực một yêu cầu ký thật đối với LBTC mà đồng thuận đã — một cách sai lầm — chấp nhận là thật.

Sau sự cố, SideSwap thừa nhận hai lựa chọn vận hành đã ảnh hưởng tới mức độ thiệt hại:

  • Khóa ký peg-out được giữ online dù Điều lệ Federation yêu cầu phải để offline, và thanh toán được chuyển tự động cho khách hàng trong cùng block Bitcoin với lệnh peg-out.
  • Không áp dụng giới hạn kích thước, kiểm soát tốc độ hay kiểm tra lịch sử ví cho lệnh peg-out. Một lệnh khoảng 4.000 LBTC — chiếm phần lớn nguồn cung lưu hành — được xử lý mà không có bất kỳ đánh giá thủ công nào.

Biện pháp khắc phục và khôi phục

Blockstream đã triển khai phản ứng nhiều tầng:

  1. Ngăn chặn tức thời (6/9): Đưa các nút bridge Liquid offline lúc 18:26 UTC, đồng thời thông báo cho các sàn giao dịch tạm dừng nạp/rút LBTC.
  2. Bản vá khẩn cấp (7/9, 01:09 UTC): Triển khai và phối hợp cập nhật bản vá cho các nút bridge trước khi phát hành đầy đủ 23.3.4.
  3. Sửa lỗi gốc Bug B (hợp nhất 8/9, phát hành v23.3.4 ngày 9/9): Chuyển hasher cache rangeproof và surjection-proof từ ghép nối CSHA256 thô sang CHashWriter (SER_GETHASH), tuần tự hóa mỗi trường với tiền tố độ dài. Bản vá cũng bổ sung tùy chọn khởi động -norangeproofcache cho phép vận hành viên tắt hoàn toàn bộ đệm.

Vì sự cố dựa trên lỗ hổng cache, Blockstream có thể xác định chính xác các giao dịch bất hợp lệ bằng cách phát lại và xác thực chuỗi bị ảnh hưởng mà không dùng cache rangeproof. Khi tắt cache, Elements từ chối đúng các giao dịch phụ thuộc Bug A hoặc Bug B. Nhóm sau đó kiểm tra chéo độc lập bằng rust-elements, xác định được hai đầu ra bất hợp lệ gốc và bốn giao dịch hậu duệ.

Quá trình khôi phục diễn ra theo ba giai đoạn, vẫn đang tiếp tục: khôi phục sản xuất block với peg-out tạm dừng; phát lại các giao dịch đã được xác minh độc lập là hợp lệ; và khôi phục hoạt động peg khi trạng thái mạng lưới được phục hồi hoàn toàn.

Bài học và hành động khắc phục

Blockstream nhấn mạnh rằng họ đã tiếp nhận, phân loại và khắc phục Bug A trong vòng 24 giờ kể từ báo cáo đầu tiên, xác nhận độc lập qua hai kênh khác trong vòng một tuần. Không có báo cáo nào bị bỏ sót, không có cảnh báo nào bị phớt lờ và không có khóa nào bị xâm phạm. Tuy vậy, công ty đã tiến hành rà soát toàn diện quy trình kỹ thuật và bảo mật.

Các hành động chính bao gồm:

  • Ưu tiên giải pháp khắc phục mạnh nhất: Khi tồn tại nhiều bản vá cho vấn đề đồng thuận then chốt, phương án đảm bảo an toàn cấu trúc cao nhất sẽ là mặc định, kể cả khi đòi hỏi thay đổi rộng hơn. Mọi sai lệch cần có biện minh và phê duyệt.
  • Rà soát định kỳ code đồng thuận: Các repository then chốt sẽ được rà soát theo hai hướng — quét bảo mật mỗi khi có thay đổi hợp nhất, và rà soát định kỳ ngay cả khi code không thay đổi.
  • Tăng cường năng lực kiểm thử đối kháng: Mở rộng sử dụng fuzz testing, mutation testing, symbolic execution và xác minh hình thức cho code đồng thuận then chốt.
  • Phòng thủ nhiều lớp: Các cache nhạy cảm ngữ cảnh sẽ mang thẻ schema có phiên bản và bắt buộc kiểm tra lại ngữ cảnh tại thời điểm tra cứu.
  • Chương trình bug bounty: Blockstream đang thiết lập chương trình bug bounty dành riêng cho Elements và các hạ tầng mã nguồn mở then chốt khác.

Nhóm nghiên cứu bảo mật bên ngoài đóng vai trò quan trọng trong an ninh mã nguồn mở. Sự cố này cho thấy giá trị của việc chính thức hóa và mở rộng các kênh báo cáo lỗ hổng một cách có trách nhiệm.

Điểm đáng chú ý với cộng đồng người dùng Việt Nam

Sự cố Liquid Network là lời nhắc nhở quan trọng với bất kỳ ai đang sử dụng hoặc xây dựng trên các giải pháp Bitcoin Layer-2. Ba bài học có thể rút ra:

  • Code ổn định không đồng nghĩa với code an toàn: Bug A tồn tại suốt 8 năm trong một codebase đã qua nhiều đợt kiểm toán. Đây là vấn đề chung của toàn ngành blockchain, không riêng Liquid.
  • Quy trình vận hành quan trọng ngang với code: Việc khóa ký được giữ online và thiếu kiểm soát kích lệnh peg-out đã khiến thiệt hại nghiêm trọng hơn mức có thể.
  • Bộ nhớ đệm trong hệ thống đồng thuận là bài toán rủi ro cao: Bất kỳ cơ chế cache nào của kết quả xác minh phụ thuộc ngữ cảnh đều cần được thiết kế cẩn trọng đặc biệt, tốt nhất là với tiền tố độ dài cho mọi trường dữ liệu.

Hiện vẫn còn khoảng 602 BTC chưa được thu hồi, tính đến báo cáo công khai ngày 17/9/2026. Kế hoạch khôi phục tiếp tục được thử nghiệm và có thể điều chỉnh; không giai đoạn nào tiến hành cho tới khi được đánh giá độc lập là an toàn.

Chia sẻ:FacebookX
Nội dung tổng hợp bằng AI, mang tính tham khảo. Xem bài gốc ↗