최근 CertiK 보안 전문가 팀은 일반적으로 Rug Pull이라고 알려진 동일한 전술을 사용하는 여러 종료 사기를 자주 발견했습니다.
더 자세히 조사한 결과, 동일한 전술을 사용한 여러 사건이 동일한 갱단을 가리키며 궁극적으로 200개 이상의 토큰 이탈 사기와 연결되어 있음을 발견했습니다. 이는 출구 사기를 통해 자산을 수집하는 대규모 자동화 해킹 팀을 발견했을 수 있음을 나타냅니다.
이러한 출구 사기에서 공격자는 새로운 ERC 20 토큰을 생성하고 생성 시 사전 채굴된 토큰과 일정량의 WETH를 사용하여 Uniswap V2 유동성 풀을 생성합니다.
체인의 새로운 로봇이나 사용자가 일정 횟수 동안 유동성 풀에서 새로운 토큰을 구매하면 공격자는 허공에서 생성된 토큰을 사용하여 유동성 풀에 있는 모든 WETH를 소진합니다.
공격자가 허공에서 얻은 토큰은 전체 공급량(totalSupply)에 반영되지 않고 Transfer 이벤트도 발생하지 않기 때문에 Etherscan에서는 보이지 않으므로 외부 세계에서 인지하기 어렵습니다.
공격자들은 스텔스를 고려했을 뿐만 아니라, 기본적인 기술과 이더스캔 판독 능력으로 사용자를 마비시키는 게임 내 게임을 설계하고, 작은 문제를 이용해 그들의 진짜 목적을 은폐하는데…
사기에 깊이 빠져들다
이 출구 사기의 세부 사항을 설명하기 위해 사례 중 하나를 예로 들어 보겠습니다.
우리가 탐지한 것은 실제로 공격자가 유동성 풀을 빼내고 수익을 내기 위해 엄청난 양의 토큰(비밀 발행)을 사용한 거래였으며, 이 거래에서 프로젝트 당사자는 총 416, 483, 104, 164, 831(약 416조) MUMI가 약 9.736 WETH로 교환되어 풀의 유동성이 고갈되었습니다.
그러나 이번 거래는 전체 사기의 마지막 고리일 뿐이며 전체 사기를 이해하려면 계속해서 추적해야 합니다.
토큰 배포
3월 6일 오전 7시 52분(UTC 시간, 이하 동일), 공격자의 주소(0x8 AF 8) Rug Pull에 MUMI(풀네임 MultiMixer AI)(주소는 0x4894)라는 ERC 20 토큰을 배포하였고, 420, 690,000(약 4억 2천만)개의 토큰이 사전 채굴되어 모두 계약 배포자에게 배포되었습니다.
사전 채굴된 토큰의 수는 계약 소스 코드에 해당합니다.
유동성 추가
오전 8시(토큰 생성 후 8분)에 공격자 주소(0x8 AF 8)에 유동성이 추가되기 시작했습니다.
공격자의 주소(0x8 AF 8)는 토큰 계약에서 openTrading 기능을 호출하고 uniswap v2 공장을 통해 MUMI-WETH 유동성 풀을 생성하고 사전 채굴된 모든 토큰과 3 ETH를 유동성 풀에 추가하고 최종적으로 약 1.036 LP를 획득합니다. 토큰.
거래 내역을 보면 원래 유동성 추가에 사용된 420,690,000개(약 4억 2천만개)의 토큰 중 약 63,103,500개(약 6300만개)의 토큰이 토큰 계약(주소 0x4894)으로 다시 전송되었음을 계약서를 보면 확인할 수 있습니다. 소스 코드를 통해 우리는 토큰 계약이 각 전송에 대해 특정 처리 수수료를 부과하고 처리 수수료를 청구하는 주소가 토큰 계약 자체라는 것을 발견했습니다(구체적으로 _transfer 함수에서 구현됨).
이상한 점은 세금 주소 0x7ffb(이체 수수료 징수 주소)가 컨트랙트에 설정되어 있지만 최종 수수료는 토큰 컨트랙트 자체로 전송되었다는 점입니다.
따라서 유동성 풀에 추가된 MUMI 토큰의 최종 수량은 420,690,000(약 4억 3천만)이 아닌 세금 면제로 357,586,500(약 3억 5천만)이 되었습니다.
유동성 확보
8시 1분(유동성 풀 생성 후 1분)에 공격자 주소(0x8 AF 8)에 유동성 추가로 얻은 1.036 LP 토큰이 모두 락업되었습니다.
LP가 락업된 후 이론적으로 공격자 주소(0x8 AF 8)가 소유한 모든 MUMI 토큰은 유동성 풀에 락(처리 수수료로 사용되는 부분 제외)되므로 공격자의 주소(0x8 AF8)에도 유동성을 제거하여 Rug Pull을 수행할 수 없습니다. 사용자가 새로 출시된 토큰을 안심하고 구매할 수 있도록 많은 프로젝트 당사자가 LP를 잠그는데, 이는 프로젝트 당사자가 나는 도망치지 않을 것입니다. 모두가 안심하고 구매할 수 있습니다!라고 말하는 것을 의미합니다. 그러나 이것이 실제로 사실입니까? ? 분명히 그렇지 않습니다. 이것이 사실입니다. 분석을 계속하겠습니다.
Rug Pull
8시 10분에 새로운 공격자 주소 ②(0x9 DF 4)가 나타났고, Ta는 토큰 계약에 선언된 세금 주소 0x7ffb를 배포했습니다.
여기서 언급할 가치가 있는 세 가지 사항이 있습니다.
1. 세금 주소가 배포된 주소와 토큰이 배포된 주소가 동일하지 않은 경우 이는 프로젝트 당사자가 의도적으로 각 작업과 주소 간의 상관 관계를 줄여 행위 추적을 더욱 어렵게 만들고 있음을 나타낼 수 있습니다.
2. 세금 주소의 계약은 오픈 소스가 아닙니다. 이는 노출을 원하지 않는 세금 주소에 숨겨진 작업이 있을 수 있음을 의미합니다.
3. 세금 계약은 토큰 계약보다 늦게 배포되며, 토큰 계약의 세금 주소가 하드 코딩되어 있어 프로젝트 당사자가 세금 계약의 주소를 예측할 수 있습니다.CREATE 명령어가 생성자 주소를 결정하므로 그리고 nonce, 배포 계약 주소가 결정되므로 프로젝트 팀은 작성자의 주소를 사용하여 계약 주소를 미리 시뮬레이션했습니다.
실제로 많은 출구 사기가 세금 주소를 통해 이루어지며, 세금 주소의 배포 모드 특성은 위의 1번과 2번 항목을 준수합니다.
오전 11시(토큰 생성 후 3시간)에 공격자 주소 ②(0x9 DF 4)에서 Rug Pull을 수행하였다. 세금 계약(0x 77 fb)의 swapExactETHForTokens 메소드를 호출하여 세금 주소에서 416, 483, 104, 164, 831(약 416조)개의 MUMI 토큰을 약 9.736 ETH에 교환하고 소비했습니다. 수영장.
세금 계약서(0x 77 fb)는 오픈소스가 아니기 때문에 바이트코드를 디컴파일했고 디컴파일 결과는 다음과 같습니다: https://app.dedaub.com/decompile?md5=01e2888c7691219bb7ea8c6b6befe11c 세금 계약서(0x 77 fb ) swapExactETHForTokens 메소드의 코드를 디컴파일한 후, 이 함수의 주요 기능은 세금 계약(0x 77 fb)이 소유한 MUMI 토큰을 xt(호출자가 지정) 금액으로 교환하는 것임을 확인했습니다. uniswap V2 라우터를 ETH로 변환하여 세금 주소에 명시된 _manualSwap 주소로 전송합니다.
_manualSwap 주소가 위치한 저장소 주소는 0x0입니다. json-rpc의 getStorageAt 명령으로 쿼리한 결과 _manualSwap에 해당하는 주소가 정확히 세금 계약의 배포자(0x 77 fb)임을 확인했습니다. 공격자 ②(0x 9DF 4).
이 RugPull 트랜잭션의 입력 매개변수 xt는 420, 690, 000, 000, 000, 000, 000, 000이며, 이는 420, 690, 000, 000, 000(약 420조) MUMI 토큰에 해당합니다(MUMI 토큰 십진수는 9입니다). .
즉, 프로젝트는 결국 420, 690, 000, 000, 000(약 420조) MUMI를 사용하여 유동성 풀의 WETH를 빼내고 전체 출구 사기를 완료했습니다.
그러나 여기서 중요한 질문이 있습니다. 세금 계약(0x 77 fb)이 수많은 MUMI 토큰에서 어디서 나온 것입니까?
이전 내용을 통해 토큰 계약 배포 당시 MUMI 토큰의 총 공급량이 420, 690,000(약 4억 2천만)임을 알고 있으며, 출구 사기가 끝난 후 MUMI 토큰 계약에서 쿼리합니다. 총 공급량은 여전히 420, 690, 000입니다(아래 그림에서 420, 690, 000, 000, 000, 000으로 표시되며 소수점에 해당하는 0을 빼야 하며 소수점은 9입니다), 세금 계약( 0x 77 fb)는 마치 허공에서 나타난 것처럼 토큰의 총 공급량(420, 690, 000, 000, 000, 약 420조)을 훨씬 초과합니다. 위에서 언급한 것처럼 0x 77 fb가 세금으로 부과된다는 점을 아셔야 합니다. MUMI 토큰 전송 시 발생하는 수수료는 세금을 받는 데 사용되지 않으며, 토큰 계약을 통해 세금을 받습니다.
공개된 기술
세금 계약은 어디에서 왔습니까?
세금 계약(0x 7 ffb)의 토큰 출처를 탐색하기 위해 ERC 20 전송 이벤트 내역을 살펴보았습니다.
0x 77 fb와 관련된 6개의 전송 이벤트 중 세금 계약(0x 7 ffb)에서 발생한 전송 이벤트만 있었고 MUMI 토큰의 전송 이벤트는 없는 것으로 나타났습니다. 7 ffb) ) 토큰은 실제로 허공에서 나타났습니다.
따라서 세금 계약(0x 7 ffb) 주소에 갑자기 나타난 거대한 MUMI 토큰에는 두 가지 특성이 있습니다.
1. MUMI 계약의 총 공급량에는 영향을 미치지 않습니다.
2. 토큰 증가로 인해 전송 이벤트가 발생하지 않습니다.
그렇다면 아이디어는 매우 명확합니다. 즉, MUMI 토큰 계약에 백도어가 있어야 합니다. 이 백도어는 잔액 변수를 직접 수정하며 balabce 수정 시 totalSupply를 수정하지 않으며 Transfer 이벤트도 트리거하지 않습니다.
즉, 이는 ERC 20 토큰의 비표준 또는 악의적 구현이며, 사용자는 전체 공급량 및 이벤트의 변경으로 인해 프로젝트 측이 비밀리에 토큰을 발행하고 있음을 감지할 수 없습니다.
다음 단계는 위의 아이디어를 검증하는 것으로, MUMI 토큰 컨트랙트 소스 코드에서 balance라는 키워드를 직접 검색합니다.
그 결과 컨트랙트에 private 형태의 swapTokensForEth 함수가 있고, 입력파라미터는 uint 256 형태의 tokenAmount라는 것을 알아냈고, 함수의 5번째 줄에서 프로젝트 당사자가 세금인 _taxWallet을 직접 변경하는 것을 확인했습니다. contract (0x 7 ffb) MUMI 잔고는 tokenAmount * 10**_decimals로 수정되며, 이는 tokenAmount의 1, 000, 000, 000(약 10억)배이며, MUMI의 tokenAmount 금액은 ETH로 변환됩니다. 유동성 풀이며 토큰 계약(0x4894)에 저장됩니다.
그런 다음 swapTokenForEth라는 키워드를 검색하세요.
swapTokenForEth 함수는 _transfer 함수에서 호출됩니다. 호출 조건을 자세히 살펴보면 다음을 찾을 수 있습니다.
1. 이체수신 주소가 MUMI-WETH 유동성 풀인 경우.
2. 다른 주소가 유동성 풀에서 MUMI 토큰을 _preventSwapBefore(5회) 이상 구매하면 swapTokenForEth 함수가 호출됩니다.
3. 들어오는 tokenAmount는 토큰 주소가 소유한 MUMI 토큰 잔액과 _maxTaxSwap 중 더 작은 값입니다.
즉, 사용자가 풀에서 WETH를 MUMI 토큰으로 5회 이상 교환한 사실이 계약에 의해 감지되면 세금 주소를 위해 비밀리에 엄청난 양의 토큰을 발행하고 토큰 중 일부를 ETH로 변환하여 저장합니다. 토큰 계약에 포함됩니다.
한편, 프로젝트 당사자는 표면적으로 세금을 징수하고 이를 정기적으로 소액의 ETH로 자동 교환하여 토큰 계약에 넣는 방식으로 이를 사용자에게 보여주며 이것이 모두가 이것이 프로젝트 당사자의 이익의 원천이라고 생각하게 만듭니다.
반면, 프로젝트팀이 실제로 하고 있는 일은 사용자의 거래 횟수가 5회에 도달한 후 계정 잔액을 직접 수정하고 유동성 풀을 모두 빼내는 것입니다.
수익을 창출하는 방법
swapTokenForEth 함수를 실행한 후 _transfer 함수는 sendETHToFee도 실행하여 토큰 주소의 세금 징수에서 얻은 ETH를 세금 계약(0x 77 fb)으로 보냅니다.
세금 계약(0x 77 fb)의 ETH는 해당 계약에 구현된 구조 기능을 통해 인출될 수 있습니다.
이제 전체 출구 사기 중 마지막 수익 거래의 환매 기록을 다시 살펴보겠습니다.
수익성 있는 거래에서 총 2번의 교환이 이루어졌으며 첫 번째 교환은 0.349 ETH에 대해 4,164,831(약 416만) MUMI 토큰이었고, 두 번째 교환은 416,483,100,000,000(약 416만)십억) MUMI였습니다. 9.368 ETH에 대한 토큰. 두 번째 교환은 세금 계약(0x 7 ffb)의 swapExactETHForTokens 함수 내에서 시작된 교환이며, 그 수는 입력 매개변수로 표시되는 420, 690, 000, 000, 000(약 420조) 토큰과 동일합니다. 불일치가 발생하는 이유는 아래 그림과 같이 일부 토큰이 세금으로 토큰 컨트랙트(0x4894)에 전송되기 때문입니다.
첫 번째 교환은 두 번째 교환 과정에 해당하며 세금 계약(0x 7 ffb)에서 라우터 계약으로 토큰이 전송되면 토큰 계약의 백도어 기능의 트리거 조건이 충족되어 교환이 시작됩니다. swapTokensForEth 기능은 중요한 작업이 아닙니다.
뒤에 있는 낫
위에서 볼 수 있듯이 배포부터 유동성 풀 생성, MUMI 토큰의 Rug Pull까지 전체 출구 사기 주기는 약 3시간밖에 걸리지 않지만 비용은 약 6.5 ETH(추가할 경우 3 ETH) 미만입니다. 유동성 풀에서 MUMI를 유도용으로 교환하는 데 3 ETH가 사용되었으며, 계약 배포 및 거래 시작에 0.5 ETH 미만이 사용되어 50% 이상의 이익으로 9.7 ETH를 얻었습니다.
공격자가 이전 글에서 언급하지 않은 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 토큰으로 교환하는 의심스러운 행위인지, 공격자가 의도하는 바는 무엇인지 알 수 있습니다. 체인에 있는 다양한 새로운 로봇의 사기 방지 절차를 통해 위장합니다.
자본 흐름을 추적한 결과, 공격으로 인한 모든 수익금은 최종적으로 공격 주소 ②(0x 9 dF 4)를 통해 주소 자금 정산 주소(0x DF 1 a)로 전송된 것으로 나타났습니다.
실제로 최근 적발한 다수의 이탈 사기에 대한 초기 자금 출처와 최종 자금 목적지가 이 주소로 지정되어 있어 이 주소에서의 거래에 대한 대략적인 분석과 통계를 실시했습니다.
해당 주소는 약 2개월 전에 활성화되었으며 현재까지 7,000건 이상의 거래가 시작되었으며 200개 이상의 토큰과 상호작용한 것으로 확인되었습니다.
우리는 약 40여 개의 토큰 거래 기록을 분석한 결과, 우리가 살펴본 거의 모든 토큰에 해당하는 유동성 풀에서 결국 토큰의 총 공급량보다 훨씬 많은 투입량의 교환 거래가 발생한다는 사실을 발견했습니다. ETH 입력이 고갈되고 전체 출구 사기 기간이 더 짧아집니다.
일부 토큰(Mingyan China)의 배포 트랜잭션은 다음과 같습니다.https://etherscan.io/tx/0x324d7c133f079a2318c892ee49a2bcf1cbe9b20a2f5a1f36948641a902a83e17
https://etherscan.io/tx/0x 0 ca 86151 3d c 68 eaef 3017 e 7118 e 7538 d 999 f 9 b 4 a 53 e 1 b 477 f 1 f 1 ce 07 d 98 2d c 3 f
따라서 이 주소는 실제로는 대규모 자동화된 탈출 사기 수확기이며, 수확 대상은 체인의 새로운 로봇이라는 결론을 내릴 수 있습니다.
이 주소는 아직 활성 상태입니다.
마지막에 쓰세요
토큰이 발행될 때 totalSupply를 수정하지 않고 Transfer 이벤트를 트리거하지 않으면 프로젝트 측에서 비밀리에 토큰을 발행하고 있는지 여부를 감지하기 어렵고, 이는 또한 토큰이 안전한지 여부에 대한 문제를 더욱 악화시킵니다. 전적으로 프로젝트 측에 달려 있습니다. 의식이 있든 없든 현상 유지.
따라서 토큰 수량 변경의 개방성과 투명성을 보장하기 위해 기존 토큰 메커니즘을 개선하거나 효과적인 토큰 총량 감지 솔루션을 도입하는 것을 고려해야 할 수도 있지만 현재 이벤트로 토큰 상태 변경을 캡처하는 것만으로는 충분하지 않습니다.
그리고 우리가 경계해야 할 것은 모든 사람의 사기 방지 인식이 향상되고 있지만 공격자의 사기 방지 방법도 향상되고 있다는 것입니다. 이것은 끝없는 게임입니다. 이것을 할 수 있으려면 계속 학습하고 생각해야 합니다. .게임에서 자신을 보호하세요.
이 글에 사용된 도구
기본 거래 정보 보기:https://etherscan.io/
