Análise técnica do roubo de aproximadamente 11,3 milhões de dólares da UXLINK

Título original: "Análise Técnica do Roubo de Aproximadamente 11,3 Milhões de Dólares da UXLINK"
Fonte original: ExVul Security

Descrição do Evento

No dia 23 de setembro, a chave privada da carteira multiassinada do projeto UXLINK foi vazada, resultando no roubo de aproximadamente 11,3 milhões de dólares em criptoativos, que já foram dispersos e transferidos para várias exchanges centralizadas (CEX) e descentralizadas (DEX). Assim que o ataque foi detectado, colaboramos com a UXLINK para investigar e analisar o incidente, além de monitorar o fluxo dos fundos. A UXLINK entrou em contato de forma emergencial com as principais exchanges para solicitar o congelamento dos fundos suspeitos, já reportou o caso à polícia e às instituições relevantes em busca de suporte legal e recuperação dos ativos. A maior parte dos ativos do hacker já foi marcada e congelada pelas exchanges, minimizando assim os riscos adicionais para a comunidade. A equipe do projeto se comprometeu a manter a transparência com a comunidade, e a ExVul continuará acompanhando e analisando o desenvolvimento do caso.

()

Últimos Desenvolvimentos

Durante o fluxo dos fundos do hacker, os valores que entraram nas exchanges foram congelados. Através de um rastreamento preliminar on-chain, foi descoberto que o hacker que anteriormente roubou os ativos da UXLINK aparentemente foi vítima de um ataque de phishing do Inferno
Drainer. Após verificação, cerca de 542 milhões de tokens $UXLINK obtidos ilegalmente foram roubados por meio de uma técnica de "phishing de autorização".

Análise do Ataque

1. O contrato anterior apresentava operações maliciosas do Owner multiassinatura ou vazamento de chave privada, permitindo que um endereço malicioso fosse adicionado como membro multiassinatura. Além disso, o limiar de assinaturas (threshold) do contrato foi redefinido para 1, ou seja, apenas uma assinatura era suficiente para executar operações no contrato. O hacker definiu o novo endereço Owner como 0x2EF43c1D0c88C071d242B6c2D0430e1751607B87.

()

2. O atacante inicialmente chamou a função execTransaction do contrato Gnosis Safe Proxy. Esta função serviu como ponto de entrada para a remoção maliciosa de membros multiassinatura, e todas as operações maliciosas subsequentes foram executadas internamente nesta transação.

()

3. Ao chamar execTransaction, o atacante especificou uma operação maliciosa no parâmetro data: uma chamada delegatecall para o contrato de implementação Safe: Multi Send Call
Only 1.3.0.

()

4. Na função multiSend do Safe: Multi Send Call Only 1.3.0, o fluxo de execução retorna ao contrato Gnosis Safe Proxy para a função removeOwner. O processo específico é: o atacante, por meio de um delegatecall executado no contrato proxy, chama o contrato de implementação MultiSend, fazendo com que ele execute multiSend no contexto do contrato proxy; em seguida, multiSend, de acordo com os parâmetros construídos pelo atacante, faz uma chamada (call) de retorno ao próprio contrato Gnosis Safe Proxy e aciona a função removeOwner, removendo assim os endereços Owner existentes.

()

5. O núcleo para que a chamada seja bem-sucedida está em satisfazer a condição msg.sender== address(this). Na função removeOwner, para evitar chamadas externas diretas, o contrato implementa uma verificação de autorização, cuja lógica interna normalmente exige que o chamador seja o próprio contrato (msg.sender == address(this)). Portanto, somente quando o fluxo interno do contrato retorna para si mesmo, removeOwner pode ser executado com sucesso.

6. O hacker, utilizando o método acima, removeu um a um os outros Owners da multiassinatura, destruindo o mecanismo multiassinatura e assumindo o controle do contrato.

7. Até este ponto, o atacante, ao repetir continuamente os passos acima, fez com que o mecanismo de segurança multiassinatura original se tornasse completamente ineficaz. Neste momento, apenas a assinatura do Owner malicioso era suficiente para passar pela verificação multiassinatura, permitindo o controle total do contrato.

()

Resumo

Devido a operações maliciosas do Owner multiassinatura ou vazamento de chave privada, o atacante adicionou um endereço malicioso como membro multiassinatura e definiu o limiar de assinaturas (threshold) do Gnosis Safe Proxy para 1, tornando o design de segurança multiassinatura original completamente ineficaz. A partir daí, apenas o Owner malicioso conseguia passar pela verificação multiassinatura. O atacante então removeu gradualmente os outros Owners do contrato, assumindo o controle total do contrato e transferindo os ativos, além de cunhar maliciosamente tokens $UXLINK on-chain.

Este ataque destaca o papel fundamental da gestão multiassinatura na segurança blockchain. Apesar do projeto ter adotado o mecanismo Safe multiassinatura e configurado múltiplas contas, falhas na gestão tornaram o design multiassinatura ineficaz. A equipe ExVul recomenda que os projetos busquem a máxima descentralização na gestão multiassinatura, como a custódia das chaves privadas por diferentes membros e a adoção de métodos diversificados de armazenamento de chaves, garantindo que o mecanismo multiassinatura cumpra efetivamente sua função de proteção de segurança.

Apêndice

A seguir, os endereços suspeitos de hackers rastreados on-chain pela equipe ExVul: