Eu acabei de dar uma olhada de novo, por acaso, nos comunicados de incidentes de segurança da Dusk Network de janeiro. A princípio, eu só queria entender o que tinha acontecido na época; mas, no fim, fiquei pensando numa questão: por que as palavras usadas no anúncio inicial e os detalhes do relatório posterior parecem tão diferentes?
No dia 17 de janeiro, a Dusk disse que a monitoração identificou “atividades anormais” nas carteiras gerenciadas pela equipe. Depois disso, suspendeu o serviço de bridge, desativou e recriou os endereços relacionados e enfatizou que “nenhum fundo do usuário foi afetado”.
Se você olhar apenas para esse comunicado, o incidente parece bastante limitado.
Mas a análise pós-evento de 10 de março trouxe mais detalhes. A Dusk afirmou que o invasor obteve acesso não autorizado a uma carteira com assinatura; em seguida, apareceram várias transferências de DUSK on-chain, incluindo 9.000, 89.700, 2,74 milhões e cerca de 8,068 milhões de DUSK. Parte dos fundos também foi transferida via bridge para a BNB Smart Chain, e a última tentativa de bridge — cerca de 8,91 milhões de DUSK — falhou depois que a ponte foi fechada.
Aqui existe, na verdade, uma diferença de informação bem interessante.
A Dusk diz que os fundos dos usuários não foram afetados; isso não entra em conflito com o processo de ataque posteriormente divulgado. Mas a ideia de “não houve perda para o usuário” é totalmente diferente da impressão que se tem ao ver que “centenas de milhões de tokens chegaram a ser transferidos”.
O que mais me chama a atenção, porém, é o problema de arquitetura. Mais tarde, a Dusk admitiu que o projeto antigo deixava a assinatura, o tratamento de eventos e a conexão de rede em um caminho de operação relativamente concentrado; depois disso, separou e reforçou esses componentes.
Talvez seja apenas um fluxo normal de comunicação de incidentes de segurança, e eu não quero tirar conclusões apenas com base nas palavras.
Mas se o objetivo da Dusk é atender à privacidade do serviço e a aplicações financeiras em conformidade, então onde exatamente está o limite de segurança — e quanto de risco real os usuários conseguem ver — vale uma investigação séria.
Se alguém acompanhou essas transações on-chain, o fluxo de assinatura do bridge ou as mudanças de arquitetura posteriores, eu realmente gostaria de saber: o que vocês descobriram de verdade?
#dusk $DUSK @Dusk
No dia 17 de janeiro, a Dusk disse que a monitoração identificou “atividades anormais” nas carteiras gerenciadas pela equipe. Depois disso, suspendeu o serviço de bridge, desativou e recriou os endereços relacionados e enfatizou que “nenhum fundo do usuário foi afetado”.
Se você olhar apenas para esse comunicado, o incidente parece bastante limitado.
Mas a análise pós-evento de 10 de março trouxe mais detalhes. A Dusk afirmou que o invasor obteve acesso não autorizado a uma carteira com assinatura; em seguida, apareceram várias transferências de DUSK on-chain, incluindo 9.000, 89.700, 2,74 milhões e cerca de 8,068 milhões de DUSK. Parte dos fundos também foi transferida via bridge para a BNB Smart Chain, e a última tentativa de bridge — cerca de 8,91 milhões de DUSK — falhou depois que a ponte foi fechada.
Aqui existe, na verdade, uma diferença de informação bem interessante.
A Dusk diz que os fundos dos usuários não foram afetados; isso não entra em conflito com o processo de ataque posteriormente divulgado. Mas a ideia de “não houve perda para o usuário” é totalmente diferente da impressão que se tem ao ver que “centenas de milhões de tokens chegaram a ser transferidos”.
O que mais me chama a atenção, porém, é o problema de arquitetura. Mais tarde, a Dusk admitiu que o projeto antigo deixava a assinatura, o tratamento de eventos e a conexão de rede em um caminho de operação relativamente concentrado; depois disso, separou e reforçou esses componentes.
Talvez seja apenas um fluxo normal de comunicação de incidentes de segurança, e eu não quero tirar conclusões apenas com base nas palavras.
Mas se o objetivo da Dusk é atender à privacidade do serviço e a aplicações financeiras em conformidade, então onde exatamente está o limite de segurança — e quanto de risco real os usuários conseguem ver — vale uma investigação séria.
Se alguém acompanhou essas transações on-chain, o fluxo de assinatura do bridge ou as mudanças de arquitetura posteriores, eu realmente gostaria de saber: o que vocês descobriram de verdade?
#dusk $DUSK @Dusk