슬로우 포그: AAVE V2 보안 감사 매뉴얼

소개

탈중앙화 금융(DeFi) 생태계가 빠르게 성장함에 따라 선도적인 탈중앙화 대출 프로토콜 중 하나인 AAVE V2는 혁신적인 대출과 유동성 관리 솔루션을 제공하는 데 앞장서 왔습니다. 신뢰가 필요 없는 독특한 메커니즘과 효율적인 자본 활용으로 많은 사용자와 기관을 끌어모았습니다. 그러나 채택이 증가하고 관련 자금 규모가 커짐에 따라 보안 감사 및 위험 관리 조치의 중요성이 점점 더 커지고 있습니다. 이 브로셔에서는 AAVE V2 프로토콜의 핵심 설계, 주요 기능, 감사 고려사항에 대해 자세히 살펴봅니다.

프로젝트 배경 개요

AAVE V2는 이더리움 블록체인 기반의 오픈 대출 플랫폼으로, 사용자가 다양한 ERC-20 토큰을 예치하고 이자를 받을 수 있는 플랫폼입니다. 토큰을 예치하고 이자를 받을 수 있을 뿐만 아니라 이자 지급의 형태로 시장에서 토큰을 빌릴 수도 있습니다. AAVE V2는 "금리 시장"이라는 개념을 도입함으로써 탈중앙화된 풀 관리와 자동화된 금리 조정 메커니즘을 가능하게 합니다. 또한 AAVE V2는 사용자의 다양한 요구를 충족시키기 위해 플래시 대출, 모기지 대출, 토큰 교환과 같은 고급 기능을 제공하여 디파이 영역에서 선도적인 위치를 더욱 공고히 하고 있습니다.

프로젝트 아키텍처 분석

AAVE V2의 전체 아키텍처는 효율적이고 안전한 탈중앙화 대출 서비스를 제공하는 것을 목표로 사용자, 자금 흐름 관리, 담보 메커니즘, 청산 프로세스 및 이자율 전략의 핵심 기능을 중심으로 설계되었습니다. 다음은 종합적인 분석입니다.

사용자 흐름

사용자: 사용자는 입금, 대출, 상환을 할 수 있습니다, 출금, 대출 및 이자율 모델 스왑, 플래시 대출, 위임 신용 등 다양한 작업을 수행할 수 있습니다. 사용자가 계약과 상호 작용할 때, 사용자의 행동에 따라 적절한 aToken을 자동으로 채굴하거나 소멸하여 계약의 예금에 대한 관심을 나타내며, 이자율 전략에 따라 수익을 받습니다.

크레딧 위임: 사용자는 자신의 크레딧을 다른 사용자에게 위임하여 프로토콜의 유연성과 사용 시나리오를 확장할 수 있습니다.

핵심 구성요소

LendingPool:은 핵심 모듈로서 모든 사용자 예금, 차입, 상환, 대출 및 차입 금리 모델 스왑, 플래시 대출, 청산, 금리 및 상태 업데이트 등 모든 운영 요청을 처리합니다.

담보 관리자:는 담보 자산을 관리하고 사용자의 대출 행위를 안전하게 통제합니다. 담보 자산이 부족할 경우 시스템의 전체 유동성을 보호하기 위해 청산 프로세스가 시작됩니다.

라이브러리: 청산 및 대출 작업을 위한 계산과 같은 저축 로직, 검증 로직, 공통 기능 로직을 캡슐화하여 LendingPool을 지원합니다.

• GenericLogic은 자산 평가, 담보 가치, 건강 상태 등 사용자의 상태를 계산하고 검증합니다. 계산, 건강 요소 및 기타 작업을 포함한 사용자의 상태를 계산하고 검증합니다.

• ReserveLogic은 각 자산의 예금, 차입금, 현재 이자율을 추적하고 업데이트하여 준비금 풀을 관리하는 데 사용됩니다.

• ValidationLogic은 사용자 행동이 계약 규칙을 준수하는지 확인하고 사용자가 예금, 대출, 상환, 청산, 플래시 대출, 부채 모드 전환 등을 할 때 담보 및 부채에 대한 엄격한 확인을 수행합니다.

