Posted on Jul 20, 2023

Reentrância Read-only (Somente Leitura): um exame detalhado

Este manual é um exame completo do assunto que ensinará a você o que é reentrância Read-only, como detectá-la e como defender efetivamente seu projeto e usuários contra ela!

Saudações, queridos leitores!

Nós continuamos nossas Series de artigos educacionais e hoje veremos o Read-Only Reentrance Attack — um dos ataques que costumava ser muito comum nos projetos baseados em contratos inteligentes Web3, mas recentemente foi relegado para segundo plano, embora ainda represente um grande perigo!

Para começar, vamos entender o que é um ataque de Reentrância, ou seja, quais ferramentas estão disponíveis atualmente para detectá-lo e, mais importante, como proteger de forma confiável seu projeto e seus usuários desse tipo de ataque.

Dito isto, tendemos a acreditar que não há quem duvide que a base de qualquer implementação segura é uma abordagem especial para escrever código. Consequentemente, este artigo será focado apenas naqueles aspectos que podem ser realmente úteis para deixar seu código a salvo e seguro!

Portanto, abaixo você verá não um artigo típico, mas uma sistematização de conhecimento (SoK), na qual me basearei em autores que eu mesmo confio neste assunto e, claro, em nossos auditores da pessimistic.io !

Compartilharemos nossas próprias observações e daremos alguns conselhos no próximo artigo de nossa série, pois nossa equipe tem trabalhado desde 2016, acumulamos alguns deles. Você também encontrará uma lista de ferramentas e pesquisas para auto-estudo, e recomendamos fortemente que você a leia separadamente para melhor compreensão.

Alguns meses atrás, terminamos nossa própria pesquisa sobre ataques de reentrância, de várias maneiras, este artigo contará com informações de nosso artigo antigo, portanto, leia-o se ainda não o fez:

Destilando ataques de reentrância em contratos inteligentes

No início, também gostaríamos de expressar nossa sincera gratidão à comunidade, aos autores de todos os materiais de recursos e, é claro, aos nossos auditores da equipe que nos ajudaram fornecendo informações muito necessárias e quebrando o véu do sigilo!

A propósito, há alguns espaços vagos agora, portanto, se o seu projeto precisar de uma auditoria - sinta-se à vontade para escrever para nós, e visite nossa página de relatórios públicos aqui!

I - Ataques de Reentrância

As questões que envolvem Reentrância em contratos inteligentes, como costuma acontecer com a tecnologia blockchain, não se originam na blockchain, mas fornecem um exemplo novo e complexo deles.

Aqui está o primeiro ataque de reentrância já documentado:

Para uma melhor compreensão das variações do ataque de reentrância, visite esta incrível lista cronológica e (espero) completa de ataques de reentrância até o momento.

A reentrância é um termo que tem sido usado em Informática por muito tempo para descrever o fenômeno pelo qual um processo pode ser interrompido no meio da execução, uma nova ocorrência da mesma função pode ser iniciada e ambos os processos podem ser encerrados.

Usamos funções reentrantes na computação com segurança todos os dias. Um bom exemplo é poder iniciar um rascunho de e-mail em um servidor, sair dele para enviar outro e-mail e depois retornar ao rascunho para finalizá-lo e enviá-lo.

Blockchain é um pouco diferente - para exemplo: Se o alvo de uma chamada externa for um contrato malicioso controlado pelo invasor, o invasor pode executar a lógica maliciosa quando o contrato atacado chama o contrato malicioso.

Em seguida, ele entrará novamente no contrato atacado para fazer uma chamada externa inesperada, afetando a lógica de execução padrão do contrato de ataque:

quantstamp.com/blog/what-is-a-re-entrance-attack

No entanto, o mecanismo de reentrância pode ser usado não apenas para ataques! Por exemplo, a Rede 1inch usa para o modo Fusion — ordens de limite são preenchidas recursivamente via reentrância de interação do tomador. Realmente incrível, muito obrigado Anton Bukov por mostrar esta característica!

II — Reentrância Read-only

