Dấu hiệu trống đã làm sụp đổ Bonzo Lend: Phân tích sau sự cố khai thác $9 triệu trên Hedera

Dấu hiệu trống đã làm sụp đổ Bonzo Lend: Phân tích sau sự cố khai thác $9 triệu trên Hedera

2026/07/15 11:18:00
Hình ảnh tùy chỉnh
Trong toán học và khoa học máy tính, số không đại diện cho sự trống rỗng—sự vắng mặt tuyệt đối của giá trị. Nhưng trong hệ sinh thái dễ tổn thương và siêu kết nối của Tài chính Phi tập trung (DeFi), một tham số "không" không được kiểm tra gần đây đã trở thành chìa khóa master kỹ thuật số. Trong vài phút, giá trị trống duy nhất này đã mở khóa và rút hơn 9 triệu đô la từ một nền tảng cho vay nổi bật.
 
Nạn nhân của vụ khai thác tàn phá này là Bonzo Lend, giao thức cho vay lớn nhất hoạt động trên mạng Hedera. Vào tháng 7 năm 2026, giao thức chứng kiến Tổng Giá trị Khóa (TVL) của mình giảm mạnh tới 77% trong chốc lát. Khi sự hoảng loạn lan rộng trong cộng đồng Hedera, các quan sát viên vội vã tìm kiếm nguồn gốc của sự rò rỉ.
 
Quan trọng là thảm họa này không xảy ra do cơ chế đồng thuận của mạng nền tảng Hedera bị lỗi, cũng không phải do các phép tính cho vay cốt lõi của Bonzo Lend sai. Thay vào đó, thảm họa xuất phát từ một lỗ hổng tích hợp chết người: một lỗ hổng xác thực chữ ký nghiêm trọng trong nhà cung cấp nguồn giá bên thứ ba của họ, Supra Oracles. Đây là bản phân tích sau sự cố về cách một sai sót logic nhỏ liên quan đến "không có gì" đã khiến một đế chế DeFi sụp đổ.

Dòng thời gian của cuộc tấn công: Từ 5 USD lên 9.000.000 USD trong vài giây

Việc thực hiện khai thác Bonzo Lend rất tài tình về sự đơn giản, yêu cầu vốn khởi đầu tối thiểu và diễn ra chỉ trong vài bước giao dịch.
 
Để tiến hành vụ trộm, kẻ tấn công đã nạp một số tiền thế chấp cực nhỏ, không đáng kể vào Bonzo Lend—cụ thể là 250 token SAUCE. Vào thời điểm nạp, số tài sản thế chấp này chỉ có giá trị vài đô la, gần như không đủ để mua một tách cà phê. Theo các quy tắc giao thức bình thường, số tiền lẻ này sẽ cho phép người dùng vay chỉ một phần nhỏ giá trị của nó dưới dạng các tài sản kỹ thuật số khác.
 
Tiếp theo, kẻ tấn công đã khởi động cuộc khai thác bằng cách vượt qua các kiểm tra xác minh của price oracle. Họ tạo và gửi một giao dịch cập nhật giá giả mạo đến hợp đồng xác thực của oracle. Giao dịch này chứa dữ liệu cực kỳ độc hại: nó làm tăng giá của token SAUCE một cách nhân tạo lên 12 cấp độ—hiệu quả là thông báo cho giao thức rằng một token SAUCE đơn lẻ đột nhiên có giá trị hàng tỷ đô la.
 
Để đẩy mức giá giả mạo này thông qua, hệ thống yêu cầu chữ ký mật mã từ một nút mạng oracle được ủy quyền. Thay vì cố gắng phá vỡ mã hóa phức tạp hoặc đánh cắp khóa riêng, kẻ tấn công chỉ để trống trường chữ ký, gửi một chuỗi các số không thay cho chữ ký mật mã.
 
Do một lỗ hổng nghiêm trọng trong logic xác thực, hợp đồng đã chấp nhận chữ ký trống là hợp lệ. Ngay lập tức, hệ thống định giá của Bonzo ghi nhận 250 SAUCE làm tài sản có giá trị khổng lồ. Khai thác sự giàu có giả tạo đột ngột này, kẻ tấn công nhanh chóng rút về 6,63 triệu USDC và 34,50 triệu wHBAR từ các hồ thanh khoản của Bonzo, thành công rút sạch giao thức trước khi bất kỳ cảnh báo nào được đưa ra.

