O BTC também tem a Floresta Escura: expondo bots maliciosos na cadeia

Autor: Tal Be'ery

Fonte:

Tradução: Vernacular blockchain

Os pesquisadores do Zengo revelaram que bots maliciosos estavam monitorando a existência de endereços aleatórios inseguros em blockchains BTC e imediatamente os exploraram para cometer roubos, causando milhões de dólares em perdas – uma das quais aconteceu em 23 de novembro de 2023.

Como parte da pesquisa contínua da Zengo X no campo da segurança blockchain, investigamos o caso dos 139 BTC recentemente perdidos, que totalizaram cerca de US$ 5,5 milhões na época. Sem o nosso conhecimento, ao fazê-lo, abrimos a caixa de Pandora BTC da Floresta Escura.

Em 2020, os pesquisadores da Paradigm Dan Robinson e Georgios Konstantopoulos publicaram um influente post no blog intitulado “ETH Workshop is a Dark Forest”: revelando os bots que se escondem na escuridão dos pools de memória do ETH Workshop, monitorando transações pendentes e tentando capitalizar as oportunidades lucrativas que criam. **

Hoje, revelamos que esse fenômeno não se limita aos blockchains ETH, mas também se aplica aos blockchains BTC (e possivelmente muitos outros).

1, este caso de taxas excessivas

Em 23 de novembro, um acordo BTC chamou a atenção dos analistas BTC. **Esta transação estabeleceu um recorde para o pagamento de taxas, pagando mais de US$ 3 milhões (83 BTC) pela transferência de US$ 2 milhões em BTC. **

Embora a explicação imediata para essas taxas exorbitantes (que geralmente devem ser inferiores a US $ 10) seja culpá-las por algum tipo de erro de digitação manual, como aconteceu no passado, não demorou muito para os usuários alegarem que eram os proprietários originais do X (antes do Twitter) e foram de alguma forma hackeados. **

O proprietário da Conta X prova criptograficamente que realmente possui o endereço BTC assinando-o com a chave privada associada.

2, nossa investigação começou

À medida que começamos a investigar este acordo de taxas exorbitantes com mais profundidade, alguns fatos mais sutis, mas interessantes, surgem.

Transações marcadas (Fonte: mempool.space)

O acima mostra alguns insights interessantes:

CPFP: significa “Child Pays For Parent”, o que significa que a entrada para esta transação é a saída de outra transação não confirmada. Nesse caso, isso significa que, enquanto a primeira transação estava aguardando no mempool, a transação sobrecarregada ocorreu. De acordo com os dados do explorador, na verdade foi enviado no mesmo minuto da transação anterior. **O custo é exatamente 60% do total gasto (83,65 / 139,4), por isso é improvável que seja um erro, mas sim o resultado de algum tipo de ação automatizada. **

RBF desativado: o remetente da transação desativou a opção “Substituir por taxa” (RBF) ou impediu que outras transações substituíssem a transação por uma taxa mais alta. Além disso, outro usuário X notou que, inicialmente, havia várias transações de sobretaxa candidatas, substituindo-se umas às outras pagando uma taxa mais alta (não mais visível no explorador, pois as informações da transação substituída foram limpas em um curto período de tempo).

3. Situação real: Vamos assumir primeiro

Com base nos dados, existem várias hipóteses possíveis para explicar esta transação com taxas excessivas:

O proprietário original pagou demais por um erro de digitação: a declaração do proprietário sobre X foi apenas para salvar a face, já que afirmar ter sido hackeado soa mais aceitável do que admitir ser desajeitado.

Nota: Isto não parece muito plausível, uma vez que a transação foi enviada enquanto a transação anterior ainda estava no mempool (ver CPFP acima), o que exigia conhecimentos técnicos, e a natureza exata da taxa (exatamente 60% da taxa total) não corresponde à teoria de erro de entrada ou desajeitada geral.

A chave privada do proprietário original foi hackeada: o invasor revelou a chave privada e esperou que o proprietário enviasse fundos para o endereço.

