PREMINT 공격 사건 전모 분석

저자: Go+ Security

7월 17일 16:00(UTC+8), premint.xyz가 해킹 공격을 당해 일부 사용자의 NFT가 도난당했습니다. 공격 사건 발생 후, GoPlus 보안 분석가는 신속하게 이를 종합적으로 분석하고, 일반 투자자와 개발자 두 가지 관점에서 보안 조언을 제공했습니다.

공격 과정

• 공격자는 premint.xyz 웹사이트에 악성 JS 스크립트를 삽입하여 공격을 감행했습니다. 사용자가 일반적인 작업을 수행할 때 악성 코드를 실행하여 사용자가 권한 부여 작업 setApprovalForAll(address,bool)의 거래에 서명하도록 속였습니다. 권한을 획득한 후, 사용자의 NFT 등 자산을 도난당했습니다.

공격 원리

• 사용자가 https://www.premint.xyz/에 접근하면, 웹사이트는 다음의 js 리소스 파일 https://s3-redwood-labs.premint.xyz/theme/js/boomerang.min.js를 로드합니다.

• 이 파일에는 해커가 주입한 스크립트가 포함되어 있으며, 이 스크립트는 해커의 가짜 도메인(s3-redwood-labs-premint-xyz.com)에 호스팅된 공격 스크립트 파일 https://s3-redwood-labs-premint-xyz.com/cdn.min.js?v=1658050292559를 로드합니다. 이 스크립트는 사용자의 권한을 속이는 상호작용을 포함하고 있습니다(현재는 접근할 수 없습니다).
• 사용자가 일반적인 지갑 소유권 확인 서명(즉, 서명 로그인) 작업을 수행할 때, 이 스크립트가 트리거되어 기존의 검증 서명을 공격자가 사용자의 고가치 NFT를 전송할 수 있는 거래로 대체합니다. 이 거래가 서명되면 자산이 도난당하게 됩니다. (참고: 공격 스크립트는 상황에 따라 사용자의 ERC20 토큰 권한을 속일 수도 있으며, 스크립트에 접근할 수 없기 때문에 현재로서는 알 수 없습니다.)

방어가 어려운 상황

• 이번 공격은 일반 사용자에게 가장 대처하기 어렵고 쉽게 당할 수 있는 경우입니다.
• 공격의 모든 C端 상호작용이 Premint의 공식 웹사이트 내에서 발생하기 때문에, 사용자들이 경계를 풀기 쉽습니다. 사람들은 공식 웹사이트가 문제 없다고 기본적으로 믿기 때문입니다.
• 거래 서명을 속이는 과정은 정상적인 작업의 서명 검증 과정에서 발생하며, 대부분의 사용자는 지갑의 서명 세부정보를 확인하지 않습니다(대부분의 사용자는 서명이 안전한지 판단하는 방법을 모르고, 공식에 대한 신뢰로 인해 이 단계에서의 위험을 쉽게 간과합니다). 따라서 공격 과정은 매우 은밀합니다.

취약점은 어디에

• 많은 사람들이 궁금해할 것입니다. 왜 Premint의 공식 웹사이트에 공격 코드가 존재하는지, 이는 호스팅된 S3(AWS의 객체 저장 서비스)에서 js 리소스 파일이 해커에 의해 침입당해 변조되었기 때문입니다.

• 왜 침입당했는지에 대해서는, 현재 자료에 따르면 S3 구성 오류로 인해 버킷이 비인가 접근이 가능해져 공격자가 S3 버킷을 자유롭게 나열, 읽기 또는 쓰기 할 수 있게 되어 js 리소스 파일이 변조된 것으로 의심됩니다.

• 전체 과정에서 가장 이해할 수 없는 점은, 해커의 공격 행위가 17일 16:00(UTC+8)에 발견되었지만, 17일 22:00(UTC+8) 이전까지 Premint 공식이 공격받은 js 파일을 수정하지 않았다는 점입니다. boomerang.min.js 파일에는 여전히 해커가 주입한 악성 스크립트가 포함되어 있으며, 페이지 로드 시 여전히 해커의 공격 스크립트 파일을 로드하려고 합니다. 다만 이 악성 스크립트 자체는 이미 접근할 수 없습니다(공격 도메인 s3-redwood-labs-premint-xyz.com은 접근할 수 없습니다). 이러한 상태는 6시간 동안 지속되었으며, 이 시점에서 스크립트가 다시 활성화된다면 더 큰 손실이 발생할 수 있을지 판단하기 어렵습니다.

