A reorganização de 13 blocos do Litecoin não foi um dia zero, o histórico de commits do GitHub mostra o contrário

Uma reorganização da cadeia de 13 blocos em LTC$56h30 na noite de sexta e sábado retrocedeu cerca de 32 minutos de atividade de rede depois que os invasores usaram uma vulnerabilidade em seu protocolo Mimblewimble Extension Block (MWEB).

O bug permitiu um ataque de negação de serviço contra grandes pools de mineração, permitindo que transações MWEB inválidas passassem por nós que não foram atualizados, antes que a cadeia válida mais longa da rede as corrigisse.

A Fundação disse na manhã asiática de domingo que o bug foi totalmente corrigido e a rede está operando normalmente.

No entanto, pesquisadores proeminentes dizem que o repositório GitHub do projeto Litecoin conta uma história diferente. O pesquisador de segurança bbsz, que trabalha com o grupo de resposta de emergência SEAL911 para explorações de criptografia, publicou o cronograma do patch retirado do log público de commits.

A vulnerabilidade de consenso que permitiu a fixação inválida do MWEB foi corrigida de forma privada entre 19 e 26 de março, cerca de quatro semanas antes do ataque. Uma vulnerabilidade separada de negação de serviço foi corrigida na manhã de 25 de abril.

Ambas as correções foram lançadas na versão 0.21.5.4 na mesma tarde, após o ataque já ter começado.

“A autópsia diz que um dia zero causou um DoS que deixou escapar uma transação MWEB inválida”, escreveu bbsz. “O git log conta uma história um pouco diferente.”

Um dia zero refere-se a uma vulnerabilidade desconhecida pelos defensores no momento de um ataque.

O histórico de commits do Litecoin mostra que a vulnerabilidade de consenso era conhecida e corrigida de forma privada um mês antes da exploração, mas a correção não foi transmitida publicamente ou exigida para todos os pools de mineração.

Isso criou uma janela onde alguns mineradores executavam o código corrigido enquanto outros executavam a versão ainda vulnerável, e os invasores parecem saber qual era qual.

Alex Shevchenko, CTO do projeto Aurora da Fundação NEAR, levantou preocupações paralelas em um thread.

Os dados do Blockchain mostraram que o invasor pré-financiou uma carteira 38 horas antes da exploração por meio de uma retirada da Binance, com o endereço de destino já configurado para trocar LTC por ETH em uma exchange descentralizada.

O ataque de negação de serviço e o bug MWEB eram componentes separados, argumentou Shevchenko, com o DoS projetado para colocar os nós de mineração corrigidos off-line para que os não corrigidos formassem a cadeia que incluía as transações inválidas.

O fato de a rede ter lidado automaticamente com a reorganização de 13 blocos assim que o DoS parou sugere que havia hashrate suficiente executando código atualizado para eventualmente dominar o ataque, mas somente depois que o fork sem patch foi executado por 32 minutos.

Um sucesso no Litecoin mostra como os ataques a várias redes diferem na forma como os mantenedores e desenvolvedores de código reagem às explorações. Cadeias mais novas com conjuntos de validadores menores e mais centralizados coordenam atualizações por meio de grupos de bate-papo e podem enviar patches para toda a rede em horas.

Redes de prova de trabalho mais antigas, como Litecoin e Bitcoin, dependem de pools de mineração independentes que escolhem quando atualizar, o que funciona para mudanças não urgentes, mas cria uma janela de vulnerabilidade quando um patch de segurança precisa chegar a todos antes que um invasor explore a lacuna.

A Fundação Litecoin não abordou publicamente o cronograma do GitHub na manhã de domingo.

A quantidade de LTC indexada durante a janela de bloqueio inválido e o valor de quaisquer swaps concluídos antes da reorganização os reverteram não foram divulgados.