Làm rõ lỗ hổng "Zero-Signature": Cách mã bị lỗi

Để hiểu cách cuộc khai thác này có thể xảy ra, chúng ta cần làm rõ toán học của chữ ký số. Trong các mạng phi tập trung, chữ ký mật mã hoạt động như những con dấu sáp số. Khi một nút mạng oracle công bố cập nhật giá, nó ký vào dữ liệu bằng khóa riêng. Hợp đồng thông minh ở phía nhận sử dụng thuật toán xác minh để xác nhận rằng chữ ký khớp với khóa công khai được ủy quyền của nút mạng oracle.
 
Thông thường, nếu người dùng gửi chữ ký không hợp lệ, thư viện xác minh sẽ cố gắng xử lý đầu vào và thất bại. Khi các thư viện xác minh mật mã gặp phải đầu vào bị hỏng, trống hoặc hoàn toàn là số không, chúng không luôn tạo ra lỗi chủ động. Thay vào đó, nhiều thư viện tiêu chuẩn được thiết kế để trả về giá trị mặc định khi không thể phân tích chữ ký. Trong hợp đồng thông minh, đầu ra mặc định này gần như luôn là địa chỉ null được biểu diễn bằng một chuỗi dài các số không.
 
Lỗ hổng nghiêm trọng trong hợp đồng xác thực của oracle nằm ở cách nó xử lý địa chỉ null mặc định. Hợp đồng được lập trình để kiểm tra xem người ký được khôi phục có khớp với địa chỉ nút mạng oracle được ủy quyền hay không. Tuy nhiên, các nhà phát triển đã quên không đưa ra quy tắc cơ bản: từ chối bất kỳ đầu vào nào có độ dài chữ ký bằng không hoặc địa chỉ khôi phục trả về giá trị null.
 
Hơn nữa, nếu trạng thái người ký được ủy quyền trong hợp đồng chưa được khởi tạo hoặc được cấu hình theo cách cho phép kiểm tra null, hợp đồng đã so sánh địa chỉ null trả về bởi việc ký không thành công với các tham số nội bộ của nó và tuyên bố là khớp. Vì logic xác thực không phân biệt được giữa “khôi phục chữ ký không thành công” và “người ký được ủy quyền hợp lệ”, hợp đồng đã coi chữ ký trống như một tín hiệu xanh tuyệt đối, chấp thuận nguồn cấp giá giả mạo.

Nghịch lý Oracle: Tại sao các khối DeFi chỉ mạnh bằng liên kết yếu nhất của chúng

DeFi thường được ca ngợi vì khả năng “lắp ghép” của nó—khả năng các giao thức, token và công cụ khác nhau kết nối với nhau như những “viên gạch Money Legos” để xây dựng các ứng dụng tài chính phức tạp. Trong khi khả năng lắp ghép thúc đẩy sự đổi mới nhanh chóng, nó cũng gây ra sự dễ tổn thương hệ thống. Một lỗi duy nhất trong thành phần nền tảng có thể làm sụp đổ toàn bộ cấu trúc.
 
Cuộc khai thác Bonzo Lend minh họa hoàn hảo lỗ hổng này. Bonzo Lend bản thân là một giao thức cho vay được xây dựng chặt chẽ và đã trải qua các cuộc kiểm tra an toàn. Tuy nhiên, giao thức buộc phải tin tưởng vào phụ thuộc oracle bên ngoài để cung cấp giá chính xác. Ngay khi hệ thống xác thực của oracle chấp nhận mức giá giả, các hợp đồng cho vay của Bonzo đã thực thi đúng như những gì đã được viết, cho phép người dùng "giàu có" được bảo đảm mạnh mẽ vay tài sản.
 
