이 블로그에서는 Poly Network 해킹의 전체 과정을 검토하고 얻은 교훈에 대해 논의하고자 합니다.
우리는 2021년 8월 10일에 Poly Network가 해킹당하고 있다는 사실을 알게 되었습니다(이 블로그에서는 +8 시간대를 사용합니다). 그러나 해킹이 어떻게 진행되고 있는지, 그리고 해킹의 근본 원인이 무엇인지에 대한 단서가 없었습니다. 보안 연구팀으로서 우리는 조사를 시작했습니다.
Step 1: 공격 트랜잭션 찾기
우리는 트랜잭션 가상화 시스템(https://tx.blocksecteam.com)에서 공격 트랜잭션 0xd8c1f7424593ddba11a0e072b61082bf3d931583cb75f7843fc2a8685d20033a를 재현했습니다.
트레이스는 상당히 단순한데, 이는 가격을 조작하는 다른 공격들과는 다릅니다. 그러한 공격들은 보통 매우 복잡한 함수 호출을 가지고 있습니다(Popsicle 해킹 참조).
Step 2: 컨트랙트 코드 분석
공격 트레이스를 얻은 후, 컨트랙트의 소스 코드를 검토해야 했습니다. 놀랍게도, Poly Network는 Etherscan에 검증된 소스 코드를 보유하고 있지 않았습니다. 그러나 우리는 Github에서 공개된 소스 코드를 찾을 수 있었습니다.
소스 코드를 검토한 후에도 명백한 코드 취약점을 발견하지 못했습니다. 또한 공격 트레이스와 정상적인 트랜잭션 트레이스를 비교했을 때 유사하다는 것을 발견했습니다.
Step 3: 중요 상태 복원
그런 다음 공격 중의 중요한 상태들을 복원했습니다. 공격이 VerifyHeaderAndExecuteTxEvent의 호출로부터 시작되었기 때문에, 여러 중요한 변수 값들을 복원했으며, 이는 첫 번째 분석에서 공유한 바 있습니다 [1].
이 과정에서 우리는 키퍼(keeper)가 하나뿐이라는 것을 발견했습니다(위 그림 참조). 해당 값이 공격 트레이스에서 얻어졌고 공격 트랜잭션이 모든 서명 검증을 통과했기 때문에, 잠재적인 원인은 개인 키 유출이거나 서버의 서명 프로세스의 버그일 수 있다고 생각했습니다 [1].
그러나 우리는 여기서 실수를 했습니다. 공격을 분석하는 것은 양파 껍질을 벗기는 것과 같습니다. 진짜 "근본적인 근본적인 근본 원인"을 찾을 때까지 한 번에 한 겹씩 벗겨냅니다. 그 당시, 우리는 키퍼가 변경되었는지 여부를 확인하기 위해 양파를 더 벗기지 않았습니다!
Step 4: 새로운 단서
몇 시간 후, Kelvin과 slow mist가 트위터에서 키퍼가 변경되었음을 보여주는 새로운 단서를 제공했습니다. 변경 과정은 해시 충돌을 악용하여 강력한 함수를 호출합니다 — "스마트"한 해킹입니다.
이제 우리는 첫 번째 분석이 완전하지 않았음을 깨달았습니다. 최신 정보를 바탕으로, 키퍼를 변경한 트랜잭션을 재현했습니다. 여전히 트레이스는 매우 단순했습니다.
그러나 이 트랜잭션 중에는 (하나가 아닌) 네 명의 키퍼가 있었다는 점을 기억하십시오. 이 모든 키는 다른 정상적인 트랜잭션들과 동일했습니다 — 즉, 키들은 정상적이었습니다. 여기서 질문이 생깁니다: 키퍼를 변경하는 트랜잭션이 어떻게 체인에 올라가고 첫 번째로 실행될 수 있었을까요?
Step 5: 소스 트랜잭션 찾기
Poly Network는 크로스체인 브릿지이기 때문에 소스 트랜잭션을 찾으려 했습니다. 어딘가에 소스 트랜잭션이 존재해야 했습니다. 우리는 중요한 변수를 디코딩하여 이를 수행했습니다(다음 그림에서와 같이). 이는 소스 체인과 폴리 체인의 트랜잭션 해시를 보여줍니다.
다른 곳에서는 언급되지 않은 트릭이 있습니다. 변수의 tx 해시 값은 폴리 체인의 공식 값과 다른 표현 방식을 가집니다. 예를 들어, 그림에서 폴리 체인의 tx 해시는 0x80cc978479eb082e1e656993c63dee7a5d08a00dc2b2aab88bc0e465cfa0721a입니다. 그러나 폴리 체인 브라우저에서 해시 값은 1a72a0cf65e4c08bb8aab2c20da0085d7aee3dc69369651e2e08eb798497cc80입니다(차이점이 보이시나요?). 우리는 8월 11일 16:55에 EthereumSecurity 텔레그램 그룹에서 발견한 내용을 공유했습니다.
Step 6: 근본 원인 찾기
그러나 여전히 "키퍼를 변경하는 트랜잭션"이 왜 체인에 패킹될 수 있었는지에 대한 질문에 답할 수 없었습니다. 이 질문에 답하기 위해 Ontology 체인에서 시작하여 트랜잭션 흐름을 찾았습니다:
Ontology 트랜잭션 -> Ontology 릴레이어 -> Poly 체인 -> Ethereum 릴레이어 -> Ethereum
그런 다음 Ontology 체인과 릴레이어들의 소스 코드를 읽었습니다. 몇 시간 후, Ontology 릴레이어가 크로스체인 트랜잭션에 대한 충분한 검증을 갖추지 않았다는 것을 발견했습니다. 이로 인해 악성 트랜잭션이 폴리 체인에 패킹될 수 있었습니다. 그 후 시스템이 침해되었습니다.
내부 토론과 검토 후, 우리는 8월 12일 02:41에 트위터와 미디엄[3]에 발견 사항을 공개했습니다.
교훈
-
설계에 의한 보안. 보안은 DeFi 프로젝트의 전체 과정에 포함되어야 합니다. 사용자들은 프로젝트에 자신의 돈을 맡깁니다. 그에 대한 보답으로 프로젝트는 그 신뢰를 받을 자격이 있어야 합니다. 안타깝게도, Poly Network에서 보안에 대한 무관심을 목격했습니다. 예를 들어, 검증의 부재는 구식 보안 취약점으로, 제가 학부 수업에서 가르치는 내용입니다.
-
600M TVL이 넘는 DeFi 프로젝트에 검증된 소스 코드가 없습니다. 분산 인프라의 기반은 신뢰이며, 신뢰의 토대는 투명성입니다. 안타깝게도, 사용자들은 블랙박스 프로젝트에 기꺼이 돈을 넣으려 하는데, 이는 나를 놀라게 하고 걱정하게 만듭니다. 사용자의 보안 의식을 향상시키는 방법은 아마도 새로운 해결책이 필요할 것입니다.
참고 문헌
[1]https://blocksecteam.medium.com/the-initial-analysis-of-the-polynetwork-hack-270ac6072e2a
[2]https://twitter.com/kelvinfichter/status/1425290462076747777
[3]https://blocksecteam.medium.com/the-further-analysis-of-the-poly-network-attack-6c459199c057
크레딧: Yufeng Hu, Siwei Wu, Lei Wu, Yajin Zhou @ BlockSecTeam
