Há mais de um ano venho traduzindo artigos sobre web3 e um dos temas que tem me chamado atenção é a vulnerabilidade das blockchains. Como não sou desenvolvedora, olho o problema de fora e vejo que uma das barreiras da adoção dos contratos inteligentes no dia a dia é a falta de confiabilidade. Sendo assim, resolvi ler alguns artigos para fazer uma compilação de informações sobre o tema.
As vulnerabilidades dos contratos inteligentes são muitas e são classificadas de várias formas. Segundo a Shark Team, existem 10 ameaças mais comuns à segurança dos contratos inteligentes. São elas:
- Ataque de Reentrância
- Oráculos Manipulados
- Vulnerabilidade de Verificação Lógica
- Vulnerabilidades de Permissão
- Vulnerabilidade de Atualização de Contrato
- Funções de Inicialização Maliciosa
- Ataque Sanduíche
- Ataque de Fallback
- Ataque de Proposta
- Ataque de Repetição
Em um artigo sobre o tema, a Metabay Security fala sobre as vulnerabilidades mais comuns em Solidity, que é uma linguagem de programação de alto nível para codificação de contratos inteligentes em várias plataformas blockchain, principalmente na Ethereum. Esse artigo classifica as vulnerabilidades dessa forma:
- Reentrância
- Manipulação de Oráculo
- Front-running (Deslocamento, Inserção e Supressão)
A ideia desse artigo é fazer comentários sobre algumas dessas vulnerabilidades e apresentar um material rico que temos no site, sobre o assunto. A reentrância é um tipo de vulnerabilidade bastante comentado nos artigos. Reentrar em uma função repetidamente pode significar um desastre.
Reentrância
Os tipos de ataques de reentrância parecem ser os mais comuns em contratos inteligentes baseados em EVM (Máquina Virtual Ethereum). São citados três tipos de reentrâncias: de função única, entre funções cruzadas e entre contratos cruzados.
O ataque de reentrância de função única ocorre quando funções podem ser chamadas repetidamente antes que a primeira invocação da função tenha terminado. Isso pode fazer com que as diferentes invocações da função interajam de forma destrutiva.
No caso de reentrância de funções cruzadas, um invasor pode ser capaz de realizar um ataque semelhante ao de função única, usando duas funções diferentes que compartilham o mesmo estado. Esse tipo ocorre quando as funções vulneráveis compartilham o estado com uma função que pode ser explorada por um atacante.
Já a reentrância de contratos cruzados ocorre quando vários contratos compartilham a mesma variável de estado e alguns contratos atualizam essa variável de forma insegura; quando um estado de um contrato é usado em outro contrato, mas esse estado não é totalmente atualizado antes de ser chamado. Esse tipo de reentrância pode ser considerado um problema complicado, pois costuma ser difícil de ser descoberto.
Manipulação de Oráculo
Oráculos fornecem informações off-chain aos protocolos. Eles são a ponte entre os serviços do mundo real (off-chain) e os protocolos da blockchain (on-chain). Um oráculo com conteúdo obsoleto ou até mesmo mal-intencionado pode ter efeitos desastrosos em todos os processos conectados ao feed de dados. Na prática, os feeds de dados manipulados podem causar danos significativos, desde liquidações injustificadas até negociações de arbitragem maliciosas.
Front-running
Como todas as transações ficam visíveis no mempool (pool de memória) por um curto período de tempo antes de serem executadas, os observadores da rede podem ver e reagir a uma ação antes que ela seja incluída em um bloco. Um exemplo de como isso pode ser explorado é com uma exchange descentralizada em que uma transação de ordem de compra pode ser vista e a segunda ordem pode ser transmitida e executada antes que a primeira transação seja incluída. Proteger-se contra isso é difícil, pois depende do próprio contrato específico.
Assim, o front-running refere-se à adição de uma transação a uma fila, sabendo que outra transação virá em seguida. Em uma plataforma blockchain, o front-running normalmente assume a forma de um minerador que coloca uma ordem que o beneficiaria com base em uma negociação ainda em andamento.
O ataque de front-running pode ser de deslocamento, inserção e supressão. No caso de deslocamento, o invasor desloca o usuário inocente, ao manter uma taxa de gas mais alta para aparecer na ordem de transação mais elevada.
No ataque de inserção, o atacante precisa que a transação do usuário ocorra após a transação do atacante. Por exemplo, um usuário chamado X faz um lance de preço de gas mais alto para que sua transação seja priorizada. Agora, o invasor fará primeiro uma transação a um custo de gas menor do que o lance de X e, logo em seguida, fará uma transação para lucrar com a diferença entre os dois.
No caso de supressão, o invasor usa um custo de gas e quantidade de gas altos para atrasar a transação do usuário, gastando todo o gas e esgotando o limite de gas do bloco.
A vulnerabilidade do tipo sanduíche, é uma espécie de negociação front-running, visando protocolos e serviços Defi. Nesse caso, negociantes mal-intencionados procuram transações pendentes em uma rede de sua escolha, como a Ethereum. O ataque sanduíche ocorre colocando um pedido antes e depois da negociação. Essencialmente, o invasor executa transações front-run e back-run, com a transação pendente original entre elas.
Como se vê, existe uma infinidade de tipos de vulnerabilidades de contratos inteligentes. Parece que cada dia surge uma forma nova de ataque, mas paralelamente, vão sendo encontradas formas de evitá-las. Por isso é tão importante estudar as vulnerabilidades e soluções para evitá-las, proporcionando mais segurança aos contratos inteligentes e aumentando a confiabilidade.
Se você gostou do conteúdo desse artigo e quer ir mais fundo sobre as formas de reduzir a chance de ocorrência desses ataques em seus contratos inteligentes, consulte essa lista de artigos traduzidos sobre o tema em nosso site:
https://www.web3dev.com.br/paulogio/conceitos-basicos-de-mev-em-seguranca-web3-4aga
https://www.web3dev.com.br/paulogio/os-problemas-de-derrapagem-e-ataques-sanduiche-em-dexs-44n1
https://www.web3dev.com.br/ojedai85/entendendo-os-ataques-csrf-3c6
Fátima Lima
Top comments (0)