Web3 보안 경고丨 체인 상에서의 신규 투자 중의 중간 함정, 대규모 러그풀 수법 해독

저자: CertiK

최근 CertiK 보안 전문가 팀은 동일한 수법의 "탈출 사기"를 자주 감지했습니다, 즉 우리가 일반적으로 부르는 Rug Pull입니다.

우리가 심층적으로 조사한 결과, 여러 건의 동일한 수법 사건이 동일한 범죄 집단을 가리키며, 결국 200개 이상의 토큰 탈출 사기로 연결되었습니다. 이는 우리가 대규모 자동화된 자산 수확을 위한 해커 팀을 발견했을 가능성을 시사합니다.

이러한 탈출 사기에서 공격자는 새로운 ERC20 토큰을 생성하고, 생성 시 미리 채굴한 토큰과 일정량의 WETH를 사용하여 Uniswap V2의 유동성 풀을 생성합니다.

체인상의 신규 구매 로봇이나 사용자가 해당 유동성 풀에서 일정 횟수의 신규 토큰을 구매하면, 공격자는 허공에서 생성된 토큰을 통해 유동성 풀의 WETH를 모두 소진합니다.

공격자가 허공에서 획득한 토큰은 총 공급량(totalSupply)에 반영되지 않으며(Transfer 이벤트를 발생시키지 않음), etherscan에서는 볼 수 없기 때문에 외부에서 인지하기 어렵습니다.

공격자는 은폐성뿐만 아니라, 초급 기술 능력을 가진 사용자가 etherscan을 보는 것을 마비시키기 위해 작은 문제를 사용하여 그들의 진정한 목적을 감추는 복잡한 구조를 설계했습니다…

심층 사기

우리는 그 중 하나의 사례를 예로 들어 탈출 사기의 세부 사항을 자세히 설명하겠습니다.

우리가 감지한 것은 실제로 공격자가 대량의 토큰(몰래 mint한)을 사용하여 유동성 풀을 소진하고 이익을 얻은 거래입니다. 이 거래에서 프로젝트 측은 총 416,483,104,164,831(약 416조) 개의 MUMI를 교환하여 약 9.736개의 WETH를 얻었고, 풀의 유동성을 소진했습니다.

그러나 이 거래는 전체 사기의 마지막 단계일 뿐이며, 전체 사기를 이해하려면 계속해서 거슬러 올라가야 합니다.

토큰 배포

3월 6일 오전 7시 52분(UTC 시간, 이하 동일), 공격자 주소(0x8AF8)는 Rug Pull을 통해 MUMI(전체 이름은 MultiMixer AI)라는 ERC20 토큰(주소: 0x4894)을 배포하고, 420,690,000(약 4.2억) 개의 토큰을 미리 채굴하여 계약 배포자에게 모두 할당했습니다.

미리 채굴한 토큰 수량은 계약 소스 코드와 일치합니다.

유동성 추가

8시 정각(토큰 생성 8분 후), 공격자 주소(0x8AF8)는 유동성을 추가하기 시작했습니다.

공격자 주소(0x8AF8)는 토큰 계약의 openTrading 함수를 호출하여 uniswap v2 factory를 통해 MUMI-WETH 유동성 풀을 생성하고, 미리 채굴한 모든 토큰과 3개의 ETH를 유동성 풀에 추가하여 약 1.036개의 LP 토큰을 얻었습니다.

거래 세부 사항에서 볼 수 있듯이, 유동성 추가에 사용된 420,690,000(약 4.2억) 개의 토큰 중 63,103,500(약 6300만) 개의 토큰이 다시 토큰 계약(주소: 0x4894)으로 전송되었습니다. 계약 소스 코드를 확인해보면, 토큰 계약은 각 전송에 대해 일정 수수료를 부과하며, 수수료를 받는 주소는 바로 토큰 계약 자체입니다(구체적인 구현은 "_transfer 함수 내"에 있습니다).

