Đi sâu phân tích: Tấn công thao túng NAV của khoản vay nhanh (flash loan) trong kho Morphо do USR mất neo

robot
Đang tạo bản tóm tắt

Viết bài: Cải bó xôi cải bó xôi

Ngày 22 tháng 3 năm 2026, giao thức Resolv gặp sự cố rò rỉ khoá riêng, kẻ tấn công đã tạo ra 80 triệu USR không thế chấp từ hư không, khiến giá USR từ 1 đô la giảm xuống còn 0.025 đô la.

Hậu quả của thảm họa này không chỉ dừng lại ở những người nắm giữ USR, mà còn có một nhóm người thông minh hơn đã thực hiện một cuộc tấn công thao túng NAV của kho bạc trên Morpho một cách tinh vi.

Bài viết này sẽ phân tích từng bước logic nền tảng của cuộc tấn công này.

  1. Hiểu về kiến trúc hai lớp của Morpho

Trước khi nói về cuộc tấn công, bạn phải hiểu về thiết kế kiến trúc của Morpho, nếu không sẽ không thể hiểu được phần sau.

Thế giới của Morpho được chia thành hai lớp:

Lớp dưới:

Morpho Blue (còn gọi là Morpho Core). Đây là một giao thức cho vay tối giản, không thể nâng cấp. Triết lý thiết kế của nó là “không cấp phép” — bất kỳ ai cũng có thể tạo ra thị trường cho vay, gửi tiền, cho vay, thanh lý.

Mỗi thị trường được xác định duy nhất bởi năm tham số: tài sản vay, tài sản thế chấp, mức thanh lý (LLTV), địa chỉ oracle, mô hình lãi suất.

Các thị trường hoàn toàn cách ly nhau, một sự cố trong một thị trường sẽ không ảnh hưởng đến các thị trường khác.

Lớp trên:

MetaMorpho Vault (kho bạc). Đây là một kho theo tiêu chuẩn ERC-4626, tương đương như một “sản phẩm quỹ”.

Người dùng gửi USDC vào kho bạc, quản lý kho (Curator) sẽ phân bổ số tiền này vào các thị trường Morpho Blue khác nhau để cho vay kiếm lãi.

Người dùng sở hữu phần của kho (shares), giá trị của phần này tăng theo lãi suất tích lũy.

Công thức cốt lõi — giá trị ròng mỗi cổ phần (NAV / Giá mỗi cổ phần): NAV = tổng tài sản / tổng phát hành

Tổng tài sản (totalAssets) là tổng các vị thế cung cấp trong tất cả các thị trường (bao gồm phần đã cho vay, vì đó là “nợ phải thu”). Tổng phát hành (totalSupply) là tổng số phần của kho đã phát hành. Khi lãi tích lũy, tổng tài sản tăng nhưng tổng phát hành không đổi, do đó NAV tăng — đó chính là nguyên lý bạn kiếm lời.

  1. supply(onBehalf) — Ai cũng có thể gửi tiền thay cho kho

Đây là điểm mấu chốt của toàn bộ cuộc tấn công.

Trong Morpho Blue, hàm supply() có tham số onBehalf. Thiết kế này nhằm tiện lợi cho bên thứ ba thay mặt — ví dụ hợp đồng chiến lược tự động có thể gửi tiền thay người dùng.

Nhưng nó hoàn toàn không có cấp phép: bất kỳ ai cũng có thể chỉ định bất kỳ địa chỉ nào làm onBehalf, kể cả địa chỉ kho.

Tài liệu chính thức của Morpho cảnh báo rõ: “Warning: Anyone can supply on behalf of the vault so the call to updateWithdrawQueue that expects a market to be empty can be griefed by a front-run.”

Khi bạn gửi 10.000 USDC thay cho kho, vị thế cung cấp của kho trong thị trường này tăng thêm 10.000, tổng tài sản cũng tăng thêm 10.000. Nhưng tổng phần của kho (totalSupply) không đổi — vì không ai gửi tiền mới qua hàm deposit() của kho.

Kết quả: NAV bị đẩy lên cao.

Thông thường, điều này giống như “quyên góp” cho kho — bạn tự bỏ tiền ra để tăng lợi nhuận cho tất cả cổ đông, chỉ có kẻ ngu mới làm vậy. Nhưng trong điều kiện nhất định, điều này có thể bị lợi dụng.

  1. Cap cung (Supply Cap) = 0 ≠ An toàn

Sau khi USR mất peg, một số quản lý kho khẩn cấp đặt giới hạn cung của thị trường USR/USDC thành 0, nghĩa là quản lý không thể gửi thêm tiền vào thị trường này nữa. Nghe có vẻ vấn đề đã được giải quyết?

Vấn đề là: Cap cung là giới hạn ở cấp độ kho, không phải ở cấp độ Morpho Blue.

