블록체인 피싱 공격 종합 분석

05-29

이 기사는 기계로 번역되었습니다

원문 표시

이 기사는 X-explore와 WuBlockchain이 공동으로 게시한 것입니다.

소개

2024년 체이널리시스 기사에 따르면, 전체 온체인 거래량의 0.34%에 해당하는 불법 주소로 242억 달러 상당의 돈을 받았다. 블록체인 산업에 대한 관심이 높아짐에 따라 더 많은 사용자와 자산이 Web 3 시장에 유입되기 시작했지만 사용자의 사이버 공격 사고 보고도 증가했습니다.

다양한 공격 중에서 피싱은 여전히 사이버 공격의 주요 측면 중 하나입니다. 공격자는 스테이블코인, ETH 또는 알트코인과 같은 다양한 토큰을 표적으로 삼습니다. 이들은 사용자가 악의적인 거래에 서명하도록 유도하거나 개인 키를 입력하여 사용자 계정을 제어하도록 유도합니다. 이 기사에서는 기존의 피싱 사기 방법을 추가로 조사하고 향후 악성 계정을 예방하거나 식별하는 방법을 탐색할 것입니다.

배경 및 관련 작업

기존 피싱 공격 방식 프레임워크(오프체인)

피싱 공격은 사용자가 온라인 세계에서 개인 정보를 입력하도록 유도하는 데 중점을 둡니다. 사용자를 유인하는 방법은 다양하지만 대부분의 피싱은 이메일, 소셜 미디어 채널, 합법적으로 보이는 복제된 웹사이트 등의 플랫폼에서 이루어집니다. 이러한 이메일이나 웹사이트는 사용자가 개인 정보를 입력하거나 사기꾼에게 통제권을 주는 거래에 서명하도록 유도합니다. 이 기사에서는 사기꾼이 오프체인에서 먼저 활용하는 3가지 주요 프레임워크를 조사할 것입니다.

스피어 피싱

스피어 피싱 공격은 특정 개인이나 조직을 대상으로 합니다. 공격자는 사전에 맞춤형 정보를 수집하여 특정 그룹에 개인화된 이메일을 만들어 이메일을 합법적으로 만듭니다. 더욱이, 생성 AI의 등장으로 이제 한 명의 사기꾼이 개인화된 정보를 수집하고 이전보다 더 광범위한 사용자 그룹을 대상으로 개인화된 이메일을 작성할 수 있는 힘을 갖게 되었습니다.

파밍 공격

파밍 공격은 가짜 웹사이트로 리디렉션되는 URL을 제작합니다. 예를 들어 Slack 웹사이트에서 "i"를 대문자 "I"로 바꾸면 " www.apple.com "이 " www.appie.com "과 동일하게 보일 수 있습니다. 이러한 방법으로 사기꾼은 악성 URL을 제작하여 이메일이나 텔레그램, 슬랙 등 SNS 채널을 통해 유포합니다.

가짜 브라우저 확장 프로그램

사기꾼은 악성 확장 프로그램을 프로그램하고 다운로드 링크를 제작하여 이메일이나 SNS 채널을 통해 배포합니다. 클릭하면 이러한 확장 프로그램이 사용자 환경에 다운로드되어 니모닉 문구 및 개인 키와 같은 개인 정보를 찾습니다.

사용자가 다운로드 링크를 클릭하거나 개인 정보를 입력하거나 거래에 서명하면 사기꾼은 계정을 완전히 통제할 수 있으며 사용자는 롤백할 방법이 없습니다. 따라서 사용자가 신뢰하지 않는 소스를 클릭하지 않는 것이 중요합니다.

블록체인(온체인)에서 자금 추출

오프체인 프레임워크를 고려하여 이 기사에서는 사기꾼이 어떻게 온체인 지갑에 대한 완전한 통제권을 얻는지 살펴볼 것입니다. 블록체인 분야에서 공격자는 다양한 방법으로 사용자 계정에 대한 통제권을 얻을 수 있습니다. 특히 스테이블 코인 및 알트코인과 같은 ERC-20 토큰 계약의 경우 사기꾼은 사용자의 개인 키가 반드시 필요한 것은 아니지만 대신 온체인 또는 오프체인에서 사용자의 서명 로그인이 필요합니다. 이 기사에서는 공격자가 자금을 빼내기 위해 활용하는 다양한 방법을 살펴보겠습니다.

개인 키

개인 키 추출은 요즘 일반적인 방법이 아닙니다. 공격자는 사용자가 시드 문구나 개인 키를 입력하도록 요구하는 웹사이트나 이메일을 제작합니다. 공격자가 사용자의 개인 키나 시드 문구를 획득하면 공격자는 지갑과 주소를 완전히 제어할 수 있습니다.

개인 키를 기반으로 한 파밍 공격 샘플 이미지. (출처: X)

간단한 방법임에도 불구하고, 과거의 사용자들은 블록체인 분야에 대한 지식이 부족하여 쉽게 함정에 빠졌습니다.

승인 및 전송From

