최근 Re-enterancy양상

 

• 제외 취약점

 

1. Malicious library : Code단에서진단불가, 악의적인 라이브러리로 부터 받은 값을 검증하거나 예외처리 하는 쪽으로 돌려서 분류
2. Transaction Ordering dependency : 채굴자가 공격하는 블록 도메인에서의 취약점이라고 볼 수 있고 코드단에서 고려하긴 힘들다.
3. Secrecy Failure :  Nature한 취약점으로 private한 변수를 설정해도 그러한 변수가 있음을 알 수. 있으므로 값을 유추하려는 공격이 시도되는 것
4. Lack of Transactional privacy
5. Under-priced opcode : 값이 저렴한 opcode의 연산을 대규모로 사용함으로서. 네트워크 단의 DOS공격을 일으키는 공격이었지만 이스탄불 하드포크이후 가스 가격이 상승하면서 어느정도 해결되었다.
6. Visibility of exposed function : Simple 취약점 및 컴파일러단에서 충분히 Warning해주는 취약점
7. Call to the unknown : Reentrancy 발생하는원인, other function invoking하는것으로재진입 공격에 포함시킨다.

 

 

• 최근 재진입 공격 양상

1. Fake token

2. 토큰을 보낸 후 이를 따로 기록할 때 미리 구해둔 balance를 활용해서 업데이트 하면 lost value가 생길 수 있다.

이는 미리 구해둔 balance와 토큰을 보내고 업데이트 하는 과정에서 하나 이상의 컨트랙트가 진입했기 때문이다.

이는 원래 재진입 공격, 즉 한 트랜잭션 내에서 재귀적으로 재진입하던 양상과는 다소 다르다.

이를 막기 위해서는 mutex를 도입한 re-enterancy Guard를 사용하는 것이 추천된다.

 

 

3. 이것 말고 원래의 재진입 공격처럼 재귀적으로 공격하는 사례도 있다.

하지만 토큰 거래에서는 Call과 같은 함수를 쓰는 것이 아니라 Transferfrom과 같은 토큰 내 표준 함수를 활용하는데

 

여기서 fallback 함수를 호출해서 이루어진 경우도 있다.( =Siren attack)
 

(다른 기능 외에도 ERC777을 사용하면 ERC777 토큰이 계정에서 전송되거나 수신될 때 토큰 계약이 발신자와 수신자에게 알릴 수 있습니다. 이 알림은 수신자에 대한 콜백 형식입니다. 따라서 토큰을 받는 사람이 스마트 계약인 경우 스마트 계약은 이러한 이벤트에 대응하도록 선택할 수 있습니다. 이러한 이벤트에 대한 한 가지 가능한 반응은 ERC777 계약을 다시 입력하고 다른 send를 호출하는 것입니다(ERC777의 특정 구현이 허용하는 경우). Lendf.Me가 imBTC를 담보로 사용하도록 설정했을 때 활성화된 ERC777 콜백 알림은 Lendf.Me를 재진입 공격에 취약하게 만들었습니다.

이 취약점으로 인해 공격자는 Lendf.Me 시스템 내에서 imBTC 담보에 대한 잘못된 기록을 만들 수 있습니다. 공격자는 먼저 상당량의 imBTC를 담보로 진정으로 예치했습니다. 그 후, 그들은 imBTC의 또 다른 예금을 촉발했지만 콜백 내에서 그리고 imBTC의 실제 전송 전에 원래 imBTC 예금을 철회했습니다. Lendf.Me의 코드는 이러한 전송이나 콜백으로의 실행이 가능한 것을 고려하지 않았으며, 로컬 변수에 저장된 데이터를 기반으로 전송이 완료된 후 중요한 상태 업데이트를 수행했습니다. 따라서 후크 출금 내에서 공격자의 담보를 적절히 감소시킨 후 실행이 수행되는 예금으로 복귀할 때 코드가 공격자의 담보 값을 덮어썼습니다.)

 

=> Transfer이 포함된 함수에는 re-enterrancy guard가 있는 것