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

Em 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 para várias exchanges centralizadas (CEX) e descentralizadas (DEX). Assim que o ataque foi detectado, investigamos e analisamos o incidente junto com a UXLINK e monitoramos o fluxo dos fundos. A UXLINK entrou em contato urgentemente com as principais exchanges para solicitar o congelamento dos fundos suspeitos, já reportou o caso à polícia e às autoridades competentes para buscar suporte legal e recuperação dos ativos. A maior parte dos ativos dos hackers já foi marcada e congelada pelas exchanges, minimizando assim o risco de danos adicionais à comunidade. A equipe do projeto prometeu manter a transparência com a comunidade, e a ExVul continuará acompanhando e analisando o desenvolvimento do caso.

（）

Últimos Desenvolvimentos

No processo de movimentação dos fundos dos hackers, os valores enviados para as exchanges já foram congelados. Através de um rastreamento preliminar on-chain, foi descoberto que o hacker que roubou os ativos da UXLINK anteriormente pode ter sido 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. Anteriormente, devido a operações maliciosas do Owner multiassinatura ou ao vazamento da chave privada, um endereço malicioso foi adicionado como membro da multiassinatura, e o limiar de assinaturas (threshold) do contrato foi redefinido para 1, ou seja, apenas uma assinatura era necessária para executar operações no contrato. O hacker definiu o novo endereço Owner como 0x2EF43c1D0c88C071d242B6c2D0430e1751607B87.

()

2. O atacante primeiramente 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 da 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, através de um delegatecall executado no contrato proxy, chama o contrato de implementação MultiSend, fazendo com que ele execute multiSend no contexto do proxy; em seguida, multiSend, de acordo com os parâmetros construídos pelo atacante, faz uma chamada (call) de volta ao próprio contrato Gnosis Safe Proxy e aciona a função removeOwner, removendo assim o endereço Owner existente.

()

5. O sucesso da chamada depende da condição msg.sender== address(this). Na função removeOwner, para evitar chamadas externas diretas, o contrato implementa uma verificação authorized, cuja lógica interna normalmente exige que o chamador seja o próprio contrato (msg.sender == address(this)). Portanto, apenas 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, comprometendo o mecanismo multiassinatura e, por fim, assumindo o controle do contrato.

7. Assim, o atacante, ao repetir continuamente os passos acima, fez com que o mecanismo de segurança multiassinatura original falhasse completamente. Neste ponto, 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 ao vazamento da chave privada, o atacante adicionou um endereço malicioso como membro da multiassinatura e definiu o threshold do Gnosis Safe Proxy para 1, tornando o design de segurança multiassinatura ineficaz. Após isso, apenas o Owner malicioso conseguia passar pela verificação multiassinatura. O atacante então removeu gradualmente os outros Owners do contrato, assumiu o controle total do contrato e transferiu os ativos, além de cunhar tokens $UXLINK de forma maliciosa on-chain.

Este ataque destaca o papel fundamental da gestão multiassinatura na segurança blockchain. Embora o projeto tenha adotado o mecanismo Safe multiassinatura e configurado várias contas, falhas na gestão tornaram o design 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 diversificação dos métodos de armazenamento das chaves, garantindo assim que o mecanismo multiassinatura cumpra efetivamente sua função de proteção.

Apêndice

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