ERC-20 표준에 따라 ERC-20 토큰은 De-Fi 프로토콜 적용을 위한 푸시 및 풀 트랜잭션을 지원합니다. 푸시 거래는 수취인에게 보낼 금액을 결정하는 지불인에 의해 시작됩니다. 그러나 풀(Pull) 거래에서는 수취인이 송금할 금액을 지급인에게 지시합니다. 따라서 세 번째 부분이 거래를 제어할 수 있습니다. Pull 트랜잭션 지시는 아래 절차에 따라 Web 3에서 관리됩니다.

사용자는 Approve()를 호출하고 서명합니다. approve( owner, spender, amount) 토큰 수취인의 주소가 사용자의 주소에서 가져갈 수 있는 금액을 설정합니다. 악용될 수 있는 increaseAllowance( spender, amount) 이 있다는 점에 유의하세요. 승인과 증가 허용량의 차이는 승인이 새로운 허용을 설정하는 반면, 증가 허용은 기존 허용에 추가됩니다[하드 제한 설정].
경계가 설정되면 수취인은 사용자의 토큰을 수취인의 주소로 이동하는 transferFrom(to, from, amount) 호출할 수 있습니다.

실제 애플리케이션에서는 일반적으로 수취인이 스마트 계약입니다. 사용자는 ERC-20 토큰을 스마트 계약으로 전송하고 스마트 계약은 그에 따라 자금을 관리합니다. 그러나 스마트 컨트랙트가 해킹되면 설정된 허용량에 따라 사용자의 자금이 빠져나가게 된다는 점을 기억하는 것이 중요합니다. 일부 시나리오에서는 사용자 UI를 단순화하기 위해 스마트 계약에서 높은 금액(무한한 금액)의 허용량을 요구할 수 있으므로 사용자는 가스 요금을 절약하기 위해 허용량을 설정하기 위해 매번 서명할 필요가 없습니다. 금액은 무한정으로 설정되어 있으므로, 이용자는 제3자가 신뢰할 수 있는 출처인지 확인해야 합니다.

Allowance를 설정하고 transferFrom 메소드를 활용하는 것은 꽤 오랫동안 취약점이었습니다. 그러나 De-Fi(Decentralized Finance) 및 dApps에서의 실용적인 적용으로 인해 Approve & TransferFrom은 최근 개선되어 자주 활용되고 있습니다.

예를 들어, EVM의 최대 용량이 1024로 설정되어 있기 때문에 허용량 설정 → transferFrom과 같은 복잡한 절차에서는 일반적으로 스택이 주어진 공간의 한계를 초과하여 트랜잭션이 되돌려지면서 "1024 스택 깊이 문제"가 발생했습니다.

따라서 각 메서드를 호출하고 다음 메서드로 진행하면 해당 메서드를 호출하면 큰 취약점이 발생하게 됩니다. 주요 악용은 재진입 공격이 될 수 있습니다. Vitalik은 특정 시나리오를 인식하고 2017년에 개선을 이루어 ERC-223 표준을 도입했습니다.

1024 스택 깊이에 대한 Vitalk의 의견 스크린샷. (출처: Github)

허가나 허가2와 같은 다른 개선된 프로토콜이 도입되었지만 지갑의 보안은 사용자 서명 거래에 달려 있습니다. 따라서 잠재적인 사기를 예방하려면 3가지 주요 측면을 확인하는 것이 중요합니다.

승인 금액 : 사기꾼은 전용 ERC-20 토큰에 대한 완전한 통제권을 획득하기 위해 비정상적으로 높은 승인 요청을 생성하는 경우가 많습니다. 계약시에는 반드시 수당금액을 확인하시기 바랍니다.
검증된 스마트 계약 : 알려진 dApp에서 제공하는 검증된 스마트 계약에 대한 허용 서명에 서명하고 있는지 확인하세요. Etherscan이나 다른 블록체인 탐색기에서 태그와 메모를 확인하면 계약이 악성으로 표시되었는지 여부를 식별하는 데 도움이 될 수 있습니다.
보안 경고 확인 : Meta Mask 또는 Wallet Connect와 같은 지갑 제공업체는 잠재적인 사기 계약과 상호 작용하는 경우 프롬프트를 생성합니다. 이러한 알림을 꼭 확인하세요.

사례 사례

블록체인 탐색기에서 실제 공격이 어떻게 수행되고 기록되는지 시각화해 보겠습니다.

블록체인: BSC 체인

날짜: 2023년 5월 11일

공격자: 0x49Dc14Dd851B6EaE8d685715e12a06cc1BFC5d8d

피해자: 0x5F464c94e93CEbd56aE2F1220912BA0ab0a27a38

Step1 : 사용자가 승인 계약에 서명합니다.

텔레그램 채널, 인스타그램, 피싱사이트 등을 통해 Web 2 환경에서 허위 정보를 수신한 경우, 사용자는 서명 승인 요청을 받습니다.

피해자는 Shiba Inu 토큰에 대한 사기꾼을 승인했습니다.

승인 및 이전 요청. 피해자는 사기꾼이 통제할 총 426923054270173310680061630 SHIB를 승인했습니다.

Dex 또는 Cex → Victim → Scammer의 자금 흐름 스크린샷

2단계 : 자금 유출

