Phân tích vụ tấn công trộm cắp 9 triệu đô la của Yearn

Lời nói đầu

Vào ngày 1 tháng 12 năm 2025, giao thức Yearn đã bị tấn công tinh vi, nhiều giai đoạn, gây thiệt hại khoảng 9 triệu đô la tài sản. Vụ tấn công không phải là một cuộc tấn công đơn lẻ; thay vào đó, những kẻ tấn công đã sử dụng đòn bẩy tài chính thông qua các khoản vay nhanh, khai thác nhiều lỗ hổng logic trong giao thức để dần dần thao túng nhóm thanh khoản, cuối cùng đạt được việc đúc gần như vô hạn các token LP liên quan đến yETH và làm cạn kiệt nhóm thanh khoản.

Cuộc tấn công này sử dụng các khoản vay flash làm đòn bẩy tài chính ban đầu và xuyên thủng hàng rào phòng thủ của giao thức qua nhiều bước. Quy trình tấn công cốt lõi có thể được chia thành bốn giai đoạn chính: chuẩn bị vốn, thao túng trạng thái, đào coin không giới hạn và chốt lời. Mỗi giai đoạn được kết nối với nhau và khai thác chính xác các lỗ hổng logic trong thiết kế giao thức.

Tấn công vào Tencent : https://etherscan.io/tx/0x53fe7ef190c34d810c50fb66f0fc65a1ceedc10309cf4b4013d64042a0331156

Phân tích kỹ thuật

Đầu tiên, chúng ta vay wstETH, rETH, WETH và 0xa35b_ETHx, rETH, wstETH, cbETH từ Balancer và Aave thông qua hai khoản vay nhanh.

Trong hàm gọi lại khoản vay nhanh, số ETH đã vay được gửi vào Tornado.Cash: 100 ETH để trộn với 1100 ETH. Sau đó, hàm Tornado.Cash: 100 ETHwithdraw được sử dụng để rút 100 ETH vào hợp đồng độc hại 0x3e8e7533dcf69c698Cf806C3DB22f7f10B9B0b97 và kích hoạt hàm dự phòng của nó.

Trong hàm fallack, chúng ta có thể thấy giao dịch cuối cùng trong hình ảnh bên dưới giống với giá trị remove_liquidity ở bước tiếp theo. Có thể suy ra rằng các bước trước đó đều nhằm mục đích trao đổi tài sản thu được từ khoản vay flash thành một lượng lớn token LP của nhóm stableswap có trọng số yETH thông qua các hoạt động như trao đổi, nhằm chuẩn bị cho các cuộc tấn công tiếp theo.

Đến thời điểm này, quá trình tấn công lõi chính thức bắt đầu.

1. Đầu tiên, tất cả token LP thu được từ sàn giao dịch trên sẽ bị hủy và chuyển đổi thành 8 tài sản cơ sở trong nhóm theo phân bổ cổ phần thông qua hàm remove_liquidity của nhóm stableswap có trọng số yETH.

Logic của hàm remove_liquidity có thể được hiểu như sau: giả sử có tổng cộng 10.000 token LP trong nhóm và bạn hủy 416,37 token LP, thì tỷ lệ của bạn là: 416,37 / 10.000 = 4,16%.

Sau đó, đối với mỗi tài sản, giả sử có 1.000 wstETH (số dư ảo prev_vb) trong nhóm, số dư ảo bạn có thể rút là: dvb = 1.000 * 416,37 / 10.000 = 41,637 wstETH, sau đó được chia cho tỷ giá hối đoái để chuyển đổi thành số lượng mã thông báo thực tế.

2. Thứ hai, bằng cách gọi liên tục `add_liquidity`, một pool một chiều được thêm vào. Có tổng cộng 8 tham số `_amounts`, mỗi tham số tương ứng với số lượng tài sản khác nhau cần được thêm vào. Có thể thấy rằng trong các vòng lặp trước, index3[rETH token], index6[wOETH token] và index7[mETH token] đều được nhập bằng 0, nghĩa là 3 token này không được thêm vào mỗi lần thêm thanh khoản.

Bằng cách bơm tài sản đơn phương và rút mã thông báo khỏi nhóm theo cách được mô tả ở trên, khoảng cách về số lượng giữa rETH, w0 ETH, mETH và các mã thông báo khác trong nhóm sẽ được nới rộng một cách giả tạo.