부채와 토큰화

부채토큰:부채 토큰: 부채 토큰은 사용자의 차입 부채를 추적하는 데 사용되며 대출된 자금과 1:1로 연동됩니다. 부채 토큰은 고정 및 변동 금리 옵션(예: DebtDAI 스테이블, DebtDAI 가변 등)으로 제공되며 부채 토큰은 양도할 수 없습니다.

a토큰: 사용자가 자산을 예치하면 기초 자산을 고정하기 위해 1:1 에이토큰이 생성되며, 이 에이토큰은 예치금에서 얻은 이자를 반영하여 가치가 증가합니다. 그런 다음 원금 잔액과 함께 스케일드 잔액(ScB)이라는 비율로 도입되어 저장됩니다.

공식은 다음과 같습니다:

가격 및 이자율

Oracles Proxy:는 외부 예후 예측자(Chainlink)를 사용하여 자산 시장 가격을 제공합니다. 데이터를 제공하여 사용자 담보 자산의 가치를 평가하고, 대출 및 차용 행위에 대한 가격 정확성과 시스템 안정성을 보장합니다.

대출 금리 오라클: 시스템 상태와 시장 상황에 따라 동적 대출 금리를 제공하여 자본 활용도와 유동성을 최적화합니다.

구성 및 관리

컨피규레이터:위험 매개변수와 다양한 자산의 대출 한도와 같은 시스템 매개변수를 구성하는 데 사용됩니다. 다양한 자산에 대한 위험 매개변수와 대출 한도를 설정하고, 비상 시 활성화, 대출, 담보, 동결, 매개변수 업데이트, 기능 활성화 또는 비활성화 등 준비금의 다양한 운영을 관리할 수 있습니다. 시장 변화에 따라 프로토콜을 동적으로 조정할 수 있는지 확인합니다.

기타 주요 기능

청산 관리자: 사용자 담보의 담보 가치가 청산 임계값 아래로 떨어지면 청산 작업을 관리하고 시스템의 자본 보안을 보호합니다. 청산 관리자는 청산 작업에 대한 보상을 받을 수 있습니다.

예비금 잔고: 이자율 전략을 계산하고 조정하는 데 사용되는 시스템의 예비금 데이터를 저장합니다.

이자율 전략

이자율 전략: 시장 및 사용자 수요에 따라 최적의 금리를 달성하기 위해 이자율을 동적으로 조정합니다.

이자율 모델에는 두 가지 유형(안정형과 변동형)이 있지만, 모델 계산은 변곡점 모델과 유사합니다. 최적 활용의 변곡점인 기울기1과 최적 활용을 초과하는 기울기2가 구간으로 계산되며, 이 조건에 따라 고정금리 모델과 변동금리 모델로 나뉩니다.

공식은 다음과 같습니다. "text-align:가운데">

프로세스 개요

입금

사용자는 LendingPool의 입금 함수를 호출하여 입금을 합니다. 사용자는 자산 주소, 입금 금액, 수취인 주소, 추천 코드의 네 가지 파라미터를 허용하는 LendingPool 컨트랙트의 입금 함수를 호출하여 입금을 합니다. 먼저 컨트랙트가 활성화되어 있지 않은지 확인한 다음, ValidationLogic.validateDeposit을 통해 입금액이 0보다 커야 하는지 확인하고, 준비금이 활성화되어 있고 동결되지 않았는지 확인합니다. 그런 다음 시스템은 reserve.updateState()를 호출하여 유동성 누적 지수 및 가변 차입 지수를 업데이트하고 해당 기간 동안 발생한 이자를 계산하여 일부를 발행하여 프로토콜 재무부로 이체합니다.

공식은 다음과 같습니다:

유동성 금리, 안정 차입 금리 및 변동 차입 금리(모두 DefaultReserveInterestRateStrategy에 의해 계산됩니다. 계산 이자율 함수). 자산 전송의 경우, 시스템은 사용자의 기본 자산을 aToken 컨트랙트로 전송하고 사용자가 제출한 onBehalfOf 주소로 동일한 양의 aToken을 채굴합니다. 에이토큰은 이자 축적을 처리하기 위해 스케일드 잔액 메커니즘을 사용합니다. 사용자가 처음 입금하는 경우, 시스템은 자동으로 해당 자산을 사용자의 담보로 표시합니다.