이제 사기꾼은 피해자의 주소에 있는 426923054270173310680061630 이하의 ERC-20 토큰 자금을 통제할 수 있으므로 피해자의 토큰을 자신의 계정으로 전송하기 시작합니다. 아래와 같이 피해자의 계좌에서 총 256153832.56 SHIB가 빠져나갔습니다.

거래는 공격자가 256153832.56 SHIB를 빼내는 것에 의해 수행되었습니다.

허용하다

Permit은 승인 및 transferFrom 워크플로의 향상된 측정으로 ERC-2612에 도입되었습니다. Approval 및 TransferFrom과 달리 오프체인 서명이 생성되므로 사용자는 이전에 온체인에서 승인을 위해 서명할 필요가 없습니다. Permit 및 transferFrom의 워크플로는 다음과 같습니다.

허가 프로토콜의 기술적 흐름(출처: 매체)

사용자는 permit (owner, spender, value, nounce, deadline) 를 통해 서명을 생성해야 합니다. 생성된 서명의 3분할인 r, s, v에 대한 반환 값입니다.
사용자가 r,s 및 v를 사용하여 Permit 서명을 생성하면 제3자가 다음 값을 사용 permit(owner,spender, value, deadline, v, r, s) 호출합니다. 단계 변경을 위해 거래되면 그에 따라 수당이 설정됩니다.
한 번의 거래 내에서 허용량이 설정되면 제3자가 이체를 실행합니다.

Permit()을 활용한 오프라인 서명 생성을 통해 온체인에서 허용량에 서명할 필요가 없어 가스 비용을 절약할 수 있었습니다. 또한 r, s, v 생성을 통해 보안이 대폭 향상되었으며, 사용자는 서명을 생성하기 위해 자신의 개인 키를 노출하지 않습니다.

모든 ERC-20 표준 토큰이 허용() 메서드를 지원하는 것은 아닙니다. 더욱이, 허가()의 핵심 메커니즘은 승인 및 전송으로부터의 워크플로우에 있습니다. 취약점은 사용자가 Permit()을 생성하거나 서명하는 데 있습니다.

사례 사례

블록체인 탐색기에서 실제 공격이 어떻게 수행되고 기록되는지 시각화해 보겠습니다.

블록체인: ETH

날짜: 2024~05~24

공격자: 0x77865b925f96fc49837cfe27ec04cd5a691e61ef

피해자: 0x7cdd2a99fc014194218119a7100c259e31a10bf2

1단계 : 사용자가 오프체인 서명을 생성합니다.

이러한 프로세스는 오프체인에서 수행되므로 Blockchain Explorer에서 추적할 수 없습니다. 사기꾼은 피해자가 간단한 클릭만으로 오프체인 서명을 생성하도록 유도합니다. 피해자가 온라인 거래에 서명하지 않았더라도 지갑을 통해 오프체인 서명을 하면 사기꾼이 나중에 TransferFrom을 수행할 수 있습니다.

2단계 : 사기꾼은 오프체인 서명을 통해 허가 계약에 서명합니다.

사기꾼은 온체인 거래를 통해 ERC-20 토큰 계약에 서명된 메시지를 제출합니다. 피해자의 주소와 nonce에 대한 검증이 완료되면 승인 요청이 이루어집니다. 허가를 통해 온체인 거래는 단 한 번만 있었습니다. 기존 Approve& TransferFrom과 비교하여 트랜잭션 절약 가스 비용이 하나 더 적습니다.

한 번의 실행 내에서 Permit 및 transferFrom이 호출되었습니다.

비정상적으로 많은 승인 금액을 확인하세요.

총 173455570204 USDC가 소진되었습니다.

ERC-4337 (계정 추상화 또는 스마트 계약 지갑)

2021년 Vitalk가 도입한 새로운 AA 체계는 현재의 기존 합의 계층 프로토콜을 기반으로 만들어졌습니다. EIP-86 (Bare multi-sig AA), EIP-3074 (Auth 및 Authcall), EIP-2938 (Account Abstraction) 등 이전에 도입된 AA 방식과 달리 현재 합의 내에서 AA를 도입한 최초의 방식이었습니다. 현재 시장에 더 쉽게 통합할 수 있는 레이어 프로토콜입니다.

계정 추상화(AA)

블록체인에는 외부 소유 계정과 스마트 계약이라는 두 가지 주요 유형의 계정이 있습니다. 두 계정의 특성은 아래 표와 같이 다릅니다.

AA의 목표는 EOA와 SC의 이점, 즉 거래 시작 기능을 갖춘 완전한 프로그래밍 기능을 갖춘 통합 계정을 만드는 것입니다. AA의 이점은 다음과 같습니다.

계약 통화에 직접 응답하는 기능
계정 소유권 이전이 용이함(EOA가 불가능함)
새로운 검증 규칙 도입(SC 레벨 내에서 패스 키 확인 가능)
EOA에서 스마트 컨트랙트까지의 가스 수수료 비용을 제거합니다.
EOA, SC 대신 하나의 주소를 관리하세요.
새로운 가스비 결제 도입(네이티브 토큰일 필요는 없음)

ERC-4337의 워크플로우

