Defi와 해킹

• Oracle 취약점을 이용한 해킹 (INV)
• Flash Loan Attack (ETH)

Oracle 취약점을 이용한 해킹 [1][2][3]

Oracle이란

Oracle의 역할

• oracle이란, 블록체인의 on-chain 데이터와 블록체인 외부의 off-chain 데이터를 연결해주는 역할이다. off-chain 데이터를 사용하는 이유는 두 가지가 있다. 첫 번째는 보안 문제이다. 모든 데이터가 블록체인 위에서 공개되면 좋겠지만, 일부 데이터는 비공개적으로 관리될 수 밖에 없다. 예를 들어, 스마트 컨트랙트에서 랜덤 함수를 사용할 때, 랜덤 함수의 seed가 공개되어 있다면 그 랜덤 함수는 예측 가능한 랜덤 함수가 된다. 그러므로, seed와 같은 데이터는 블록체인 위에서 on-chain 데이터로 관리되기 어려운 off-chain 데이터 중 하나 이다.
• 두 번째는 블록체인 위에서 존재하지 않는 데이터이기 때문이다. 주로 Defi에서 볼 수 있는데, 예를 들어, BTC를 담보로 DOGE를 대출해주는 서비스(Lending Protocol)가 있다고 하자. 이 경우, BTC가 현재 얼만큼의 가치를 가지는지, 그리고 이 가치에 따라서 얼만큼의 DOGE를 대출해야하는지 결정해야할 때가 있다. 이 경우, BTC의 가격을 외부에서 가져와야 하고, 그 역할을 하는 것이 oracle이다. 여기서는 BTC의 가격이 off-chain 데이터가 된다.
• 대부분의 Defi들은 ChainLink의 oracle을 사용하는데, 때때로 추가적인 기능이 필요할 때는 자체적으로 개발한 oracle을 사용하는 경우도 있다. 예를 들어, 이번에 다루는 Inverse Finance 의 경우 Keep3r 이라는 자체 오라클을 사용하고 있었다.

해킹 과정 [4]

• 해커는 Keep3r이라는 oracle 설계의 취약점을 이용하여 다음과 같은 작업을 진행했다.

PeckShield 에서 공개한 Attack Flow

1. 토네이도 캐시*에서 901 ETH 를 출금함.
2. Disperse** 를 통해 241개의 이더리움 계좌에 각각 1.5 ETH 씩 총 361.5 ETH 를 송금함.
3. 241개의 계좌는 DDoS 공격처럼 5개의 Smart Contract를 수행할 준비를 함. 이 중 하나만이 공격용 Contract이고, 나머지는 혼란을 주기 위한 연막용 Contract 였음.
4. 공격에 앞서, 해커는 스시스왑에서 500 ETH를 1700 INV 로 스왑하여 일시적으로 유동성 풀의 비율을 변경시켜버림.
5. 일반적인 경우, 이렇게 풀의 비율은 급변한 경우 Arbitrage bot이 이를 바로잡는 역할을 하지만, 이번 경우는 241개의 계정이 수행한 스팸성 Smart Contract들때문에 Arbitrage bot 이 정상적으로 가격 조정하지 못함.
6. Inverse Finance의 자체 oracle인 Keep3r은 스시스왑의 oracle인 TWAP을 사용하고 있었고, TWAP은 짧은 시간 샘플을 기반으로 가격을 결정하는 취약점이 있었음.
7. 해커는 이를 이용하여 일시적으로 풀의 비율을 변경시킨 것이고, 스팸성 Smart Contract를 통해 가격이 정상화되는 것을 막은 것임.
8. 따라서, oracle은 일시적으로 INV의 가치를 높게 평가하는 착각을 하게 됨.
9. 해커는 Anchor 라는 Inverse Finance 에서 제공하는 Defi를 활용하여 높게 평가된 1700 INV 를 담보로 영구적으로 ETH로 대출 받았음.
10. 그 결과, 일시적으로 가치를 높인 INV를 담보로 처음에 스왑했던 500ETH 보다 더 많은 가치의 ETH의 시세차익을 볼 수 있었음.
11. 흥미로운 것은, 해커 또한 oracle이 예상보다 빨리 가격을 조정했으면 막대한 손실을 볼 수 있던 해킹 수법이었음.
12. 현재는 INV를 담보로 대출해주는 서비스는 막혀있음.

* 토네이도 캐시 (Tornado Cash): Transaction 을 마구 섞어서 누가 누구한테 보낸 것인지 찾을 수 없도록 만든 private transaction 을 위한 툴. 자세히
** Disperse: 여러 개의 이더리움 계좌에서 Transaction 을 발생시킬 수 있도록 하는 자동화 툴. 자세히

사건에 대한 언급들

ChainLinkGod says…

"짧은 시간동안 거래가 많지 않은 단일 Dex 트레이딩 페어에서 만들어진 TWAP 에 의존하는 것은 시장 조작의 위험성을 엄청나게 높일 수 있습니다."

