Công ty phân tích kỹ thuật Balancer bị trộm 120 triệu đô la; lỗ hổng nằm ở đâu?

Tiêu đề gốc: "Balancer bị đánh cắp 120 triệu đô la: Phân tích lỗ hổng"
Nguồn gốc: ExVul Security

Giới thiệu

Vào ngày 3 tháng 11 năm 2025, giao thức Balancer đã bị tin tặc tấn công vào nhiều chuỗi công khai, bao gồm Arbitrum và Ethereum, dẫn đến thiệt hại 120 triệu đô la tài sản. Nguyên nhân cốt lõi của cuộc tấn công bắt nguồn từ lỗ hổng kép liên quan đến mất độ chính xác và thao túng bất biến.

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

Vấn đề chính trong cuộc tấn công này nằm ở logic xử lý các giao dịch nhỏ của giao thức. Khi người dùng thực hiện một giao dịch nhỏ, giao thức sẽ gọi hàm _upscaleArray, sử dụng mulDown để làm tròn giá trị xuống.

Nếu số dư và số tiền đầu vào trong một giao dịch đều nằm trong một ranh giới làm tròn cụ thể (ví dụ: phạm vi 8-9 wei), một lỗi độ chính xác tương đối đáng kể sẽ xảy ra. Lỗi độ chính xác này lan truyền đến phép tính giá trị bất biến D của giao thức, khiến D bị giảm bất thường. Sự thay đổi D này trực tiếp làm giảm giá BPT (Mã thông báo nhóm cân bằng) trong giao thức Balancer. Tin tặc có thể lợi dụng mức giá BPT thấp này để kiếm lời chênh lệch giá thông qua các đường dẫn giao dịch được thiết kế sẵn, cuối cùng dẫn đến tổn thất tài sản khổng lồ. Giao dịch khai thác lỗ hổng: https://etherscan.io/tx/0x6ed07db1a9fe5c0794d44cd36081d6a6df103fab868cdd75d581e3bd23bc9742 Giao dịch chuyển giao tài sản:

https://etherscan.io/tx/0xd155207261712c35fa3d472ed1e51bfcd816e616dd4f517fa5959836f5b48569

Phân tích kỹ thuật

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

Điểm vào tấn công là hợp đồng Balancer: Vault và hàm vào tương ứng là hàm batchSwap, gọi onSwap nội bộ để thực hiện hoán đổi mã thông báo.

Từ các tham số và hạn chế của hàm, chúng ta có thể thu thập được 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 phải trực tiếp.

2. Hàm này gọi _scalingFactors() nội bộ để lấy các hệ số tỷ lệ cho các hoạt động tỷ lệ.

3. Các hoạt động tỷ lệ được tập trung trong _swapGivenIn hoặc _swapGivenOut.

Phân tích mô hình tấn công Cơ chế tính toán giá BPT Trong mô hình nhóm ổn định của Balancer, **giá BPT** là một tham chiếu quan trọng, xác định số lượng BPT mà người dùng nhận được và số lượng tài sản mà mỗi BPT đại diện. Trong phép tính trao đổi của nhóm: Phần đóng vai trò là **giá trị chuẩn của giá BPT** là **giá trị hằng số D**, nghĩa là việc thao túng giá BPT đòi hỏi phải thao túng D. Hãy phân tích quy trình tính toán của D:

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

Nguyên nhân gốc rễ của việc mất độ chính xác

Hoạt động điều chỉnh tỷ lệ:

Như đã trình bày ở trên, khi sử dụng _upscaleArray, nếu số dư rất nhỏ (ví dụ: 8-9 wei), việc làm tròn xuống của mulDown sẽ dẫn đến mất độ chính xác đáng kể.

Luồng tấn công chi tiết

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

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

Giai đoạn 3: Lợi nhuận từ Giá BPT Giảm

Như được hiển thị ở trên, kẻ tấn công thực hiện nhiều lần hoán đổi trong một giao dịch bằng cách sử dụng **Hoán đổi hàng loạt**:

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

2. Hoán đổi thứ hai: wstETH

(8) → cbETH (kích hoạt mất độ chính xác) 3. Hoán đổi thứ ba: Tài sản cơ sở → BPT (lợi nhuận) Tất cả các lần hoán đổi này đều nằm trong cùng một giao dịch hoán đổi hàng loạt, chia sẻ cùng trạng thái số dư, nhưng mỗi lần hoán đổi gọi _upscaleArray để sửa đổi mảng số dư. Thiếu cơ chế Gọi lại Quá trình chính được bắt đầu bởi Vault, vậy làm thế nào nó dẫn đến sự tích tụ mất độ chính xác? Câu trả lời nằm ở cơ chế truyền của mảng balances. Phân tích đoạn mã trên, mặc dù Vault tạo một mảng currentBalances mới mỗi khi onSwap được gọi, trong Batch Swap:

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

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

3. Mất độ chính xác tích lũy, cuối cùng khiến giá trị bất biến D trở nên nhỏ hơn đáng kể

Các vấn đề chính:

Tóm tắt

Cuộc tấn công vào Balancer này có thể được tóm tắt như sau:

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

2. Tính toán giá trị bất biến nhạy cảm với độ chính xác: Việc tính toán giá trị bất biến D dựa trên mảng số dư đã chia tỷ lệ. Tổn thất độ chính xác được truyền trực tiếp vào phép tính D, làm cho D nhỏ hơn. 3. Thiếu xác minh các thay đổi giá trị bất biến: Trong quá trình hoán đổi, không xác minh được liệu các thay đổi trong giá trị bất biến D có nằm trong phạm vi hợp lý hay không, cho phép kẻ tấn công liên tục khai thác tổn thất độ chính xác để hạ giá BPT. 4. Tích lũy tổn thất độ chính xác trong các hoán đổi hàng loạt: Trong cùng một hoán đổi hàng loạt, tổn thất độ chính xác từ nhiều lần hoán đổi tích lũy, cuối cùng khuếch đại thành một khoản lỗ tài chính khổng lồ. Hai vấn đề này—tổn thấ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 này. Bài viết này là một bài gửi và không đại diện cho quan điểm của BlockBeats.