Abuso de `CREATE2` no Ethereum permite aprovações contra contratos ainda não implantados

Técnica explora endereços determinísticos de contratos inteligentes para contornar validações baseadas em histórico e drenar carteiras após aprovação de allowance pelo usuário.

Componente	Opcode CREATE2 do Ethereum, usado para implantar contratos inteligentes em endereços determinísticos antes de o contrato existir na blockchain.
Vetor	O operador induz a vítima a aprovar ou aumentar a allowance de um contrato ainda não implantado; depois implanta o contrato no endereço previsto e usa a autorização já concedida.
Impacto	A técnica pode permitir transferência de fundos de uma carteira quando a vítima aprovou previamente o contrato como spender; um caso citado resultou em perda de US$ 3,5 milhões.
Prioridade	Revisar aprovações para endereços sem histórico de contrato implantado, tratar allowances novas como evento sensível e bloquear aprovações para endereços calculados por CREATE2 quando não houver bytecode verificável.
Artefatos	A computação do endereço em CREATE2 usa prefixo fixo 0xff, endereço do criador, salt e hash do código de inicialização.
Limite técnico	O problema descrito não é uma falha de execução arbitrária no Ethereum; é abuso de uma propriedade legítima do opcode para enganar fluxos de aprovação e validação de carteiras.

Resumo técnico

O CREATE2 é um opcode do Ethereum criado para tornar previsível o endereço de contratos inteligentes antes da implantação efetiva do bytecode. Essa previsibilidade é útil em aplicações descentralizadas porque permite coordenar interações entre contratos, preparar dependências e planejar fluxos em que componentes distintos precisam conhecer endereços futuros. A mesma propriedade, porém, cria uma condição perigosa para carteiras e ferramentas de segurança que avaliam uma aprovação olhando apenas o histórico do endereço, o bytecode já publicado ou comportamentos anteriores associados ao contrato.

A técnica descrita depende de uma diferença crítica entre intenção do usuário e estado on-chain no momento da assinatura. A vítima é levada a aprovar ou ampliar uma allowance para um endereço que ainda não contém contrato implantado. Como não há bytecode, histórico de chamadas nem metadados verificáveis naquele endereço, soluções que confiam nesses sinais podem não classificar a transação como perigosa. Após a aprovação, o operador implanta o contrato malicioso exatamente no endereço calculado e passa a ter uma autorização válida para movimentar os tokens permitidos pela vítima.

O impacto confirmado no contexto é drenagem de ativos vinculados à allowance concedida. Em um incidente citado, uma vítima perdeu US$ 3,5 milhões depois de aprovar uma transação para um contrato inexistente no momento da autorização. O contrato foi implantado depois e uma função foi executada para transferir fundos para um endereço controlado pelo operador. A relevância defensiva está menos em um bug isolado e mais na lacuna de modelagem de risco: aprovações para endereços sem código não devem ser consideradas seguras apenas porque não há comportamento anterior a analisar.

Fluxo técnico

No fluxo tradicional com CREATE, o endereço do contrato deriva do endereço do criador e de um nonce. No CREATE2, a determinação do endereço é diferente: entram no cálculo um prefixo fixo, o endereço que cria o contrato, um valor salt e o hash do código de inicialização. O formato descrito no contexto é keccak256(0xff + sender_address + salt + keccak256(initialization_code)). Isso permite que uma fábrica de contratos calcule previamente o endereço de um contrato filho e só implante o bytecode em um momento posterior.

O abuso começa quando o operador calcula um endereço futuro e prepara uma solicitação de aprovação de token para esse endereço. A vítima vê ou assina uma autorização em favor de um spender que, naquele instante, pode parecer inofensivo para controles que dependem da existência do contrato. A ausência de bytecode impede a análise estática do contrato final, e a ausência de histórico reduz a utilidade de reputação, simulação baseada em comportamento passado e listas de contratos já conhecidos. Essa janela é o ponto central da evasão.

Depois que a aprovação está registrada, o operador usa o mesmo salt e o mesmo código de inicialização para implantar o contrato no endereço previamente autorizado. A autorização concedida antes da implantação continua válida para aquele endereço. Com isso, o contrato recém-criado pode acionar a lógica necessária para consumir a allowance, incluindo uma chamada compatível com transferência delegada de tokens. O contexto cita o uso de transferFrom para movimentar o saldo da vítima com base na permissão já concedida.

A técnica não exige que o Ethereum aceite comportamento anômalo: o endereço determinístico e a implantação posterior são parte do funcionamento esperado de CREATE2. O risco aparece na camada de experiência do usuário, carteiras, validadores de transação e produtos de proteção que não correlacionam aprovações com endereços futuros. A condição também mostra que uma análise pontual no momento da assinatura pode ser insuficiente quando o objeto autorizado ainda não existe, mas pode existir logo depois com bytecode escolhido pelo operador.

Superfície afetada