3. Tiếp theo, một lượng lớn mã thông báo rETH được đưa vào một cách đơn phương, tiếp theo là bước quan trọng là loại bỏ tính thanh khoản, nhưng với _amount=0.

Tại sao có thể rút 0 token? Điều này là do việc triển khai nội bộ remove_liquidity .

Hàm remove_liquidity không thực hiện xử lý ngắn mạch cho các giao dịch giá trị 0; nó vẫn thực hiện vòng lặp tính toán vb_prod hoàn chỉnh và tính toán cũng như cập nhật trạng thái packed_pool_vb toàn cục dựa trên sự khác biệt về số lượng mã thông báo trong nhóm được tạo nhân tạo đã đề cập ở trên.

4. Sau đó, gọi hàm update_rates để chỉ cập nhật tỷ lệ pool của index6[wOETH], và cuối cùng gọi hàm remove_liquidity để trích xuất token từ pool. Lúc này, số lượng W0 ETH trong pool gần như đã hết.

5. Tương tự, hãy chia nhỏ phần của index6[w0 ETH] và index7[mETH] trong nhóm theo cách tương tự. Lưu ý rằng sau khi cập nhật index6 hai lần đầu tiên, remove_liquidity được sử dụng để rút token, trong khi index7[mETH] chỉ mới được cập nhật và chưa được rút.

Bằng cách thêm một lượng lớn mã thông báo vào nhóm một chiều và liên tục trích xuất mã thông báo từ tất cả các nhóm, tỷ lệ W0 ETH so với mETH trong nhóm hiện đã đạt gần bằng 0.

Tại thời điểm này, một hợp đồng độc hại mới 0xADbE952eBB9b3e247261d2E3b96835f00f721f8E được tạo và tất cả token được chuyển sang hợp đồng này. Lưu ý rằng token LP thu được bằng cách thêm rETH đơn phương ở bước trước không được chuyển đổi thành token cơ sở mà còn được chuyển sang hợp đồng độc hại mới.

Hoạt động tấn công trước đó đã cập nhật index7[mETH] trong update_rates, nhưng các token chưa được rút sẽ được rút tại đây bằng cách gọi remove_liquidity. Hiện tại, tỷ lệ index6[w0 ETH] trong nhóm rất nhỏ, và tỷ lệ index7[mETH] thậm chí còn nhỏ hơn.

Lúc này, tỷ lệ token trong pool đã mất cân bằng nghiêm trọng. Kẻ tấn công đã gọi lại lệnh add_liquidity để thêm thanh khoản, thu được một lượng lớn token LP theo tỷ lệ [1, 1, 1, 1, 1, 1, 1, 9].

Lúc này, kẻ tấn công đã thu được một lượng lớn token LP. Sau đó, chúng sử dụng các phương pháp như trao đổi và mua lại để kiếm lời và trả lại phí cho khoản vay nhanh.

Đánh giá tấn công

Cuộc tấn công này là cuộc tấn công kết hợp phức tạp, nhiều giai đoạn, trong đó kẻ tấn công khai thác ba lỗ hổng cốt lõi trong hợp đồng pool.vy: Precision Loss, Yield Stripping và Zero Supply Initialization.

Giai đoạn một: Tạo ra sự mất cân bằng cực độ

• Hoạt động: Kẻ tấn công liên tục gọi add_liquidity nhưng cố tình tránh chỉ mục 3 (rETH), chỉ mục 6 (wOETH) và chỉ mục 7 (mETH).
• Mục tiêu: Tạo ra sự mất cân bằng giả tạo trong tỷ lệ tài sản trong nhóm.
• Bước quan trọng: Sau đó tiêm một lượng lớn rETH một cách đơn phương.
• Hậu quả: Điều này làm gia tăng đáng kể khoảng cách định lượng giữa rETH và các tài sản khác (đặc biệt là wOETH và mETH), tạo ra các điều kiện toán học dẫn đến mất độ chính xác.

Giai đoạn hai: Kích hoạt và khóa lỗi

• Hoạt động: Gọi remove_liquidity(_amount=0).
• nguyên tắc:

`remove_liquidity` không thực hiện việc ngắn mạch đối với số lượng bằng 0.

Ngay cả khi không chuyển tiền, hợp đồng vẫn thực hiện vòng lặp tính toán hoàn chỉnh của vb_prod.

