RT @dobsec: "Nenhuma pessoa normal usa uma VPN" mostra que ele claramente não viu os bilhões de criadores promovendo VPNs em cada vídeo.

BlockThreat - Semana 28, 2025 💙 Patrocinado por @SecurityOak 🔥 Exploração em massa de contratos proxy descoberta por @deeberiroz e whitehatted por @pcaversaccio @dedaub e @_SEAL_Org 💸 Hack de reentrância @GMX_IO $42M ($37M recuperados) 💸 @KintoXYZ proxy não inicializado. $1.55M

Lições para especialistas em segurança: Auditem rigorosamente as inicializações de proxy. Monitorem as cadeias de delegatecall (fácil de fazer na nossa aplicação) e garantam a integridade do armazenamento com padrões de proxy complexos. Agradecimentos a @deeberiroz @VennBuild @pcaversaccio @_SEAL_Org Mantenham-se vigilantes.

então descobri que é ainda mais sofisticado. Observei que a transação de frontrunning (pelos atacantes) chama `initialize` e os protocolos também chamam _com sucesso_ `initialize` depois (assim eles pensam que está tudo normal). Mas espere, como isso é até possível? Tive que olhar muito profundamente nas mudanças dos slots de armazenamento e adivinha o que encontrei: eles _resetaram_ o valor do slot de armazenamento `_initialized` no final da transação de frontrunning (depois de trocarem para o contrato de implementação malicioso). Isso significa que o armazenamento do proxy agora parece que nunca foi inicializado. O slot de armazenamento relevante a ser observado é `keccak256(abi.encode(uint256(keccak256(" - 1)) & ~bytes32(uint256(0xff))` = `0xf0c57e16840df040f15088dc2f81fe391c3923bec73e23a9662efc9c229c6a00` Isto é maldade de nível superior.

No início desta semana, foi identificada uma potencial vulnerabilidade no contrato de gestor de cross-chain da Orderly na cadeia BNB. Em resposta, o nosso cofre BNB para depósitos e levantamentos foi imediatamente pausado, os contratos foram migrados e os depósitos/levantamentos foram retomados em 2 horas. ✅ Nenhum fundo de utilizador está em risco ou foi perdido. Agradecimentos especiais a @deeberiroz, @VennBuild, @seal_911, @pcaversaccio e ao resto da equipa que ajudou a sinalizar isto! Mais seguros juntos 🤝

[5/5] Chamada de gratidão • @SlowMist_Team pela triagem e correção ininterruptas • @dedaub, @pcaversaccio, e a sala de guerra @seal_911 por uma varredura de código de 36 horas • @etherscan pela limpeza de UI super rápida • E novamente, obrigado @deeberiroz, @VennBuild, @davidberiro—o seu aviso salvou o dia 💙

Fica ainda mais sofisticado: a forma como o Etherscan foi enganado a mostrar o contrato de implementação errado baseia-se na definição de 2 slots de proxy diferentes na mesma transação de frontrunning. Assim, o Etherscan utiliza uma certa heurística que incorpora diferentes slots de armazenamento para recuperar o contrato de implementação. Há um proxy antigo da OpenZeppelin que usou o seguinte slot: `keccak256("org.zeppelinos.proxy.implementation")` = `0x7050c9e0f4ca769c69bd3a8ef740bc37934f8e2c036e5a723fd8ee048ed3f8c3` Agora também temos o slot padrão EIP-1967 `bytes32(uint256(keccak256('eip1967.proxy.implementation')) - 1)` = `0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc` O que aconteceu foi que o slot do proxy antigo da OpenZeppelin foi escrito com o endereço de implementação benigno _e_ o slot padrão EIP-1967 também foi escrito com o endereço de implementação malicioso. Como o Etherscan consulta primeiro o slot do proxy antigo, ele recuperou o que parecia benigno primeiro e, assim, o exibiu.

RT @devops199fan: .@seal_911 serve basicamente como o centro de operações de segurança global (GSOC) voluntário do crypto temos sorte de ter pessoas assim...

Não sei, mano, mas a verdadeira ameaça ao Ethereum não é o estado, na verdade (pelo menos não hoje). São os VCs e os carreiristas de protocolo tentando transformá-lo em um playground fintech brilhante para um DeFi "seguro" e em conformidade. Ouça-me: Eles não querem código imparável. Eles não querem resistência. Eles querem controle, caralho. Porque, no fundo, eles sabem o que o Ethereum poderia se tornar se fosse deixado sem correntes: uma camada de execução global resistente à censura e focada na privacidade que nenhum estado, nenhuma corporação, nenhum cartel de engravatados poderia parar. Vamos tornar isso uma realidade.

Então alguém te contacta no LinkedIn com uma oportunidade de emprego promissora. Parece bom, não é? Eles parecem legítimos (depois de os verificar por 1 min) e após uma breve conversa, enviam-te um repositório do GitHub com uma "tarefa de recrutamento" simples em Next.js. Tu clonas, executas... e 10 minutos depois, o teu dispositivo está totalmente comprometido ao descobrires que as tuas carteiras quentes foram drenadas. Ok, o que aconteceu? Dado o fato de que nós (= SEAL 911) já vimos este ataque repetidamente, deixe-me revelar alguns dos detalhes mais importantes: - primeiro, a advertência mais importante: NÃO executes código aleatório que algum desconhecido te enviou. Honestamente, não o faças. - verifica sempre os arquivos de configuração _executáveis_ dos repositórios minuciosamente. Neste caso particular, o arquivo `next.config.js` tinha um grande preenchimento escondendo a carga maliciosa muito à direita. - sempre rola horizontalmente - só porque não vês nada malicioso quando olhas para o conteúdo, não significa que esteja limpo. Importante: Código malicioso pode estar escondido dentro de arquivos em que confias, apenas não onde esperas encontrá-lo. Espero realmente que este tweet chegue a pessoas suficientes para prevenir pelo menos algumas futuras vítimas de caírem neste tipo de ataque.