O que é o "efeito de reentrada" (re-entrancy attack) - O que é o efeito de reentrada (re‑entrancy attack) e como proteger seus contratos inteligentes

O que é o efeito de reentrada (re‑entrancy attack) e como proteger seus contratos inteligentes

作者

O que é o efeito de reentrada (re‑entrancy attack) e por que você deve se preocupar?

O efeito de reentrada, conhecido internacionalmente como re‑entrancy attack, é uma das vulnerabilidades mais críticas em contratos inteligentes, especialmente na rede Ethereum. Ele permite que um atacante invoque novamente uma função antes que a execução original seja concluída, drenando fundos ou alterando o estado do contrato de forma inesperada. Desde o famoso hack do DAO em 2016, milhares de projetos têm investido pesado em auditorias e boas práticas para evitar esse tipo de exploração.

1. Como funciona o ataque de reentrada?

Para entender o mecanismo, imagine um contrato inteligente que possui uma função withdraw() responsável por transferir Ether para um endereço solicitado. Se o contrato simplesmente envia Ether usando call.value() e, em seguida, atualiza o saldo do usuário, o código pode ser explorado da seguinte forma:

  1. O atacante chama withdraw() e a transferência de Ether é iniciada.
  2. Antes que o saldo seja atualizado, o endereço do atacante (um contrato malicioso) recebe o Ether e, dentro de seu fallback function, chama novamente withdraw().
  3. Como o saldo ainda não foi reduzido, a segunda chamada passa novamente, permitindo que o atacante retire mais fundos.
  4. O processo pode se repetir até que o contrato fique sem Ether ou atinja o limite de gás.

Em termos simples, o contrato permite que o código externo (o atacante) “re‑entre” na sua própria lógica antes que o estado interno seja atualizado.

2. Exemplos reais que marcaram a história

O ataque ao DAO (2016) – O caso mais emblemático. O contrato do DAO continha uma função de retirada vulnerável que permitiu ao atacante drenar cerca de 3,6 milhões de ETH, o que representou quase 15% de toda a oferta circulante na época. A gravidade do incidente levou à criação do hard fork da Ethereum, resultando nas cadeias Ethereum (ETH) e Ethereum Classic (ETC).

Parity Wallet Hack (2017) – Embora o ataque principal tenha sido causado por um bug de autorização, a exploração de reentrada também foi usada para drenar fundos de algumas carteiras.

Esses incidentes mostram que a reentrada não é apenas teórica; ela tem consequências econômicas reais.

3. Por que a reentrada ainda é relevante em 2025?

Mesmo com a evolução das linguagens de contrato (Solidity, Vyper) e a introdução de ferramentas como ReentrancyGuard, novos desenvolvedores ainda cometem erros básicos. Além disso, blockchains emergentes (Polygon, Binance Smart Chain, Avalanche) utilizam a mesma Máquina Virtual Ethereum (EVM), herdando as mesmas vulnerabilidades. Por isso, entender o ataque e as defesas continua sendo essencial para qualquer profissional que trabalhe com contratos inteligentes.

O que é o
Fonte: the blowup via Unsplash

4. Estratégias de mitigação: como evitar ser vítima

4.1. Padrão Checks‑Effects‑Interactions

O primeiro e mais simples mecanismo de defesa é seguir o padrão Checks‑Effects‑Interactions:

  • Checks: Verifique todas as condições necessárias (ex.: saldo suficiente).
  • Effects: Atualize o estado interno (ex.: diminua o saldo).
  • Interactions: Só então interaja com contratos externos (ex.: enviar Ether).

Ao atualizar o estado antes de chamar funções externas, elimina‑se a janela de tempo em que a reentrada pode ocorrer.

4.2. Uso de ReentrancyGuard (OpenZeppelin)

Bibliotecas consolidadas como OpenZeppelin fornecem um modificador nonReentrant que impede chamadas recursivas:

contract MyVault is ReentrancyGuard {
    function withdraw(uint256 amount) external nonReentrant {
        // lógica segura
    }
}

O guard usa um estado interno (bool) que bloqueia a função enquanto está em execução.

4.3. Preferir transfer ou send (com limites de gás)

Historicamente, transfer e send limitavam o gás a 2300 unidades, impedindo a execução de código complexo no fallback. Contudo, a partir da EIP‑1884 (2019) e outras mudanças de custo de gás, essas funções podem falhar inesperadamente. Portanto, seu uso deve ser avaliado caso a caso, e ainda assim combiná‑las com Checks‑Effects‑Interactions.

4.4. Uso de padrões de pull‑payment

Em vez de empurrar fundos para o usuário (push), registre o valor a ser retirado e deixe que o usuário invoque withdraw() quando desejar. Isso reduz a necessidade de chamadas externas dentro de funções críticas.

4.5. Auditorias e ferramentas automáticas

Ferramentas como Slither, Echidna e MythX analisam o bytecode em busca de padrões de reentrada. Contudo, nenhuma ferramenta substitui uma auditoria humana experiente.

O que é o
Fonte: Buddha Elemental 3D via Unsplash

5. Como detectar um contrato vulnerável

Alguns sinais de alerta incluem:

  • Uso de .call.value() sem verificação de retorno.
  • Atualização de estado após a chamada externa.
  • Ausência de nonReentrant ou de guardas semelhantes.
  • Funções de retirada que não utilizam o padrão pull‑payment.

Um teste simples em uma rede de teste (Ropsten, Goerli) pode revelar vulnerabilidades: tente chamar a função de retirada a partir de um contrato malicioso que re‑entre e observe o comportamento.

6. O papel das hard forks na mitigação de vulnerabilidades

Quando uma vulnerabilidade crítica é descoberta, a comunidade pode optar por uma hard fork para corrigir o problema, como ocorreu após o ataque ao DAO. Contudo, hard forks são medidas drásticas e podem fragmentar a comunidade. Por isso, a prevenção via boas práticas de desenvolvimento é sempre preferível.

7. Boas práticas para desenvolvedores iniciantes

  1. Estude o padrão Checks‑Effects‑Interactions e implemente‑o desde o início.
  2. Utilize bibliotecas reconhecidas (OpenZeppelin) para guardas de reentrada.
  3. Teste exaustivamente em testnets e use fuzzing.
  4. Faça auditorias regulares por especialistas independentes.
  5. Mantenha-se atualizado com as EIPs que afetam o modelo de gás e segurança.

8. Recursos adicionais

Para aprofundar seu conhecimento, consulte os seguintes guias internos do nosso site:

Além disso, fontes externas de alta autoridade que complementam o assunto:

9. Conclusão

O efeito de reentrada continua sendo uma das vulnerabilidades mais perigosas no universo dos contratos inteligentes. Apesar das ferramentas e padrões disponíveis, a responsabilidade final recai sobre os desenvolvedores, que precisam adotar boas práticas, realizar auditorias rigorosas e manter-se informados sobre as mudanças da rede. Ao seguir os passos descritos neste guia, você reduz drasticamente o risco de perdas financeiras e contribui para um ecossistema blockchain mais seguro e confiável.