A maioria dos ataques de Reentrância são feitos reinserindo a mesma função (reentrância de função única) da qual é chamada; no entanto, também existem outras variações que são mais difíceis de descobrir e prevenir.

Não entraremos em detalhes sobre cada um deles nesta postagem, mas ofereceremos alguns links na conclusão para você investigar adiante!

Tipicamente, os auditores e caçadores de bugs estão preocupados apenas com pontos de entrada que modificam o estado ao procurar reentrância. No entanto, a reentrância Read-only pode ocorrer quando um protocolo depende da leitura do estado de outro.

Condições para reentrância Read-only

Para proteger você e seu código durante o processo de desenvolvimento ou auditoria, lembre-se dos seguintes pontos. Seu código geralmente se torna vulnerável nestes tipos de condições:

Há algum estado: ;
Há uma chamada externa, e este estado é modificado após a chamada;
Existe outro contrato, que depende desse estado (utilizado pelo getter).

Em seguida, vamos examinar a seguinte captura de tela:

Vamos examinar o exemplo e identificar a causa dos problemas mostrados na captura de tela acima usando a lista mencionada acima como guia:

Há algum estado: (_number neste exemplo);
Existe uma chamada externa, e este estado é modificado após a chamada;
Existe outro contrato (MinimalVictim), que depende desse estado (utilizado pelo getter).

Em seguida, vamos examinar outra captura de tela assim que terminarmos com o primeiro exemplo. Recomendamos que você preste muita atenção a este cenário, pois ele o ajudará a prever possíveis problemas com seu código:

No exemplo a seguir, o estado está localizado em um terceiro contrato (token balance). Como os shares são queimados primeiro, durante msg.sender.call, getSharePrice() retornará os preços mais altos, pois os saldos ainda não foram atualizados. O que significa que o invasor pode manipular o preço das ações, se algum contrato depender da função getSharePrice()…

Os exemplos clássicos de reentrância normalmente reentram em uma função de modificação de estado para que um estado inconsistente seja usado para executar gravações maliciosas no armazenamento do contrato. Normalmente, os contratos protegem a si mesmos com bloqueios de reentrância, protegendo seu estado de tais ações maliciosas.

TL;DR

A reentrancia Read-only é um cenário de Reentrância onde a função view é inserida novamente, o que na maioria dos casos é desprotegido, pois não modifica o estado do contrato.

No entanto, se o estado for inconsistente, valores incorretos podem ser relatados. Outros protocolos que dependem de um valor de retorno podem ser levados a ler o estado errado para executar ações indesejadas. Confira esse blog e esse artigo para saber mais sobre isso.

III — Contramedidas

Para estabelecer uma reentrância já existente, os auditores usam diferentes ferramentas e métodos — existem muitos deles. Basta dar uma olhada nesta incrível seleção abaixo e escolher aquele que funcionará melhor para você.

A maioria das ferramentas existentes, gratuitas e pagas, podem ser usadas para detectar esse tipo de vulnerabilidade. No entanto, alguns deles podem detectar apenas um tipo de vulnerabilidade, enquanto outros podem detectar todos eles.

Aqui está uma lista de algumas das melhores ferramentas para localizar essas vulnerabilidades:

De nossa perspectiva, Slither é certamente o melhor para encontrar essas vulnerabilidades, mas lembre-se de que você precisa configurá-lo corretamente!

Nossa equipe gostaria de expressar nossa mais profunda gratidão aos criadores da ferramenta Slither: Josselin Feist, Gustavo Grieco e Alex Groce, assim como Crytic, a divisão de segurança em blockchain Trail of Bits e todas as pessoas que acreditam na ferramenta original e em sua evolução!

Confira nosso artigo recente sobre o Slither, se você ainda não o fez:

Slither: A cornucópia de um auditor

Fazer a pré-auditoria do código usando as ferramentas e dicas listados acima irão ajudá-lo a detectar a Reentrância, mas acredito que você concordará que é melhor não deixar isso acontecer em de forma alguma!