AAVE V2의 입금 프로세스는 컴파운드와 비교해 다음과 같은 주요 특징이 있습니다.

수취인 주소 지정 지원(onBehalfOf).

ValidationLogic 컨트랙트를 통한 입금 유효성 검사.

유동성 축적 지수 및 가변 차입 지수를 업데이트하여 합의된 국고채 이자를 계산하고 할당합니다.

유동성, 안정 차입, 변동 차입에 대한 세 가지 이자율을 동시에 조정합니다.

이자는 에이토큰의 잔액을 사용하여 처리됩니다.

첫 예치금은 자동으로 담보로 표시됩니다.

출금

사용자는 출금 기능을 호출하여 돈을 인출할 수 있습니다. 먼저 해당 aToken 주소를 포함하여 지정된 자산의 준비금 데이터를 가져와서 해당 사용자의 aToken 잔액을 확인합니다. 다음으로 ValidationLogic.validateWithdraw 함수를 호출하여 출금 금액이 유효한지, 사용자의 잔액이 충분한지, 리저브가 활성화되어 있는지 확인하는 등 출금 요청의 유효성을 검사합니다. 이 중 사용자의 건강 인자와 출금이 담보에 영향을 미치는지 여부는 컴파운드에서 getHypotheticalAccountLiquidityInternal 함수의 역할과 유사하게 GenericLogic.balanceDecreaseAllowed에서 확인합니다. balanceDecreaseAllowed 함수에서 계산UserAccountData 및 계산HealthFactorFromBalances 함수는 자금 인출 후 유동성 임계값을 계산하고 사용자의 총 담보, 총 차입 금액, 사용자의 현재 건강 계수를 확인하여 사용자의 건강 계수가 유동성 임계값에 있는지 확인합니다. 사용자의 건전성 지표가 유동성 임계값에 안전한지 여부를 확인합니다.

HF는 다음과 같이 계산됩니다:

이후 적립금 상태가 업데이트되고 이자율이 업데이트되어 현금 인출 금액이 함수에 전달됩니다. 사용자가 현재 잔액과 동일한 금액의 인출을 요청하면 사용자 설정이 업데이트되어 준비금이 더 이상 담보로 사용되지 않는 것으로 표시됩니다. 마지막으로 사용자의 에이토큰이 소멸되고 출금된 자산이 지정된 주소로 전송됩니다.

컴파운드와 비교했을 때 AAVE V2의 출금 프로세스는 다음과 같은 주요 특징이 있습니다.

A토큰을 사용하여 프로토콜에서 사용자의 예치금을 나타내므로 출금 시 실제로는

사용자가 지정된 주소(to 매개변수를 통해)로 출금할 수 있도록 허용하여 유연성을 높입니다.

부분 출금 및 전액 출금 옵션을 제공합니다.

출금 유효성 검사에서 AAVE는 보다 정교한 balanceDecreaseAllowed 함수를 사용하여 출금이 사용자의 전체 담보 포지션에 미치는 영향을 확인합니다.

AAVE의 출금 프로세스는 Compound처럼 accrueInterest 함수를 통하지 않고 이자율을 직접 업데이트합니다.

차입

사용자는 차용 기능을 통해 차용하며, 차용은 가격 예측 기계에서 자산의 현재 가격을 가져와서 차용 금액을 해당 이더로 환산합니다. 그런 다음 차입은 ValidationLogic.validateBorrow와 GenericLogic.calculateUserAccountData를 통해 적법성을 확인하며, 이는 onBehalfOf 주소, 총 부채, 현재 담보가치 대비 대출 비율(LTV), 청산 임계값, 청산 한도를 포함한 총 담보 자산을 계산합니다. 건전성 비율, 시장 안정성(복리의 getHypotheticalAccountLiquidityInternal과 유사), 차입할 담보 자산이 충분한지 여부 등입니다. reserve.updateState는 이자율, 차입 지수 등 준비금 상태를 업데이트합니다(이 단계는 복리의 accrueInterest와 유사). 의 accrueInterest)를 호출하여 이자율을 계산하고 업데이트하는 데 사용됩니다.

