Linha do tempo e reflexões do hack do Vyper

"Confie, mas verifique" (confie, mas verifique), não faça "depois do fato". O bug mais sério é preto sob as luzes.

Devido à imutabilidade do contrato, o projeto dependerá implicitamente do código escrito há muitos anos. Quando corrigimos bugs, precisamos prestar mais atenção ao seu impacto potencial.

Desta vez aconteceu assim.

Linha do tempo

Neste artigo, usarei "nós" para me referir a todos aqueles que trabalharam arduamente neste evento. Sinto que, embora inicialmente tenha contribuído um pouco para encontrar o bug, inúmeras pessoas ajudaram muito mais ao longo do processo.

13:10 UTC pETH/ETH US$ 11 milhões [1] ralo.

13:19 UTC Michal publica no ETHSecurity sobre a queda repentina de preço do pETH.

Igor foi o primeiro a perceber que algo estava errado. Graças a ele, começamos a investigar mais.

Mas como o robô reinsere add_liquidity() na chamada remove_liquidity()?

14:01 UTC Formou uma equipe de contingência sobre o assunto.

14:07 UTC Usamos nosso descompilador favorito [2] Descompilei o contrato JPEG e notei que os slots de proteção de reentrância são um pouco diferentes.

// Entrada da tabela de despacho para add_liquidity(uint256 [2] ,uint256) label_0057: se (armazenamento [0x00] ) { reverter(memória[0x00:0x00]); } armazenar [0x00] = 0x01; // Entrada da tabela de despacho para remove_liquidity(uint256,uint256 [2] ) label_1AF3: se (armazenamento [0x02] ) { reverter(memória[0x00:0x00]); } armazenar [0x02] = 0x01;

14:27 UTC Confirmamos esse problema com um simples contrato de teste local.

@externo @nonreentrant("bloqueio") def test(addr: address) -> bool: retornar Verdadeiro @externo @nonreentrant("bloqueio") def test2(addr: endereço) -> bool: retorna falso

Este não é apenas outro bug de reentrância.

Nesse ponto, percebemos o impacto que isso teria. Bloquear mensagem, removemos as mensagens públicas sobre esta vulnerabilidade.

14:37 UTC Wavey ajudou a identificar o commit vulnerável e a versão afetada. Charles e eu também confirmamos isso inspecionando manualmente a saída do compilador Vyper.

É uma corrida contra os hackers.

Felizmente, as pessoas também o confundem com reentrância somente leitura. Trecho do canal Web3 Security Alert - Alchemix e Metronome DAO também hackeados devido a um bug de reentrância somente leitura [3]

Michael encontrou vulnerabilidades potenciais nos pools alETH e msETH executando a versão 0.2.15 também.

14:50 UTC msETH/ETH esgotados [4] 。

15:34 UTC alETH/ETH está esgotado [5] 。

15:43 UTC Encontramos uma vulnerabilidade no CRV/ETH compilado com Vyper versão 0.3.0 [6] . É vital que mantenhamos os contratos afetados em sigilo pelo maior tempo possível.

16:11 UTC Começamos a trabalhar nas vulnerabilidades white hat.

Infelizmente, muitas organizações estão conduzindo pesquisas independentes ao mesmo tempo, e os rumores abundam. Às 16:44 UTC, decidimos emitir uma declaração pública sobre a versão afetada [7] 。

Às 18:32 UTC, tínhamos uma exploração de prova de conceito que poderia ser usada para um possível resgate de chapéu branco. O bpak da Chainlight também está trabalhando em uma vulnerabilidade ao mesmo tempo e a compartilhou às 19:06 UTC.

Cinco minutos depois, às 19:11 UTC, alguém roubou os fundos [8] 。

A estrutura de ataque é muito diferente da nossa prova de conceito e é improvável que seja um vazamento da nossa equipe. De qualquer forma, é muito frustrante.

Ainda assim, há muito o que fazer.

21:26 UTC Addison apresentou um plano ambicioso para salvar os ativos restantes no pool CRVETH.

Se você enviar 30k crv para crv/eth pool, Você pode atualizar a taxa de administração em seguida, defina a taxa de crv/eth em torno de 0,15 eth por crv Basicamente, todas as centenas de K crv no pool podem ser extraídas

21:52 UTC bpak fez uma prova de conceito funcional que poderia economizar 3100 ETH.

Dez minutos depois, às 22:02 UTC, fomos derrotados novamente. Surpreendentemente, CRV gerencia robôs de despesas [9] Os fundos foram retirados e a piscina foi drenada [10] 。

culpa

culpa (Balme) é uma palavra forte. Apontar o dedo é inútil. Acho útil pensar no que poderia ser feito melhor.

Concurso

Os esforços do White Hat foram todos derrotados em menos de meia hora. Às vezes, cada segundo conta.

Talvez esses ataques pudessem ter sido realizados com melhor preparação e recursos. Ao mesmo tempo, isso parece ser uma faca de dois gumes. É realmente uma boa ideia reunir informações sobre como realizar um hack? Em quem devemos confiar?

Por outro lado, acho que todo o processo é muito eficaz. Passamos da suspeita inicial à confirmação de quem estava vulnerável em 2 horas e 4 minutos.

Divulgação de informação

Eu sou um auditor e um hacker de chapéu branco.

A indústria de auditoria tem uma cultura editorial única. Somos pagos por nossa liderança de pensamento técnico e profunda compreensão das vulnerabilidades. Uma maneira de demonstrar sua liderança e profundidade é publicar [11] O "furo" sobre hacking. Os pesquisadores são caros e o retorno do investimento é a publicidade.

Por outro lado, há um argumento convincente de que uma divulgação antecipada de uma versão afetada teria um impacto significativo em um resgate whitehat.

Se tivesse sido meia hora a mais, US$ 18 milhões poderiam ter sido economizados.

Os auditores não pagam pelo impacto de seus relatórios. Em vez disso, eles recebem curtidas, retuítes e cobertura. Isso parece ser um problema.

Próxima Etapa

Discordo de "precisamos de verificação formal para resolver este problema" e coisas do gênero. Esse erro pode ser detectado pelo teste de unidade. A verificação formal é muito útil para muitos tipos de erros, mas não acredito que seja igualmente útil para compiladores relativamente simples e não otimizados.

Observe que esse bug foi corrigido em novembro de 2021 [12] 。

Acho que essa vulnerabilidade do Vyper não é um problema com a tecnologia ou linguagem da equipe do Vyper, mas sim um problema de processo. Este bug foi corrigido há muito tempo sem perceber seu impacto potencial no momento da correção.

Infelizmente, os bens públicos são facilmente negligenciados. Devido à imutabilidade do contrato, os projetos dependem implicitamente de códigos escritos há muitos anos. Os desenvolvedores de protocolo e especialistas em segurança devem estar cientes dos últimos desenvolvimentos de segurança na pilha de execução.