Quản lý kho có thể kiểm soát hàm nội bộ _supplyMorpho() của chính kho.

Nhưng supply(onBehalf=vault) lại trực tiếp tương tác với hợp đồng Morpho Blue Core, hoàn toàn bỏ qua mọi logic của kho: hàng đợi cung cấp (supply queue), giới hạn cung (supply cap), kiểm tra quyền của bộ phân bổ (allocator), tất cả đều không qua.

Nói ví dụ: quản lý kho đóng cửa cổng trước (Cap=0), nhưng kẻ tấn công có thể dùng cửa hậu của Morpho Core để gửi tiền trực tiếp vào.

  1. Oracle cố định — lớp áo ngụy trang nợ xấu

Đây là điều kiện thứ hai.

Thị trường USR/USDC có oracle cố định tỷ lệ 1:1. Nói cách khác, dù USR trên thị trường ngoài giảm giá bao nhiêu, trong thế giới của Morpho, 1 USR luôn bằng 1 USDC.

Tại sao quản lý kho lại dùng oracle cố định? Vì USR là “stablecoin”, bình thường giá biến động nhỏ. Oracle cố định giúp tránh “tự thanh lý giả” do thiếu thanh khoản ngắn hạn.

Nhưng khi USR thực sự mất peg, oracle cố định trở thành thảm họa — người vay dùng USR không giá trị làm tài sản thế chấp vay USDC đầy đủ, mà hệ thống không biết gì.

Cơ chế xử lý nợ xấu của Morpho hoàn toàn mất tác dụng ở đây — các phiên bản V1.0 phản ánh theo thời gian thực và V1.1 phân bổ đều, đều dựa trên giả định hệ thống có thể nhận diện nợ xấu.

Oracle cố định, thì không thể nhận diện gì cả.

  1. Toàn bộ quá trình tấn công — vòng tròn 5 bước

Giờ đây, tất cả điều kiện đã sẵn sàng. Dưới đây là các thao tác nguyên tử trong một giao dịch duy nhất:

[Chưa có nội dung mô tả các bước cụ thể, cần bổ sung nếu có]

  1. Tại sao nhất định cần flash loan?

Đây là vấn đề dễ bị bỏ qua nhất. Lợi nhuận của cuộc tấn công dựa trên việc “tăng tổng tài sản ảo rồi phân chia theo phần” để hưởng lợi. Nếu kẻ tấn công không dùng flash loan, dù tăng tổng tài sản lên bao nhiêu, phần của hắn vẫn là 0%, lợi nhuận sẽ thuộc về các cổ đông khác, hắn không nhận được gì.

  1. Ai là người thiệt hại?

Số USDC mà kẻ tấn công lấy đi thêm 12.300 là không tự nhiên sinh ra. Số tiền này đến từ thanh khoản thực của các thị trường khác trong kho.

Khi kho rút tiền, sẽ theo thứ tự hàng đợi rút (withdraw queue) để lấy USDC từ các thị trường khác nhau. Trong thị trường USR, USDC đã bị vay hết, không thể rút ra. Do đó, số tiền rút ra đến từ các thị trường khác — ví dụ như wETH/USDC, cbBTC/USDC, các thị trường hoạt động bình thường khác.

  1. Hiệu ứng chồng chất của ba lỗ hổng

Cuộc tấn công này không phải do một lỗ hổng đơn lẻ, mà là sự cộng hưởng của ba vấn đề thiết kế:

[Chưa có nội dung chi tiết, cần bổ sung]

Kết luận

Triết lý thiết kế tối giản của Morpho — không cấp phép, không nâng cấp, quản trị tối thiểu — phần lớn là lợi thế. Nhưng sự kiện này cho thấy, thiết kế tối giản có thể mang lại trách nhiệm lớn hơn cho các bên tham gia cấp cao.

Giao thức không kiểm tra oracle, quản trị viên phải tự làm tốt. Giao thức không giới hạn supply(onBehalf), kho phải có các biện pháp phòng ngừa bổ sung.

Với người gửi tiền, “chọn Curator đúng” còn quan trọng hơn “chọn Morpho”. Giao thức là công cụ, công cụ an toàn hay không phụ thuộc vào người sử dụng.

MORPHO-4,52%
Xem bản gốc
Trang này có thể chứa nội dung của bên thứ ba, được cung cấp chỉ nhằm mục đích thông tin (không phải là tuyên bố/bảo đảm) và không được coi là sự chứng thực cho quan điểm của Gate hoặc là lời khuyên về tài chính hoặc chuyên môn. Xem Tuyên bố từ chối trách nhiệm để biết chi tiết.
  • Phần thưởng
  • Bình luận
  • Đăng lại
  • Retweed
Bình luận
Thêm một bình luận
Thêm một bình luận
Không có bình luận
  • Ghim