AA는 사용자의 UI를 대폭 개선하는 통합 계정을 생성할 수 있는 새로운 표준입니다. ERC-4337의 기술적 흐름은 다음과 같습니다.

ERC-4337의 흐름도(출처: Eden Network)

ERC-4337의 기술 흐름도(출처: 공식 ERC-4337 문서)

ERC-4337은 크게 4가지 프로세스로 나눌 수 있습니다.

1단계: 사용자 작업 생성

dApp과 지갑을 통해 사용자는 AA 체계 작업과 상호 작용하여 사용자 작업을 생성할 수 있습니다. 응용 프로그램이 다중 서명, 소셜 복구 등과 같은 다양한 기능을 하나로 지원할 수 있으므로 사용자는 더 나은 UI를 갖습니다. 사용자 작업이 생성되면 오프라인으로 서명이 생성되며 실행 전에 나중에 계정에서 유효성을 검사합니다.

2단계 : 번들러 처리

사용자가 사용자 작업을 제출하면 번들러가 수집하여 번들로 집계하는 사용자 작업 메모리풀에 저장됩니다. 번들러는 트랜잭션의 유효성을 확인하고 통과되면 번들 트랜잭션이 처리를 위해 온체인으로 전송됩니다.

3단계 : 진입점 계약

EntryPoint 계약에 관한 규정. (출처: 공식 ERC-4337 문서)

위 규정에서 언급한 바와 같이 체인에는 통합 진입점 계약이 있습니다. 번들 거래를 수신하면 스마트 계약 계정이 지불해야 하는 가스 요금을 확인하기 위해 가스 계산을 수행합니다. Entrypoint 계약을 통해 사용자는 스마트 계약 계정이 지불하거나 paymaster처럼 가스 요금을 지불할 필요가 없습니다. 게다가 이 제도의 가장 중요한 장점은 가스 요금을 네이티브 토큰으로 지불할 필요가 없다는 것입니다. 수수료는 dApp에 따라 규제될 수 있으며 PayMaster를 통해 ERC-20 토큰으로 지불될 수 있습니다. 이러한 배열은 거래에 대한 사용자의 경험을 향상시킵니다.

4단계 : 검증 및 실행

진입점 계약에서 메서드를 받으면 원래 사용자 작업의 유효성 검사가 수행됩니다. 검증되면 그에 따라 거래가 실행됩니다. ETH 네트워크 mempool에 트랜잭션을 추가하는 것은 EntryPoint 계약입니다.

취약점 포인트

보안 관점에서 보면 취약점이 많이 남아있습니다. AA 체계는 오프체인에서 관리되는 번들러에서 온체인까지 사용자 작업을 실행할 수 있도록 허용하므로 사기꾼이 사용자 작업을 수행하기 위해 사용자를 조작할 수 있는 많은 공백을 제공합니다. 이 문서에서는 작업 실행 프로세스 전반에 걸쳐 잠재적인 취약점을 제공합니다.

가짜 진입점 계약

체인당 하나의 EntryPoint 계약만 있어야 합니다. 그러나 사기꾼은 체인에서 자신의 EntryPoint 계약 버전을 만들어 사용자 작업을 수행할 수 있습니다. 대부분의 보안 프로토콜과 모니터링은 싱글톤 EntryPoint 계약에 중점을 두기 때문에 사기꾼은 이를 피하기 위해 자신만의 버전을 만들고 싶어할 수도 있습니다. 그러나 이러한 계약은 현재의 블록체인 모니터링 시스템을 통해 쉽게 감지하고 관리할 수 있습니다.

악성 번들러

사기꾼은 사용자 작업 메모리 풀을 사용하여 자신만의 Bundler 서비스 버전을 만들 수 있습니다. Bundler 서비스는 구성, RPC 서버, 대체 mempool 및 UserOperation 번들링이라는 네 가지 주요 측면으로 구성됩니다.

구성은 EntryPoint 및 수혜자 계정의 주소를 설정합니다.

