~$88 Milhões Perdidos: Explorações do COLDCARD & LULA

Durante a última semana (27/07/2026 - 02/08/2026), destacam-se os seguintes 2 incidentes de segurança notáveis, que juntos totalizam aproximadamente $88M em perdas.

Data	Incidente	Tipo	Perda Estimada
29/07/2026	LULA	Falha de Lógica de Negócio	~$578K
30/07/2026	COLDCARD	Geração de Entropia Falha	~1.370 BTC (~$88M)*

* A perda da COLDCARD varia conforme o método de confirmação: o valor de ~1.370 BTC (~$88M) exibido é o mínimo verificável publicamente na blockchain (coldcardwatch.com); a reconciliação por canal privado (Galaxy Research, a partir de correspondência com 73 vítimas) aponta um valor mais alto, cerca de 1.596 BTC e até ~2.055 BTC (~$130M) quando se incluem drenagens suspeitas mas não confirmadas.

Motivos da seleção

LULA: Uma função privilegiada de token que pode mover os saldos de um par AMM e forçar uma resincronização de reservas se transforma em um mecanismo repetível de drenagem de liquidez por meio de manipulação de preços.
COLDCARD: Um erro de build e integração no firmware da carteira encaminhou silenciosamente a geração de seed por meio de um fallback de software determinístico, comprometendo as garantias de entropia e transformando a recuperação de seed em uma busca offline que escalou para uma grande perda de fundos.

Destaque da Semana: COLDCARD

Selecionamos a COLDCARD como destaque desta semana porque um bug de entropia da carteira produziu a maior perda do período. A causa raiz, uma proteção de build que verificava se uma macro de configuração existia em vez de verificar se ela estava habilitada, é o tipo de erro de integração silencioso que testes funcionais não conseguem detectar, e a lição se aplica a qualquer sistema em que a segurança on-chain dependa de aleatoriedade off-chain.

A COLDCARD, uma carteira de hardware Bitcoin, lançou em 2021 um firmware que gerava seeds de carteira usando uma fonte de software determinística em vez do gerador de números aleatórios (RNG) de hardware pretendido [1][2]. A falha não foi explorada em larga escala até o final de julho de 2026, quando carteiras afetadas foram varridas em ondas on-chain a partir de 30 de julho: as perdas confirmadas publicamente totalizam pelo menos 1.370 BTC (~$88M, ao preço de $64.099 em 5 de agosto) [3], enquanto relatos confirmados de forma privada apontam para uma cifra tão alta quanto cerca de 1.596 BTC [4]. A causa raiz foi um erro de build e configuração que encaminhou a geração de seed para um fallback de software em vez do RNG de hardware pretendido. Para os dispositivos afetados, isso transformou a recuperação de seed de um problema criptograficamente inviável em uma busca offline.

Contexto

A COLDCARD é uma carteira de hardware Bitcoin. As chaves privadas e endereços de uma carteira são todos derivados de um único valor secreto, sua seed, portanto a segurança de qualquer carteira de autocustódia se baseia em duas propriedades dessa seed: que ela permaneça secreta e que seja imprevisível quando gerada. As carteiras de hardware existem principalmente para proteger a primeira propriedade; este incidente é uma falha da segunda. Uma frase seed BIP-39 é legível por humanos, mas a propriedade de segurança subjacente ao requisito de imprevisibilidade ainda é a entropia dos bytes aleatórios usados para criá-la. Se esses bytes puderem ser reproduzidos, a seed pode ser reproduzida. A intuição é a de um cofre cuja combinação é escolhida rolando dados: se os dados forem viciados, o cofre fica aberto para quem conhecer o viés, não importa quão forte seja a fechadura.

Para uma carteira, "dados viciados" significa um gerador de números aleatórios fraco. Espera-se que carteiras de hardware extraiam entropia de seed a partir de um gerador de números verdadeiramente aleatórios (TRNG) de hardware em seu microcontrolador seguro, porque um gerador pseudoaleatório (PRNG) de software é determinístico: dado seu estado interno e histórico de chamadas, sua saída pode ser reproduzida exatamente. Se as saídas do gerador forem previsíveis, seu intervalo de candidatos pode ser enumerado e comparado com dados públicos da carteira, como um endereço, um xpub ou uma chave pública, o que colapsa a recuperação de seed de um problema criptograficamente inviável para uma busca offline.