INV는 Inverse Finance 와 스시스왑에서 밖에 거래가 되지 않았기 때문에 low volume, thinly traded 되고 있는 토큰이라고 볼 수 있었음.

"거래량이 많지 않은 토큰 (thinly traded) 담보로 대출해주는 것은 사용자들을 위험에 노출시키는 것입니다"

"TWAP 의 문제점은 가격 결정에 대해서 너무 짧은 time sample을 사용한 것입니다."

* 참고: TWAP vs ChainLink VWAP

Michael Bentley says…

1. "Thinly traded 한 토큰을 담보로 해주지 마라"
2. 해커들 또한 자칫하면 많은 돈을 잃을 수 있는 해킹 수법이었다.

Flash Loan Attack

Flash Loan Attack 이란?

• Flash Loan은 Defi 상품 중 하나로, 비담보 대출이다. 비담보 대출이라함은 암호화폐, 디지털 자산 등 담보 없이 대출을 해주는 것인데, 이것이 가능한 이유는 블록체인의 특성때문이다. 블록체인은 transaction (tx)는 그 특성상 대출과 상환이 하나의 tx 안에서 가능하기 때문에 비담보 대출과 같은 금융 상품이 나올 수 있다.
• 하지만, 이를 악용하면 다음과 같은 시나리오가 가능하다.
  1. Flash Loan을 통해서 거액의 돈을 대출받는다.
  2. 그 다음, 대출받은 돈으로 시장의 시세를 조작하여 이득을 취한다.
  3. 그리고 바로 대출금을 갚기 때문에 공격자는 아무런 리스크없이 막대한 이득을 챙길 수 있다.
• 어떻게 하나의 tx 안에 여러 개의 Transfer 가 발생할 수 있을까? Contract 를 그렇게 짜면 가능하다. Tx 는 하나의 Contract 를 호출했을 때 발생하는 것이고, 그 안에 Contract 가 어떻게 구성되어 있느냐에 따라서 여러 개의 Transfer 를 발생시킬 수 있다.
• 실제 이더리움의 Flash Loan Attack 에 대한 Contract 를 보면 다양한 Transaction 이 하나의 Contract 안에 담겨져 있는 것을 볼 수 있다.

실제 해킹에 사용된 Contract

• 이더리움의 Flash Loan Attack 은 First Attack 과 Second Attack 두 차례에 걸쳐서 진행되었다.

First Attack [5]

1. 이더리움을 비담보대출로 받음.
2. 다른 Dex에서 비담보대출을 받은 이더리움의 일부를 담보로 비트코인을 빌림.
3. 남은 이더리움의 일부를 N 배의 레버리지를 통해서 숏포지션을 잡음. 이를 통해 적은 양의 이더리움을 통해 레버리지를 크게 잡아 이더리움의 가치를 떨어뜨림과 동시에 비트코인의 가치를 올림.
4. 3번의 결과로 Dex에서 숏 스왑을 하여 이더리움을 덤핑, 비트코인을 펌핑시킴.
5. 2번의 비트코인을 이더리움으로 스왑하면, 처음에 예치했던 이더리움보다 더 많은 이더리움을 얻게 됨. (3,4 과정을 통해서 이더리움의 가치가 떨어졌으므로)
6. 1번에서 대출받은 것을 상환함.

Second Attack [6]

이더리움에 대한 Flash Loan Attack 은 First Attack 발생 3일 후 다시 이뤄졌다.

1. 이더리움을 비담보대출로 받고, 일부를 sUSD(스테이블 코인)으로 변환함.
2. 대출금의 일부를 Kyber Dex 에서 이더리움을 sUSD 로 스왑. 이 때, 정상적인 비율보다 2.5배 더 비싼 가격에 sUSD 를 삼.
3. 추가로 Syntetix 에서 sUSD을 구매함.
4. bZx에 구매한 스테이블 코인을 담보로 ETH를 대출함.
5. 이 때, bZx는 sUSD와 ETH의 비율은 Kyber에 의존하는 oracle에 의해서 결정되었는데, 2로 인해서 sUSD와 ETH 의 비율이 비정상적인 상태였음. 따라서, 그 비정상적인 비율에 따라 2.5배 만큼의 ETH를 대출해줌.
6. 공격자는 대출받은 ETH를 상환하고, 나머지 차액을 얻어 이익을 취함.
7. 담보를 맡긴 sUSD는 찾을 이유가 없기 때문에 그냥 두고 도망감.

결론

• Lending Protocol에서 대출 시 자체 토큰 또는 규모가 작은 토큰에 대해 안정적인 토큰 (BTC, ETH 등) 의 담보 비율을 너무 높게 잡은 것이 첫 번째 문제라고 한다.
• 두 번째 문제는, oracle이 일시적인 가격 변동에 대해서 착각하지 않도록 설계가 잘 되었어야 했는데 그렇지 못했다는 것이다. ChainLink 는 스시스왑의 이러한 설계 문제점을 지적했는데, 이 두 가지 문제점에서 발생하는 취약점을 이용한 해킹은 Defi 에서 비일비재하기 때문에 Lending Protocol 을 개발해야할 때 유의해야 한다.