RPC 서버는 EntryPoint 주소가 지정된 작업을 처리합니다.

 async handleMethod (method: string, params: any[]): Promise<any> { let result: any switch (method) { case 'eth_supportedEntryPoints': result = await this.methodHandler.getSupportedEntryPoints() break case 'eth_sendUserOperation': result = await this.methodHandler.sendUserOperation(params[0], params[1]) break case 'eth_estimateUserOperationGas': result = await this.methodHandler.estimateUserOperationGas(params[0], params[1]) break case 'eth_getUserOperationReceipt': result = await this.methodHandler.getUserOperationReceipt(params[0]) break case 'eth_getUserOperationByHash': result = await this.methodHandler.getUserOperationByHash(params[0]) break // ... default: throw new RpcError(`Method ${method} is not supported`, -32601) } return result }

대체 메모리는 작업을 체인으로 보내기 전에 배열 형식으로 저장합니다. 번들러의 관점에서는 DoS 공격 방지를 여기서 관리해야 합니다.

 // add userOp into the mempool, after initial validation. // replace existing, if any (and if new gas is higher) // revets if unable to add UserOp to mempool (too many UserOps with this sender) addUserOp (userOp: UserOperation, userOpHash: string, prefund: BigNumberish, senderInfo: StakeInfo, referencedContracts: ReferencedCodeHashes, aggregator?: string): void { const entry: MempoolEntry = { userOp, userOpHash, prefund, referencedContracts, aggregator } const index = this._findBySenderNonce(userOp.sender, userOp.nonce) if (index !== -1) { const oldEntry = this.mempool[index] this.checkReplaceUserOp(oldEntry, entry) debug('replace userOp', userOp.sender, userOp.nonce) this.mempool[index] = entry } else { debug('add userOp', userOp.sender, userOp.nonce) this.entryCount[userOp.sender] = (this.entryCount[userOp.sender] ?? 0) + 1 this.checkSenderCountInMempool(userOp, senderInfo) this.mempool.push(entry) } this.updateSeenStatus(aggregator, userOp) }

마지막으로 userOperations 번들링의 경우 EntryPoint 계약으로 전송될 번들을 생성합니다. 번들러는 DoS 공격을 방지하기 위해 작업을 전달하기 전에 작업의 수수료 지불 능력을 확인해야 합니다. 그렇지 않은 경우 사기꾼은 수수료를 지불하는 것처럼 보이지만 되돌려 체인의 멤풀에 정체를 일으키는 작업을 조작할 수 있습니다.

또한 확인 단계는 상태 변경을 위반해서는 안 됩니다. 즉, 보낸 사람과 관련된 데이터에 따라 확인해야 합니다. Bundle 확인 및 생성은 아래 코드에 있습니다.

 async createBundle (): Promise<[UserOperation[], StorageMap]> { const entries = this.mempoolManager.getSortedForInclusion() const bundle: UserOperation[] = []

 // paymaster deposit should be enough for all UserOps in the bundle. const paymasterDeposit: { [paymaster: string]: BigNumber } = {} // throttled paymasters and deployers are allowed only small UserOps per bundle. const stakedEntityCount: { [addr: string]: number } = {} // each sender is allowed only once per bundle const senders = new Set<string>() // all entities that are known to be valid senders in the mempool const knownSenders = entries.map(it => { return it.userOp.sender.toLowerCase() }) const storageMap: StorageMap = {} let totalGas = BigNumber.from(0) debug('got mempool of ', entries.length) // eslint-disable-next-line no-labels mainLoop: for (const entry of entries) { // check reputation system // check duplicate UserOps per sender // check stake // check storage access // check UserOp call gas limit // check Paymaster deposit if present // If sender's account already exist: replace with its storage root hash senders.add(entry.userOp.sender) bundle.push(entry.userOp) totalGas = newTotalGas } return [bundle, storageMap] }

PayMaster 악용

PayMaster는 거래를 처리하기 위한 맞춤형 계약이므로 사기꾼은 코드의 취약점을 악용하여 가스 요금을 유용할 수 있습니다. 앞으로 추가적인 연구가 진행될 예정이다. 현재 페이마스터 악용 사례가 확인된 사례는 많지 않습니다.

사례 사례

블록체인 탐색기에서 실제 공격이 어떻게 수행되고 기록되는지 시각화해 보겠습니다. AA는 번들 운영 방식으로 트랜잭션을 처리하는 방식입니다. 사기꾼은 일반적으로 Perimt 또는 Approve와 같은 거래를 처리하기 위해 AA 체계를 활용합니다. 아래 예에서는 Approve & TransferFrom 요청을 살펴보겠습니다.

블록체인: BSC 체인

날짜: 2024년 3월 23일

공격자: 0x454b8b645a981e6c197087ea154df94b5187d682 , 0x170f7be1baf9234af5966d194a0a6bd6073eed99

피해자: 0x3f3ce11b7809ecf6f571943800c28f585e8b187d

https://app.blocksec.com/explorer/tx/bsc/0x812bc694a8c6732b899e81727f128d06c2b7b6717a2dd67936079928b41621b3

1단계 : 사용자가 오프체인 허가 요청에 서명합니다.

일반적인 허가 요청과 마찬가지로 사기꾼은 사용자에게 허가 메시지에 서명하도록 유도합니다. 거래 승인이나 서비스 이용을 위해 꼭 필요한 단계로 위장됩니다. 요청이 합법적이라고 믿는 피해자는 개인 키를 사용하여 오프체인 메시지에 서명합니다.

2단계 : 번들러와 상호작용

이제 사기꾼은 허가증 거래를 하나의 작업으로 처리하는 번들러와 상호작용하게 됩니다. 사기꾼은 트랜잭션을 번들러에 보내고 번들러는 이제 사용자 작업 mempool에 트랜잭션을 저장합니다. 사용자 작업 mempool에 저장된 후 유효성 검사 프로세스를 거쳐 EntryPoint 계약으로 처리됩니다.

3단계 : EntryPoint 계약

번들러로부터 작업 프로세스를 수신하면 EntryPoint 계약은 실행 전에 번들의 사용자 작업을 검증합니다. 아래 스크린샷과 같습니다. 가스 요금의 가용성과 상태 변경의 정확성을 확인한 후 내부 작업을 처리합니다.

InnerOperations를 처리하기 전의 작업 스크린샷

4단계 : 프로세스 상태 변경

아래에 강조 표시된 대로 이 예제의 내부 작업에는 두 개의 transferFrom 작업이 포함되어 있습니다. 두 개의 주소 212856150000000008192 , 37562849999999991808 )에서 이체 금액의 값 차이를 확인하세요. 비율은 대략 0.85:0.15로 사기를 서비스로 제공하고, 빼낸 금액을 드레이너와 고객에게 일정 비율로 공유하는 드레이너 서비스가 가능함을 나타낸다. Drainer 서비스에 대한 자세한 내용은 기사 뒷부분에서 설명합니다.

승인과 전송이 포함된 BSC-USD 토큰에 대한 TransferFrom의 두 가지 작업

승인 시 비정상적으로 높은 값의 공지

자금 흐름 및 운영 흐름

사기꾼의 공격 방법

암호화폐 배수 장치(서비스 제공자로서의 사기)

최근 암호화폐 시장에서는 서비스 제공업체로서의 사기에 대한 보고가 증가하고 있습니다. 공급자는 다중 체인을 사용하여 ERC-20 토큰을 배출하는 서비스를 제공하고 보상으로 도난당한 토큰을 얻습니다. 이 기사에서는 암호화폐 드레이너의 예시 사례 시나리오를 살펴보겠습니다.

인페르노 배수기

Scam Sniffer에 따르면 Inferno Drainers는 활동 기간 중 1년(2022년 11월~2023년 11월) 이내에 8천만 달러 이상을 훔쳤습니다. Inferno Drainer는 소셜 엔지니어링을 사용하여 피싱 웹사이트를 설정하고 플랫폼을 고객과 공유합니다.

Group-IB의 Scam Sniffer에 기반한 기사

그런 다음 고객은 Telegram, Facebook, Instagram 또는 기타 소셜 네트워크에 소셜 엔지니어링 웹사이트 링크를 보내 일반 사용자를 유인합니다. 평소 암호화폐와 블록체인 분야에 대한 지식이 없는 피해자들은 자신도 모르게 인페르노 드레이너 고객에게 접근 권한을 부여하게 됩니다.

인페르노 드레이너의 일반적인 공격 흐름은 다음과 같습니다.

Inferno Drainer의 운영 흐름 (출처: Group-IB)

순서도에서 볼 수 있듯이 Inferno Drainer는 주로 피해자의 자금을 빼내기 위해 피싱 소셜 엔지니어링 웹사이트를 구축하는 데 중점을 두고 있으며, 고객은 피해자에게 피싱 웹사이트를 전파하는 일을 담당합니다. 피해자가 사이트를 열고 거래에 서명하면 고객은 훔친 토큰의 80%를 가져가고 Inferno Drainer는 20%를 가져갑니다.

간단한 Approve&TransferFrom 방법 또는 Permit 방법을 사용한 매우 간단한 설정을 통해 Inferno Drainer는 온체인에서 8천만 달러 이상의 자산을 훔쳤습니다.

배수 방법

Inferno Drainer는 주로 고전적인 Approve & TransferFrom 방식이나 허가 방식을 사용했습니다. 활성 시간 동안 Approve&TransferFrom 중 하나를 살펴보겠습니다.

피해자 : 0xe142C1858b8447238F3953e685e62ED6005DcAaA

공격자 : 0xFC4EAA4ac84D00f1C5854113581F881b42b4A745

토큰: PEPE

손실 금액: 26,372,295.3 ($220)

Step1 : 피해자 서명 승인()

승인된 금액의 가치를 확인하세요.

2단계 : 공격자는 TransferFrom()을 수행합니다.

엔젤드레이너 및 공격방식 개선

인페르노 드레이너 서비스가 종료된 후, 더욱 발전된 새로운 형태의 드레이너 서비스가 나왔습니다. 주목할만한 배수구 중 하나는 Angel Drainer였습니다. Inferno 드레이너와 달리 Angel 드레이너는 고급 기술을 활용하여 스마트 계약 논리와 사용자 행동을 조작했습니다. 특정 방법은 행동 분석 및 속도 제한에 의해 트리거되는 보안 경고를 우회하는 데 중점을 둡니다. 이 기사에서는 Angel Drainer가 자금을 빼내는 데 사용되는 두 가지 주요 공격 방법을 살펴보겠습니다.

Angel Drainer가 제공하는 서비스 스크린샷. (출처: 체크포인트)

중첩된 스마트 계약 배포 메커니즘

Approve&TransferFrom 또는 Permit을 활용하는 다양한 피싱 사기로 ChainAlytic, BlockAid 및 Check Point와 같은 블록체인 보안 그룹도 체인에서 잠재적인 사기꾼을 식별할 수 있는 정교한 모니터링 알고리즘을 개발했습니다. 특히, 사기꾼 주소에 대한 Permit, Approve&TransferFrom 등의 거래는 식별이 매우 간단했습니다. 따라서 Angel Drainer는 멀티콜 기능을 수행하는 새로운 스마트 계약 생성을 통해 보안 경고를 우회하는 정교한 방법을 채택했습니다.

예

Angel Drainer가 어떻게 보안 경고를 우회했는지 이해하기 위해 활용된 스마트 계약을 조사하여 실제 공격 사례를 살펴보겠습니다. 뒤에 있는 거래를 살펴보겠습니다.

0xb60c32fb28aa6160df6f472f494f162b997aa49fb06776dce250aff80602a8a3

1단계 : 중첩된 스마트 계약 생성

Angel Drainer는 먼저 다음 기능을 사용하여 스마트 계약을 생성합니다.

아래 스크린샷에 표시된 것처럼 이 특정 트랜잭션에 대해 Angel Drainer는 먼저 0x095838d2() 활용하고 다음으로 0xf2fde38b() transferOwnership(address)을 호출합니다.

단순화를 위해 이 계약을 주 계약이라고 부르겠습니다. 기본 계약 내에서 0x095838d2() 함수에 집중해야 합니다. 함수의 논리는 다음과 같습니다.

세 가지 매개변수 (secondContractAddress, tokenContractAddress, arrayOf3Elements) 가 필요합니다.
secondContractAddress가 기존 계약인지 확인하세요. 주어진 주소의 코드 크기를 확인합니다. 0보다 크면 계약이 존재한다는 의미이고, 그렇지 않으면 그 반대입니다.
그렇다면 (Permit & TransferFrom)을 포함하는 Multicall 기능을 실행하십시오. 그렇지 않은 경우 해당 주소로 새 계약을 배포한 후 Muticall 기능을 실행하세요.

이 트랜잭션 사례의 경우 secondContractAddress는 Null이므로 먼저 새 스마트 계약을 생성하게 됩니다.

2단계 : 다중 호출 기능

주 계약이 두 번째 계약을 식별하거나 생성하면 두 번째 계약의 Multicall() 함수가 실행됩니다. 이러한 기능은 계약 상호 작용을 조정하기 위해 존재합니다. multicall() 함수의 주요 기능을 살펴보겠습니다.

위에서 강조한 것처럼 다중 호출은 트랜잭션 작업을 매개 변수로 받아들이고 v1[v3]에 지정된 주소에서 외부 계약을 만들어 각 매개 변수를 처리합니다. Multicall에 대한 자세한 내용은 아래의 실행 과정에서 확인할 수 있습니다.

위와 같이 muticall은 Permit과 transferFrom 2개의 총 3개의 트랜잭션을 처리했습니다. 허가 및 전송은 토큰 계약 Lido: stETH 에서 이루어집니다.

transferFrom의 값 차이를 확인하세요. 비율은 0.85:0.15입니다. 이는 Customer와 Angel Drainer의 이익 분배를 나타냅니다.

3단계 : 소유권 이전

사기꾼이 두 번째 계약에 대한 모든 권한을 갖기 위해서입니다. 0x095838d2() 의 마지막 단계에는 두 번째 계약에서 사기꾼의 주소로 TransferofOwnership을 실행하는 것이 포함됩니다.

새로운 계약을 생성하고 새로운 계약의 다중 호출 내에서 작업을 처리하여 보안 경고를 우회하기 위해 Angel Drainer가 사용하는 조작 방법을 살펴보았습니다. 새로운 컨트랙트는 거래 기록을 보유하지 않고, 다중 호출을 통해 거래를 모호하게 하며, 사기꾼의 주소로 직접 배포되지 않기 때문에 보안 경고를 우회할 수 있었습니다. 그러나 Check Point Research의 식별 덕분에 이제 Nested 스마트 계약 공격 방법을 식별할 수 있으며 더 이상 보안 경고를 우회하지 않습니다.

2. EigenLayer Retake Farming 공격

EigenLayer는 사용자가 토큰을 스마트 계약에 잠글 수 있는 "재스테이킹" 프로세스를 통해 블록체인 네트워크의 보안과 효율성을 향상시키도록 설계된 분산형 프로토콜입니다. 사용자는 처음에 일정 기간 동안 토큰을 스테이킹하고 보상을 받을 수 있으며 스테이킹을 취소하고 다시 스테이킹하는 대신 더 많은 토큰을 다시 스테이킹할 수도 있습니다. 이러한 프로세스를 통해 사용자는 여러 서비스와 상호 작용하고 더 많은 토큰을 스테이킹할 수 있으며, 이는 궁극적으로 체인의 보안과 유용성을 동시에 향상시킵니다.

공격 벡터 포인트

그러나 재스테이킹 메커니즘에는 취약점이 있었습니다. 주로 EigenLayer 프로토콜의 queueWithdrawal 메커니즘을 사용합니다. 공격이 어떻게 작동하는지 이해하려면 스테이킹 및 재스테이킹 프로세스가 어떻게 작동하는지 이해해야 합니다.

EigenLayer 프로토콜은 스테이킹 인출을 처리하기 위해 특별한 방법을 사용합니다.

사용자가 일정량의 토큰을 스테이킹한 후 나중에 스테이킹된 토큰을 출금하기로 결정한 경우 거래가 즉시 처리되지 않습니다. 대신 대기열에 저장됩니다. 사용자는 스테이크를 해제하려면 7일의 에스크로 기간을 기다려야 하며 이더리움에서는 검증인 스윕 후 4~5일마다 한 번씩 스테이크 자금의 부분 인출이 가능합니다. 이러한 승인 방법은 새로운 것이기 때문에 대부분의 보안 공급자나 내부 보안 도구는 이러한 승인 유형을 검증하지 않고 이를 무해한 거래로 표시했습니다. 따라서 Angel Drainer가 악용할 수 있는 취약점이 남아 있습니다.

예

체인: ETH

날짜: 2024년 1월 15일부터 2024년 1월 29일까지

공격자: 0x8031A648B169a9fa6f63954C0F0B106E57027696

1단계 : CREATE2 컨트랙트

보안 경고를 우회하여 프로세스를 모호하게 할 수 있었던 부분입니다. Angel Drainer는 매개변수 (salt, bytecode) 와 함께 CREATE2를 사용하여 계약을 준비합니다. 그런 다음 CREATE2는 특정 새 주소를 생성합니다. 새 주소는 보안 경고를 성공적으로 우회하여 보상을 수집하고 토큰을 언스테이크하는 데 사용됩니다.

2단계 : queueWithdrawal 시작

공격자는 Eigen 레이어에서 언스테이크를 시작하여 7일의 에스크로 기간을 시작합니다.

Step3 : 배수

일정 시간이 지나면 아래와 같이 토큰이 CREATE2 주소로 유출되어 공격에 성공하게 됩니다.

Blockaid 덕분에 이러한 공격이 식별되었으며 EigenLayer Protocol에도 통보되었습니다. 현재는 이전과 달리 이러한 공격을 탐지하기 위해 더 높은 보안 조치가 설정되어 있습니다.

암호화폐의 돈세탁

라자루스 그룹 및 로닌 브리지 공격

공격은 라자루스가 크로스체인 브리지에서 처형을 위해 개인 키 보유자 9명 중 5개를 획득하면서 시작되었습니다. 이는 Shamir Secret Key가 마련한 다중 서명 계정으로 인해 가능합니다. 체인에 접근한 후 세탁 프로세스를 시작합니다.

단계는 다음과 같습니다:

도난당한 Ether가 중개 지갑에 배포됨
Tornado Cash 활용 → 무작위 혼합 배치 프로토콜
ETH에서 BTC로
BTC를 혼합 및 배치
CEX에서 현금으로

그래프로 표현하면 아래와 같습니다.

Lazarus 그룹의 자금 흐름도(출처: ChainAlytic)

토네이도 현금으로 인해 이러한 활동을 탐지하는 것은 극히 어려웠습니다. 그러나 미국이 돈세탁 혐의로 Tornado Cash에 대한 통제권을 획득한 후 Lazarus 그룹은 De-Fi 프로토콜을 활용하는 다른 방법을 취했습니다.

자금이 여러 브리지를 통해 이동하므로 추적이 더 어려워집니다. (출처: ChainAlytic)

핵심 아이디어는 온체인 거래가 모든 사람에게 공개되고 추가 조사를 통해 거래가 감지될 수 있다는 것입니다. 그러나 혼합 및 배치 방식을 통해 거래가 분기되어 단일 지갑으로 통합됩니다. 이는 교묘한 사기꾼들의 추세일 것이며 앞으로도 그러할 것입니다.

세탁 및 피싱 방법은 진화할 것이며 사용자의 자금을 보호하기 위해서는 일치하는 탐지 방법이 필요합니다.

악성계정 탐지

기계 학습

모든 탐지 방법은 위에서 설명한 기본 사항을 기반으로 합니다. 그러나 인간이 수행하는 이러한 법의학 프로세스는 시간이 많이 걸리고 부정확합니다. 따라서 ChainAlytic과 같은 주요 회사는 이를 위해 기계 학습을 활용합니다. 정확한 기능 엔지니어링 및 방법은 ChainAlytic 또는 기타 보안 플랫폼에 포함되지 않았습니다. 그러나 본 논문에서는 다양한 연구와 문헌을 바탕으로 향후 개발 목적으로 추가 조사가 이루어져야 할 다음과 같은 방법을 제시하고 있다.

그래프 신경망 머신러닝

하위 그래프 Elliptic2 기계 학습

심층 신경망(특성 공학)

https://www.sciencedirect.com/science/article/abs/pii/S095741742201555X

결론

블록체인에 대한 피싱 공격은 업계의 성장과 함께 진화하여 보안 경고를 우회하는 정교한 방법을 통해 사용자를 표적으로 삼았습니다. 사용자는 스마트 계약을 확인하고, 승인 금액을 확인하고, 보안 경고에 주의하면서 경계해야 합니다. 분산형 금융 생태계에서 자산을 보호하려면 최신 정보를 유지하고 모범 사례를 채택하는 것이 필수적입니다.

사용자는 현재와 미래의 모든 형태의 공격으로부터 자신을 보호하기 위해 두 가지 황금률을 기억해야 합니다.

우리는 블록체인에서 피싱 공격이 어떻게 수행되는지, 그리고 사기꾼이 사용자의 계정과 자산을 손상시키기 위해 온체인 및 오프체인 인프라를 어떻게 공식화하는지 살펴보았습니다. 그러나 두 가지 황금률을 사용하면 모든 형태의 공격으로부터 자신을 보호할 수 있습니다.