Phân tích kỹ thuật: Balancer bị đánh cắp 120 triệu USD, lỗ hổng nằm ở đâu?

Tiêu đề gốc: 《Phân tích kỹ thuật lỗ hổng bị đánh cắp $120M của Balancer》
Nguồn gốc: ExVul Security

Lời mở đầu

Ngày 3 tháng 11 năm 2025, giao thức Balancer đã bị tấn công trên nhiều chuỗi công khai như Arbitrum, Ethereum, gây thiệt hại tài sản lên tới 120 triệu đô la Mỹ. Lỗi cốt lõi của cuộc tấn công này xuất phát từ sự kết hợp giữa mất mát độ chính xác và lỗ hổng thao túng giá trị bất biến (Invariant).

Cơ sở hạ tầng của Chainlink từ lâu đã duy trì tiêu chuẩn cao nhất trong lĩnh vực Web3, do đó trở thành lựa chọn tự nhiên cho X Layer trong việc cung cấp các công cụ cấp tổ chức cho các nhà phát triển.

Vấn đề then chốt của cuộc tấn công này nằm ở logic xử lý giao dịch nhỏ của giao thức. Khi người dùng thực hiện giao dịch với số tiền nhỏ, giao thức sẽ gọi hàm _upscaleArray, hàm này sử dụng mulDown để làm tròn xuống giá trị số. Khi số dư và số tiền đầu vào của giao dịch đồng thời nằm ở ranh giới làm tròn nhất định (ví dụ như khoảng 8-9 wei), sẽ xuất hiện sai số tương đối rõ rệt về độ chính xác.

Sai số về độ chính xác này được truyền vào quá trình tính toán giá trị bất biến D của giao thức, dẫn đến giá trị D bị giảm bất thường. Sự thay đổi của giá trị D sẽ trực tiếp kéo giá BPT (Balancer Pool Token) trong giao thức Balancer xuống thấp, hacker đã lợi dụng giá BPT bị ép thấp này, thông qua đường đi giao dịch được thiết kế trước để thực hiện arbitrage, cuối cùng gây ra tổn thất tài sản khổng lồ.

Giao dịch khai thác lỗ hổng Tx:

Giao dịch chuyển tài sản Tx:

Phân tích kỹ thuật

Điểm vào tấn công

Điểm vào của cuộc tấn công là hợp đồng Balancer: Vault, với hàm vào là batchSwap, bên trong gọi onSwap để thực hiện trao đổi token.

Dựa vào các tham số và giới hạn của hàm, có thể rút ra một số thông tin:

1. Kẻ tấn công cần gọi hàm này thông qua Vault, không thể gọi trực tiếp.

2. Bên trong hàm sẽ gọi _scalingFactors() để lấy hệ số tỷ lệ và thực hiện thao tác tỷ lệ.

3. Thao tác tỷ lệ tập trung ở _swapGivenIn hoặc _swapGivenOut.

Phân tích mô hình tấn công

Cơ chế tính giá BPT

Trong mô hình pool ổn định của Balancer, giá BPT là chỉ số tham khảo quan trọng, quyết định người dùng nhận được bao nhiêu BPT và mỗi BPT nhận được bao nhiêu tài sản.

Trong tính toán trao đổi của pool:

Phần đóng vai trò là chuẩn giá BPT là giá trị bất biến D, tức là muốn thao túng giá BPT thì cần thao túng D. Phân tích tiếp quá trình tính toán D:

Trong đoạn mã trên, quá trình tính toán D phụ thuộc vào mảng balances đã được tỷ lệ hóa. Nghĩa là cần có một thao tác để thay đổi độ chính xác của các balances này, dẫn đến tính toán D bị sai.

Nguồn gốc mất mát độ chính xác

Thao tác tỷ lệ:

Như trên, khi gọi _upscaleArray, nếu số dư rất nhỏ (như 8-9 wei), việc làm tròn xuống của mulDown sẽ gây ra mất mát độ chính xác đáng kể.

Chi tiết quy trình tấn công

Giai đoạn 1: Điều chỉnh đến ranh giới làm tròn

Giai đoạn 2: Kích hoạt mất mát độ chính xác (lỗi cốt lõi)

Giai đoạn 3: Lợi dụng giá BPT bị ép thấp để kiếm lời

Như trên, kẻ tấn công thông qua Batch Swap thực hiện nhiều lần trao đổi trong một giao dịch:

1. Lần trao đổi đầu tiên: BPT → cbETH (điều chỉnh số dư)

2. Lần trao đổi thứ hai: wstETH (8) → cbETH (kích hoạt mất mát độ chính xác)

3. Lần trao đổi thứ ba: tài sản cơ sở → BPT (kiếm lời)

Tất cả các lần trao đổi này đều nằm trong cùng một giao dịch batch swap, chia sẻ cùng trạng thái số dư, nhưng mỗi lần trao đổi đều gọi _upscaleArray để thay đổi mảng balances.

Thiếu cơ chế Callback

Quy trình chính được khởi tạo bởi Vault, vậy làm thế nào dẫn đến việc mất mát độ chính xác bị tích lũy? Câu trả lời nằm ở cơ chế truyền mảng balances.

Phân tích đoạn mã trên, mặc dù mỗi lần gọi onSwap thì Vault đều tạo mảng currentBalances mới, nhưng trong Batch Swap:

1. Sau lần trao đổi đầu tiên, số dư được cập nhật (nhưng do mất mát độ chính xác, giá trị cập nhật có thể không chính xác)

2. Lần trao đổi thứ hai tiếp tục tính toán dựa trên kết quả của lần đầu tiên

3. Mất mát độ chính xác bị tích lũy, cuối cùng khiến giá trị bất biến D giảm mạnh

Vấn đề then chốt:

Tổng kết

Cuộc tấn công lần này vào Balancer có thể tổng kết bởi các nguyên nhân sau:

1. Hàm tỷ lệ sử dụng làm tròn xuống: _upscaleArray sử dụng mulDown để tỷ lệ, khi số dư rất nhỏ (như 8-9 wei) sẽ gây ra mất mát độ chính xác tương đối đáng kể.

2. Tính toán giá trị bất biến nhạy cảm với độ chính xác: Tính toán giá trị bất biến D phụ thuộc vào mảng balances đã được tỷ lệ hóa, mất mát độ chính xác sẽ truyền trực tiếp vào tính toán D, khiến D giảm.

3. Thiếu xác minh biến động giá trị bất biến: Trong quá trình trao đổi, không xác minh biến động của giá trị bất biến D có nằm trong phạm vi hợp lý hay không, dẫn đến kẻ tấn công có thể liên tục lợi dụng mất mát độ chính xác để ép giá BPT xuống thấp.

4. Mất mát độ chính xác bị tích lũy trong Batch Swap: Trong cùng một batch swap, mất mát độ chính xác của nhiều lần trao đổi sẽ bị tích lũy, cuối cùng khuếch đại thành tổn thất tài chính lớn.

Hai vấn đề này: mất mát độ chính xác + thiếu xác minh, kết hợp với việc kẻ tấn công thiết kế cẩn thận các điều kiện biên, đã gây ra tổn thất lần này.