폴리 네트워크 공격에 대한 추가 분석

공격은 두 가지 주요 단계로 구성됩니다. 첫 번째 단계는 keeper를 변경하는 것이고 두 번째 단계는 토큰을 인출하는 것(unlock 함수 실행)입니다. 두 번째 단계는 완전히 분석되었습니다. 첫 번째 단계에 대해, Kevin은 해시 충돌이 해커가 putCurEpochConPubKeyBytes 함수를 호출하기 위해 사용한 영리한 트릭 중 하나라고 지적했습니다. 그러나 공격자가 애초에 이 호출을 수행할 수 있는 유효한 트랜잭션을 가질 수 있는 이유는 여전히 알려지지 않았습니다.

이 블로그에서는 Ontology의 악성 트랜잭션(0xf771ba610625d5a37b67d30bf2f8829703540c86ad76542802567caaffff280c)을 사용하여 전체 과정을 설명합니다.

요약하면, 다음을 발견했습니다:

Ontology 릴레이어는 Ontology 체인의 트랜잭션에 대한 충분한 검증 메커니즘을 갖추고 있지 않습니다.
공격자는 Poly 체인에 유효한 블록이 존재하는 한, Ethereum 릴레이어를 거치지 않고 EthCrossChainData의 putCurEpochConPubKeyBytes 함수를 직접 호출할 수 있습니다.
Kevin이 지적한 해시 충돌

면책 조항: 이 블로그는 공개적으로 이용 가능한 소스 코드와 온체인 트랜잭션을 기반으로 한 우리 팀의 분석 결과를 포함합니다. Poly Network의 추가 정보 없이는 결과를 검증할 수 없습니다.

0x.1 트랜잭션 및 컨트랙트

공격 흐름

Ontology 트랜잭션 -> Ontology 릴레이어 -> Poly 체인 -> Ethereum 릴레이어 -> Ethereum

Ethereum

0x838bf9e95cb12dd76a54c9f9d2e3082eaf928270: EthCrossChainManager
0xcf2afe102057ba5c16f899271045a0a37fcb10f2: EthCrossChainData
0x250e76987d838a75310c34bf422ea9f1ac4cc906: LockProxy
 
Transaction: 0xb1f70464bd95b774c6ce60fc706eb5f9e35cb5f06e6cfe7c17dcda46ffd59581

Ontology

Transaction: 0xf771ba610625d5a37b67d30bf2f8829703540c86ad76542802567caaffff280c

Poly

Transaction: 0x1a72a0cf65e4c08bb8aab2c20da0085d7aee3dc69369651e2e08eb798497cc80

0x2. 공격 흐름

Ethereum에서 발생한 공격을 예로 들겠습니다. 이것은 세 개의 체인(및 해당 릴레이어), 즉 Ontology 체인, Poly 체인, Ethereum을 포함하는 크로스체인 공격입니다.

전체 공격 흐름은 세 단계로 구성됩니다:

공격자는 먼저 Ontology 체인에서 악성 트랜잭션(0xf771ba610625d5a37b67d30bf2f8829703540c86ad76542802567caaffff280c)을 시작했습니다;
공격자는 그런 다음 Ethereum의 EthCrossChainData 컨트랙트에 저장된 keeper의 공개 키를 수정했습니다;
공격자는 마지막으로 암호화 자산을 탈취하기 위한 악성 트랜잭션을 만들었습니다.

0x2.1 첫 번째 단계

공격자는 먼저 Ontology에서 크로스체인 트랜잭션(0xf771ba610625d5a37b67d30bf2f8829703540c86ad76542802567caaffff280c)을 시작했으며, 여기에는 악성 페이로드가 포함되어 있습니다:

이 페이로드에 조작된 함수 이름(변환 후 6631, 즉 f1121318093로 시작)이 포함되어 있음을 알 수 있습니다. 이 이름은 분명히 세심하게 만들어진 것인데, 공격자가 함수 시그니처의 해시 충돌을 악용하여 putCurEpochConPubKeyBytes 함수(Ethereum의 EthCrossChainData 컨트랙트 참조)를 호출하는 데 사용할 것이기 때문입니다. 해시 충돌에 대한 세부 사항은 이미 많이 논의되었으므로 여기서는 설명하지 않겠습니다.

그 후, 이 트랜잭션은 Ontology 체인 릴레이어에 의해 성공적으로 수락되었습니다. 엄격한 검증이 존재하지 않는다는 점에 유의하십시오. 결과적으로, 이것은 Poly 체인에서 유효한 새 트랜잭션(0x1a72a0cf65e4c08bb8aab2c20da0085d7aee3dc69369651e2e08eb798497cc80)이 되었습니다.

새 트랜잭션은 그 후 Ethereum 릴레이어에 의해 감지되고 거부되었습니다. Ethereum 릴레이어가 대상 컨트랙트 주소(이 경우 EthCrossChainData)를 검증했는데, LockProxy만 허용되기 때문입니다.

따라서 처리가 종료되었습니다. 그러나 악성 페이로드가 포함된 트랜잭션은 Poly 체인에 저장되어 공격에 악용될 수 있습니다.

0x2.2 두 번째 단계

공격자는 EthCrossChainManager 컨트랙트의 verifyHeaderAndExecuteTx 함수를 호출하여 Ethereum으로 수동으로 트랜잭션을 전송했습니다. Poly 체인에 저장된 악성 트랜잭션 데이터가 입력으로 사용되었습니다. 유효한 Poly 체인 트랜잭션으로서, verifyHeaderAndExecuteTx 함수의 검증(서명 및 머클 증명 포함)을 우회할 수 있었습니다. 그 후, EthCrossChainData 컨트랙트의 putCurEpochConPubKeyBytes 함수가 호출되어 원래의 네 keeper를 공격자가 제어하는 새로운 keeper(즉, 0xA87fB85A93Ca072Cd4e5F0D4f178Bc831Df8a00B)로 수정했습니다.

