Người viết: Eric, Foresight News

Vào khoảng 10:21 giờ Bắc Kinh hôm nay, Resolv Labs phát hành stablecoin USR bằng chiến lược trung lập Delta đã bị tin tặc tấn công. Địa chỉ bắt đầu bằng 0x04A2 đã đúc 50 triệu USR từ giao thức Resolv Labs bằng 100.000 USDC.

Kể từ khi sự kiện được công khai, USR đã giảm xuống gần 0,25 USD, và tính đến thời điểm viết bài đã phục hồi lên khoảng 0,8 USD. Giá của token RESOLV trong thời gian ngắn cũng gần giảm 10%.

Sau đó, tin tặc lại tiếp tục sử dụng 100.000 USDC để đúc 30 triệu USR. Với sự sụt giảm mạnh của USR, các nhà giao dịch chênh lệch giá cũng nhanh chóng hành động, nhiều thị trường cho vay hỗ trợ USR, wstUSR làm tài sản thế chấp trên Morpho đã gần như bị vét sạch, Lista DAO trên BNB Chain cũng đã tạm dừng các yêu cầu vay mới.

Ngoài những giao thức cho vay bị ảnh hưởng, trong thiết kế của giao thức Resolv Labs, người dùng cũng có thể đúc một loại token RLP có biến động giá lớn hơn, lợi nhuận cũng cao hơn, nhưng cần phải chịu trách nhiệm bồi thường khi giao thức bị thiệt hại. Hiện tại, lưu thông của token RLP gần 30 triệu, chủ sở hữu lớn nhất Stream Finance đang nắm giữ hơn 13 triệu RLP, với rủi ro ròng khoảng 17 triệu USD.

Đúng vậy, Stream Finance, trước đây đã bị tấn công xUSD, có thể sẽ lại bị tấn công lần nữa.

Tính đến thời điểm viết bài, tin tặc đã chuyển đổi USR thành USDC và USDT, và tiếp tục mua Ethereum, hiện đã mua hơn 10.000 đồng. Sử dụng 200.000 USDC đã rút ra hơn 20 triệu USD tài sản, tin tặc đã tìm thấy "mã số trăm lần" thuộc về TA trong thị trường gấu.

Một lần nữa bị lợi dụng vì "không nghiêm túc"

Cú sập vào ngày 11 tháng 10 năm ngoái đã khiến nhiều stablecoin phát hành bằng chiến lược trung lập Delta gặp phải thiệt hại tài sản do ADL (giảm đòn bẩy tự động). Một số dự án sử dụng các tài sản altcoin làm chiến lược thực thi đã chịu thiệt hại nặng nề hơn và thậm chí là bỏ chạy.

Lần này, Resolv Labs bị tấn công cũng sử dụng cơ chế tương tự để phát hành USR, dự án đã thông báo hoàn thành vòng gọi vốn hạt giống 10 triệu USD vào tháng 4 năm 2025 với sự dẫn dắt của Cyber.Fund và Maven11, cùng với sự tham gia của Coinbase Ventures, và đã ra mắt token RESOLV vào cuối tháng 5 và đầu tháng 6.

Nhưng nguyên nhân Resolv Labs bị tấn công không phải do tình huống cực đoan, mà là thiết kế cơ chế đúc USR "không đủ nghiêm túc".

Hiện tại vẫn chưa có công ty an toàn hoặc cơ quan chính thức nào phân tích nguyên nhân của sự kiện tấn công này. Cộng đồng DeFi YAM thông qua phân tích đã đưa ra kết luận ban đầu: cuộc tấn công rất có thể là do SERVICE_ROLE phía backend của giao thức bị tin tặc kiểm soát, dẫn đến việc cung cấp tham số cho hợp đồng đúc.

Theo phân tích của Grok, khi người dùng đúc USR, sẽ phát động yêu cầu trên chuỗi và gọi hàm requestMint của hợp đồng, các tham số bao gồm:

_depositTokenAddress: địa chỉ token được gửi vào;

_amount: số lượng gửi vào;

