Tradução de Christoph Michel feita por
Dimitris Calixto, artigo original disponível aqui.
De vez em quando, recebo mensagens me pedindo conselhos sobre como começar a ser um auditor de segurança de smartcontracts. Embora já existam artigos escritos sobre este tópico, a maioria deles são apenas uma coleção de artigos relacionados com a segurança que são jogados aos principiantes, sobrecarregando-os. Vou providenciar um caminho que tomaria se tivesse que fazer tudo de novo. Esse será específico da ETH (ou mais geral específico da EVM), uma vez que a maior parte do trabalho de auditoria ainda se encontra nesse ecossistema.
No final, também passarei examinando as perguntas mais frequentes que estão relacionadas com a auditoria e a obtenção do seu primeiro emprego.
Quem me fez um especialista?
Quem sou eu e porque é que deveriam sequer me ouvir?
Sou atualmente um investigador independente de segurança que já trabalhou em empresas de auditoria tradicionais, então conheço ambos os lados. Não precisa me ouvir, mas se chegou até mim, provavelmente tem as suas próprias razões para pensar que os meus conselhos são valiosos. No momento em que escrevo, sou atualmente o auditor número 1 no Code4rena, a importância que quer dar a esta classificação depende de novo, de você.
Aprenda programação
Espero que já saiba como programar, qualquer língua está bem. Caso contrário, aprender a programar deve ser o seu primeiro passo, uma vez que o código de auditoria requer a capacidade de o ler. Na minha opinião, ser um programador é um pré-requisito, caso contrário, você estará gastando tempo demais tentando dar sentido à sintaxe e à semântica das instruções individuais. Seria como tentar ler Nietzsche enquanto se é analfabeto. Torne-se alfabetizado primeiro. Este é definitivamente o passo que leva mais tempo a aprender. Aprender os aspectos de segurança acontecem muito mais depressa.
Se não tiver experiência prévia de programação, esteja mentalmente preparado para levar anos até que as suas revisões sejam úteis. Começaria com o Javascript, é a linguagem mais amigável e versátil para principiantes. Se você verificar que não gosta de ser um auditor, a transição para ser um programador de Frontend, Backend ou de smartcontract é fácil. A sintaxe de Solidity e Javascript são também um pouco semelhantes.
Aprenda o básico da blockchain ETH & Solidity
Então agora você sabe como programar, mas ainda não sabe nada sobre o Ethereum e a Solidity. A forma mais rápida de aprender uma nova língua é usando-a na prática, escrevendo código nela - ler apenas a documentação não faz o conhecimento fixar (e por alguma razão, mesmo depois de todos estes anos, continuo achando a documentação de Solidity confusa e desestruturada). Não há melhor forma de combinar a aprendizagem de Solidity com a aprendizagem da segurança ETH do que resolver os CTFs.
“Os CTFs (Capture The Flags / Jogos de guerra) são desafios de segurança onde o código vulnerável é apresentado e é necessário escrever um contrato inteligente para explorar a vulnerabilidade.”
Esses são os três CTFs que resolvi pessoalmente para aprender Solidity e a linguagem:
Os desafios do Ethernaut e Capture The Ether muitas vezes se sobrepõem e algumas vulnerabilidades aplicam-se apenas a versões antigas de Solidity. Você não os verá mais em código moderno; esteja ciente disso.
“Esses CTFs foram originalmente feitos para serem executados contra um teste Ethereum para o qual é difícil obter qualquer fundo ETH e cuja experiência de desenvolvimento é muito complicada. Recomendo uma abordagem alternativa utilizando frameworks de estrutura modernas de teste & fazendo o forking para resolver esses desafios, que está descrito na minha postagem Ethernaut Solutions. Pode clonar o meu repositório no GitHub para começar com a mesma configuração.”
Há também CTFs que são muito mais difíceis, como os CTFs da_ Paradigm_. A boa pontuação nestes mostra que você sabe o que está fazendo e são ótimos para contratação, especialmente se você é desconhecido. Todas as grandes empresas de auditoria me contactaram após o meu post de soluções com o call-to-action no final.
Familiarizar-se com os smart contracts mais utilizados
Existem certos contratos, padrões ou mesmo algoritmos que você verá repetidamente durante a sua carreira de auditor. É bom familiarizar-se com eles e compreender profundamente como funcionam e as suas nuances.
- Contratos Token: Os padrões de tokens mais utilizados são EIP20 para tokens fungíveis, e EIP721 para NFTs. Há muitos mais, mas estes dois são tudo o que você precisa saber no início. É importante compreender que a norma ERC20 original evoluiu muito e há tokens que não cumprem com a EIP20 final (mais notavelmente USDT), que não retorna um booleano de sucesso entre outras questões. Deve também compreender que os tokens podem ter decimais diferentes e devem ser interpretados como um número de pontos flutuantes com a precisão dos decimais, ou seja, 1e18 TOKENS (= 10**18 TOKENS) ~ 1.0 TOKENS para uma ficha com 18 decimais. Encontrará muitos bugs onde alguma quantidade de fichas computadorizadas está no número errado de decimais.
- Proxies: Os contratos Ethereum não são atualizáveis. Se quiser atualizar o código, tem de implantar um novo contrato. No entanto, isso significa que o armazenamento que ainda reside no contrato original também se perde. Assim, os proxies implementam a ideia de separar o armazenamento da lógica. Existem muitas implementações diferentes de proxy, dê uma olhada no OpenZeppelin Proxy. Você deve compreender como a delegatecall é essencial para a construção de proxies.
- MasterChef: O MasterChef é um contrato de staking onde os utilizadores depositam fichas de liquidez (LP) e recebem recompensas proporcionais ao seu tempo * stakeAmount. Este contrato tem sido muito bifurcado, mas a principal razão l é importante compreender é que o seu algoritmo de recompensa aparece em muitos lugares diferentes. Paradigm chama o algoritmo de bilhões de dólares. Você deve compreender como funciona e porque é necessário em uma configuração de_ blockchain _(não pode atualizar todos os usuários ao mesmo tempo).
- Compound: Eu diria que o Compound é a base de todos os protocolos descentralizados de empréstimo ponto a ponto. Você deve conhecê-lo como muitos dos primitivos DeFi interagem de alguma forma com os protocolos de empréstimo. O código também é mais limpo do que o da Aave e é um grande exemplo de como uma boa documentação deve ser. Os seus contratos Governor & TimeLock são utilizados como contratos de governança de muitos outros protocolos também. Você deve notar as semelhanças entre o algoritmo de recompensa MasterChef e a forma como a dívida é acumulada para o utilizador através do borrowIndex.
- UniswapV2: Enquanto a Uniswap já está em V3, a Uniswap V2 é significativamente mais simples, menos gas-golfed, e ainda é a base para compreender os criadores de mercado automatizados (AMMs) em geral. Também você deve compreender como funcionam os tokens LP (mais geralmente, tokens compartilhados que lhe dão uma parte justa de um equilíbrio subjacente).
Aprenda as noções básicas de finanças
Haverá uma hora em que quando você estiver auditando um projeto DeFi que usa muitos termos financeiros tradicionais e não compreende nada. Quando procurar esses termos, terá definições que se referem a ainda mais termos que não conhece. Desse modo, achei muito útil passar por um curso básico de finanças que não pressupõe nada e explica realmente a intenção de utilizar este instrumento financeiro específico.
Recomendo o Khan Academy de Opções, swaps, futures, MBSs, CDOs, e outros derivados, da Khan Academy onde aprenderá a terminologia de opções, shorting, futures (~contratos perpétuos). A partir daí, poderá expandir e ir ainda mais a fundo nos tópicos individuais.
Obtendo experiência real
Neste momento, a sua formação terminou e vai continuar lendo mais código e a explorar os pós-mortems para melhorar. Sempre que a parte teórica se tornar muito entediante, você deverá tentar encontrar problemas em código real, isto pode ser a recompensa de bugs no Immunefi ou concursos de auditoria no Code4rena. A grande vantagem aqui é que eles não têm permissão. Pode ser anônimo, não há necessidade de passar numa entrevista de emprego, os pagamentos são puramente baseados em competências. Receber uma recompensa real de bug é uma grande adição no caso de querer candidatar-se a empresas de auditoria.
FAQ
Recentemente realizei um AMA no bootcamp da Secureum e recebi muitas perguntas interessantes para as quais compartilharei aqui as minhas respostas.
Como é que você se mantém atualizado sobre segurança?
Esteja no Twitter para notificações em tempo real, mas se quiser ler apenas um artigo agregado por semana, inscreva-se na Newsletter BlockThreat por iphelix,
Qual é a remuneração?
Não sou especialista nisso, mas diria que o preço por hora para os auditores são, grosso modo:
- Junior: 100$/h
- Experiente: 100$-250$/h
- Melhor Auditor: 250$-1000$/h
Eu categorizaria a remuneração em duas categorias:
- Fixa: Recebe um salário fixo (por hora) pelo seu trabalho
- Quanto mais ou maior for o número de erros que você achar, maior será a sua remuneração.
Se for um júnior, recomendo a entrada numa firma de auditoria, se estiver do outro lado da curva do sino, será mais lucrativo procurar oportunidades com este último modelo de remuneração. Note que os melhores caçadores de recompensas podem ganhar muito mais com os pagamentos em milhões por vulnerabilidades críticas.
Quanto tempo demora a revisão de uma base de códigos?
As auditorias são sempre uma tarefa difícil e, na minha opinião, só se melhora com a experiência. Mas darei uma regra de ouro: Digamos que pode auditar 200 linhas de código por hora (o que é uma hipótese padrão entre alguns auditores até onde eu sei) - ajuste esse parâmetro para baixo se o código for complexo, pesado em matemática ou se a documentação for ruim. Depois pega-se nas linhas de código e divide-se por 200 LOC/h, depois obtém-se as horas necessárias para auditar o código para uma única pessoa. Se for um auditor independente, deve também acrescentar 5h-10h para compilar o relatório e todo o trabalho biz-dev, além de responder a perguntas. Depois multiplique pelo seu preço/hora.
Como você sabe quando deixar de procurar por bugs?
Essa é uma boa pergunta. Eu poderia sempre gastar mais tempo com o código e isso aumentaria a probabilidade de eu encontrar bugs. Mas em algum momento, há o ponto de diminuir os retornos, onde não é razoável gastar mais tempo com o código.
Foi feita a Alexander Schlindwein a mesma pergunta em relação às recompensas de bugs, mas penso que se aplica também às auditorias:
A abordagem que funciona melhor para mim é estabelecer, eu mesmo, o objetivo de compreender plenamente o sistema ao ponto de poder reimplementá-lo a partir do zero sem me permitir olhar para a base de código original. Sem recordar o código, mas ter compreendido o que a aplicação deve fazer. Se tiver examinado um projeto a tal ponto e não tiver encontrado um bug, as hipóteses de o encontrar continuando são baixas. Entrevista.
Realisticamente, eu paro frequentemente antes de chegar a esse ponto devido a restrições de tempo e custos de oportunidade quando penso que o meu tempo limitado é mais bem gasto em outro lugar.
Você pode ser um auditor, mas não ser um programador?
Na minha opinião, as competências dos auditores e dos programadores sobrepõem-se na sua maioria. Diria mesmo que ser um auditor fez de mim um melhor programador. Já devem ter ouvido falar deste mito de um engenheiro de 10x, mas é apenas alguém que já trabalhou em muitos projetos semelhantes e pode copiar-colar do seu trabalho anterior de tal forma que a montagem de um novo protocolo acontece muito mais depressa em comparação com alguém sem código anterior a que se possa recorrer. Provavelmente já vi ~100 bases de códigos de solidity e sei exatamente de onde procurar e copiar código se tivesse de construir um novo protocolo. Por outro lado, um protocolo dev sabe mais sobre áreas como as implantações adequadas, gestão das tarefas cotidianas na cadeia, monitorização, etc. Têm também melhor memória muscular para a sintaxe, ao digitarem o código, enquanto eu o estou lendo na maior parte do tempo.
Quais ferramentas utilizam na auditoria?
Não utilizo quaisquer ferramentas que realizem diretamente análises de vulnerabilidade. Utilizo apenas a excelente extensão VSCode "Solidity Visual Developer" que realça variáveis de armazenamento e parâmetros de função, que torna mais fácil ter um contexto quando se lê uma nova base de código.
O que me faz um bom auditor?
Além das capacidades técnicas como conhecer muitos tipos de explorações, conhecer bem a EVM, ou ter visto questões de protocolos semelhantes, um traço de personalidade que considero útil: consciência - sinto que alguns auditores nem sequer tentam encontrar todos os bugs e apenas querem terminar com o seu trabalho o mais rapidamente possível. Isto é mais provável que aconteça se os incentivos não forem alinhados e se receberem um salário fixo, como é frequentemente o caso das empresas de auditoria tradicionais. Assim, você quer contratar pessoas conscientes, que levem o seu trabalho a sério e se orgulhem do seu trabalho.
Eu preciso saber matemática?
Vejo cada vez mais protocolos de DeFi pesados em matemática, por isso ser bom em matemática é definitivamente uma vantagem.
Como é o seu processo de auditoria?
O meu processo de auditoria é bastante simples. Primeiro leio a documentação. Depois leio o código de cima para baixo, ordeno os contratos de uma forma que faz sentido para mim: por exemplo, leio primeiro o contrato de classe base antes de ler o contrato de classe derivado. Não utilizo quaisquer ferramentas, mas tomo notas e rabisco~~s~~ em todo o código. 😃 estou usando a extensão "Solidity Visual Developer" que vem com os marcadores @audit, @audit-info, @audit-ok, @audit-issue que eu uso para categorizar as minhas notas. Depois de ter lido uma vez toda a base de código, revisito as minhas notas e resolvo quaisquer pontas soltas ou coisas que não compreendi anteriormente. Posteriormente, crio o meu relatório de auditoria a partir destas notas.
Pode auditar facilmente projetos em outras blockchains? As redes mais recentes são mais seguras?
Investiguei Solana que usa Rust _e devo dizer que a curva de aprendizagem de _Rust é bastante íngreme mesmo para mim e o modelo não convencional da blockchain Solana também precisa de algum tempo para se habituar. Penso que as garantias de segurança que línguas como a Rust/Haskell dão irão apanhar alguns bugs de baixa pendência, mas também auditorias. Os bugs mais interessantes são os econômicos/ lógica errada / vetores de ataque imprevistos.
Algumas razões pelas quais eu penso que ETH vê tantas explorações é que
- Os protocolos mais inovadores e, portanto, geralmente complexos e não testados ainda estão em ETH
- o modelo de invocação da função de cross-contracts é ótimo para bugs de reentrância
- tratamento especial da ETH em vez de ser apenas mais um token ERC20
- sem possibilidade de atualização do contrato incorporado, em vez disso, temos vários padrões complicados de proxy e módulos para trabalhar em torno desta limitação
- A cultura de código aberto da ETH é muito mais forte do que em qualquer outra cadeia e é muito mais difícil encontrar bugs em sistemas de código fechado
- ETH é ainda onde o dinheiro está, o que atrai mais olhos.
Como se pode ver, existem algumas decisões de camada de blockchain que influenciam a segurança que outras blockchains resolveram melhor. Não se trata realmente da linguagem do smart contract em si, mas mais de compreender como funciona a blockchain e as implicações relativas à segurança. Esse é o maior obstáculo à auditoria de uma nova cadeia, geralmente, esta informação está espalhada por posts de blogs ou nem sequer está documentada e é preciso olhar para o código ou esperar encontrar um desenvolvimento central no Discord/Telegram.
Top comments (0)