O firmware da COLDCARD expunha duas superfícies de RNG separadas. O MicroPython vinha com uma camada de plataforma STM32 que expunha o símbolo global rng_get() esperado pela biblioteca criptográfica da carteira, enquanto a COLDCARD também mantinha seu próprio wrapper de RNG de hardware local à placa. Ambas as superfícies têm a intenção de fornecer entropia de hardware, e a biblioteca criptográfica da carteira acessa uma delas por meio de um único símbolo global de RNG resolvido no momento em que o firmware é compilado.

Análise da Vulnerabilidade

A causa raiz foi um erro de build e integração envolvendo a macro de configuração MICROPY_HW_ENABLE_RNG. A configuração de placa de produção da COLDCARD definia essa macro como 0, porque o firmware pretendia usar seu próprio wrapper de RNG de hardware local à placa em vez da implementação de RNG de hardware do MicroPython. No entanto, o caminho de geração de carteira havia sido migrado para ngu.random.bytes(32), e o caminho STM32 da biblioteca criptográfica dependia, em última análise, do símbolo global rng_get() resolvido pelo MicroPython.

A cadeia do problema era:

generate_seed()
  -> ngu.random.bytes(32)
  -> libngu CHIP_TRNG_32()
  -> rng_get()
  -> MicroPython STM32 RNG module
  -> Yasmarang software fallback because MICROPY_HW_ENABLE_RNG == 0

A configuração da placa desabilitava o branch de RNG de hardware do MicroPython:

// We have our own version of this code.
#define MICROPY_HW_ENABLE_RNG (0)

A biblioteca criptográfica ainda tratava a macro como prova suficiente da existência de um RNG de hardware [5], pois verificava apenas se a macro existia antes de chamar rng_get():

extern uint32_t rng_get(void);
#define CHIP_TRNG_32() rng_get()

#ifndef MICROPY_HW_ENABLE_RNG
#error "get a HW TRNG plz"
#endif

Essa proteção não detecta o caso perigoso: uma macro definida como 0 ainda está definida, então a verificação #ifndef passa e o build é concluído com sucesso. Como o MicroPython seleciona sua implementação de RNG pelo valor da macro em vez de sua existência, MICROPY_HW_ENABLE_RNG == 0 encaminhou rng_get() para o branch de fallback de software em vez do wrapper local à placa da COLDCARD [6]:

#if MICROPY_HW_ENABLE_RNG
    // STM32 hardware RNG
#else
    // Yasmarang software fallback
#endif

As consequências diferem por geração de dispositivo. Para o firmware Mk2/Mk3 v4.0.0-v4.1.9, a análise da Block [7] afirma que nenhuma entropia criptográfica foi adicionada ao ngu.random, de modo que a geração de carteira pode se tornar determinística quando o estado do fallback e o histórico de chamadas são conhecidos (o comunicado da Coinkite [2] delimita o intervalo Mk2/Mk3 de forma um pouco mais restrita, como v4.0.1-v4.1.9). Para Mk4/Q/Mk5, o material do elemento seguro era hasheado, mas apenas quatro bytes eram passados para ngu.random.reseed(), limitando o reseed seguro a uma única palavra de estado de 32 bits, um espaço de busca muito menos eficaz do que a entropia de carteira que os usuários esperam. O hash dos 32 bytes aleatórios finais não pode aumentar a entropia do resultado; ele apenas transforma um conjunto de candidatos já limitado.

Análise do Ataque

Diferentemente de uma exploração de contrato inteligente, este incidente não possui uma única transação de ataque on-chain para rastrear. Foi um problema de recuperação de seed offline seguido por varreduras on-chain. A pré-condição era que os usuários afetados tivessem gerado suas seeds de carteira por meio do caminho vulnerável ngu.random.bytes(32), de modo que o material de suas seeds dependesse de um estado de fallback de software reproduzível em vez de entropia de hardware completa. Uma segunda pré-condição, inferida, é que as carteiras afetadas fossem deriváveis apenas a partir da seed: uma frase-passe BIP-39 forte e única mescla entropia independente, fornecida pelo usuário, por meio do PBKDF2, que a falha de RNG nunca afetou, colocando essas carteiras fora do alcance da mera enumeração de seeds, e a escala das varreduras sugere que a maioria dos usuários afetados não havia definido tal frase-passe. A partir daí, a recuperação provavelmente ocorreu em três etapas:

O atacante restringiu ou enumerou estados candidatos de RNG usando metadados do dispositivo, tempo de boot, suposições de RTC/SysTick e histórico plausível de chamadas de RNG.
Para cada estado candidato, o atacante derivou seeds de carteira candidatas e as verificou offline em relação a dados públicos da carteira, como endereços, xpubs ou chaves públicas geradas.
Uma vez que um candidato correspondesse a uma carteira real, o atacante recuperava a seed, reconstruía as chaves privadas e varria o BTC associado.

On-chain, o roubo apareceu como uma explosão de varreduras de endereços a partir de 30 de julho. O rastreamento heurístico independente on-chain [3] identifica várias ondas de drenagem totalizando pelo menos 1.370 BTC (aproximadamente $88M, valorando as moedas ao preço do BTC de $64.099 em 5 de agosto) varridos de 4.580 endereços verificados, um mínimo verificado, não um total. Enquanto isso, um canal privado [4], confirmado por correspondência com 73 vítimas, aponta para uma cifra tão alta quanto cerca de 1.596 BTC, subindo para até 2.055 BTC (~$130M) quando se somam as drenagens suspeitas mas não confirmadas.

Conclusão

O incidente da COLDCARD foi uma falha na geração de entropia: a API de geração de seed, crítica para a segurança, resolveu-se silenciosamente para um fallback de PRNG de software determinístico em vez do RNG de hardware pretendido, porque uma proteção de build verificava se uma macro de configuração existia em vez de se estava habilitada. Para os dispositivos afetados, isso transformou a recuperação de seed de um problema criptograficamente inviável em uma busca offline, e o resultado foi mais de 1.370 BTC [3] varridos em múltiplas ondas (apurações de canal privado situam o valor entre aproximadamente 1.596 e 2.055 BTC [4]).

A falha central de engenharia é que o firmware lançado nunca comprovou que sua API mais crítica para a segurança realmente alcançava o RNG de hardware pretendido. Três práticas teriam detectado o problema: proteções de build para entropia criptográfica devem verificar tanto a existência da macro quanto seu valor; fallbacks de entropia devem falhar de forma segura ("fail closed") em vez de substituir silenciosamente por um PRNG de software; e a verificação da imagem final do firmware deve cobrir a proveniência dos símbolos e o fluxo de entropia de ponta a ponta, não apenas o fato de o código compilar. Uma seed afetada não pode ser corrigida no local; seus fundos devem ser movidos para uma carteira criada com firmware corrigido, e uma frase-passe forte e única reduz a exposição imediata sem reparar a seed [2].

Vale destacar o modo de falha: bugs de aleatoriedade desse tipo são invisíveis a testes funcionais porque cada seed gerada é individualmente válida. O defeito não está em nenhuma saída isolada, mas na fonte que as produziu: como essa fonte é previsível e reproduzível, as seeds acabam, coletivamente, caindo em um intervalo pequeno e enumerável. Componentes de geração de chaves off-chain merecem escrutínio de segurança de primeira classe.

Referências

Mais Incidentes Desta Semana

LULA

A LULA, um token BEP-20 na BNB Chain, perdeu aproximadamente $578K em 29 de julho de 2026 devido a uma falha de lógica de negócio em seu contrato de token. Um caminho acessível pelo atacante podia acionar sua função privilegiada recycle(), permitindo que o contrato Rental transferisse LULA diretamente para fora do par PancakeSwap V2 e, em seguida, chamasse sync(), atualizando as reservas do par para os saldos manipulados. O atacante acionou repetidamente recycle() para reduzir a reserva de LULA do par a quase zero, e então trocou uma pequena quantidade de LULA por quase todo o seu USDT [1].

Contexto

A LULA é um token BEP-20 na BNB Chain com um mecanismo de recompensa de equipe baseado em aluguel (rental). Endereços elegíveis acumulam recompensas de equipe pendentes em um contrato Rental e as reivindicam por meio de claimTeamReward(). Durante o fluxo de reivindicação, o contrato Rental chama a função recycle() do token para obter LULA para distribuição de recompensas. recycle() não pode ser chamada por usuários arbitrários; apenas o contrato Rental está autorizado a executá-la.

O ponto de entrada claimTeamReward() contém uma verificação "apenas EOA". Ele suporta chamadas diretas de contas de propriedade externa em que msg.sender == tx.origin, e também suporta chamadas delegadas EIP-7702 ao inspecionar o prefixo de código delegado.