이상한 점은, 계약에서 이미 세금 주소 0x7ffb(전송 수수료를 받는 주소)가 설정되어 있는데, 최종적으로 수수료가 토큰 계약 자체로 발송되었다는 것입니다.

따라서 최종적으로 유동성 풀에 추가된 MUMI 토큰 수량은 세금이 공제된 357,586,500(약 3.5억) 개가 되었고, 420,690,000(약 4.3억) 개가 아닙니다.

유동성 잠금

8시 1분(유동성 풀이 생성된 지 1분 후), 공격자 주소(0x8AF8)는 유동성을 추가하여 얻은 모든 1.036개의 LP 토큰을 잠갔습니다.

LP가 잠긴 후, 이론적으로 공격자 주소(0x8AF8)가 소유한 모든 MUMI 토큰은 유동성 풀 내에 잠겨 있게 됩니다(수수료로 사용된 부분을 제외하고), 따라서 공격자 주소(0x8AF8)는 유동성을 제거하여 Rug Pull을 수행할 수 있는 능력이 없습니다.

사용자가 새로 출시된 토큰을 안심하고 구매할 수 있도록 하기 위해, 많은 프로젝트 측은 LP를 잠그는 경우가 많습니다. 이는 프로젝트 측이 "나는 도망치지 않을 것입니다, 여러분은 안심하고 구매하세요!"라고 말하는 것과 같습니다. 그러나 사실은 그렇지 않습니다. 이 사례가 바로 그러하며, 계속 분석해 보겠습니다.

Rug Pull

8시 10분, 새로운 공격자 주소②(0x9DF4)가 등장했습니다. 그는 세금 주소 0x7ffb를 배포했습니다.

여기서 주목할 만한 세 가지 점이 있습니다:

1. 세금 주소를 배포한 주소와 토큰을 배포한 주소가 동일하지 않다는 점은 프로젝트 측이 각 작업 간의 주소 연관성을 줄이고 행동 추적의 난이도를 높이려는 의도를 나타낼 수 있습니다.

2. 세금 주소의 계약은 오픈 소스가 아니므로, 세금 주소에 숨겨진 노출하고 싶지 않은 작업이 있을 수 있습니다.

3. 세금 계약은 토큰 계약보다 늦게 배포되었으며, 토큰 계약 내에서 세금 주소가 이미 고정되어 있다는 것은 프로젝트 측이 세금 계약의 주소를 미리 알 수 있다는 것을 의미합니다. CREATE 명령이 생성자 주소와 nonce가 결정된 경우, 배포된 계약 주소는 확정적이므로, 프로젝트 측은 미리 생성자 주소를 사용하여 계약 주소를 시뮬레이션하여 계산했습니다.

실제로 많은 탈출 사기가 세금 주소를 통해 이루어지며, 세금 주소의 배포 방식 특성이 위의 1, 2점을 충족합니다.

오전 11시(토큰 생성 3시간 후), 공격자 주소②(0x9DF4)는 Rug Pull을 수행했습니다. 그는 세금 계약(0x77fb)의 "swapExactETHForTokens" 메서드를 호출하여 세금 주소에서 416,483,104,164,831(약 416조) 개의 MUMI 토큰을 교환하여 약 9.736개의 ETH를 얻고, 풀의 유동성을 소진했습니다.

세금 계약(0x77fb)은 오픈 소스가 아니므로, 우리는 그 바이트 코드를 역컴파일했습니다. 역컴파일 결과는 다음과 같습니다:

https://app.dedaub.com/decompile?md5=01e2888c7691219bb7ea8c6b6befe11c

세금 계약(0x77fb)의 "swapExactETHForTokens" 메서드의 역컴파일 코드를 확인한 결과, 실제로 해당 함수의 주요 기능은 uniswapV2 라우터를 통해 세금 계약(0x77fb)이 보유한 MUMI 토큰을 ETH로 교환하고, 세금 주소에 선언된 "_manualSwap" 주소로 전송하는 것입니다.

