By: yudan@slow fog 보안팀

보조 제목

공격 내역 분석

BurgerSwap은 Uniswap과 유사한 AMM 프로젝트이지만 Uniswap 아키텍처와는 다릅니다. BurgerSwap 아키텍처는 일반적으로 [Delegate -> lpPlatForm -> Pair]로 나뉩니다. Delegate 레이어는 모든 Pair 정보를 관리하고 lpPlatForm 레이어 생성을 담당합니다. 그런 다음 lpPlatForm 레이어가 내려가 해당 페어 계약을 생성합니다. 아키텍처 전반에 걸쳐 lpPlatForm 레이어는 Uniswap에서 라우터 역할을 하며 계산된 트랜잭션 데이터와 교환할 토큰을 Pair 계약으로 전달하여 교환을 완료합니다.

이 사건의 근원은 이 구조의 문제에 있다. 공격자의 트랜잭션 동작을 단계별로 분석하여 전체 공격 프로세스의 핵심을 복원합니다.

이 공격은 Pancake의 Flash Loan에서 시작되었으며, 공격자는 Pancake로부터 WBNB를 대량으로 빌린 후 BurgerSwap을 통해 이 WBNB를 Burger 토큰으로 전환했습니다. 위의 작업을 완료한 후 공격자는 자신이 제어하는 ​​토큰(공격 계약 자체)과 Burger 토큰을 사용하여 Delegate 레이어를 통해 트랜잭션 쌍을 생성하고 유동성을 추가하여 후속 공격에 대비합니다.

토큰 생성 및 준비 완료 후 공격자는 즉시 PaltForm 레이어의 swapExactTokensForTokens 기능을 통해 교환을 개시하며, 교환 경로는 [공격자가 제어하는 ​​토큰 -> Burger -> WBNB]입니다.

다음은 가장 중요한 작업이었습니다.

공격자는 트랜잭션 쌍을 생성할 때 자신이 제어하는 ​​토큰을 사용했기 때문에 토큰 교환 과정에서 _innerTransferFrom 함수는 공격자가 제어하는 ​​토큰 계약을 호출하므로 공격자는 _innerTransferFrom 함수에 swapExactTokensForTokens 함수를 다시 입력할 수 있습니다. 공격자는 왜 이렇게 할까요?

PlatForm 레이어의 swapExactTokensForTokens 함수의 코드를 분석해보면 컨트랙트가 _innerTransferFrom 함수를 호출할 때 사용자의 교환 데이터를 먼저 계산한 다음 미리 계산된 데이터를 사용하여 하위 레이어로 전달하는 것을 어렵지 않게 알 수 있다. _innerTransferFrom 함수의 작동 토큰 교환. 이 함수의 관점에서 공격자가 swapExactTokensForTokens 함수에 재진입하더라도 하위 레이어에서 호출하는 스왑 함수도 독립적이므로 언뜻 보기에는 문제가 없지만 체인 상의 동작이 주목을 끌었습니다. SlowMist 보안 팀:

환매 과정에서 슬리피지(slippage)로 인한 교환 횟수가 줄어들지 않아 놀랐습니다. 이유가 무엇입니까? 핵심은 기본 Pair 계약의 문제인 것 같습니다. 우리는 최하위 계층에서 호출한 쌍 계약을 추가로 분석했으며 코드는 다음과 같습니다.

요약하다

요약하다

이 공격은 BurgerSwap 아키텍처의 문제인데, Pair 레이어는 PaltForm 레이어의 데이터를 완전히 신뢰하고 자체적으로 다른 검사를 수행하지 않기 때문에 공격이 발생합니다. 최근 DeFi 보안 사고가 빈번하게 발생하고 있으며, DApp 공격이 점점 더 심화되고 있는 점을 감안하여, SlowMist 보안팀은 DApp 개발자들이 다른 프로토콜에서 코드를 이식할 때 이식 프로토콜의 아키텍처를 완전히 이해하고 포팅 프로토콜과 그들의 이식 프로토콜을 충분히 고려할 필요가 있다고 권고합니다. 자체 프로젝트.

공격 트랜잭션 참조:

https://bscscan.com/tx/0xac8a739c1f668b13d065d56a03c37a686e0aa1c9339e79fcbc5a2d0a6311e333