편집자 주: 이 기사의 출처는슬로우 미스트 기술(ID: SlowMist)슬로우 미스트 기술(ID: SlowMist)

머리말

보조 제목

머리말

Lianwen에 따르면 4월 18일 Tokenlon은 공격자가 Uniswap 유동성 계약의 ERC777 재진입 취약점을 사용하여 ETH-imBTC 풀 주기를 차익 거래한 사실을 발견했기 때문에 imBTC 전송 중단을 발표했습니다. 이번 공격 방식은 Uniswap v1에 존재하는 알려진 취약점으로, 이 취약점은 2019년 4월 Consensys에 의해 처음 발견되었으며 당시 Consensys는 위험 요소만 발견했을 뿐 이 방식을 공격에 사용할 수 있는 토큰은 찾지 못했습니다. 이후 imBTC가 Uniswap에 런칭된 후 imBTC는 ERC777을 기반으로 구현되기 때문에 ERC777의 특성과 Uniswap 코드의 문제점을 결합하여 공격자가 재진입 취약점을 통해 차익거래를 할 수 있습니다. 다음으로 이번 차익거래의 공격 방식과 구체적인 내용은 추후 분석하도록 하겠습니다.

보조 제목

지식 준비

ERC777 프로토콜은 이더리움의 토큰 표준 프로토콜이며 이 프로토콜은 이더리움의 ERC20 프로토콜의 개선된 버전입니다.주요 개선 사항은 다음과 같습니다.

1. 토큰을 보내기 위해 에테르를 보내는 것과 같은 개념을 사용합니다. 방법은 다음과 같습니다: send(dest, value, data)

2. 컨트랙트와 일반 주소 모두 tokensToSend 후크 기능을 등록하여 어떤 토큰의 전송을 제어하고 거부할 수 있습니다(전송 거부는 후크 기능 tokensToSend에서 되돌리기로 실현됨)."4. tokensReceived는 두 번의 호출(approve/transferFrom)을 통해 완료해야 하는 ERC20과 달리 후크 기능을 통해 토큰을 전송하고 한 트랜잭션에서 토큰을 수락하도록 컨트랙트에 알릴 수 있습니다."그리고"5. 홀더는 할 수 있습니다"인정 받은

그리고

취소

운영자(운영자: 보유자를 대신하여 토큰을 보낼 수 있음) 이러한 운영자는 일반적으로 (분산형) 교환, 수표 프로세서 또는 자동 지불 시스템입니다.

여기서 우리는 두 번째 포인트, 즉 ERC777 표준의 tokenToSend 기능에 특별한 주의를 기울여야 합니다.ERC777 프로토콜의 정의에 따르면 이 표준을 따르는 토큰 토큰은 토큰 전송이 발생할 때마다 토큰을 호출하려고 시도합니다. 발생 발신자 tokensToSend 기능 및 토큰 소유자는 ERC1820 등록 계약에 자신의 계약을 등록하고 이 후크 기능에서 일부 작업을 정의하여 토큰 전송 거부 또는 기타 작업과 같은 토큰 전송 프로세스에서 특정 프로세스를 처리할 수 있습니다.

상세한 분석

이러한 핵심 사항을 이해하면 이번 공격의 구체적인 공격 방법을 이해하는 데 도움이 됩니다. 이제부터 조금 속도를 내서 이번에 유니스왑에 무슨 일이 일어났는지 보실까요?

보조 제목

상세한 분석

Etherscan 0x32c83905db61047834f29385ff8ce8cb6f3d24f97e24e6101d8301619efee96e를 통해 공격자의 트랜잭션 중 하나를 쿼리합니다.

공격자는 imBTC를 0.00823084라는 동일한 금액으로 Uniswap 계약으로 두 번 전송한 다음 Uniswap에서 두 개의 ETH를 받았음을 알 수 있습니다. 이는 두 번의 매우 정상적인 거래처럼 보였지만 실제로는 저류 및 기타 미스터리였습니다. 전체 트랜잭션의 세부 정보를 더 잘 이해하려면 bloxy.info를 통해 트랜잭션의 특정 세부 정보를 확인해야 합니다.

