Estou curioso sobre o que exatamente foi o ataque por meio da ferramenta de IA interna da Binance, pois parece ser algo importante e potencialmente útil como referência para outras pessoas. Parece que há pouca divulgação pública sobre como ataques por meio de ferramentas de IA internas ocorrem e como devem ser combatidos.
Criei um novo modelo de segurança, enquanto acordava, para evitar eventos semelhantes a vazamentos em outras exchanges; anotei como memorando. Por enquanto, estou validando a ideia com IA e, se parecer adequado, talvez consulte alguns indivíduos.
Aviso de segurança do BTCPay Server
A Binance está começando gradualmente a retirar fundos; presumo que, logicamente, considere que a segurança interna esteja garantida e que não haja risco de novos ataques ou roubo de ativos. No entanto, ainda não houve nenhum anúncio sobre os detalhes do ataque, sua causa ou as medidas atuais de segurança implementadas.
Foi lançado o update #3 sobre o incidente de segurança da Binance, mas não há informações sobre como o ataque ocorreu, apenas sobre reembolsos e outros assuntos relacionados.
Se houver uma fuga de fundos da exchange, o problema é resolvido se os usuários forem integralmente indenizados? O dinheiro roubado da Binance pode se transformar em mísseis da Coreia do Norte. Por isso, esta fuga de aproximadamente 1 trilhão de ienes (cerca de 6,3 bilhões de dólares) diz respeito até mesmo às pessoas que não possuem nenhum ativo cripto. O FBI dos EUA determinou que este incidente foi cometido pela Coreia do Norte. Os governos do Japão, EUA e Coreia do Sul já apontaram anteriormente que roubo de ativos criptográficos serve como fonte de financiamento para o desenvolvimento nuclear e de mísseis da Coreia do Norte. Mesmo que a Binance compense integralmente os usuários, seus ativos estarão protegidos. Contudo, o dinheiro usado para a indenização virá da própria Binance. O dinheiro roubado pela Coreia do Norte não diminui em um único iene com isso. Segundo a declaração da Binance, até 30 de outubro, apenas cerca da metade do valor roubado foi congelado. Por outro lado, o FBI já confirmou que os criminosos trocaram os ativos roubados por Ether (ETH) e pediu às empresas que interrompam as transações relacionadas. É tão importante acompanhar “quanto foi recuperado antes de a Coreia do Norte conseguir usá-lo” quanto “quanto foi indenizado aos usuários”. Para o Japão, este é um problema de segurança nacional.
Será que a Binance implementou algo como o policy engine da Fireblocks? Atualmente, parece que não existe, mas não há nenhuma evidência.
Serviço de custódia do Google Pessoalmente, é um vento favorável enorme, estou mais do que feliz
Foi relatada uma vulnerabilidade (RUSTSEC-2026-0387) no crate de cálculo criptográfico Rust, crypto-bigint, que pode levar a ataques de temporização (ataques de canal lateral). Não se trata apenas de uma simples recomendação de atualização — produtos que adotam stacks principais da Web3/EVM, como o Alloy, são diretamente afetados. Por isso, compartilhamos esta análise e alerta para esclarecer a situação. 1. Visão geral da vulnerabilidade Crate afetado: crypto-bigint (biblioteca de operações de inteiro de tamanho fixo) Problema: Em operações internas como subtração e multiplicação de Montgomery, bifurcações condicionais podem ocorrer devido à otimização do compilador, resultando em variações de tempo de execução dependentes dos dados de entrada. Risco: Atacantes podem medir com precisão tempos de execução em milissegundos ou microssegundos para inferir ou recuperar informações confidenciais, como chaves privadas (ataque de temporização). 2. Por que “não é possível atualizar imediatamente”? Embora uma versão corrigida (v0.7.6) do crypto-bigint já tenha sido lançada, há bloqueios nas dependências de bibliotecas upstream. O Alloy, amplamente utilizado em torno do EVM/Ethereum, depende da biblioteca criptográfica k256 v0.13. Atualmente, a k256 v0.13 ainda não acompanhou a atualização para o crypto-bigint v0.7.6 (ou está aguardando liberação). Assim, simplesmente executar cargo update não resolve o problema — a estrutura de bloqueio das dependências mantém versões antigas. 3. Próximos passos e procedimentos de verificação Visualização do impacto: Execute primeiro cargo tree -i crypto-bigint ou cargo audit para identificar quais caminhos (ex: alloy -> k256) introduzem essa dependência em seu projeto. Monitoramento das atualizações upstream: Acompanhe os PRs de atualização (bump) na k256 e no alloy. Consideração de soluções alternativas: Se for necessário agir imediatamente, verifique a possibilidade de substituir forçadamente as dependências usando [patch.crates-io] no Cargo.toml. É esperado um certo atraso antes que a correção se espalhe por todo o ecossistema Rust/Web3. Recomendamos fortemente que usuários desses stacks monitorem o comportamento de suas árvores de dependência. ▼ Advisory do RustSec https://t.co/FJSYIOHwtH #Rust #RustLang #Web3 #Alloy #Ethereum #Security #Criptografia