~US$ 542 mil perdidos: ataque ao MakerDaoBot | Boletim semanal da BlockSec

Durante a última semana (2026/10/05 - 2026/10/11), observamos 1 incidente de segurança, com uma perda total estimada em aproximadamente US$ 542 mil.

Destaque da semana: MakerDaoBot

Em 6 de outubro de 2026, um invasor explorou a falta de controle de acesso no MakerDaoBot, um bot de liquidação legado da MakerDAO na Ethereum, e retirou 200 ETH, avaliados em aproximadamente US$ 542 mil. A função vulnerável permitia que qualquer pessoa fornecesse um contrato externo, concedesse a ele controle sobre os saldos do bot e executasse seu código. O invasor usou esse caminho para liquidar quatro leilões antigos de garantia e transferir os ETH liberados em uma única transação.

Contexto

O MakerDaoBot participava dos leilões legados de garantia ETH-A da MakerDAO por meio do Flipper, o contrato de leilão de garantias usado pelo sistema de liquidação antigo. O bot gerenciava permissões no Vat, depositava e retirava ETH e DAI e processava tarefas de liquidação.

O Vat é o registro contábil interno da MakerDAO. Ele registra a garantia livre de cada endereço por tipo de garantia em gem[ilk][address] e seu crédito interno em DAI em dai[address]; não há uma carteira ou um contrato de conta separado. Portanto, os saldos do MakerDaoBot no Vat são as entradas registradas sob o endereço do próprio contrato do bot.

Chamar hope(usr) não transfere esses saldos. A chamada define can[msg.sender][usr] como 1, permitindo que usr passe pela verificação de permissão wish() do Vat e opere os saldos registrados sob msg.sender. Funções como flux() e move() usam essa verificação ao transferir garantias internas ou DAI.

mapping(address => mapping (address => uint)) public can;
function hope(address usr) external note { can[msg.sender][usr] = 1; }
function nope(address usr) external note { can[msg.sender][usr] = 0; }
function wish(address bit, address usr) internal view returns (bool) {
    return either(bit == usr, can[bit][usr] == 1);
}

mapping (bytes32 => mapping (address => uint)) public gem;  // [wad]
mapping (address => uint256)                   public dai;  // [rad]

function flux(bytes32 ilk, address src, address dst, uint256 wad) external note {
    require(wish(src, msg.sender), "Vat/not-allowed");
    gem[ilk][src] = sub(gem[ilk][src], wad);
    gem[ilk][dst] = add(gem[ilk][dst], wad);
}
function move(address src, address dst, uint256 rad) external note {
    require(wish(src, msg.sender), "Vat/not-allowed");
    dai[src] = sub(dai[src], rad);
    dai[dst] = add(dai[dst], rad);
}

Análise da vulnerabilidade

A causa raiz foi a falta de controle de acesso na função 0x8804d1de() do contrato MakerDaoBot em 0x6839...5546. A função tratava varg0 como o endereço de um contrato externo (chamado abaixo de adaptador), invocando drip(), vat() e, posteriormente, join() nesse endereço. Após obter o endereço do Vat por meio de vat(), o bot verificava se o adaptador podia operar seus saldos no Vat. Caso não pudesse, chamava hope(varg0) para conceder a permissão e então invocava join() no mesmo adaptador.

Outros pontos de entrada privilegiados no mesmo contrato usavam uma verificação ds-auth antes de executar suas operações. A comparação abaixo mostra dois pontos de entrada protegidos que passam um seletor bytes4 e msg.sender ao auxiliar de autorização e, em seguida, revertem com ds-auth-unauthorized quando a verificação falha. A função 0x8804d1de() não tinha uma verificação equivalente de quem a chamava.

Assim, a função 0x8804d1de() permitia que qualquer pessoa escolhesse o endereço que receberia permissão no Vat. O bot concedia permissão a esse endereço por meio de hope() e imediatamente chamava sua função join(). A delegação permanecia ativa durante essa chamada externa, permitindo que o código no endereço escolhido operasse os saldos internos de garantia e DAI do bot.

Análise do ataque

A análise a seguir baseia-se na transação 0xbb6940...f3a88c.

• Etapa 1: A conta de propriedade externa (EOA) do invasor chamou um contrato de ataque que ele havia implantado. Esse contrato implantou um adaptador malicioso e, em seguida, chamou a função 0x8804d1de() do MakerDaoBot com o endereço do adaptador. O bot não encontrou nenhuma delegação existente no mapeamento can do Vat e chamou hope(), permitindo que o adaptador operasse os saldos registrados sob o endereço do bot.

• Etapa 2: O MakerDaoBot chamou a função join() do adaptador. Enquanto a delegação estava ativa, o código malicioso chamou deal(uint256 id) no Flipper desativado de ETH-A e liquidou os leilões 1457, 1458, 1459 e 1460. Em seguida, o adaptador usou sua permissão no Vat para mover 200 unidades de garantia ETH-A do MakerDaoBot para si, retirou-as por meio do ETH Join para receber 200 WETH e transferiu os tokens para o contrato de ataque.

• Etapa 3: O contrato de ataque converteu 200 WETH em 200 ETH e os enviou para a EOA do invasor. Na época, o valor era de aproximadamente US$ 542 mil.

Conclusão

A causa raiz foi a falta de controle de acesso no MakerDaoBot, não uma falha no sistema de permissões do Vat da MakerDAO. Uma função pública permitia que qualquer pessoa escolhesse um contrato externo, concedesse a ele controle sobre os saldos internos do bot e executasse seu código. O invasor usou esse caminho para liquidar quatro leilões legados e retirar 200 ETH.

Qualquer função que delegue controle sobre ativos deve restringir tanto quem pode iniciar a operação quanto quais contratos externos podem receber essa autoridade. Fluxos sensíveis de integração devem aplicar os mesmos controles de autorização das demais funções privilegiadas e aceitar apenas contratos explicitamente aprovados.

Sobre a BlockSec

A BlockSec é uma fornecedora de segurança blockchain e conformidade cripto com atuação em todas as camadas. Desenvolvemos produtos e serviços que ajudam clientes a realizar auditorias de código (incluindo contratos inteligentes, blockchains e carteiras), interceptar ataques em tempo real, analisar incidentes, rastrear fundos ilícitos e cumprir obrigações de combate à lavagem de dinheiro e ao financiamento do terrorismo (AML/CFT) ao longo de todo o ciclo de vida de protocolos e plataformas.

A BlockSec publicou diversos artigos sobre segurança blockchain em conferências de prestígio, identificou vários ataques de dia zero contra aplicações DeFi, bloqueou diversos ataques e evitou perdas superiores a 20 milhões de dólares, além de proteger bilhões de dólares em criptomoedas.

• Site oficial: https://blocksec.com/

• Conta oficial no Twitter: https://twitter.com/BlockSecTeam

• 🔗 Serviço de auditoria da BlockSec : Envie uma solicitação

• 🔗 Aplicativo Phalcon Security: Agende uma demonstração

• 🔗 Phalcon Compliance