그런 다음 사용자가 선택한 이자 모드(안정 또는 변동)에 따라 부채가 생성되고, 다른 이자율 모델을 가진 토큰 콘트랙트가 토큰을 발행하기 위해 선택됩니다. 또한 토큰이 발행되는지 확인하여 onBehalfOf 주소가 호출자가 아닌 경우 호출 사용자로부터 빌릴 수 있는 권한이 토큰 컨트랙트에서 차감됩니다. 사용자의 첫 번째 차입인 경우 활성 차입자로 구성되며, DebtToken이 사용자에게 발행된 후 프로토콜은 새로운 이자율과 차입 이후 준비금 풀의 변경 사항을 반영하여 updateInterestRates를 통해 차입 이자율을 업데이트합니다. 사용자가 차입을 위한 기초 자산의 릴리스를 요청하면 프로토콜은 해당 자산을 사용자에게 직접 전송합니다.

컴파운드와 비교했을 때 AAVE V2의 차입 및 대출 프로세스는 다음과 같은 주요 특징이 있습니다.

안정형과 변동형의 두 가지 이자율 모델을 지원합니다.

차입과 대출은 별도의 검증 로직 컨트랙트를 통해 검증됩니다.

부채토큰을 사용하여 사용자 차입금을 나타냅니다.

신용 위임을 지원하여 사용자가 다른 주소를 대신하여 대출할 수 있습니다.

상환

사용자는 상환 기능을 통해 상환을 수행하며, 먼저 사용자의 현재 부채(stableDebt 포함)를 가져옵니다. 안정적인 부채 및 변동 부채 포함). 사용자가 선택한 이자율 모드(고정 또는 변동)에 따라 ValidationLogic.validateRepay는 사용자의 부채 잔액이 상환에 충분한지 여부를 포함하여 사용자의 상환 작업의 적법성을 검증합니다. 상환할 부채의 구체적인 유형은 사용자가 선택한 이자율 모드(고정 이자율 또는 변동 이자율)에 따라 결정됩니다. 사용자가 상환해야 할 금액이 현재 부채 잔액보다 적을 경우 시스템은 사용자가 제공한 상환 금액을 사용하여 일부 상환하고, 그렇지 않으면 모든 부채를 상환합니다. 준비금 상태 업데이트 상태는 계약의 이자율, 차입금 규모, 차입 지수를 계산하고 업데이트하는 데 사용됩니다. 그런 다음 해당 스테이블 부채 토큰이 소각되고 차입 이자율은 updateInterestRates를 통해 업데이트됩니다. 이 시점에서 상환 후 사용자의 모든 부채(안정 부채와 변동 부채 모두)가 0이 되면 사용자의 차입 상태는 거짓으로 표시되어 사용자가 더 이상 차입하지 않음을 나타냅니다. 마지막으로 사용자는 상환 금액을 자신의 계정에서 계약서에 있는 aToken 계약 주소로 이체합니다.

컴파운드와 비교하여 AAVE V2의 상환 프로세스는 다음과 같은 주요 특징을 가지고 있습니다.

안정 및 변동 금리 모드 모두에서 상환을 지원합니다.

부채토큰을 사용하여 부채를 표시 및 관리하고 상환 시 해당 부채토큰을 소각합니다.

부분 상환과 전액 상환을 지원하며, 안정 부채와 유동 부채를 별도로 처리합니다.

신용 위임을 통해 다른 주소로 상환할 수 있도록 지원합니다.

청산

사용자는 프록시 모델을 통해 렌딩풀의 liquidationCall 함수를 통해 청산합니다. 이 함수는 LendingPoolCollateralManager의 liquidationCall 함수를 호출하여 함수의 성공적인 실행을 보장합니다. 먼저 GenericLogic.calculateUserAccountData는 담보 자산 및 부채 자산 준비금 데이터와 사용자의 설정 정보를 가져오고, 사용자의 건전성 지수를 계산하고, getUserCurrentDebt를 통해 사용자의 현재 안정 및 변동 부채를 가져옵니다.

