Pérdidas de ~542.000 dólares: explotación de MakerDaoBot

Durante la última semana (2026/10/05 - 2026/10/11), observamos 1 incidente de seguridad con una pérdida total estimada de aproximadamente $542K.

Fecha	Incidente	Tipo	Pérdida estimada
2026/10/06	MakerDaoBot	Falta de control de acceso	~$542K

Lo más destacado de la semana: MakerDaoBot

El 6 de octubre de 2026, un atacante aprovechó la falta de control de acceso en MakerDaoBot, un bot de liquidación heredado de MakerDAO en Ethereum, y retiró 200 ETH, por un valor aproximado de $542K. La función vulnerable permitía a cualquier usuario proporcionar un contrato externo, concederle control sobre los saldos del bot y ejecutar su código. El atacante utilizó esta vía para liquidar cuatro antiguas subastas de garantía y transferir los ETH liberados en una sola transacción.

Contexto

MakerDaoBot participaba en las subastas de garantía ETH-A del sistema heredado de MakerDAO a través de Flipper, el contrato de subastas de garantía utilizado por el antiguo sistema de liquidación. El bot gestionaba permisos en Vat, depositaba y retiraba ETH y DAI, y procesaba tareas de liquidación.

Vat es el libro contable interno de MakerDAO. Registra la garantía libre de cada dirección por tipo de garantía en gem[ilk][address] y su crédito interno de DAI en dai[address]; no existe un contrato de monedero o cuenta independiente. Por tanto, los saldos de MakerDaoBot en Vat son las entradas del libro contable registradas bajo la propia dirección del contrato del bot.

Llamar a hope(usr) no transfiere esos saldos. Establece can[msg.sender][usr] en 1, lo que permite a usr superar la comprobación de permisos wish() de Vat y operar con los saldos registrados bajo msg.sender. Funciones como flux() y move() utilizan esta comprobación al transferir garantías internas o 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álisis de la vulnerabilidad

La causa raíz fue la falta de control de acceso en la función 0x8804d1de() del contrato MakerDaoBot en 0x6839...5546. La función trataba varg0 como una dirección de contrato externo (denominado en adelante el adaptador) y llamaba a drip(), vat() y, posteriormente, a join() en esa dirección. Tras obtener la dirección de Vat mediante vat(), el bot comprobaba si el adaptador podía operar con sus saldos en Vat. De no ser así, llamaba a hope(varg0) para concederle permiso y luego invocaba join() en el mismo adaptador.

Otros puntos de entrada privilegiados del mismo contrato utilizaban una comprobación ds-auth antes de ejecutar sus operaciones. La comparación siguiente muestra dos puntos de entrada protegidos que pasan un selector bytes4 y msg.sender a la función auxiliar de autorización y luego revierten con ds-auth-unauthorized si la comprobación falla. La función 0x8804d1de() no tenía ninguna comprobación equivalente del llamante.

Por tanto, la función 0x8804d1de() permitía a cualquier usuario elegir la dirección que recibiría el permiso en Vat. El bot concedía permiso a esa dirección mediante hope() y llamaba inmediatamente a su función join(). La delegación seguía activa durante esta llamada externa, lo que permitía que el código de la dirección elegida operara con los saldos internos de garantía y DAI del bot.

Análisis del ataque

El siguiente análisis se basa en la transacción 0xbb6940...f3a88c.

Paso 1: La EOA del atacante llamó a un contrato de ataque que había desplegado. Ese contrato desplegó un adaptador malicioso y luego llamó a la función 0x8804d1de() de MakerDaoBot con la dirección del adaptador. El bot no encontró ninguna delegación existente en el mapeo can de Vat y llamó a hope(), lo que permitió al adaptador operar con los saldos registrados bajo la dirección del bot.

Paso 2: MakerDaoBot llamó a la función join() del adaptador. Mientras la delegación estaba activa, el código malicioso llamó a deal(uint256 id) en el Flipper retirado de ETH-A y liquidó las subastas 1457, 1458, 1459 y 1460. Luego, el adaptador utilizó su permiso en Vat para mover 200 unidades de garantía ETH-A de MakerDaoBot a sí mismo, retiró la garantía mediante ETH Join para recibir 200 WETH y transfirió los tokens al contrato de ataque.

Paso 3: El contrato de ataque convirtió 200 WETH en ETH y envió 200 ETH a la EOA del atacante, por un valor aproximado de $542K en ese momento.

Conclusión

La causa raíz fue la falta de control de acceso en MakerDaoBot, no un fallo en el sistema de permisos de Vat de MakerDAO. Una función pública permitía a cualquier usuario elegir un contrato externo, concederle control sobre los saldos internos del bot y ejecutar su código. El atacante utilizó esta vía para liquidar cuatro subastas heredadas y retirar 200 ETH.

Toda función que delegue el control sobre activos debe restringir tanto quién puede iniciar la operación como qué contratos externos pueden recibir esa autoridad. Las vías de integración sensibles deben aplicar los mismos controles de autorización que otras funciones privilegiadas y aceptar únicamente contratos aprobados explícitamente.

Acerca de BlockSec

BlockSec es un proveedor integral de seguridad de blockchain y cumplimiento normativo en el sector de las criptomonedas. Desarrollamos productos y servicios que ayudan a los clientes a auditar código (incluidos contratos inteligentes, cadenas de bloques y monederos), interceptar ataques en tiempo real, analizar incidentes, rastrear fondos ilícitos y cumplir las obligaciones de prevención del blanqueo de capitales y financiación del terrorismo, a lo largo de todo el ciclo de vida de los protocolos y las plataformas.

BlockSec ha publicado varios artículos sobre seguridad de blockchain en conferencias de prestigio, ha comunicado varios ataques de día cero contra aplicaciones DeFi, ha bloqueado múltiples ataques para rescatar más de 20 millones de dólares y ha protegido criptomonedas por valor de miles de millones de dólares.