Bảng dưới đây phân tích sự phân bổ trách nhiệm cấu trúc trong suốt cuộc tấn công, cho thấy nơi nào hàng phòng thủ bị sụp đổ:
Thành phần Vai trò hệ thống dự kiến Hiệu suất trong suốt cuộc khai thác Bài học cấu trúc
Lớp đồng thuận Hedera Giữ trạng thái sổ cái an toàn, sắp xếp các giao dịch và duy trì thời gian hoạt động của mạng. Hoạt động hoàn hảo với thời gian ngừng hoạt động bằng không và không có lỗ hổng ở cấp độ mạng. Một lớp đồng thuận mạng an toàn không đảm bảo an toàn ở cấp độ ứng dụng.
Supra Oracle Cung cấp dữ liệu giá tài sản đã được ký, xác minh mật mã và chính xác. Không thể từ chối chữ ký rỗng, đang đăng tải giá bị hỏng. Các phụ thuộc phải được xử lý theo các mô hình xác thực không tin tưởng hoàn toàn.
Bonzo Cho vay Quản lý tài sản nạp, theo dõi tỷ lệ sức khỏe khoản vay và xử lý các khoản vay. Đã tin tưởng mù quáng vào dữ liệu giá đầu vào, không giới hạn các đợt tăng giá đột biến. Các hợp đồng thông minh phải triển khai logic phòng thủ để tồn tại khi gặp sự cố phụ thuộc.

Can thiệp của Người đội mũ trắng: Cuộc đua 1 triệu đô la chống lại tin tặc

Khi cuộc khai thác diễn ra trên sổ cái công khai, một sự kiện thứ cấp đầy kịch tính đã xảy ra. Trên các blockchain công khai, các giao dịch được hiển thị trong "mempool" trước khi được xác nhận. Sự minh bạch này cho phép các bên tham gia khác, cả có ý đồ xấu lẫn có đạo đức, phân tích các cuộc tấn công đang diễn ra theo thời gian thực.
 
Ngay sau khi kẻ tấn công chính bắt đầu rút tiền khỏi giao thức, một nhà nghiên cứu bảo mật độc lập—thường được biết đến với tên gọi “white hat” hacker—đã phát hiện ra lỗ hổng đang được khai thác. Nhận thức được rằng toàn bộ giao thức sắp bị rút sạch, white hat đã nhanh chóng thực hiện chính xác lỗ hổng không cần chữ ký để rút khoảng 1 triệu USD tài sản.
 
Chiến thuật này, được gọi là "front-running", là một động thái phòng thủ phổ biến trong bảo mật Web3. Bằng cách rút tiền trước, người dùng thiện chí đã ngăn chặn tác nhân độc hại đánh cắp một phần khoản thanh khoản trong hồ sơ.
 
Sau khi rút tiền thành công, chuyên gia mũ trắng đã lập tức liên hệ với đội ngũ Bonzo Lend. Sau khi xác minh danh tính và mục đích của họ, hacker đạo đức đã trả lại toàn bộ 1 triệu đô la Mỹ vào các địa chỉ phục hồi của giao thức. Trong khi kẻ tấn công chính vẫn trốn thoát với phần lớn số tiền, sự can thiệp nhanh chóng này đã bảo toàn một phần quan trọng tài sản của cộng đồng và thể hiện tính chất hợp tác độc đáo của bảo mật Web3.

Đuổi theo hàng triệu: Cách số tiền bị đánh cắp rời khỏi hệ sinh thái Hedera

Sau khi tin tặc vay thành công số tiền triệu đô la Mỹ giá trị USDC và wHBAR dựa trên tài sản đảm bảo giả mạo, mục tiêu chính của họ chuyển sang thoát khỏi hệ sinh thái Hedera trước khi giao thức tạm dừng các hợp đồng của nó.
 
Kẻ tấn công không giữ tài sản bị đánh cắp ở dạng ban đầu. Sử dụng SaucerSwap, một sàn giao dịch phi tập trung phổ biến trên Hedera, tên hacker đã nhanh chóng đổi các token vay thành các stablecoin và tài sản bản địa có thanh khoản cao để tránh các cơ chế đóng băng tập trung.
 
Ngay sau khi hoán đổi các token, kẻ tấn công đã sử dụng các cầu liên chuỗi, cụ thể là chuyển tiền qua LayerZero. Bằng cách cầu nối các tài sản, kẻ trộm đã chuyển hơn 5 triệu USD số tiền bị đánh cắp trực tiếp lên mạng chính ethereum.
 