Nosso próprio detector: Slitherin

Nos últimos meses, temos desenvolvido ativamente nossos próprios detectores Slither para ajudar com a revisão do código e processo de auditoria. Mais recentemente, lançamos nossos próprios detectores e encorajamos você a usá-los para sua auditoria interna inicial, particularmente o detector de Reentrância Read-only:

slitherin/read_only_reentrancy.py no mestre · pessimistic-io/slitherin

Nosso objetivo era aumentar a sensibilidade do detector para auxiliar nossos auditores, por isso é bastante direto e não escrito no “estilo original”. Como resultado, produz FPs (Falso-positivo) com mais frequência do que os “Slither originais”.

Assim sendo, nossos detectores são uma espécie de automatização das checagens implementadas no checklist, sua principal função é procurar por problemas e auxiliar o auditor de código!

Por favor, deixe-nos saber se você descobriu um problema/bug/vulnerabilidade através de nossos detectores Slither personalizados. Você pode entrar em contato conosco através da abertura de um PR/Problema ou diretamente, o que for mais conveniente para você!

Configuração Slitherin

Este detector destaca o uso de funções getters que retornam um valor que teoricamente poderia ser manipulado durante a execução. Siga estas etapas para configurá-lo e instalá-lo:

Verificar: pess-readonly-reentrancy
Gravidade: High
Confiança: Low

Certifique-se de que os valores da função getter não sejam cruciais e não possam ser usados de forma maliciosa em outras partes do contrato durante chamadas externas antes de serem atualizados!

Siga estes links para usar nosso detector:

Se você tiver mais dúvidas ou sugestões, por favor junte-se ao nosso servidor de discord ou bate-papo do Telegram. Esperamos vê-lo lá, e pretendemos apoiar a comunidade e suas iniciativas!

Táticas de Defesa:

Mas primeiro, vamos definir alguns conceitos e para isso vou encaminhá-lo para este grande estudo do time Immunefi, em nossa opinião, é uma das melhores explicações da mecânica de ataques e seus tipos:

O Guia Definitivo Para Reentrância

A) Proteção de reentrância (sem reentrância read-only)

Isso é muito mais simples para nos protegermos quando não estamos lidando com reentrância read-only, por exemplo, aderindo às seguintes diretrizes e práticas. Nós vamos dissecar essas estratégias de defesa no ponto A antes de passar para o nosso assunto principal no ponto B, que é a reentrância read-only.

De qualquer forma, vamos começar do simples ao complexo e examinar como os seguintes tipos de reentrância são protegidos. É crucial reconhecer as variações e paralelos entre esses tipos de reentrância:

Resumindo, toda a bagunça com os tipos de Reentrância mencionados pode ser evitada se você melhorar a qualidade do seu código, e agora vamos dizer exatamente o que você deve levar em consideração:

Ao escrever código, você precisa seguir o padrão de codificação (Checagem-Efeitos-Interações) do primeiro julgamento e depois escrever variáveis em chamadas externas. Você também deve ter em mente que usar o CEI para todos os contratos confiáveis devem ser usado com cautela para prevenir reentrância read-only entre contratos;
Adicione um protetor de Reentrância; isso evita que mais de uma função seja executada ao mesmo tempo, bloqueando o contrato.

O seguinte código é um exemplo de uma proteção de reentrada:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.3;
contract ReEntrancyGuard {
bool internal locked;
modifier noReentrant() {
require(!locked, "No re-entrancy");
locked = true;
_;
locked = false;
}}

Os auditores também sugerem prestar atenção às características das vulnerabilidades de reentrada: todos os locais de código envolvidos em chamadas externas de contrato são inseguros. Você precisa se concentrar em chamadas externas e, em seguida, deduzir o possível dano de chamadas externas para julgar se elas podem ser exploradas devido ao ponto de reentrada!

Gostaríamos de destacar o seguinte recurso de aprendizado em particular, use-o para melhorar suas habilidades de segurança:

GitHub - jcsec-security/all-things-reentrância: Workshop sobre os diferentes tipos de reentrância…