ValidationLogic.validateLiquidationCall 함수는 사용자의 건강 계수, 부채 상태, 담보 구성 확인을 포함하여 청산 호출의 적법성을 검증합니다. 건강 계수가 임계값보다 작고, 담보로 사용되었으며, 부채가 모두 0이 아닌 경우 유효성 검사는 통과합니다. 다음으로 사용자의 최대 청산 가능한 부채를 계산하고 실제로 청산해야 하는 부채의 수를 결정합니다. 청산 부채가 사용자의 가용 담보를 초과하는 경우 청산 금액이 조정됩니다.

청산인이 청산 대상자가 담보로 제공한 기초 자산을 받기로 선택한 경우, 담보 준비금에 충분한 유동성이 있는지 확인해야 합니다. 채무 준비금 상태를 업데이트하고 청산인의 에이토큰 수령 여부에 따라 적절한 수의 변동형 및 안정형 채무 토큰을 소각합니다. 청산 후 시장 상황을 반영하여 부채의 이자율을 업데이트합니다. 청산자는 청산자가 aT토큰을 수락할 경우 적절한 수의 aT토큰을 청산자에게 보상하고, 수락하지 않을 경우 담보물의 상태와 담보물의 이자율을 업데이트하고 사용자 계정에서 해당 수의 aT토큰을 소각한 후 기초 자산을 청산자에게 이전합니다. 마지막으로 청산에 필요한 채무 자산이 청산자로부터 해당 예비 에이토큰으로 이체되어 청산 절차가 완료됩니다.

AAVE V2 청산 프로세스는 컴파운드와 비교해 다음과 같은 주요 특징이 있습니다.

담보와 채무 자산의 다양한 조합을 청산할 수 있도록 지원합니다.

청산자가 에이토큰 또는 기초 자산 중 하나를 선택할 수 있습니다.

청산 프로세스는 검증 로직, 계산 로직 등을 별도의 기능으로 분리하여 보다 모듈화되어 있습니다.

안정형 및 변동금리 부채 유형 모두의 청산을 지원합니다.

플래시 대출

사용자는 렌딩풀의 flashLoan 기능을 통해 플래시 대출을 할 수 있습니다. 플래시 대출은 대출 계약으로 현재 플래시 대출을 즉시 상환하거나 추후 상환할 부채로 설정할 수 있으며, 전달된 모드 파라미터에 따라 0은 즉시 상환, 1은 안정 부채, 2는 변동 부채로 설정할 수 있습니다.

이 함수는 먼저 ValidationLogic.validateFlashloan을 통해 입력 매개변수가 일치하는지 확인하고, 플래시 크레딧에 필요한 프리미엄 비용을 계산한 후 필요한 aToken을 수신자 주소로 직접 전달합니다. 수신자의 실행 오퍼레이션은 미리 정의된 플래시 대출을 구현하기 위해 호출됩니다. 플래시 대출 작업의 AAVE 구현에는 교환, 교환 청산, 교환 상환 작업이 이미 포함되어 있습니다. 실행 오퍼레이션이 이러한 작업을 완료하면 상환할 라이트닝 크레딧의 양과 그에 상응하는 수수료가 기록됩니다. 사용자가 비부채 모드에서 자금을 반환하기로 선택한 경우: 시스템에서 준비금 상태를 업데이트하고 준비금 유동성을 누적하며 유동성 지수를 업데이트합니다. 마지막으로 자금과 수수료가 요청자로부터 준비금 풀로 이체됩니다. 사용자가 부채 모드로 처리하도록 선택하면 _executeBorrow가 호출되어 해당 부채 포지션이 열립니다.

부채 모드 전환

