Neste incidente de segurança da Binance, acho que há um detalhe que merece mais reflexão do que o desvio de ativos no valor de dezenas de bilhões de dólares.
Não foi confirmado que as chaves privadas tenham sido expostas, mas o atacante conseguiu transferir os ativos. Como isso foi possível?
Em termos simples, o incidente pode ter exposto um problema que muitos tendem a ignorar: a maior vulnerabilidade de segurança de uma exchange talvez não esteja na carteira, mas fora dela.
De acordo com as informações preliminares divulgadas pela Binance, o ataque pode ter começado com a invasão do notebook de um engenheiro de DevOps e, em seguida, afetado contêineres de serviços internos e o processo de saque.
Depois, a GCSA realizou uma análise forense on-chain, revisando 18 transações originais, 50 assinaturas de autorização inicial EIP-7702 e 1 assinatura de revogação de autorização.
Há um detalhe técnico que merece atenção: uma transação Type-4 pode conter 50 autorizações, mas isso não significa que todas as 50 tenham sido efetivadas. Uma assinatura válida também não significa que a chave privada tenha sido roubada.
O relatório também rastreou três transações consecutivas associadas ao MetaMask Gas Station e constatou que o valor do depósito de ETH anterior correspondia exatamente ao orçamento máximo de Gas das duas transações seguintes.
Quanto às alegações de que o atacante selecionou USDT por engano ou de que a MetaMask tinha acesso ao endereço IP real, não há, até o momento, evidências suficientes para sustentá-las.
A TRM Labs associou o incidente, com alto grau de confiança, ao grupo de ameaças TraderTraitor, ligado à Coreia do Norte. Isso, porém, não significa que a identidade do atacante e seu percurso operacional tenham sido completamente esclarecidos.
Sempre achei que a segurança de uma exchange não pode se concentrar apenas em carteiras frias, assinaturas múltiplas e chaves privadas.
Computadores de funcionários, permissões internas, ambientes de DevOps, serviços de assinatura, aprovações de saque e até infraestruturas de terceiros: uma falha em qualquer um desses pontos pode tornar ineficaz todo o sistema de segurança dos ativos.
Outro ponto: a estimativa de que o incidente afetou cerca de US$ 6,3 bilhões não equivale à perda líquida final, e congelar os ativos não significa recuperá-los.
O que realmente merece reflexão por parte de todo o setor é isto: quando um atacante não precisa obter diretamente as chaves privadas, mas ainda assim consegue movimentar os ativos, talvez os limites de segurança das exchanges, tal como os entendíamos até agora, já não sejam suficientes.
Não foi confirmado que as chaves privadas tenham sido expostas, mas o atacante conseguiu transferir os ativos. Como isso foi possível?
Em termos simples, o incidente pode ter exposto um problema que muitos tendem a ignorar: a maior vulnerabilidade de segurança de uma exchange talvez não esteja na carteira, mas fora dela.
De acordo com as informações preliminares divulgadas pela Binance, o ataque pode ter começado com a invasão do notebook de um engenheiro de DevOps e, em seguida, afetado contêineres de serviços internos e o processo de saque.
Depois, a GCSA realizou uma análise forense on-chain, revisando 18 transações originais, 50 assinaturas de autorização inicial EIP-7702 e 1 assinatura de revogação de autorização.
Há um detalhe técnico que merece atenção: uma transação Type-4 pode conter 50 autorizações, mas isso não significa que todas as 50 tenham sido efetivadas. Uma assinatura válida também não significa que a chave privada tenha sido roubada.
O relatório também rastreou três transações consecutivas associadas ao MetaMask Gas Station e constatou que o valor do depósito de ETH anterior correspondia exatamente ao orçamento máximo de Gas das duas transações seguintes.
Quanto às alegações de que o atacante selecionou USDT por engano ou de que a MetaMask tinha acesso ao endereço IP real, não há, até o momento, evidências suficientes para sustentá-las.
A TRM Labs associou o incidente, com alto grau de confiança, ao grupo de ameaças TraderTraitor, ligado à Coreia do Norte. Isso, porém, não significa que a identidade do atacante e seu percurso operacional tenham sido completamente esclarecidos.
Sempre achei que a segurança de uma exchange não pode se concentrar apenas em carteiras frias, assinaturas múltiplas e chaves privadas.
Computadores de funcionários, permissões internas, ambientes de DevOps, serviços de assinatura, aprovações de saque e até infraestruturas de terceiros: uma falha em qualquer um desses pontos pode tornar ineficaz todo o sistema de segurança dos ativos.
Outro ponto: a estimativa de que o incidente afetou cerca de US$ 6,3 bilhões não equivale à perda líquida final, e congelar os ativos não significa recuperá-los.
O que realmente merece reflexão por parte de todo o setor é isto: quando um atacante não precisa obter diretamente as chaves privadas, mas ainda assim consegue movimentar os ativos, talvez os limites de segurança das exchanges, tal como os entendíamos até agora, já não sejam suficientes.