B)Reentrada read-only: Contramedidas

Para reduzir a bagunça, você deve aumentar o calibre do seu código. Vamos agora delinear as considerações específicas que você deve fazer:

Em protocolos:
Verifique o bloqueio de reentrada nas funções de visualização vulneráveis;
Tornar os bloqueios de reentrância visíveis ao público.
Em projetos integrados:
Use informações de reentrada lib/public;
No caso de contratos legados: tente chamar a função protegida por reentrância.

Dito isso, ataques de reentrância continuam a ser uma grande preocupação no mundo dos contratos inteligentes. Para reduzir o risco de ataques de reentrância, os desenvolvedores devem permanecer vigilantes em suas práticas de codificação e implementar as melhores práticas de segurança; por enquanto confira:

Para uma melhor compreensão das variações do ataque de reentrância, visite esta incrível lista cronológica e (esperançosamente) completa de ataques de reentrância até o momento!

C) Monitoramento e Proteção Ativa

Auditores e pesquisadores de segurança também são importantes para identificar vulnerabilidades e fornecer feedback aos desenvolvedores. Por meio de recompensas de bugs (por exemplo —Immunefi) e auditorias, a comunidade blockchain pode continuar a melhorar a segurança dos contratos inteligentes e evitar que ataques de reentrada causem mais danos.

Os auditores, por sua vez, podem (e na minha opinião devem!) contribuir para o desenvolvimento de ferramentas FOSS! Mas... ao olhar para eses hacks sem fim do mês, pode-se perguntar por que eles acontecem tão freqüentemente…

As empresas de auditoria realmente ficaram pior no que eles fazem???

Este, em nossa opinião, não é o caso; ainda assim, o tema é bastante complicado porque, de certa forma, você pode reduzir os riscos para si e para o seu projeto!

A mitigação de riscos não é algo para definir e esquecer; é um processo contínuo de monitoramento, atualização e refinamento de processos com base nas condições de mercado em evolução. Por favor note, nós estamos trabalhando em tal solução dentro da equipe e esperamos entregar isto em breve:

Spotter's Digest №6

Confira nosso serviço de monitoramento on-chain e proteção ativa Pessimistic Spotter! Ao contrário da versão privada, a versão pública (este canal) revela ataques seletivamente e não permite rastrear um endereço específico. Para utilizar a versão privada, que oferece mais recursos, Preencha este formulário!

Obrigado por ler até o fim! Esperamos que este artigo tenha sido informativo e útil para você! Que instrumentos devemos rever? Sobre o que você estaria interessado em ler?

Por favor, deixe seus comentários, ficaremos felizes em respondê-los, e as melhores respostas e perguntas podem ser incluídas no próximo artigo!

Fique seguro!

IV — Recursos e Ferramentas

Importantes:

Descoberta inicial da reentrância read-only: Curve LP oracle .getVirtualPrice
Sentiment Hack Analysis - Ataque de Reentrância: Balancer pool .getRate (.getTokens)
Teórico-Prático: Balancer e Reentrância Read-only
Decodificando Exploit de US$ 220.000 de Reentrância Read-only | QuillAudits
Novo vetor de ataque de reentrância: twitter.com/bytes032/status/1616357019522400256 & POC
Reentrada read-only POC
Nosso próprio detector: github.com/pessimistic-io/slitherin/blob/master/slither_pess/detectors/read_only_reentrancy.py

Externos:

Confira também:

Esperamos que este artigo tenha sido informativo e útil para você! Obrigado por ler!

Ataques de manipulação de preço e recompensa destilados

A propósito, há alguns espaços vagos agora, portanto, se o seu projeto precisar de uma auditoria - sinta-se à vontade para escrever para nós, visite nossa página de relatórios públicos aqui!

Ataque de reentrância

Segurança de contrato inteligente

Este artigo foi escrito por Pessimistic Security e traduzido por Diogo Jorge. O artigo original pode ser encontrado aqui.

Top comments (0)

Se inscrever

WEB3DEV