AAVE V2에서는 swapBorrowRateMode 함수를 통해 사용자가 안정형과 변동형 모드를 변동금리 모드로 전환할 수 있습니다. 먼저, getUserCurrentDebt 함수는 대상 자산에 대한 사용자의 현재 안정금리 부채와 변동금리 부채를 가져와 사용자의 부채 상태를 파악하는 데 사용됩니다. 그런 다음 ValidationLogic.validateSwapRateMode 함수를 호출하여 전환 작업이 합법적인지 확인합니다. 이를 통해 사용자에게 모드 전환을 지원하기에 충분한 안정형 또는 변동형 부채가 있는지 확인하고, 전환 대상 모드가 자산의 구성과 사용자의 부채 프로필과 일치하는지 확인합니다. reserve.updateState를 호출하여 자산 준비금 상태를 업데이트하여 준비금 데이터가 최신 상태인지 확인합니다. 그런 다음 두 부채 토큰을 서로 변환하여 스테이블 부채 토큰을 소각하여 유동 부채 토큰을 발행하거나 유동 부채 토큰을 소각하여 스테이블 부채 토큰을 발행합니다. 전환이 완료되면 reserve.updateInterestRates는 목표 자산 금리를 업데이트하여 현재 시장 상태와 사용자 부채의 변화를 반영하도록 합니다.

보안 취약성 체크리스트

빈 시장으로 인한 라운딩 취약성

AAVE와 컴파운드 모두 공매도 시장에서의 정밀도 손실로 인한 반올림 취약성 문제가 있습니다. 빈 시장(즉, 시장에서 대출하는 사용자가 없는 경우)의 경우, 누적 유동성 지수 함수의 유동성 지수 값은 컨트랙트에 해당하는 기초 자산 토큰의 수에 따라 달라지기 때문에 공격자는 대량의 기초 자산 토큰을 계약에 플래시 대출함으로써 에이토큰의 가격을 조작할 수 있습니다.

컴파운드 포크 프로젝트인 헌드레드 파이낸스의 첫 번째 해킹과 유사하게, 호프렌드 이벤트에서 공격자는 먼저 유동성 지수를 조작하여 hETHWBTC와 WBTC의 가치를 1:1로 조절했습니다. 공격자는 먼저 유동성지수를 조작하여 WBTC에 대한 hETHWBTC의 가치를 1:1로 제어한 다음 기초 자산을 교환하고 돈을 빌려 유동성지수를 높였습니다. 그런 다음 플래시 대출 주기를 통해 _handleFlashLoanRepayment 함수를 반복해서 호출합니다.

