O Bitcoin Core 31.0 contém uma vulnerabilidade de privacidade, e nós maliciosos podem forçar o vazamento de IP

A equipe de desenvolvimento do Bitcoin Core publicou no X em 12 de junho, confirmando que a nova funcionalidade -privatebroadcast introduzida na versão 31.0 do Bitcoin Core tem uma falha de privacidade: sob certas condições de rede, se o handshake v2 falhar, o Bitcoin Core conectará nós pares via IPv4 ou IPv6, expondo assim ao destinatário o endereço IP público do remetente.

Condições de usuários afetados: cinco requisitos que precisam ocorrer simultaneamente

De acordo com o comunicado oficial do Bitcoin Core, somente quando todos os cinco itens a seguir forem atendidos ao mesmo tempo é que o nó será afetado por esta falha:

· O nó está executando o Bitcoin Core 31.0 e já ativou a funcionalidade -privatebroadcast

· A transação é transmitida via comando RPC sendrawtransaction (RPCs de carteira como sendtoaddress, sendall etc. não usam broadcast privado, portanto não são afetados)

A Tor pode estabelecer conexões de saída

· É possível estabelecer diretamente conexões de saída IPv4 ou IPv6 (sem restrição -onlynet e sem configuração -proxy=...)

· A transmissão BIP324 v2 não foi desativada (não foi definido -v2transport=0)

As conexões com nós pares onion e I2P não são afetadas, porque em qualquer tentativa de reenvio v1, essas conexões sempre passam por suas respectivas rotas via proxy.

Mecanismo técnico do bug: após falha no handshake v2, a repetição v1 não passa pela Tor

Conforme as explicações oficiais, o mecanismo que aciona a falha é o seguinte: quando um par de nós IPv4 ou IPv6 compatível com a transmissão v2 (BIP324) é selecionado para broadcast privado, a conexão inicial segue, como esperado, pelas rotas via proxy da Tor. Se o handshake v2 falhar, o Bitcoin Core tentará reenviar usando o protocolo v1; essa repetição v1 não passa pelo proxy da Tor e, em vez disso, se conecta diretamente via IPv4 ou IPv6, o que acaba vazando o endereço IP do iniciador.

Esse comportamento viola a garantia de privacidade descrita na versão 31.0: “o destinatário nunca saberá o endereço IP (e a localização) deles”. A equipe de desenvolvimento confirma que essa falha tem mais probabilidade de ser acionada deliberadamente por um nó par malicioso, ao desligar intencionalmente o handshake v2 para forçar uma repetição v1.

Três soluções temporárias: até antes da atualização para 31.1, é possível usar

O Bitcoin Core oficial fornece as seguintes três soluções temporárias:

Solução 1 (recomendada): desabilitar diretamente a configuração -privatebroadcast com -privatebroadcast=0

Solução 2: desabilitar a transmissão v2 com -v2transport=0. Atenção: esta configuração fará com que todas as conexões do nó usem o protocolo v1 não criptografado, tornando-o mais fácil de ser identificado por impressão digital (fingerprinting) e sofrer fiscalização na rede pública (mainnet).

Solução 3: rotear o tráfego de saída IPv4/IPv6 para a Tor com -proxy=127.0.0.1:9050 (substitua pela porta SOCKS do Tor em uso). Atenção: esta configuração deixará o nó mais suscetível a ataques de Sybil (Sybil Attack).

Perguntas frequentes

Nó que usa RPC da carteira como sendtoaddress ou sendall é afetado?

De acordo com o comunicado oficial do Bitcoin Core, os RPCs da carteira (como sendtoaddress, sendall etc.) não usam o recurso de broadcast privado, portanto não são afetados por esta falha. A falha é acionada apenas quando a transmissão via sendrawtransaction é usada e as outras quatro condições também são atendidas.

A falha pode ocorrer naturalmente sem a necessidade de um nó malicioso?

Conforme as explicações oficiais, para nós pares que realmente suportam a transmissão v2, no cenário normal a falha do handshake v2 é improvável. A falha tem mais probabilidade de ser acionada artificialmente quando um nó par malicioso desabilita intencionalmente o handshake v2 para forçar a repetição v1.

Qual é o cronograma de lançamento do Bitcoin Core 31.1?

De acordo com o comunicado oficial do Bitcoin Core, a correção será lançada junto com a versão 31.1, mas o comunicado não forneceu uma data específica de lançamento. A recomendação oficial é adotar uma das três soluções temporárias acima antes de atualizar para 31.1.