Trong trường hợp mất cân bằng trọng lượng nghiêm trọng, hàm _pow_down sẽ tạo ra lỗi sàn đáng kể.

Hợp đồng ghi giá trị lỗi nhỏ hơn của vb_prod vào trạng thái toàn cục packed_pool_vb.

• Về cơ bản, đây là cuộc tấn công trạng thái "không tốn chi phí", trong đó kẻ tấn công có thể thay đổi thành công giá trị sổ sách của nhóm mà không phải chịu bất kỳ chi phí nào.

Giai đoạn ba: Tách doanh thu và khai thác thị phần

• vận hành:

update_rates([6]) (cập nhật tỷ giá hối đoái wOETH).

remove_liquidity (Xóa tài sản).

update_rates([7]) (cập nhật tỷ giá hối đoái mETH).

• nguyên tắc:

`update_rates` sẽ kích hoạt `_update_supply`. Do `vb_prod` trước đó đã bị xóa một cách cố ý, hệ thống đã nhầm lẫn khi cho rằng giá trị pool đã giảm, và do đó đã hủy các token LP được nắm giữ bởi hợp đồng staking để cân bằng tài khoản.

Kẻ tấn công đã khai thác remove_liquidity để kiếm lời trước và sau khi cập nhật tỷ giá hối đoái, dần dần làm cạn kiệt nguồn wOETH và mETH.

• Kết quả: Một lượng lớn hợp đồng staking đã bị phá hủy, phần LP của kẻ tấn công đã tăng lên một cách thụ động và Tổng cung của nhóm bị đẩy về 0.

Giai đoạn bốn: Nguồn cung bằng không, đúc không giới hạn

• Trạng thái tồn tại trước: Sau các hoạt động trên, nhóm đã được làm trống, Tổng cung gần bằng 0 và số dư wOETH và mETH cực kỳ thấp.
• Hoạt động: add_liquidity, tham số là _amounts=[1, 1, 1, 1, 1, 1, 1, 9].
• nguyên tắc:

Khi prev_supply ≈ 0, công thức lặp cho _calc_supply sẽ không thành công khi xử lý các giá trị cực nhỏ (1 wei, 9 wei).

Hợp đồng đã tính toán sai số lượng token LP khổng lồ cần đúc.

• Kết quả: Kẻ tấn công đã lấy được 235.443 ... token yETH LP từ hư không.

Tóm tắt

Cuộc tấn công Yearn đã phơi bày nhiều thiếu sót trong các giao thức DeFi liên quan đến việc xác minh logic trong các kịch bản biên, kiểm soát độ chính xác trong các phép tính số và phòng ngừa rủi ro trước nhiều tổ hợp lỗ hổng. Mô hình tấn công của kẻ tấn công, sử dụng các khoản vay flash làm công cụ, khai thác kết hợp lỗ hổng làm cốt lõi, và che giấu quỹ làm vỏ bọc, làm nổi bật xu hướng chuyên nghiệp hóa và phức tạp hiện nay trong các cuộc tấn công DeFi. Các bài học kinh nghiệm chính từ cuộc tấn công này bao gồm: Thứ nhất, các giao thức cần tăng cường xác minh logic cho các kịch bản biên như "số tiền bằng không" và "mất cân bằng cực độ" để tránh rủi ro can thiệp trạng thái do thiếu xử lý ngắn mạch; thứ hai, mất độ chính xác trong các tỷ lệ cực độ cần được giải quyết trong các phép tính số, và logic tính toán của các hàm chính như `_pow_down` cần được tối ưu hóa. Giao thức Balancer trước đây đã gặp phải một sự cố bảo mật do mất độ chính xác, đóng vai trò như một bài học cảnh báo; thứ ba, cần thiết lập một hệ thống giám sát rủi ro đa chiều để đưa ra cảnh báo cho các hoạt động đáng ngờ như bơm thanh khoản một chiều tần suất cao và cập nhật tỷ giá hối đoái bất thường. Đối với toàn bộ ngành DeFi, sự cố này một lần nữa chứng minh rằng bảo mật giao thức không chỉ yêu cầu khắc phục các lỗ hổng riêng lẻ mà còn phải ngăn chặn các cuộc tấn công kết hợp nhiều lỗ hổng từ góc độ toàn bộ quy trình, đồng thời tăng cường theo dõi và chặn dòng tiền của kẻ tấn công để cải thiện khả năng bảo vệ an ninh tổng thể của ngành.