"해커는 키를 얻기 위해 부동산을 찾기 위해 소유자의 인증서를 가져갔습니다. 증명은 위조되었지만 부동산에서 실제 키를 얻었습니다."
"해커는 키를 얻기 위해 부동산을 찾기 위해 소유자의 인증서를 가져갔습니다. 증명은 위조되었지만 부동산에서 실제 키를 얻었습니다."
보조 제목
2021년 8월 10일, PolyNetwork는 크로스체인 공격을 당했고, 미화 6억 달러의 암호화된 자산이 전송되었습니다(이후 공격자들은 훔친 자산을 차례로 반환하기 시작했습니다). 공격자는 여러 퍼블릭 체인에서 공격 거래를 수행했으며, 크로스 체인 관리 계약 및 리피터 구성 요소를 통해 공격을 완료했습니다.
위 속성의 예를 들어 해커는 가짜 주택 소유자 인증서(소스 체인의 유효하지 않은 트랜잭션)를 사용하여 속성(리피터)에서 실제 키(Alliance Chain의 서명된 Merkle 인증서)를 가져왔습니다.
보조 제목
공격 분석
1. 해커가 소스 체인에서 유효하지 않은 공격 트랜잭션을 초기화했습니다.
2. 공격 트랜잭션이 완전히 확인되지 않은 채 소스 체인에 기록된 후 리피터에 의해 Alliance Chain의 Merkle 트리에 포함되고 서명된 후 Alliance Chain 블록으로 릴리스되었습니다.
4. 키퍼 권한을 얻은 후 해커는 여러 퍼블릭 체인에서 자산을 임의로 잠금 해제할 수 있습니다.
일부 체인에 있는 Poly Network의 리피터는 공격 트랜잭션을 통과하지 않았기 때문에 스마트 계약이 유사하더라도 대상 체인의 일부 자산은 영향을 받지 않는다는 점에 주목할 가치가 있습니다.
보조 제목
https://explorer.ont.io/tx/F771BA610625D5A37B67D30BF2F8829703540C86AD76542802567CAAFFFF280C#
상세한 분석
1. 해커는 베이징 시간으로 2021년 8월 10일 17:32:32에 소스 체인에 대한 공격 거래를 시작했습니다."66313231333138303933"트랜잭션을 디코딩하고 다음 매개변수 맵을 얻었습니다.
https://explorer.poly.network/tx/1a72a0cf65e4c08bb8aab2c20da0085d7aee3dc69369651e2e08eb798497cc80
2. 이 공격 트랜잭션은 메서드를 호출합니다.
, 해당 서명은 0x41973cd9(나중에 호출되는 putCurEpochConPubKeyBytes 함수의 서명과 동일)와 같습니다. 이 트랜잭션은 유효하지 않은 트랜잭션이어야 하지만 소스 체인에 기록되고 리피터에 의해 Alliance Chain의 Merkle 트리에 포함되고 서명된 후 Alliance Chain 블록에 게시됩니다. 머클 트리는 트랜잭션이 실제로 존재하는지 여부를 증명하는 데 사용됩니다. 결과 크로스 체인 트랜잭션은 다음과 같습니다.
https://etherscan.io/tx/0xb1f70464bd95b774c6ce60fc706eb5f9e35cb5f06e6cfe7c17dcda46ffd59581
4. 이 기능은 Merkle 증명을 분석하고 증명이 유효한지 확인하고 서명된 Merkle 트리에 공격 트랜잭션이 존재하는지 확인합니다. 그런 다음 EthCrossChainManager._executeCrossChainTx() 함수를 호출하여 트랜잭션을 실행합니다. 즉, 계약(0xcf2afe102057ba5c16f899271045a0a37fcb10f2)의 메서드(0x6631313231333138303933)를 가리키도록 toContract를 호출하고 매개변수 args( 010000000000000014a87fb85a93ca072cd4e5f0d4f178bc831df8a00b). 그리고 이 메서드는 putCurEpochConPubKeyBytes(bytes)를 가리키고 있는데, 함수 서명이 2단계에서 언급한 메서드 서명과 동일하기 때문에(둘 다 0x41973cd9, 여기서는 해시 충돌임) 성공적으로 실행되고 키퍼의 공개 키가 됩니다. 해커의 공개키로 변경됩니다. Ethereum의 트랜잭션은 다음과 같습니다.
5. 해커가 공개 키를 변경한 후 마음대로 자산을 잠금 해제할 수 있습니다.
보조 제목
이벤트 요약
이 공격은 일련의 트랜잭션으로 구성되며 공격의 근본 원인은 다음과 같이 분석됩니다."makeFromOntProof"1. 공격 트랜잭션이 충분한 확인 없이 소스 체인에 기록됩니다.
2. 리피터는
이벤트 거래.
3. repeater는 1단계의 트랜잭션을 Alliance Chain에 게시합니다.
“The management contract fetches the block headers from chain A, verifies whether or not the cross chain parameters and the proof are valid, and then transmits the necessary information to chain B in the form of an event;”
"4. 2단계에서 공격 트랜잭션은 Alliance Chain의 Merkle 트리에 통합되어 유효한 Merkle 증명을 생성합니다."
5. 원래 체인의 ECCM 계약은 2단계에서 생성된 Merkle 인증서를 통과했으며, 이는 트랜잭션이 소스 체인에 "실제로 존재"하고 원본 데이터가 파괴되거나 수정되지 않았음을 확인합니다. 그러나 대상 체인으로 보낼 Merkle 증명을 구성하기 전에 거래가 완전히 검증되어야 한다는 점을 강조하는 것이 중요합니다. 디자인 문서에 표시된 대로.
관리 계약은 A 체인에서 블록 헤더를 얻고 교차 체인 매개변수와 증명이 유효한지 확인한 다음 필요한 정보를 이벤트 형식으로 B 체인에 전송합니다.