_manualSwap 주소의 storage 주소는 0x0이며, json-rpc의 getStorageAt 명령어로 조회한 결과 _manualSwap에 해당하는 주소는 세금 계약(0x77fb)의 배포자: 공격자②(0x9DF4)임을 확인했습니다.

이 Rug Pull 거래의 입력 매개변수 xt는 420,690,000,000,000,000,000,000으로, 이는 420,690,000,000,000(약 420조) 개의 MUMI 토큰에 해당합니다(MUMI 토큰의 decimal은 9입니다).

즉, 최종적으로 프로젝트 측은 420,690,000,000,000(약 420조) 개의 MUMI를 사용하여 유동성 풀의 WETH를 소진하고, 전체 탈출 사기를 완료했습니다.

그러나 여기서 중요한 질문이 있습니다. 세금 계약(0x77fb)은 어디서 그렇게 많은 MUMI 토큰을 얻었을까요?

앞서의 내용에서 우리는 MUMI 토큰이 배포될 때의 총 공급량이 420,690,000(약 4.2억)이라는 것을 알았습니다. 그러나 탈출 사기가 끝난 후, MUMI 토큰 계약에서 조회한 총 공급량은 여전히 420,690,000(아래 그림에서 420,690,000,000,000,000으로 표시되며, decimal에 해당하는 0을 빼야 함, decimal은 9)입니다. 세금 계약(0x77fb) 내의 총 공급량을 초과하는 토큰(420,690,000,000,000, 약 420조)은 마치 허공에서 나타난 것처럼 보입니다. 세금 주소인 0x77fb는 심지어 MUMI 토큰 전송 과정에서 발생한 수수료를 받기 위해 사용되지 않았습니다. 수수료는 토큰 계약이 받았습니다.

수법 해명

• 세금 계약의 토큰 출처

세금 계약(0x7ffb)의 토큰 출처를 조사하기 위해, 우리는 ERC20 전송 이벤트 기록을 확인했습니다.

결과적으로 0x77fb에 대한 총 6건의 전송 이벤트 중, 세금 계약(0x7ffb)에서 전송된 사건만 발견되었고, MUMI 토큰이 전송된 사건은 없었습니다. 얼핏 보기에는 세금 계약(0x7ffb)의 토큰이 정말 허공에서 나타난 것처럼 보입니다.

따라서 세금 계약(0x7ffb) 주소에 허공에서 나타난 대량의 MUMI 토큰에는 두 가지 특징이 있습니다:

1. MUMI 계약의 totalSupply에 영향을 미치지 않음

2. 토큰의 증가는 Transfer 이벤트를 발생시키지 않음

그러므로 생각이 명확해집니다. 즉, MUMI 토큰 계약 내에는 반드시 백도어가 존재하며, 이 백도어는 balance 변수를 직접 수정하고, balance를 수정하는 동시에 totalSupply를 수정하지 않으며, Transfer 이벤트를 발생시키지 않습니다.

즉, 이는 비표준적이거나 악의적인 ERC20 토큰 구현으로, 사용자는 총 공급량의 변화와 이벤트를 통해 프로젝트 측이 몰래 토큰을 mint하고 있는지 인지할 수 없습니다.

그 다음은 위의 생각을 검증하는 것입니다. 우리는 MUMI 토큰 계약 소스 코드에서 "balance"라는 키워드를 직접 검색했습니다.

결과적으로 계약 내에는 private 유형의 "swapTokensForEth" 함수가 있으며, 매개변수로 uint256 유형의 tokenAmount를 받습니다. 해당 함수의 5번째 줄에서 프로젝트 측은 직접 taxWallet, 즉 세금 계약(0x7ffb)의 MUMI 잔액을 tokenAmount * 10**decimals로 수정하고, 이후 유동성 풀에서 tokenAmount 수량의 MUMI를 ETH로 교환하여 토큰 계약(0x4894)에 저장합니다.

그 다음 "swapTokenForEth"라는 키워드를 검색합니다.