Nossa opinião: Isso é improvável porque a transação foi antecipada pela RBF, o que significa que várias partes estão cientes da chave privada.

A chave privada do proprietário original é previsível: a chave privada é criada de alguma forma previsível, como hashing de uma frase secreta (“Brian-wallet”) ou selecionando uma chave de um conjunto que é muito pequeno (32 bits). Essas questões são discutidas em profundidade em nossa recente postagem no blog.

Os atacantes estão gerando uma coleção de todas essas chaves privadas previsíveis e seus endereços correspondentes, e sempre que uma transação para enviar fundos para qualquer um desses endereços está no mempool, eles são imediatamente rápidos e se esforçam para enviar transações subsequentes para transferir esses fundos para seu endereço.

Esta última suposição explica tudo: resposta imediata (“CPFP” acima) e taxas exorbitantes são o que os atacantes têm de fazer para derrotar outros atacantes. A natureza “fixa” da taxa (60%) deve-se à natureza automática da operação, que é necessária para derrotar as outras partes. A desativação do RBF é outro mecanismo empregado pelos atacantes para aumentar suas chances de derrotar outras partes.

Essa suposição também é consistente com o comportamento passado do endereço na extremidade recetora de uma transação de taxa excessivamente alta. Muitas das transações que fluem para o endereço têm as mesmas características desta transação de alta taxa (embora não tão lucrativa quanto esta transação multimilionária).

O comportamento dos atacantes é consistente (fonte: X/Twitter).

Esta conclusão é, naturalmente, uma explicação muito assustadora e arrojada que requer mais provas. **

4. Provas

Para verificar nossas reivindicações, decidimos gerar uma chave privada previsível, enviar fundos para ela e observar os resultados. Se as nossas suposições estiverem corretas, então os fundos devem ser roubados imediatamente. Para criar uma chave privada não aleatória e obter o endereço gerado, usamos a popular ferramenta web de Ian Cloeman (que também funcionou bem no passado).

Defina a chave privada como “1” (note que a frase mnemônica gerada é composta principalmente pela palavra “abandonar” com índice 0)

Usando esta ferramenta, definimos a chave privada para “1” e obtivemos o endereço gerado: bc1q4jgysxym8yvp6khka878njuh8dem4l7mneyefz. Verificamos que ele não havia sido usado antes para descartar outras possíveis explicações.

Então enviamos uma transação de $10 para este endereço… Como esperado, descobrimos que isso foi seguido por uma transação de taxa exorbitante (US $ 5, ou 50%) que redirecionou os fundos para outro endereço!

Além disso, observamos uma concorrência feroz entre várias partes tentando obter uma vantagem através da RBF com taxas mais altas, que chegaram a quase 99% dos fundos, mas essas tentativas foram infrutíferas devido à primeira transação desativar a RBF.

4 transações RBF, a última ofereceu US $ 9,87 de um total de US $ 10 como taxa.

5. Conclusão: Monstros existem

Se a frase semente ou a chave privada de um usuário for gerada de maneira previsível ou sujeita a aleatoriedade indesejável, ela será explorada assim que o invasor descobrir os detalhes exatos da geração previsível. **

Como detalhamos em nossa recente postagem no blog, a questão da geração segura de chaves em carteiras cripto é negligenciada pela maioria dos usuários, mas prova ser um problema que atormenta as carteiras e causa enormes perdas.

Como os usuários não podem gerar suas próprias chaves privadas, mas não podem provar que as chaves privadas são aleatórias, os usuários não podem verificar a aleatoriedade de suas chaves e devem confiar em suas carteiras.

Esta questão é mais uma manifestação de um problema central maior que depende de carteiras unipartidárias. A fim de resolver este problema central, bem como o problema específico da aleatoriedade, devemos aceitar o fato de que os usuários precisam confiar em algumas entidades externas e passar para uma arquitetura mais robusta que reduz a confiança em cada parte envolvida, aumentando o número de partes envolvidas. **

Adicionar participantes pode reduzir a confiança necessária para cada participante e tornar o sistema mais robusto (consulte nossa postagem recente no blog para obter detalhes).