Durante a semana passada (27/07/2026 - 02/08/2026), os 2 incidentes de segurança notáveis a seguir estão em destaque, representando juntos 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 com Defeito | ~1.370 BTC (~$88M)* |
* A perda do COLDCARD varia de acordo com o método de confirmação: os ~1.370 BTC (~$88M) exibidos representam o mínimo verificável publicamente on-chain (coldcardwatch.com); a reconciliação por canais privados (Galaxy Research, a partir de correspondência com 73 vítimas) aponta para um valor maior, de aproximadamente 1.596 BTC e até ~2.055 BTC (~$130M) quando drenagens suspeitas mas não confirmadas são incluídas.
Motivos da seleção
- LULA: Uma função de token privilegiada capaz de mover os saldos de um par AMM e forçar uma ressincronização de reservas torna-se uma primitiva repetível de drenagem de liquidez por meio de manipulação de preços.
- COLDCARD: Um erro de compilação e integração no firmware da carteira redirecionou silenciosamente a geração de seed para 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 grandes perdas de fundos.
Melhor Auditor de Segurança para Web3
Valide design, código e lógica de negócio antes do lançamento
Destaque da Semana: COLDCARD
Selecionamos o COLDCARD como destaque desta semana porque um bug de entropia em carteira produziu a maior perda do período. A causa raiz — uma guarda de compilação que verificava se uma macro de configuração existia em vez de verificar se estava habilitada — é o tipo de erro silencioso de integração que testes funcionais não conseguem detectar, e a lição se aplica a qualquer sistema em que a segurança on-chain depende de aleatoriedade off-chain.
O COLDCARD, uma carteira de hardware para Bitcoin, lançou um firmware em 2021 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 as carteiras afetadas foram esvaziadas 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 relatórios confirmados por canais privados elevam o valor para cerca de 1.596 BTC [4]. A causa raiz foi um erro de compilação e configuração que redirecionou 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
O COLDCARD é uma carteira de hardware para Bitcoin. As chaves privadas e os 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 repousa sobre duas propriedades dessa seed: que ela permaneça secreta e que seja imprevisível no momento da geração. As carteiras de hardware existem em grande parte para proteger a primeira; este incidente é uma falha da segunda. Uma frase de 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 poderá ser reproduzida. A intuição é a de um cofre cuja combinação é escolhida jogando dados: se os dados forem viciados, o cofre fica aberto para qualquer pessoa que conheça o viés, independentemente da resistência do cadeado.
Para uma carteira, "dados viciados" significa um gerador de números aleatórios fraco. Espera-se que as carteiras de hardware obtenham a entropia da seed de um gerador de números verdadeiramente aleatórios (TRNG) de hardware em seu microcontrolador seguro, pois um gerador pseudo-aleató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 do COLDCARD expunha duas superfícies de RNG separadas. O MicroPython fornecia uma camada de plataforma STM32 que expunha o símbolo global rng_get() esperado pela biblioteca criptográfica da carteira, enquanto o COLDCARD também mantinha seu próprio wrapper de RNG de hardware local da placa. Ambas as superfícies destinam-se a fornecer entropia de hardware, e a biblioteca criptográfica da carteira acessa uma delas por meio de um único símbolo de RNG global resolvido no momento da compilação do firmware.
Análise de Vulnerabilidade
A causa raiz foi um erro de compilação e integração em torno da macro de configuração MICROPY_HW_ENABLE_RNG. A configuração de produção da placa do COLDCARD definia essa macro como 0, pois o firmware pretendia usar seu próprio wrapper de RNG de hardware local da 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()
-> Módulo RNG STM32 do MicroPython
-> Fallback de software Yasmarang porque MICROPY_HW_ENABLE_RNG == 0A configuração da placa desabilitava o ramo 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 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"
#endifEssa guarda não cobre o caso perigoso: uma macro definida como 0 ainda está definida, portanto a verificação com #ifndef passa e a compilação é bem-sucedida. Como o MicroPython seleciona sua implementação de RNG pelo valor da macro, e não pela sua existência, MICROPY_HW_ENABLE_RNG == 0 redirecionava rng_get() para o ramo de fallback de software em vez do wrapper local da placa do COLDCARD [6]:
#if MICROPY_HW_ENABLE_RNG
// STM32 hardware RNG
#else
// Yasmarang software fallback
#endifAs consequências variam de acordo com a geração do 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 do Mk2/Mk3 de forma ligeiramente mais estreita, como v4.0.1-v4.1.9). Para o Mk4/Q/Mk5, material do elemento seguro foi incluído via hash, mas apenas quatro bytes foram 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. Aplicar hash aos 32 bytes aleatórios finais não pode aumentar a entropia do resultado; apenas transforma um conjunto de candidatos já limitado.
Análise do Ataque
Ao contrário de uma exploração de contrato inteligente, este incidente não tem uma única transação de ataque on-chain para rastrear. Foi um problema de recuperação de seed offline seguido de varrimentos on-chain. A pré-condição era que os usuários afetados tinham gerado as seeds de suas carteiras pelo caminho vulnerável ngu.random.bytes(32), de modo que o material de seed dependia de um estado de fallback de software reproduzível, e não de entropia de hardware completa. Uma segunda pré-condição inferida é que as carteiras afetadas eram deriváveis apenas da seed: uma senha BIP-39 forte e única mistura entropia independente fornecida pelo usuário por meio de PBKDF2, que a falha do RNG nunca tocou, colocando tais carteiras fora da enumeração pura de seed; e a escala dos varrimentos sugere que a maioria dos usuários afetados não havia definido tal senha. A partir daí, a recuperação provavelmente procedeu em três etapas:
- O atacante restringiu ou enumerou estados candidatos do RNG usando metadados do dispositivo, tempo de inicialização, suposições de RTC/SysTick e histórico plausível de chamadas do RNG.
- Para cada estado candidato, o atacante derivou seeds candidatas de carteira e as verificou offline contra dados públicos da carteira, como endereços, xpubs ou chaves públicas geradas.
- Uma vez que um candidato correspondeu a uma carteira real, o atacante recuperou a seed, reconstruiu as chaves privadas e varreu o BTC associado.
On-chain, o roubo apareceu como uma rajada de varrimentos de endereços a partir de 30 de julho. O rastreamento heurístico on-chain independente [3] identifica diversas ondas de drenagem totalizando pelo menos 1.370 BTC (aproximadamente $88M, avaliando as moedas ao preço de $64.099 em 5 de agosto) varridos de 4.580 endereços verificados — um mínimo verificado, e não um total. Enquanto isso, um canal privado [4], confirmado por correspondência com 73 vítimas, eleva o valor para cerca de 1.596 BTC, chegando a 2.055 BTC (~$130M) quando drenagens suspeitas mas não confirmadas são adicionadas.
Conclusão
O incidente do COLDCARD foi uma falha na geração de entropia: a API de geração de seed crítica para a segurança silenciosamente resolveu para um fallback de PRNG de software determinístico em vez do RNG de hardware pretendido, porque uma guarda de compilação verificava se uma macro de configuração existia em vez de verificar 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 (contagens por canais privados apontam para aproximadamente 1.596 a 2.055 BTC [4]).
A falha central de engenharia é que o firmware entregue nunca provou 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: guardas de compilação para entropia criptográfica devem verificar tanto a existência quanto o valor da macro; fallbacks de entropia devem falhar de forma fechada em vez de substituir silenciosamente por um PRNG de software; e a verificação da imagem final do firmware deve cobrir a proveniência de símbolos e o fluxo de entropia de ponta a ponta, não apenas que o código compila. Uma seed afetada não pode ser corrigida no lugar; seus fundos devem ser movidos para uma carteira criada em firmware corrigido, e uma senha forte e única reduz a exposição imediata sem reparar a seed [2].
O modo de falha merece ser destacado: bugs de aleatoriedade desse tipo são invisíveis para testes funcionais porque cada seed gerada é individualmente válida. O defeito não está em nenhuma saída individual, mas na fonte que as produziu: como essa fonte é previsível e reproduzível, as seeds coletivamente caem 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
- [1] Alerta do BlockSec Phalcon vinculando a drenagem da carteira COLDCARD à fraca aleatoriedade na geração de seed
- [2] Coinkite, Análise Técnica Aprofundada sobre o Problema de Entropia
- [3] coldcardwatch.com, Coldcard Sweep Watch: rastreamento on-chain de endereços drenados e metodologia
- [4] Galaxy Research, estimativa de perdas no hack do COLDCARD (~1.596 BTC confirmados via relatos de vítimas)
- [5] libngu, o caminho de RNG STM32 referencia o
rng_get()global e usa apenas#ifndef MICROPY_HW_ENABLE_RNGcomo guarda - [6] MicroPython do Coldcard,
rng_get()recai para Yasmarang quando o RNG de hardware está desabilitado - [7] Block Engineering, Fallback de RNG Previsível e Reseed de 32 Bits no Firmware do COLDCARD
Comece a usar o Phalcon Explorer
Mergulhe nas Transações para Agir com Sabedoria
Experimente agora gratuitamenteMais Incidentes desta Semana
LULA
O 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 do par PancakeSwap V2 e então chamasse sync(), atualizando as reservas do par com os saldos manipulados. O atacante acionou recycle() repetidamente para reduzir a reserva de LULA do par quase a zero, e então trocou uma pequena quantidade de LULA de volta por quase todo o USDT do par [1].
Contexto
O LULA é um token BEP-20 na BNB Chain com um mecanismo de recompensa de equipe baseado em aluguel. 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 de "somente EOA". Ele suporta chamadas diretas de contas de propriedade externa onde msg.sender == tx.origin, e também suporta chamadas delegadas EIP-7702 inspecionando o prefixo do código delegado.
Em um criador de mercado automatizado (AMM), um par precifica swaps a partir de suas reservas armazenadas, e essas reservas são atualizadas por meio da função sync() do par, que as define como os saldos atuais de tokens do par. As reservas normalmente acompanham negociações genuínas porque se movem com swaps e eventos de liquidez, mas o saldo de tokens 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 de Vulnerabilidade
A causa raiz foi que LULA.recycle() permite que o contrato Rental transfira LULA diretamente do par PancakeSwap V2 e então chame sync(), atualizando as reservas do par com os saldos manipulados [1].
Como sync() define as reservas para qualquer saldo de LULA que permaneça no par, esse caminho privilegiado pode reduzir a reserva de LULA do par a um valor arbitrariamente baixo enquanto deixa o lado do USDT intacto. Uma vez que a reserva de LULA está próxima de zero, o par precifica uma pequena quantidade de LULA como equivalente a 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 empréstimo relâmpago 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 um grande swap
USDT -> LULApelo roteador 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 acionouLULA.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 roteou um swap final pelo PancakeSwap V2 por meio do roteador, enviando apenas ~4.749 LULA para o par e recebendo ~197,64M USDT em troca.
- Etapa 5: O atacante reembolsou todos os empréstimos relâmpago, lucrando aproximadamente $578K.
Conclusão
O token LULA na BNB Chain foi explorado por aproximadamente $578K por meio 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 do par PancakeSwap V2 e então chamasse sync(), ressincronizando 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 de volta 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 ressincronização de reservas, pois isso entrega o controle do preço a quem puder acessar esse caminho. Tokens que se integram com pares AMM devem manter as reservas do par vinculadas a mudanças de saldo genuínas e 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.