cumulateToLiquidityIndex 함수에서 rayDiv의 정밀도 손실은 다시 한번 준비금을 증폭시킬 것입니다. 유동성지수 값을 증폭시켜 궁극적으로 교환할 수 있는 WBTC의 양을 증폭시킵니다. (공격 거래: https://etherscan.io/tx/0x1a7ee0a7efc70ed7429edef069a1dd001fbff378748d91f17ab1876dc6d10392)

감사 포인트: 감사 시 환율 계산이 조작하기 쉬운지, 반올림이 적절한지 주의해야 하며, 새로운 시장이 생성되는 즉시 프로젝트 팀이 aToken을 채굴하여 시장이 비어 조작되는 것을 방지하도록 권장할 수 있습니다.

ERC677 / ERC777 토큰으로 인한 재진입 취약점

컴파운드 포크 프로젝트인 Hundred Finance의 2차 해킹과 유사합니다. 두 번째로 해킹당한 아가베 공격의 경우, 공격자는 아무런 책임 없이 스스로 청산하기 위해 liquidateCall 함수를 호출했습니다. 청산된 토큰은 노시스 체인에서 사용되는 ERC-677 표준 토큰으로 송금 시 수신 주소의 기능을 외부에서 호출하게 되므로 청산 계약은 공격 계약을 호출했으며, 공격 계약은 플래시 대출을 통해 얻은 2,728 WETH를 입금하고 2,728 aWETH를 발행하여 이를 담보로 아가베 프로젝트의 가용 자산을 모두 빌려주게 됩니다. 프로젝트의 모든 가용 자산을 대출했습니다. 외부 호출이 끝나면 liquidationCall 함수는 공격자가 이전에 예치한 2728 aWETH를 직접 청산하여 청산자에게 전송합니다.

(참조 출처: https://x. com/danielvf/status/1503756428212936710; 공격 트랜잭션: https://gnosis.blockscout.com/tx/ 0xa262141abcf7c127b88b4042aee8bf601f4f3372c9471dbd75cb54e76524f18e)

감사 포인트: 감사에서는 직불 및 신용 기능과 관련된 코드가 CEI를 준수하는지 여부를 살펴봐야 합니다( Checks-Effects-Interactions) 사양 또는 재입력 방지 잠금 장치가 있는지 살펴보고 콜백 기능이 있는 토큰의 영향을 고려해야 합니다.

부적절한 예측 메커니즘으로 인한 가격 조작 위험

Blizz Finance 프로젝트 해킹의 경우, LUNA의 가격이 계속 급락하자 가격 조작에 사용된 프로토콜이 충분히 견고하지 않았습니다. 가격이 계속 급락하면서 프로토콜에서 사용하는 체인링크 가격 정보가 부정확해졌고, 이로 인해 고가의 LUNA를 담보로 자금을 차입할 수 있는 가능성이 생겼습니다. 동시에 이 프로젝트에는 기존의 안전장치가 없었고, 사전에 경고를 받은 것처럼 보였지만 손실을 막기 위한 예방 조치가 제때 취해지지 않았습니다. 가격이 그 수준 이하로 떨어졌을 때, 누구나 시장 가격(0.10달러보다 훨씬 낮은 가격)으로 루나를 대량으로 구매하여 플랫폼에서 자금을 빌리기 위한 담보(0.10달러 가치)로 사용할 수 있었습니다.

(참고 출처: https://x.com/BlizzFinance/status/1524911400992243761)

감사 포인트. 프로젝트를 감사할 때 담보 가치를 계산하는 데 사용되는 예후 예측기 공급 메커니즘이 외부 조작에 취약한지 여부에 주의를 기울여야 하며, 프로젝트 소유자는 단일 가격 출처로 인한 위험을 피하기 위해 여러 가격 출처를 사용하여 종합적인 평가를 수행하도록 권고받을 수 있습니다. 또한 프로젝트에 이러한 우발 상황을 방지할 수 있는 합리적인 중단 메커니즘이 있는지 여부도 중요합니다.

주변 계약에 대한 외부 호출로 인한 의도하지 않은 문제

AAVE 프로토콜과 Para Swap 프로토콜 간의 상호작용에서 Aave. 담보 상환 어댑터 V3 컨트랙트의 _buyOnParaSwap 함수에는 여러 가지 보안 취약점이 있습니다. 이 함수는 safeApprove 메서드를 호출하여 토큰 전송 프록시에서 assetToSwapFrom 한도를 최대 금액으로 설정하지만, 상환이 전혀 또는 부분적으로 이루어지지 않는 경우를 고려하지 않아 한도를 모두 사용하지 않으면 잔액이 변경되지 않습니다. 또한 이 함수는 상환을 수행하기 위해 외부 컨트랙트 호출(augustus.call(buyCalldata))에 의존하며, 파라스왑데이터 패스를 적절히 검증하고 제한하지 않아 공격자가 악의적으로 구성된 파라스왑데이터를 통해 디코딩된 buyCalldata와 augustus 계약 주소를 조작할 수 있게 합니다. 를 사용하여 의도된 상환 로직을 우회하거나 아예 상환을 피할 수 있습니다. 이 함수는 교환 후 자산ToSwapFrom의 토큰 한도를 줄이거나 확인하지 않기 때문에 교환이 실패하거나 우회하더라도 공격자는 변경되지 않은 상한을 사용하여 계약에서 토큰을 인출하여 무단 자금 이체를 할 수 있습니다. 입력 데이터와 거래소 결과에 대한 검증이 부족하고 토큰 한도를 효과적으로 관리하지 못하면 공격자가 컨트랙트를 악용할 수 있는 상황이 발생할 수 있습니다.

(트랜잭션 공격: https:// etherscan.io/tx/0xc27c3ec61c61309c9af35af062a834e0d6914f9352113617400577c0f2b0e9de)

감사 포인트: 감사 시 다음과 상호작용하는 코드에 특히 주의하십시오. 외부 타사 프로토콜의 상호 작용 코드에 특히 주의하세요. 외부 계약의 입출력이 엄격하게 제한되어 있는지, 상호작용 로직이 프로토콜의 핵심 모델이나 자금 안전에 잠재적인 영향을 미치는지, 악성 데이터가 보안 문제를 일으키지 않도록 입력 데이터를 정리하고 검증했는지 평가하는 데 중점을 두세요. 외부 상호작용의 코드 로직과 데이터 검증 메커니즘을 엄격하게 검토하면 이러한 취약점의 위험을 효과적으로 줄일 수 있습니다.

토큰 및 금리 전략 호환성 문제

폴리곤 체인에 AAVE를 배포하는 동안, 다음과 같은 이유로 이자 전략 설정과 호환되지 않는 문제로 인해 WETH에 대해 호환되지 않는 이자율 전략을 잘못 설정하는 기능적 예외가 발생했습니다.

오류 설정된 InterestRateStrategy 컨트랙트의 인터페이스는 다음과 같습니다:

그리고 AAVE V2의 코드가 AAVE V2의 LendingPool 구현 코드는 다음과 같습니다:

(참조 출처: https://x.com/mookim_eth/status/1659589328727859205)

인터페이스 비호환성으로 인해 LendingPool에서 새로운 InterestRateStrategy를 제대로 호출할 수 없었고, 이는 곧바로 AAVE V2의 WETH 풀 기능 중단으로 이어졌으며 사용자는 이더를 입출금할 수 없었습니다.

감사 포인트 감사 시 코드(또는 포크)의 주요 구성 요소의 인터페이스가 완벽하게 호환되는지 확인하세요. 또한 위의 문제는 멀티체인 기능으로 인해 발생한 문제는 아니지만, 감사 시 의도하지 않은 결과를 초래할 수 있는 다양한 체인 기능에 대해 알고 있어야 합니다.

더스트 토큰 문제

AAVE로의 입출금은 setUsingAsCollateral 함수를 통해 설정됩니다. 담보화 전략을 유연하게 관리하기 위해 AsCollateral을 사용합니다. 외부 프로토콜이나 컨트랙트가 AAVE 대출 기능을 통해 처음으로 자금을 빌릴 때, 대출 기능은 usingAsCollateral을 true로 설정하고, 외부 프로토콜이나 컨트랙트가 AAVE에서 자금을 완전히 인출할 때, AAVE 내 프로토콜 핸들러의 usingAsCollateral 상태는 false로 설정됩니다. 그러나 실제로 AAVE가 인출을 위해 소각할 aT토큰 수를 계산할 때, 산술 정밀도 오류로 인해 이 시점에서 프로토콜 핸들러에 남아 있는 aT토큰이 거의 없을 수 있습니다. 그 결과, 프로토콜 핸들러가 다음에 AAVE에 예치할 때 usingAsCollateral은 변경되지 않고 여전히 true로 설정되며, 프로토콜 핸들러 컨트랙트에 setUserUseReserveAsCollateral 함수를 호출할 인터페이스가 없기 때문에 프로토콜 핸들러가 더 이상 차입 작업을 수행할 수 없게 될 수 있습니다.

감사 포인트: 감사 시 토큰 호환성, 호출 구현 로직 호환성 등 상호작용하는 외부 프로토콜과의 호환성 문제가 있는지 확인하기 위해 호출하는 프로토콜을 완전히 숙지하고 그 특성을 충분히 이해해야 합니다.

결론

이 책자는 AAVE V2 프로토콜의 핵심 설계, 주요 기능 및 감사 측면을 심층적으로 다루고 있으며, 개발자와 보안 연구자가 AAVE V2 프로토콜의 주요 특징을 파악하는 데 도움이 되기를 바랍니다. 이 매뉴얼이 개발자와 보안 연구원이 잠재적인 위험을 식별하고 프로토콜의 안전한 운영을 보장하는 데 도움이 되기를 바랍니다. 지면 제약으로 인해 일부 코드와 이미지는 이 글에서 생략되었으므로 이 글 끝에 있는 원본 글을 클릭하면 GitHub로 이동하여 정식 버전(https://github.com/slowmist/AAVE-V2-Security-Audit-Checklist)을 읽어보실 수 있습니다.