"swapTokenForEth" 함수는 "_transfer" 함수 내에서 호출되며, 호출 조건을 자세히 살펴보면:

1. 전송받는 주소 to가 MUMI-WETH 유동성 풀일 때

2. 다른 주소가 유동성 풀에서 MUMI 토큰을 구매한 횟수가 _preventSwapBefore(5회)를 초과할 때, "swapTokenForEth" 함수가 호출됩니다.

3. 전달된 tokenAmount는 토큰 주소가 보유한 MUMI 토큰 잔액과 _maxTaxSwap 중 작은 값입니다.

즉, 계약이 사용자가 풀에서 WETH로 MUMI 토큰을 교환하는 횟수가 5회를 초과하면, 세금 주소를 위해 몰래 대량의 토큰을 mint하고, 일부 토큰을 ETH로 교환하여 토큰 계약에 저장합니다.

한편, 프로젝트 측은 표면적으로 세금을 부과하고 정기적으로 소량의 ETH를 토큰 계약으로 교환하는 행위를 하여 사용자에게 보여주며, 이것이 프로젝트 측의 이익 출처라고 생각하게 만듭니다.

다른 한편으로, 프로젝트 측이 실제로 하는 것은 사용자의 거래 횟수가 5회에 도달하면, 직접 계좌 잔액을 수정하여 유동성 풀을 모두 소진하는 것입니다.

• 어떻게 이익을 얻는가

"swapTokenForEth" 함수를 실행한 후, "_transfer" 함수는 sendETHToFee를 실행하여 토큰 주소에서 세금으로 얻은 ETH를 세금 계약(0x77fb)으로 전송합니다.

세금 계약(0x77fb) 내의 ETH는 계약 내 구현된 "rescue" 함수를 통해 인출할 수 있습니다.

이제 탈출 사기에서 마지막으로 이익을 얻은 거래의 교환 기록을 다시 살펴보겠습니다.

이익 거래에서는 두 번의 교환이 이루어졌습니다. 첫 번째는 4,164,831(약 416만) 개의 MUMI 토큰을 0.349개의 ETH로 교환한 것이고, 두 번째는 416,483,100,000,000(약 416조) 개의 MUMI 토큰을 9.368개의 ETH로 교환한 것입니다. 두 번째 교환은 세금 계약(0x7ffb) 내의 "swapExactETHForTokens" 함수에서 시작된 교환으로, 수량이 입력 매개변수로 나타낸 420,690,000,000,000(약 420조) 개의 토큰과 일치하지 않는 이유는 일부 토큰이 세금으로 토큰 계약(0x4894)으로 전송되었기 때문입니다. 아래 그림과 같이:

첫 번째 교환은 두 번째 교환 과정에서 세금 계약(0x7ffb)에서 라우터 계약으로 토큰이 전송될 때, 토큰 계약 내의 백도어 함수의 트리거 조건을 충족하여 발생한 교환으로, 주요 작업이 아닙니다.

• 뒤에 있는 큰 낫

위의 내용을 보면, MUMI 토큰은 배포부터 유동성 풀 생성, Rug Pull까지 약 3시간 만에 진행되었지만, 약 6.5개의 ETH 비용(3 ETH는 유동성 추가에 사용되고, 3 ETH는 유동성 풀에서 MUMI를 교환하는 데 사용되며, 0.5 ETH 미만은 계약 배포 및 거래 시작에 사용됨)으로 9.7개의 ETH를 얻어 이익이 50%를 초과했습니다.

공격자가 ETH를 MUMI로 교환한 거래는 5건이 있으며, 앞서 언급하지 않았습니다. 거래 정보는 다음과 같습니다:

