원문 제목: "밸런서, 1억 2천만 달러 도난: 취약점 분석"
원문 출처: ExVul Security

소개

2025년 11월 3일, 밸런서 프로토콜은 Arbitrum과 Ethereum을 포함한 여러 퍼블릭 체인에 대한 해커 공격을 받아 1억 2천만 달러의 자산 손실을 입었습니다. 공격의 핵심은 정밀도 손실과 불변 조작을 포함하는 이중 취약점에서 비롯되었습니다.

체인링크의 인프라는 오랫동안 웹 3.0 분야에서 최고 수준을 유지해 왔기 때문에 X Layer가 개발자에게 기관급 도구를 제공하는 데 있어 당연한 선택이었습니다.

이 공격의 핵심 문제는 소액 거래를 처리하는 프로토콜의 논리에 있습니다. 사용자가 소액 거래를 할 때, 프로토콜은 _upscaleArray 함수를 호출하는데, 이 함수는 mulDown을 사용하여 값을 내림합니다.

거래의 잔액과 입력 금액이 모두 특정 반올림 경계(예: 8-9 wei 범위) 내에 있는 경우, 상당한 상대 정밀도 오류가 발생합니다. 이 정밀도 오류는 프로토콜의 불변값 D 계산에 영향을 미쳐 D가 비정상적으로 감소하게 됩니다. 이러한 D의 변화는 Balancer 프로토콜에서 BPT(Balancer Pool Token) 가격을 직접적으로 낮춥니다. 해커는 이렇게 낮아진 BPT 가격을 악용하여 미리 설계된 거래 경로를 통해 차익거래를 시도할 수 있으며, 궁극적으로 막대한 자산 손실을 초래할 수 있습니다. 취약점 악용 Tx: https://etherscan.io/tx/0x6ed07db1a9fe5c0794d44cd36081d6a6df103fab868cdd75d581e3bd23bc9742 자산 전송 Tx:

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

기술 분석

공격 진입 지점

공격 진입 지점은 Balancer: Vault 계약이고 해당 진입 기능은 내부적으로 onSwap을 호출하여 토큰 교환을 수행하는 batchSwap 함수입니다.

함수 매개변수와 제한 사항에서 다음과 같은 정보를 얻을 수 있습니다.

1. 공격자는 직접이 아닌 Vault를 통해 이 함수를 호출해야 합니다.

2. 이 함수는 내부적으로 _scalingFactors()를 호출하여 스케일링 작업에 필요한 스케일링 계수를 얻습니다.

3. 스케일링 작업은 _swapGivenIn 또는 _swapGivenOut에 집중되어 있습니다.

공격 패턴 분석 BPT 가격 계산 메커니즘 Balancer의 안정적인 풀 모델에서 **BPT 가격**은 사용자가 받는 BPT 수와 각 BPT가 나타내는 자산 수를 결정하는 중요한 기준입니다. 풀의 교환 계산에서 **BPT 가격 벤치마크** 역할을 하는 부분은 **상수 값 D**입니다. 즉, BPT 가격을 조작하려면 D를 조작해야 합니다. D의 계산 과정을 분석해 보겠습니다.

위 코드에서 D의 계산 과정은 스케일링된 잔액 배열에 따라 달라집니다. 즉, 이러한 잔액의 정밀도를 변경하는 연산이 필요하여 D가 잘못 계산됩니다.

정밀도 손실의 근본 원인

스케일링 작업:

위에서 보듯이 _upscaleArray를 사용할 때 잔액이 매우 작은 경우(예: 8-9 wei) mulDown의 다운라운딩으로 인해 정밀도가 크게 저하됩니다.

자세한 공격 흐름

1단계: 반올림 경계에 맞게 조정

2단계: 트리거 정밀도 손실(핵심 취약점)

3단계: 하락한 BPT 가격에서 수익 창출

위에서 보듯이 공격자는 **일괄 스왑**을 사용하여 한 번의 트랜잭션에서 여러 스왑을 수행합니다.

1. 첫 번째 스왑: BPT → cbETH(잔액 조정)

2. 두 번째 스왑: wstETH

(8) → cbETH(정밀도 손실 발생) 3. 세 번째 스왑: 기초 자산 → BPT(수익) 이러한 스왑은 모두 동일한 일괄 스왑 트랜잭션에 있으며 동일한 잔액 상태를 공유하지만 각 스왑은 _upscaleArray를 호출하여 잔액 배열을 수정합니다. 콜백 메커니즘이 부족합니다. 주요 프로세스는 Vault에서 시작되므로 어떻게 정밀도 손실이 누적될까요? 답은 balances 배열의 전달 메커니즘에 있습니다. 위 코드를 분석하면 Vault는 onSwap이 호출될 때마다 새로운 currentBalances 배열을 생성하지만 Batch Swap에서는 다음과 같습니다.

1. 첫 번째 스왑 후 잔액이 업데이트됩니다(단, 정밀도 손실로 인해 업데이트된 값이 부정확할 수 있음)

2. 두 번째 스왑은 첫 번째 스왑 결과를 기반으로 계산을 계속합니다.

3. 정밀도 손실이 누적되어 결국 불변값 D가 상당히 작아집니다.

주요 문제:

요약

밸런서에 대한 이 공격은 다음과 같이 요약할 수 있습니다.

1. 스케일링 함수는 내림을 사용합니다. _upscaleArray는 스케일링에 mulDown을 사용하는데, 이는 잔액이 매우 작을 때(예: 8-9 wei) 상당한 상대적 정밀도 손실을 발생시킵니다.

2. 불변값 계산은 정밀도에 민감합니다. 불변값 D의 계산은 스케일링된 잔액 배열에 의존합니다. 정밀도 손실은 D 계산에 직접 전달되어 D를 더 작게 만듭니다. 3. 불변값 변경 검증 부족: 스왑 프로세스 중에 불변값 D의 변경이 합리적인 범위 내에 있는지 검증하지 못하여 공격자가 정밀도 손실을 반복적으로 악용하여 BPT 가격을 낮출 수 있었습니다. 4. 일괄 스왑에서 정밀도 손실 누적: 동일한 일괄 스왑에서 여러 스왑으로 인한 정밀도 손실이 누적되어 결국 막대한 재정적 손실로 확대됩니다. 정밀도 손실 + 검증 부족이라는 두 가지 문제가 공격자의 경계 조건 설계와 결합되어 이러한 손실을 초래했습니다. 본 기사는 제출된 글이며 BlockBeats의 견해를 대변하지 않습니다.

BlockBeats 공식 커뮤니티에 참여하세요:

Telegram 구독 그룹：https://t.me/theblockbeats

Telegram 토론 그룹：https://t.me/BlockBeats_App

Twitter 공식 계정：https://twitter.com/BlockBeatsAsia