Autor: Ismael Bejarano. 27 de Novembro de 2018.
Neste artigo avaliaremos comparativamente várias ferramentas de auditoria. A auditoria de segurança de Smart Contracts é uma fase crítica no desenvolvimento de Smart Contracts. O hack DAO foi apenas uma viagem na odisseia para garantir contratos inteligentes Ethereum e blockchains compatíveis como RSK e Cardano. É importante destacar que em 2016 foi publicada uma chamada por uma moratória temporária sobre o DAO, mas não foi ouvida. Lição aprendida: nunca implemente um Smart Contract sem uma ou mais auditorias de segurança. É tentador usar ferramentas de segurança automatizadas para economizar tempo e dinheiro, mas, atualmente, essas ferramentas não podem substituir o cérebro humano.
Linters e ferramentas de análise são usadas para apontar rapidamente erros na sintaxe e na lógica do Smart Contract. Ferramentas mais complexas podem ser usadas para melhor analisar em profundidade o comportamento de Smart Contracts.
Neste artigo, examinaremos como algumas dessas ferramentas se saem contra vulnerabilidades bem conhecidas extraídas do Smart Contracts Weakness Registry (Registro de Fragilidade de Smart Contracts).
Ferramentas
Selecionamos um conjunto de ferramentas que possuem diferentes formas de analisar e relatar erros e que são bem conhecidas na comunidade. Veremos linters, Solhint e o Solium que realizarão uma análise no nível do código-fonte e outros mais avançados como o Oyente que atua no nível do opcode para detectar comportamento incorreto.
Manticore
Uma ferramenta de execução simbólica que fornece uma API para escrever seus próprios testes dentro do Python. Ele vem com um conjunto de heurísticas para detectar alguns erros comuns e nós os verificamos.
Mythril
Mythril é uma ferramenta definida especificamente para segurança e parece de fato se sair bem contra bugs comuns, mas ainda não foi perfeita. Ele também pode gerar um gráfico de fluxo de controle e pode instalar uma determinada versão de solc.
Oyente
Uma Ferramenta de Análise para Smart Contracts que executa a avaliação no nível do opcode, de forma que problemas na sintaxe do Solidity não sejam detectados. Nossos testes foram feitos com a versão mais recente disponível como um docker container que inclui Oyente v0.2.7.3.
SmartCheck
SmartCheck é uma ferramenta online que verifica automaticamente os Smart Contracts em busca de vulnerabilidades e más práticas. Testamos com a versão 0.0.9 lançada em 25 de outubro.
Solhint
Essa ferramenta examina erros de sintaxe e estilo, além de alguns problemas de segurança. Executamos nossos testes com Solhint versão 1.4.0.
Solium
Este é um linter projetado para destacar problemas de estilo com o código. No entanto, ele também aceita alguns plug-ins que ajudam a detectar problemas de segurança. Testamos na versão 1.1.8. Esta ferramenta possui um sistema de plugins, que permite estendê-la.
SonarSolidity
Esta é uma ferramenta fornecida como um plugin (ligação) para o console SonarQube para analisar o código. Classifica o que encontra em “code smell”, vulnerabilidades e bugs. Ele também pode importar relatórios do Solium, que podem ser aprimorados com os próprios plug-ins do Solium. Testamos a versão 3.2.0.1227 sozinha para ver o que encontramos.
Testes
Selecionamos um subconjunto representativo do registro SWC (Classificação de Fragilidade de Smart Contracts) para executar nosso teste. Escolhemos especialmente algumas das classificações do Projeto de Segurança de vulnerabilidade de Aplicativos Descentralizado com maior impacto.
- WC-100: Visibilidade Padrão da Função
- No Solidity funções sem visibilidade são marcadas como públicas e serão expostas,.
- SWC-101: Integer (Totalidade) de Overflow e Underflow
O resultado das operações aritméticas pode exceder o valor de tipo máximo ou cair abaixo do mínimo e se não for endereçado adequadamente irá desencadear um comportamento indesejado.
SWC-106: Instrução SELFDESTRUCT (auto destruir) desprotegida
- A operação SELFDESTRUCT faz com que o acesso ao Smart Contracts seja excluído do estado e não possa ser chamado posteriormente. O ataque à carteira Multi-Sig da Parity foi causado por um contrato que não foi inicializado corretamente, deixando-o desprotegido.
• SWC-107: Reentrada
Quando um contrato faz uma chamada/ acesso para um contrato externo, ele abre mão do controle e é possível que outra função no mesmo contrato seja acessado.
- SWC-108: Variável de Estado de Visibilidade padrão
- Definir explicitamente a visibilidade das variáveis de armazenamento evita que o uso indevido das mesmas herde contratos.
- SWC-109: Storae Pointer não Inicializado
Variáveis de armazenamento local não inicializadas podem apontar para variáveis de armazenamento existentes no contrato e o uso incorreto causará substituições inadvertidas.
- SWC-112: Delegatecall (variante especial de chamada de mensagem, chamada delegatecall que é idêntica à chamada de mensagem, exceto pelo fato que o código no endereço de destino é executado no contexto do contrato chamado e msg.sender e msg.value não alteram seus valores. para Callee não confiável
- Chamar um contrato não confiável com delegatecall permite que o destino modifique o armazenamento do chamador.
- • SWC-113: DoS com falha na chamada
- Fazer chamadas para contratos externos pode falhar. Se várias chamadas forem executadas dentro de um loop, uma única falha fará com que toda a transação seja revertida.
• SWC-114: Dependência da Ordem de Transação
Os mineradores estão autorizados a reordenar as transações. Um contrato que depende de determinada ordem de transação pode ser suscetível a ataques como o Front Running, por exemplo.
- SWC-116: Dependência do Timestamp (uma cadeia de caracteres denotando a hora ou data que certo evento ocorreu) O timestamp no bloco é controlado pelo minerador que pode manipulá-lo conforme sua conveniência. Não deve ser usado para cálculos críticos.
- SWC-119: Variáveis de estado de sombra (um registro alternativo do histórico de transações escondido de outros mineradores)
Solidity permite usar os mesmos nomes para variáveis em diferentes contextos. Usar o mesmo nome é confuso e pode causar erros sutis.
• SWC-120: Fontes frágeis de aleatoriedade dos atributos da cadeia
As possíveis fontes de aleatoriedade disponíveis para Smart Contracts são limitadas e um cálculo incorreto pode fazer com que os resultados não sejam aleatórios. A loteria SmartBillions foi atacada por meio da suposição incorreta de que todos os hashes de bloco eram acessíveis por Smart Contracts sendo que apenas os últimos 256 hashes são disponíveis.
Resultados
A tabela a seguir resume a execução das diferentes ferramentas em nossos testes.
| SWC | Descrição | Manticore | Mythril | Oyente | Smartec | Solhint | Solium | SonarSolidity | |||
| 100 | Function Default Visibility Visibilidade padrão da função | ✘ | n/a (1) | (2.a) | ✘ | ||||||
| 101 | Integer Overflow and Underflow | ✘ | ✘ | (2.b) | ✘ | ||||||
| 106 | Unprotected SELFDESTRUCT Instruction | ✘ | ✘ | ✘ | ✘ | ✘ | ✘ | ||||
| 107 | Reentrancy Reentrada | ✘ | ✘ | ✘ | ✘ | ✘ | |||||
| 108 | State Variable Default Visibility | ✘ | n/a (1) | (2.c) | ✘ | ||||||
| 109 | Uninitialized Storage Pointer | ✘ | ✘ | ✘ | ✘ | ✘ | ✘ | ||||
| 112 | Delegatecall to Untrusted Callee | ✘ | ✘ | ✘ | ✘ (2.d) | ✘ | |||||
| 113 | DoS with Failed Call | ✘ | ✘ | ✘ | ✘ | ✘ | |||||
| 114 | Transaction Order Dependence | ✘ | ✘ | ✘ | ✘ | ✘ | ✘ | ||||
| 116 | Timestamp Dependence | ✘ | ✘ | ✘ | ✘ | ||||||
| 119 | Shadowing State Variables | ✘ | ✘ | n/a (1) | ✘ | ✘ | (2.e) | ✘ | |||
| 120 | Weak Sources of Randomness from Chain Attributes / Fontes fracas de aleatoriedade dos atributos da cadeia | ✘ | ✘ | ✘ | ✘ | ✘ | ✘ | ||||
Notas
1. A análise Oyente está no nível EVM, portanto, não será capaz de detectar problemas com a linguagem do Solidity.
2. Solium usa uma arquitetura de plug-in, para detectar alguns dos ataques um plug-in separado deve ser ativado.
security/enforce-explicit-visibility
zeppelin/no-arithmetic-operations
zeppelin/constant-candidatessecurity/no-low-level-calls
zeppelin/no-state-variable-shadowing
Conclusão
A maioria das ferramentas analisadas encontra os erros mais comuns, como função ou visibilidade variável ou overflows / underflows aritméticos. Algum evento identificará e recomendará as melhores práticas.
A maioria deles falhará contra ataques mais complexos, como reordenamento de transações ou negação de serviços de ataques. Esses ataques são complexos de serem detectados por um auditor competente e geralmente requerem interação entre vários contratos.
Em geral, o resultado estava longe de ser perfeito. Eles encontram os erros mais simples e falharam em ataques mais complexos. Os humanos vencem.