_minMintAmount: số lượng USR tối thiểu dự kiến nhận được (chống trượt giá).

Sau đó, người dùng sẽ gửi USDC hoặc USDT vào hợp đồng, SERVICE_ROLE phía backend của nhóm dự án theo dõi yêu cầu, sử dụng oracle Pyth để kiểm tra giá trị của tài sản gửi vào, sau đó gọi hàm completeMint hoặc completeSwap để quyết định số lượng USR thực tế được đúc.

Vấn đề nằm ở chỗ, hợp đồng đúc hoàn toàn tin tưởng vào _mintAmount được cung cấp bởi SERVICE_ROLE, cho rằng con số này đã được Pyth xác minh bên ngoài, vì vậy không đặt giới hạn trên, cũng không có xác minh oracle trên chuỗi, đã trực tiếp thực hiện mint(_mintAmount).

Theo đó, YAM nghi ngờ rằng tin tặc đã kiểm soát SERVICE_ROLE lẽ ra phải do nhóm dự án kiểm soát (có thể do oracle nội bộ mất kiểm soát, ăn cắp tài sản hoặc khóa bị đánh cắp), và đã trực tiếp đặt _mintAmount thành 50 triệu trong quá trình đúc, dẫn đến sự kiện tấn công khi sử dụng 100.000 USDC để đúc 50 triệu USR.

Cuối cùng, kết luận của Grok là, Resolv khi thiết kế giao thức đã không tính đến khả năng địa chỉ (hoặc hợp đồng) dùng để nhận yêu cầu đúc của người dùng có thể bị tin tặc kiểm soát, khi yêu cầu đúc USR được gửi đến hợp đồng cuối cùng đúc USR, không có giới hạn số lượng đúc tối đa, cũng không yêu cầu hợp đồng đúc thực hiện xác minh hai lần bằng oracle trên chuỗi, đã hoàn toàn tin tưởng vào tất cả các tham số do SERVICE_ROLE cung cấp.

Phòng ngừa cũng không đầy đủ

Ngoài việc suy đoán nguyên nhân bị tấn công, YAM cũng chỉ ra rằng nhóm dự án đã chuẩn bị không đủ trong việc ứng phó với khủng hoảng.

YAM đã cho biết trên X rằng Resolv Labs chỉ ngừng giao thức sau 3 giờ kể từ khi tin tặc thực hiện tấn công lần đầu tiên, trong đó có khoảng 1 giờ bị trì hoãn do cần thu thập 4 chữ ký cho giao dịch đa chữ ký. YAM cho rằng, việc tạm dừng khẩn cấp chỉ cần một chữ ký, và quyền hạn nên được phân bổ cho các thành viên trong nhóm hoặc các nhân viên vận hành bên ngoài đáng tin cậy, điều này có thể tăng cường sự chú ý đến các tình huống bất thường trên chuỗi và nâng cao khả năng tạm dừng nhanh chóng, đồng thời bao phủ tốt hơn các múi giờ khác nhau.

Mặc dù đề xuất chỉ cần một chữ ký để tạm dừng giao thức có vẻ hơi cực đoan, nhưng yêu cầu nhiều chữ ký từ các múi giờ khác nhau để tạm dừng giao thức thực sự có thể làm chậm trễ các vấn đề quan trọng khi tình huống khẩn cấp xảy ra. Việc đưa vào các bên thứ ba đáng tin cậy, theo dõi hành vi trên chuỗi liên tục, hoặc sử dụng công cụ giám sát có quyền tạm dừng khẩn cấp, đều là bài học "hậu sự" từ sự kiện này.

Sự tấn công của tin tặc vào các giao thức DeFi đã không chỉ giới hạn ở các lỗ hổng hợp đồng, sự kiện của Resolv Labs cảnh báo các dự án rằng: những giả định về an toàn của giao thức không thể tin tưởng vào bất kỳ một mắt xích nào, tất cả các khâu liên quan đến tham số đều phải được xác minh ít nhất hai lần, ngay cả khi đó là backend do nhóm dự án vận hành.