• https://etherscan.io/tx/0x62a59ba219e9b2b6ac14a1c35cb99a5683538379235a68b3a607182d7c814817
• https://etherscan.io/tx/0x0c9af78f983aba6fef85bf2ecccd6cd68a5a5d4e5ef3a4b1e94fb10898fa597e
• https://etherscan.io/tx/0xc0a048e993409d0d68450db6ff3fdc1f13474314c49b734bac3f1b3e0ef39525
• https://etherscan.io/tx/0x9874c19cedafec351939a570ef392140c46a7f7da89b8d125cabc14dc54e7306
• https://etherscan.io/tx/0x9ee3928dc782e54eb99f907fcdddc9fe6232b969a080bc79caa53ca143736f75

유동성에서 작업을 수행하는 eoa 주소를 분석한 결과, 상당수의 주소가 체인상의 "신규 구매 로봇"으로 확인되었습니다. 전체 사기의 빠른 진행 특성을 고려할 때, 우리는 이 전체 사기가 체인상에서 매우 활발한 다양한 신규 구매 로봇과 신규 구매 스크립트를 대상으로 하고 있다고 믿을 이유가 있습니다.

따라서 토큰의 복잡한 계약 설계, 계약 배포, 유동성 잠금 과정이 불필요해 보이더라도, 공격자가 ETH를 MUMI 토큰으로 교환하는 의문스러운 행동은 공격자가 체인상의 다양한 신규 구매 로봇의 반사기 프로그램을 속이기 위해 시도한 위장으로 이해될 수 있습니다.

우리는 자금 흐름을 추적한 결과, 공격자가 얻은 수익이 최종적으로 공격자 주소②(0x9dF4)에서 자금 침전 주소 (0xDF1a)로 전송되었음을 발견했습니다.

실제로 최근 감지된 여러 탈출 사기의 초기 자금 출처와 최종 자금 흐름이 모두 이 주소를 가리키고 있으며, 우리는 이 주소의 거래를 대략 분석하고 통계했습니다.

결국 이 주소는 약 2개월 전부터 활동을 시작하여, 오늘까지 7,000건 이상의 거래를 시작했습니다. 또한 이 주소는 200개 이상의 토큰과 상호작용했습니다.

우리는 그 중 약 40개의 토큰 거래 기록을 분석한 결과, 우리가 확인한 거의 모든 토큰에 해당하는 유동성 풀에서 마지막에 총 공급량을 초과하는 수량의 교환 거래가 발생하여 유동성 풀의 ETH가 소진되었고, 전체 탈출 사기 주기가 짧았습니다.

일부 토큰(명연중화)의 배포 거래는 다음과 같습니다:

https://etherscan.io/tx/0x324d7c133f079a2318c892ee49a2bcf1cbe9b20a2f5a1f36948641a902a83e17

https://etherscan.io/tx/0x0ca861513dc68eaef3017e7118e7538d999f9b4a53e1b477f1f1ce07d982dc3f

따라서 우리는 이 주소가 실제로 대규모 자동화된 "탈출 사기" 수확기이며, 수확의 대상은 체인상의 신규 구매 로봇이라는 것을 확인할 수 있습니다.

이 주소는 현재도 활발히 활동 중입니다.

마지막으로

만약 어떤 토큰이 mint할 때 totalSupply를 수정하지 않고, Transfer 이벤트를 발생시키지 않는다면, 우리는 프로젝트 측이 몰래 토큰을 mint하고 있는지 인지하기 어렵습니다. 이는 "토큰이 안전한지 여부는 전적으로 프로젝트 측의 자발성에 의존한다"는 현상을 더욱 심화시킬 것입니다.

따라서 우리는 기존의 토큰 메커니즘을 개선하거나 효과적인 토큰 총량 감지 방안을 도입하여 토큰 수량 변동의 공개성과 투명성을 보장해야 할 필요성이 있습니다. 현재 event를 통해 토큰 상태 변화를 포착하는 것은 충분하지 않습니다.

그리고 우리는 경각심을 가져야 합니다. 현재 모두의 사기 방지 인식이 높아지고 있지만, 공격자의 반사기 방지 수단도 향상되고 있습니다. 이는 끊임없는 게임이며, 우리는 지속적으로 학습하고 생각해야만 이러한 게임에서 자신을 보호할 수 있습니다.