교훈

교훈 1: 일반 투자자로서 우리는 무엇을 해야 할까요? 공식 웹사이트가 신뢰할 수 없다면, 어떻게 사기를 피할 수 있을까요?

• 이번 공격은 기술을 잘 모르는 많은 사용자에게 "첫 경험의 살해"와 같아서 100% 당할 수 있습니다. 결국 누구도 공식 웹사이트에 사기가 있을 것이라고 의심하지 않기 때문입니다. 그러나 모든 블록체인 거래는 지갑의 서명을 통해 이루어져야 하므로, 서명 내용을 주의 깊게 살펴보면 위험을 인식할 수 있습니다.
• 많은 블록체인 사용자들은 지갑에 들어가면 가스 조정 과정 외에는 다른 단계에서 무의식적으로 작업하는 매우 나쁜 습관을 가지고 있습니다. 사실 서명 전의 확인 정보에는 많은 중요한 내용이 포함되어 있으므로, GoPlus Security는 모든 서명 작업 전에 반드시 세심하게 확인할 것을 권장합니다.
• 이번 공격을 예로 들면, 사용자가 Premint에 대해 서명 검증을 수행할 때, 정보 검증만 수행하므로 블록체인에 올라갈 필요가 없습니다. 따라서 발행된 Signature Request는 Origin 정보(요청자), 사용자의 주소, Nounce 정보, 일부 추가 반환 정보만 포함해야 합니다. 아래 그림과 같이(현재 https://www.premint.xyz/는 임시로 오프라인 상태이므로 Opensea를 예로 들겠습니다):

• 그러나 공격에 의해 주입된 거래 서명은 거래를 블록체인에 올려야 하므로, 거래는 계약 호출의 형태로 더 많은 정보를 표시합니다. 예를 들어 setApprovalForAll을 사용하는 NFT 권한 부여의 경우, 이 거래가 어디에서 이루어졌는지(그림은 etherscan), 어떤 방법을 호출했는지(setApprovalForAll), 권한 부여 대상이 누구인지, 얼마나 많은 ETH를 소모했는지 등이 표시됩니다.

• 돌아보면, 네티즌이 제공한 스크린샷을 보면, Permint가 공격을 받은 후 서명 검증을 하라고 안내하지만, 실제로 지갑 서명을 요청하는 거래는 완전히 블록체인에 올라가는 setApprovalForAll과 일치합니다. 조금만 관찰하면 이 부분에 문제가 있다는 것을 알 수 있습니다.

• 실제로 계약의 다양한 호출, ETH(또는 다른 원주화) 전송, 토큰 전송 등은 지갑의 서명 정보가 모두 다릅니다. 모든 투자자는 이러한 차이를 이해해야 하며, 이와 같은 공격을 당할 때 손실을 피할 수 있습니다. GoPlus Security는 여러분이 직접 작업 과정을 시뮬레이션하여 다양한 서명 정보를 이해할 것을 강력히 권장합니다(거래가 발송되지 않으면 비용이 발생하지 않으며, 학습 비용이 없습니다). 서명 정보를 보는 법을 배우면 거의 모든 피싱, 주입, 사기 공격을 피할 수 있습니다.
• 게으르지 마세요. 자신의 안전을 보장하고 싶다면, 학습이 유일한 방법입니다.

교훈 2: 개발자로서 우리는 무엇을 해야 할까요? 어떻게 주입 공격을 피할 수 있을까요?

• 이번 공격은 개발자에게 가장 큰 교훈을 주는데, web3.0 세계가 web2.0과 독립적으로 존재할 수 없다면, 반드시 web2.0과 같은 공격 방식을 견뎌야 한다는 것입니다. 계약 수준에서만 자신의 안전을 보장하는 것으로는 충분하지 않으며, 모든 전통적인 보안 준비를 소홀히 해서는 안 됩니다. 작은 실수 하나가 큰 손실을 초래할 수 있습니다.
• 또한, 이러한 문제가 발생하면 즉시 수정하거나 격리해야 하며, 만약 안일한 마음으로 위험 요소를 즉시 처리하지 않으면, 보안 분석가에게 비웃음을 당하는 것은 작은 일입니다. 만약 공격 수단이 여전히 유효하다면, 손실은 계속 발생할 수 있으며, 이는 큰 문제입니다.