Em um formador de mercado automatizado (AMM), um par precifica trocas com base em suas reservas armazenadas, e essas reservas são atualizadas por meio da função sync() do par, que as define de acordo com os saldos atuais de tokens do par. As reservas normalmente acompanham negociações genuínas porque se movem com trocas e eventos de liquidez, mas o saldo de token de um par também pode ser alterado por uma transferência direta, e sync() copia qualquer saldo presente, manipulado ou não, para as reservas armazenadas.

Análise da Vulnerabilidade

A causa raiz foi que LULA.recycle() permite que o contrato Rental transfira LULA diretamente para fora do par PancakeSwap V2 e, em seguida, chame sync(), atualizando as reservas do par para os saldos manipulados [1].

Como sync() define as reservas conforme o saldo de LULA que permanece no par, esse caminho privilegiado pode levar a reserva de LULA do par a um valor arbitrariamente baixo, deixando o lado do USDT intocado. Uma vez que a reserva de LULA esteja próxima de zero, o par precifica uma pequena quantidade de LULA como valendo quase todo o seu USDT.

Análise do Ataque

A análise a seguir é baseada na transação 0xa219ab9...411d7c.

Etapa 1: O atacante financiou a manipulação acumulando ~197,05M USDT. Os fundos vieram de múltiplas fontes de flash loan e empréstimo, incluindo Moolah/Lista, Aave V3, Venus, PancakeSwap V3, PancakeSwap Vault, Uniswap V4 PoolManager e Uniswap V3.
Etapa 2: O atacante usou os ~197,05M USDT para realizar uma grande troca USDT -> LULA por meio do router PancakeSwap V2. Isso reduziu drasticamente a reserva de LULA do par de cerca de 8M LULA para 24.022 LULA, enquanto aumentava o lado do USDT para aproximadamente 197,64M USDT.
Etapa 3: O atacante invocou o caminho de recompensa por meio de múltiplas carteiras EIP-7702. Cada carteira chamou claimTeamReward() no contrato Rental, que então acionou LULA.recycle(), reduzindo a reserva de LULA do par de 24.022 LULA para 0,004 LULA, enquanto o par ainda mantinha um lado de USDT muito grande.
Etapa 4: O atacante encaminhou uma troca final no PancakeSwap V2 através do router, enviando apenas ~4.749 LULA para o par e recebendo ~197,64M USDT.
Etapa 5: O atacante quitou todos os flash loans, lucrando aproximadamente $578K.

Conclusão

O token LULA na BNB Chain foi explorado por aproximadamente $578K através de uma falha de lógica de negócio em seu contrato de token: um caminho acessível pelo atacante podia acionar sua função privilegiada recycle(), permitindo que o contrato Rental transferisse LULA diretamente para fora do par PancakeSwap V2 e, em seguida, chamasse sync(), resincronizando as reservas do par com os saldos manipulados. O atacante acionou isso repetidamente para distorcer o preço do par e trocar uma pequena quantidade de LULA por quase todo o seu USDT.

Um contrato de token nunca deve expor um caminho privilegiado que possa mover os saldos de um par AMM e forçar uma resincronização de reservas, pois isso entrega o controle de preço a quem conseguir acessar esse caminho. Tokens que se integram com pares AMM devem manter as reservas do par vinculadas a mudanças de saldo genuínas, orientadas pelo mercado, e qualquer lógica que leia as reservas do pool para precificação deve tratá-las como manipuláveis, e não como autoritativas.

Referências

[1] Análise da BlockSec Phalcon sobre a exploração da LULA

Sobre a BlockSec

A BlockSec é uma provedora full-stack de segurança blockchain e conformidade cripto. Desenvolvemos produtos e serviços que ajudam os clientes a realizar auditoria de código (incluindo contratos inteligentes, blockchain e carteiras), interceptar ataques em tempo real, analisar incidentes, rastrear fundos ilícitos e cumprir obrigações de AML/CFT, ao longo de todo o ciclo de vida de protocolos e plataformas.

A BlockSec publicou diversos artigos de segurança em blockchain em conferências prestigiosas, reportou vários ataques de dia zero em aplicações DeFi, bloqueou múltiplos hacks para resgatar mais de 20 milhões de dólares e protegeu bilhões de dólares em criptomoedas.