Một khi tài sản được chuyển sang một mạng lưới lớn và thanh khoản cao như ethereum, việc theo dõi và khôi phục chúng trở nên khó khăn hơn gấp nhiều lần. Số tiền có thể được chia nhỏ thành hàng trăm địa chỉ mới, gửi vào các máy trộn bảo mật phi tập trung, hoặc hoán đổi thành các đồng tiền bảo mật không do bên thứ ba giữ giữ. Con đường thoát nhanh chóng và tự động này làm nổi bật lý do tại sao giám sát thời gian thực và tạm dừng khẩn cấp ngay lập tức là những biện pháp phòng vệ duy nhất khả thi chống lại các vụ khai thác chéo chuỗi hiện đại.

Những bài học đắt giá: Cách các giao thức DeFi có thể bảo vệ chính mình khỏi những thảm họa oracle

Việc mất 9 triệu đô la là một bài học đắt giá, nhưng mang lại những hiểu biết vô cùng quý giá cho các nhà phát triển hợp đồng thông minh đang tìm cách bảo vệ các ứng dụng của họ khỏi các lỗi tích hợp trong tương lai.
 
Để ngăn ngừa các lỗ hổng không có chữ ký, các nhà phát triển phải áp dụng các thực hành lập trình nghiêm ngặt và phòng thủ. Các cải tiến cấu trúc chính bao gồm:
  • Xác minh địa chỉ Null rõ ràng: Đừng bao giờ giả định rằng hàm xác minh chữ ký thành công. Mọi quy trình xác thực mã hóa đều phải kiểm tra rõ ràng rằng độ dài chữ ký lớn hơn không và xác minh rằng địa chỉ đầu ra không trả về giá trị null (0x00...00). Nếu trả về giá trị null, giao dịch phải lập tức bị hoàn lại.
  • Các kiến trúc oracle thừa thãi: Việc phụ thuộc vào một nhà cung cấp oracle duy nhất tạo ra điểm lỗi đơn lẻ. Các giao thức DeFi mạnh mẽ nên lấy giá tài sản từ nhiều mạng oracle độc lập khác nhau (như Chainlink, Pyth và Supra đồng thời). Nếu một nguồn cấp dữ liệu lệch đáng kể so với trung vị của các nguồn còn lại, giao thức nên cảnh báo sự khác biệt và tạm dừng hoạt động tự động.
  • Các bộ ngắt giá trên chuỗi: Các giao thức cho vay phải triển khai giới hạn tỷ lệ và ranh giới lệch giá. Ngay cả khi một oracle tuyên bố giá trị của một đồng tiền đã tăng một nghìn tỷ lần trong một khối duy nhất, bộ ngắt nội bộ của hợp đồng thông minh phải từ chối cập nhật này như một bất thường, tạm dừng mọi hành động vay hoặc thanh lý cho đến khi có xác minh thủ công từ quản trị viên.

Tương lai của các cuộc kiểm toán hợp đồng thông minh: Tại sao chúng ta phải thử thách các giới hạn

Việc khai thác Bonzo Lend phơi bày một hạn chế nghiêm trọng trong các thực hành kiểm toán Web3 hiện tại. Nhiều bản kiểm toán bảo mật tập trung mạnh vào việc xác minh rằng logic kinh doanh của hợp đồng hoạt động đúng dưới các điều kiện mong đợi—thường được gọi là kiểm tra "happy-path".
 
Tuy nhiên, các kẻ tấn công thực tế không tuân theo kịch bản lý tưởng. Họ tìm kiếm đặc biệt các điều kiện biên, trạng thái chưa được khởi tạo và đầu vào không mong đợi. Ngành công nghiệp bảo mật phải chuyển sang kiểm tra tích cực các trường hợp biên để phát hiện các lỗ hổng ẩn trước khi mã được triển khai trên mạng chính.
 
Để đạt được điều này, các giao thức phải đưa các phương pháp thử nghiệm nâng cao như fuzzing và xác minh hình thức trở thành tiêu chuẩn bắt buộc. Fuzzing liên quan đến việc sử dụng các công cụ tự động để gửi hàng triệu đầu vào ngẫu nhiên, không hợp lệ và rỗng vào hợp đồng thông minh—bao gồm cả chuỗi byte rỗng và chữ ký null. Nếu hợp đồng xác minh đã được thử nghiệm nghiêm ngặt bằng fuzzing, lỗ hổng bỏ qua chữ ký không sẽ được phát hiện ngay lập tức.
 