A superfície principal são carteiras e usuários que assinam aprovações de token para endereços sem contrato implantado, especialmente quando a interface não deixa claro que o spender ainda não possui bytecode verificável. Também entram na superfície dApps e fluxos de autorização que solicitam allowances amplas, persistentes ou maiores do que o necessário para a operação imediata. Quanto mais duradoura e ampla for a permissão, maior o intervalo em que um contrato implantado posteriormente pode explorá-la.

Produtos de segurança para blockchain também ficam expostos quando tratam endereço vazio como ausência de risco. Se a lógica defensiva depende apenas de reputação histórica, bytecode presente, contratos verificados ou padrões conhecidos de chamadas, ela pode falhar justamente antes de o artefato malicioso existir. A lacuna é agravada quando a carteira não simula cenários futuros, não sinaliza endereços derivados de fábrica e não destaca que a aprovação está sendo concedida a um endereço que poderá receber contrato depois.

• Carteiras que exibem aprovações de allowance sem alerta forte para spender sem bytecode implantado.
• Usuários que concedem aprovações amplas ou aumentam allowances para endereços desconhecidos.
• dApps que dependem de aprovações prévias e não limitam escopo, valor ou duração da permissão.
• Ferramentas de triagem que avaliam somente contratos existentes e reputação histórica do endereço.
• Monitoramento on-chain que não correlaciona aprovação, implantação posterior por CREATE2 e uso rápido da allowance.

Hunting e telemetria

A investigação deve partir da sequência temporal. O sinal de maior valor é uma aprovação de token para um endereço sem bytecode no bloco ou no momento da transação, seguida por implantação de contrato no mesmo endereço e posterior consumo da allowance. A análise precisa preservar a ordem dos eventos, porque olhar apenas o estado atual da blockchain pode esconder o fato de que o contrato não existia quando a vítima concedeu a permissão.

Em telemetria de carteira, SOC ou plataforma de monitoramento on-chain, é importante registrar o estado do endereço autorizado no momento exato da assinatura: existência de bytecode, histórico de transações, método chamado, valor da allowance, token afetado e relação com contratos fábrica. Também é útil acompanhar se o endereço aprovado foi produzido por parâmetros compatíveis com CREATE2, como presença de salt e implantação posterior por uma fábrica conhecida ou recém-criada.

Para resposta a incidente, a trilha deve conectar a aprovação original ao contrato implantado depois. O contexto menciona um endereço aprovado terminado em ...36fa71c que não existia no momento da autorização e um endereço de destino terminado em ...96b89a1e2 associado à transferência dos fundos. Esses valores devem ser tratados como artefatos de caso e não como lista completa de indicadores. O foco defensivo deve ser a classe de comportamento: allowance para endereço sem contrato, implantação determinística subsequente e transferência delegada em curto intervalo.

• Evento de aprovação ou aumento de allowance para endereço sem bytecode no momento da assinatura.
• Implantação posterior de contrato no mesmo endereço por meio de fluxo compatível com CREATE2.
• Uso de transferFrom ou função equivalente consumindo a permissão logo após a implantação.
• Endereços de fábrica que calculam contratos filhos com salt previsível ou reutilizado.
• Diferença entre estado do endereço na assinatura e estado do endereço no momento da investigação.

Mitigação

A mitigação começa na política de aprovação. Carteiras e dApps devem reduzir o uso de allowances amplas e persistentes, pedir escopo mínimo para a operação pretendida e destacar aprovações para endereços sem contrato implantado. Quando não houver bytecode verificável no momento da assinatura, a interface deve tratar o caso como risco elevado, não como endereço limpo. O usuário precisa ver que está autorizando um spender que pode receber código posteriormente.

Controles de segurança devem incorporar o estado temporal do endereço aprovado. Em vez de avaliar apenas o contrato existente, a defesa deve registrar que o endereço estava vazio no momento da aprovação e monitorar qualquer implantação posterior. Se a implantação ocorrer, a aprovação anterior deve ser reavaliada imediatamente, com alerta para consumo de allowance e recomendação de revogação quando a permissão ainda estiver ativa. Essa lógica é especialmente importante para tokens de alto valor e carteiras com histórico de aprovações amplas.

Equipes de engenharia de dApps podem reduzir a exposição evitando fluxos que exijam aprovação para endereços futuros quando não houver justificativa técnica forte. Quando o uso de CREATE2 for legítimo, a aplicação deve fornecer metadados verificáveis, vínculo claro com a fábrica responsável e limites de valor compatíveis com a operação. Para usuários e custodiantes, a resposta prática é revisar permissões concedidas, revogar allowances desnecessárias e priorizar carteiras que alertem sobre aprovação para endereços sem bytecode.

• Bloquear ou exigir confirmação reforçada para aprovações destinadas a endereços sem contrato implantado.
• Registrar o estado do spender no momento da assinatura, incluindo presença de bytecode e histórico on-chain.
• Alertar quando um contrato for implantado por CREATE2 em endereço que já recebeu allowance.
• Revogar permissões antigas, excessivas ou concedidas a endereços desconhecidos.
• Limitar allowances por valor e finalidade, evitando permissões amplas quando a operação não exige esse escopo.