거래 내역을 조회하여 공격자가 ethToTokenSwapInput 기능을 통해 imBTC 일부를 Uniswap으로 먼저 교환한 후, tokenToEthSwapInput 기능을 통해 imBTC를 1차로 ETH로 교환한 후 Uniswap이 먼저 ETH를 공격자에게 전송하고, 그런 다음 imBTC의 transferFrom 함수를 호출합니다. imBTC는 ERC777 표준을 구현하기 때문에 imBTC의 transferFrom 함수를 호출할 때 imBTC는 공격자의 tokensToSend 함수를 호출합니다. 그런 다음 공격자의 tokensToSend 기능에서 공격자는 imBTC를 ETH로 두 번째로 교환한 다음 프로세스가 종료됩니다.

트랜잭션 세부 정보에서 여기에는 문제가 없는 것으로 보이며 계속해서 UniSwap 코드를 따릅니다.

위의 코드는 Uniswap의 ethToTokenSwapInput 함수의 코드인데, 코드 분석에 따르면 Uniswap의 ethToTokenSwapInput 함수는 ethToTokenInput 함수를 호출한 후 getInputPrice를 통해 토큰으로 교환할 수 있는 eth의 양을 먼저 구한 후 사용자에게 eth를 보낸다. send 기능을 통해 마지막으로 transferFrom을 통해 토큰을 계약으로 전송합니다. getInputPrice 함수로 이동하겠습니다.

getInputPrice 함수를 분석하여 얻은 ETH의 양을 계산하는 공식이 다음과 같음을 알 수 있습니다.

이 공식에 따라 ETH에 대한 정상적인 imBTC 교환 과정에서 분모인 imBTC 준비금은 교환 후 증가해야 하며 해당 ETH 준비금은 감소합니다.

그런데 공격자의 조작 방식을 살펴보면 공격자가 처음으로 imBTC를 ETH로 보낼 때 Uniswap이 먼저 공격자에게 ETH를 보내게 되는데 이때 Uniswap의 ETH 예비금이 줄어들고 이후 Uniswap이 transferFrom 함수를 호출하게 됩니다. 이때 공격자의 imBTC는 차감되지 않음) 공격자가 transferFrom 함수에서 두 번째로 ethToTokenSwapInput을 호출하면 getInputPrice를 통해 교환된 ETH 금액을 구하는 공식은 다음과 같습니다.

• 두 번째 교환 계산에서 ETH의 예치금만 감소했지만 imBTC의 예치금은 증가하지 않았다는 점에 유의하십시오. ETH 두 번째로 계산 공식의 분자는 변경되었지만 공식의 분모는 변경되지 않습니다. 일반 거래소에 비해 공격자가 재진입 방식을 통해 수행하는 두 번째 거래소는 작은 수익을 얻게 되어 결과적으로 수익이 발생합니다. 이 과정을 반복하면 동일한 양의 imBTC를 통해 더 많은 ETH를 얻을 수 있어 Uniswap 사업자의 손실이 발생합니다.

• 보조 제목

방어 방법

• 다음과 같은 주요 비즈니스 운영 방법에 잠금 메커니즘을 추가합니다. OpenZeppelin의 ReentrancyGuard

• 컨트랙트 작성 시 이 컨트랙트의 변수를 먼저 변경한 후 외부 호출을 하는 방식으로 작성

• 프로젝트가 시작되기 전에 우수한 제3자 보안 팀을 초대하여 포괄적인 보안 감사를 수행하여 잠재적인 보안 문제를 최대한 발견합니다.

• 여러 계약이 연결된 경우 다자간 계약의 코드 보안 및 비즈니스 보안도 확인하고 다양한 비즈니스 시나리오의 조합에 따른 보안 문제를 충분히 고려해야 합니다.

• 여러 계약이 연결된 경우 다자간 계약의 코드 보안 및 비즈니스 보안도 확인하고 다양한 비즈니스 시나리오의 조합에 따른 보안 문제를 충분히 고려해야 합니다.

• 보안은 역동적이며 각 프로젝트 당사자는 적시에 자체 프로젝트와 관련될 수 있는 위협 인텔리전스를 캡처하고 잠재적인 보안 위험을 신속하게 조사해야 합니다.

계약은 "블랙 스완" 이벤트가 발생할 때 시간 손실을 감지하고 중지할 수 있도록 가능한 한 일시 중지 스위치를 설정해야 합니다.

보안은 역동적이며 각 프로젝트 당사자는 적시에 자체 프로젝트와 관련될 수 있는 위협 인텔리전스를 캡처하고 잠재적인 보안 위험을 신속하게 조사해야 합니다.

보조 제목

마지막 생각들