0x2.3 세 번째 단계

keeper 수정 후, 공격자는 Poly 체인을 사용하지 않고 verifyHeaderAndExecuteTx 함수를 직접 호출할 수 있었습니다. 마지막으로, LockProxy 컨트랙트의 unlock 함수가 호출되어 Ethereum에서 대량의 디지털 자산을 탈취했습니다. 자세한 분석은 이전 보고서에서 확인할 수 있습니다.

0x3. 릴레이어

Ontology와 Ethereum 릴레이어 모두 Go로 구현되어 있습니다. 그러나 충분한 검증이 부족하여

공격자는 Poly 체인에 포함될 악성 트랜잭션을 구성할 수 있습니다
공격자는 Ethereum의 EthCrossChainData 스마트 컨트랙트의 함수를 직접 호출할 수 있습니다

0x3.1 Ontology 릴레이어는 Ontology의 크로스체인 트랜잭션을 맹목적으로 신뢰합니다

ont_relayer는 Ontology 체인의 크로스체인 트랜잭션을 수신하고 Poly 체인으로 전송하는 역할을 합니다.

Side는 Ontology 체인을 의미하고; Alliance는 Poly 체인을 의미합니다
CrossChainContractAddress는 Ontology 체인의 네이티브 스마트 컨트랙트(번호 09)입니다

위 그림은 Ontology 릴레이어가 Ontology 체인과의 크로스체인 트랜잭션을 수신하는 두 개의 루틴과 크로스체인 트랜잭션 상태를 확인하는 루틴(71번 줄)을 시작함을 보여줍니다.

위 그림에서, Ontology 릴레이어는 Ontology 체인이 노출한 RPC 인터페이스(215번 줄 GetSmartContractEventByBlock)를 호출하여 체인의 이벤트를 가져옵니다. 228번 줄과 232번 줄에서, 이 루틴은 CrossChainContractAddress에 의해 트리거된 makeFromOntProof 이벤트만 수신함을 알 수 있습니다.

위 그림에서, 크로스체인 트랜잭션을 처리할 때 다섯 가지 검사가 있습니다. 처음 두 개는 Ontology 체인에 대한 RPC 요청 검사(검사 1과 4)이고, 세 개는 매개변수가 null인지 여부에 대한 검사(검사 2, 3, 5)입니다. 그러나 크로스체인 트랜잭션의 의미론적 검사, 즉 컨트랙트와 메서드 이름이 적절한지에 대한 검사는 존재하지 않습니다. 마지막으로, 트랜잭션을 Poly 체인으로 전송합니다(183번 줄).

Ontology 릴레이어는 RPC 인터페이스를 사용하여 트랜잭션을 구성하고 Poly 체인으로 전송합니다(164번 줄 - SendTransaction).

함수 ProcessToAliianceCheckAndRetry는 트랜잭션이 실패했는지 여부만 확인합니다. 실패한 경우 트랜잭션을 재전송합니다.

요약하면, ont-relayer는 Ontology 체인의 CrossChainContractAddress에 의해 트리거된 모든 makeFromOntProof 이벤트를 수신합니다. 그런 다음 트랜잭션이 Poly 체인으로 전송됩니다. 참고로, Ontology 체인의 누구든지 크로스체인 트랜잭션을 시작하면 makeFromOntProof 이벤트가 트리거되어 Poly 체인으로 전송됩니다.

0x3.2 Ethereum 릴레이어 우회

Ethereum 릴레이어는 Poly 체인의 트랜잭션을 수신하고 Ethereum으로 전송하는 역할을 합니다.

Ethereum 릴레이어는 Poly 체인을 모니터링하기 위한 고루틴을 시작합니다;

Ethereum을 대상으로 하는 크로스체인 트랜잭션을 모니터링합니다(275번 - 278번 줄). 그런 다음 대상 컨트랙트(ToContractAddress)가 config.TargetContracts에 구성된 컨트랙트 중 하나인지 확인합니다. 그렇지 않으면 크로스체인 트랜잭션이 대상 체인(Ethereum)으로 전송되지 않습니다.

그러나 공격자는 대상 체인과 직접 상호작용하여 EthCrossChainManager의 함수를 호출할 수 있습니다. 다시 말해, Ethereum 릴레이어의 검사를 우회할 수 있습니다. 악성 트랜잭션이 Poly 체인에 포함되기만 하면(이전 단계에서 Ontology 릴레이어를 통해 달성됨), 공격자는 EthCrossChainManager와 직접 상호작용할 수 있습니다. 이 과정에서 Poly 체인에 유효한 트랜잭션이 있으므로 서명 검증(ECCUtils.verifySig)과 머클 증명(ECCUtils.merkleProve)을 통과할 수 있습니다.

앞의 두 가지 방법을 사용하여, 공격자는 Ethereum에서 ToContractAddress.method를 성공적으로 호출할 수 있습니다. 해시 충돌과 결합하여, putCurEpochConPubKeyBytes 함수가 최종적으로 호출되어 keeper를 변경합니다.

크레딧

Yufeng Hu, Siwei Wu, Lei Wu, Yajin Zhou @ BlockSec

공식 웹사이트: https://blocksec.com/

공식 트위터 계정: https://twitter.com/BlockSecTeam