Cuối cùng, các nhà cung cấp oracle bên thứ ba cũng phải chấp nhận các tiêu chuẩn bảo mật cao hơn. Vì các luồng dữ liệu này đóng vai trò là nền tảng cho hàng trăm triệu đô la hoạt động kinh tế, mã xác minh của chúng phải được xử lý với mức độ kiểm tra nghiêm ngặt tương đương với các mạng lớp một mà chúng hỗ trợ.

Kết luận: Phục hồi niềm tin trong một hệ sinh thái không cần niềm tin

Vụ khai thác Bonzo Lend là lời nhắc nhở rõ ràng về bản chất không khoan nhượng của các hợp đồng thông minh. Trong Web3, mã nguồn là luật pháp, và EVM không quan tâm đến ý định của bạn. Một kẽ hở logic nhỏ liên quan đến "không có gì" có thể xóa sạch ngay lập tức nhiều năm phát triển và hàng triệu đô la niềm tin của người dùng.
 
Ngay sau vụ tấn công, cả Bonzo Lend và Supra Oracles đã nhanh chóng vá lỗ hổng và bảo vệ cơ sở hạ tầng còn lại. Mặc dù sự cố này gây đau xót, nhưng những bài học rút ra chắc chắn sẽ dẫn đến các tiêu chuẩn tích hợp an toàn hơn trên toàn bộ hệ sinh thái DeFi. Đối với cả nhà phát triển và nhà đầu tư, bài học quan trọng nhất là đơn giản: đừng bao giờ coi nhẹ bảo mật tích hợp, hãy kiểm tra giới hạn của mã nguồn và luôn xác minh điều gì xảy ra khi bạn không cung cấp bất kỳ dữ liệu nào vào hệ thống của mình.

Câu hỏi thường gặp:

Câu 1: Lỗ hổng "Zero-Signature" có nghĩa là mật mã blockchain bị phá vỡ không?

Không. Các nguyên lý toán học đằng sau chữ ký số và mã hóa khóa công khai vẫn hoàn toàn an toàn. Lỗ hổng được gây ra bởi một lỗi logic trong lập trình hợp đồng thông minh xử lý đầu ra của thư viện mã hóa. Thư viện hoạt động đúng bằng cách trả về giá trị null khi nhận chữ ký trống, nhưng hợp đồng đã diễn giải sai giá trị null đó như một xác thực thành công.

Câu hỏi 2: Tại sao Bonzo Lend tự động tin tưởng mức giá bị thổi phồng một cách phi lý đối với SAUCE?

Các giao thức cho vay được thiết kế để mô-đun, nghĩa là chúng chuyển giao nhiệm vụ phức tạp về định giá tài sản cho các mạng oracle chuyên dụng. Vì Bonzo Lend được xây dựng để chấp nhận luồng giá từ oracle như sự thật tuyệt đối mà không thực hiện bất kỳ kiểm tra hợp lý độc lập nào hoặc giới hạn lệch giá, nên nó đã chấp nhận mức tăng giá nhân tạo gấp nghìn tỷ lần và cho phép giao dịch vay diễn ra.

Câu hỏi 3: Người dùng DeFi hàng ngày có thể làm gì để bảo vệ bản thân khỏi các cuộc tấn công liên quan đến oracle?

Mặc dù người dùng không thể kiểm soát mã của giao thức, họ có thể quản lý rủi ro của chính mình. Để bảo vệ vốn của bạn, hãy đa dạng hóa tài sản trên nhiều nền tảng độc lập, tránh các giao thức phụ thuộc vào một nguồn dữ liệu oracle duy nhất cho các tài sản đặc thù, và tìm các nền tảng đã tích hợp công khai hệ thống oracle đa nguồn cùng các bộ ngắt khẩn cấp mạnh mẽ trên chuỗi.
 
Thông báo miễn trừ trách nhiệm: Nội dung này chỉ mang tính chất thông tin và không phải là lời khuyên đầu tư. Đầu tư vào tiền điện tử tiềm ẩn rủi ro. Vui lòng tự nghiên cứu (DYOR).

Tuyên bố từ chối trách nhiệm: Trang này được dịch bằng công nghệ AI để thuận tiện cho bạn. Để biết thông tin chính xác nhất, hãy tham khảo bản gốc tiếng Anh.