Lecciones del hackeo a Bybit: la experiencia de firma es el eslabón más débil de la MultiSig

El 21 de febrero, unos 1.500 millones de dólares en tokens de ETH y staked-ETH salieron de una de las billeteras frías de Bybit en una sola transacción aprobada: el mayor robo de cripto del que se tiene registro. La billetera era una MultiSig. Todos los firmantes requeridos firmaron. Y, hasta donde ha demostrado cualquier investigación, nunca se robó ninguna clave privada. Si de todas las lecciones del hackeo a Bybit te quedas solo con una, que sea esta: la criptografía aguantó y el dinero se fue de todos modos.

Eso no es un argumento en contra de la MultiSig. Nosotros construimos una billetera MultiSig y seguimos considerando la firma M-of-N la forma más verificable de manera independiente de custodiar fondos importantes. Es un argumento sobre dónde se sitúa la verdadera superficie de ataque. La MultiSig reparte la custodia de las claves; no reparte, por sí sola, la verificación. Cada firma es exactamente tan fiable como la comprensión que tiene el firmante del payload que tiene delante, y el 21 de febrero esa comprensión la fabricó un atacante.

Lo que sabemos, dos semanas después

Al momento de escribir esto, la imagen que se arma a partir de las declaraciones de Bybit, la divulgación posterior al incidente de Safe y la atribución pública del FBI es coherente. El equipo de Bybit se dispuso a realizar una transferencia rutinaria desde una MultiSig fría de Ethereum a una billetera caliente, usando la interfaz web de Safe{Wallet} que había utilizado muchas veces antes. Cada firmante vio una transacción de apariencia legítima: la interfaz familiar, el flujo esperado, nada que interrumpiera la memoria muscular.

Lo que el quórum autorizó en realidad era otra cosa. La transacción cambió de forma silenciosa la lógica del contrato inteligente de la propia billetera, sustituyéndola por una implementación que el atacante controlaba. Una vez que las firmas genuinas quedaron registradas on-chain, la bóveda obedeció su nueva lógica y unos 400.000 ETH y tokens de staked-ETH —unos 1.500 millones de dólares en ese momento— salieron. La investigación de Safe rastreó el compromiso hasta la máquina de un desarrollador, con código malicioso servido a través del front-end y dirigido específicamente a los firmantes de Bybit; la interfaz se comportó con normalidad para todos los demás. A finales de febrero, el FBI atribuyó públicamente la operación al Grupo Lazarus de Corea del Norte, rastreado bajo el nombre de TraderTraitor.

Otros dos hechos merecen el mismo protagonismo. Bybit siguió siendo solvente y continuó procesando retiros durante todo lo sucedido. Y en ningún momento se extrajo material de claves: no se robó ninguna seed phrase por phishing, no se incautó ningún dispositivo de firma, no se eludió matemáticamente ningún umbral.

Las claves aguantaron, y ese es exactamente el punto

Una billetera MultiSig requiere M de N claves independientes para aprobar una transacción antes de que los fondos puedan moverse. Esa propiedad funcionó a la perfección el 21 de febrero. Las firmas eran genuinas, el quórum era legítimo y el contrato ejecutó exactamente lo que se firmó. El atacante nunca intentó vencer las matemáticas; se las arregló para que el quórum firmara voluntariamente una mentira. El hackeo a Bybit fue un fallo de verificación de transacciones, no de la criptografía MultiSig.

Una firma es una opinión sobre un payload. Si el payload que verificaste no es el payload que firmaste, el número de firmantes es irrelevante.

Los titulares que dicen «billetera fría hackeada» pasan por alto esta distinción, y la distinción importa porque decide qué es lo que arreglas. El almacenamiento en frío cumplió su función concreta: las claves nunca tocaron una máquina en línea. La MultiSig cumplió su función concreta: ningún firmante por sí solo podía actuar en solitario. El componente que falló es el que casi nadie incluye en su modelo de amenazas: la pantalla.

La firma a ciegas, con precisión

La firma a ciegas consiste en aprobar una transacción cuyo contenido real el firmante no puede verificar de forma independiente. En Ethereum, lo que un firmante aprueba criptográficamente es un hash de datos estructurados de la transacción, no el resumen legible para humanos que aparece en la pantalla. Algún programa tiene que decodificar esos datos de vuelta en una intención —destino, importe, llamada al contrato— y el firmante hereda lo que ese programa afirme. Si la interfaz miente, el humano confirma una ficción mientras la cadena ejecuta la verdad.

La transacción de Bybit abusó exactamente de esta brecha. Un único campo que la mayoría de las interfaces no muestran de forma prominente —el tipo de operación— convirtió una aparente transferencia en un delegatecall que reconfiguró la lógica de la billetera. Los dispositivos de firma por hardware tampoco cierran la brecha de forma automática: un dispositivo que solo muestra un hash opaco le pide a un humano que verifique algo que ningún humano puede interpretar. Eso es teatro de la verificación y, se podría decir, es peor que nada, porque fabrica confianza sin añadir escrutinio.

Un solo front-end, un solo quórum, un solo fallo

Los firmantes de Bybit tenían claves independientes, en dispositivos separados. Pero todos verificaron la transacción a través del mismo front-end web, así que una sola interfaz comprometida alcanzó a todo el quórum a la vez. La independencia de los firmantes exige canales de verificación independientes, no solo claves independientes. Una billetera 3-of-3 cuyos firmantes confían todos en una misma pantalla se reduce, a efectos prácticos, a una 1-of-1, y el «1» es quienquiera que controle la interfaz.

La lección es agnóstica al esquema. Las billeteras MPC sustituyen el contrato on-chain por fragmentos de clave distribuidos —comparamos las ventajas y desventajas en MPC vs MultiSig: una comparación honesta—, pero un quórum MPC termina exactamente en el mismo lugar: humanos aprobando un payload que alguna interfaz representó para ellos. También dice algo sobre las prioridades del sector que tanta energía se dedique a amenazas lejanas y exóticas —en diciembre examinamos lo lejos que siguen los ordenadores cuánticos de las claves de Bitcoin— mientras que el mayor robo de la historia del sector no requirió ninguna criptografía nueva. Requirió JavaScript.

Lecciones prácticas del hackeo a Bybit

Nada de lo siguiente requiere criptografía nueva ni hardware nuevo. Es disciplina operativa, que es precisamente por lo que se pasa por alto.

1. Trata toda pantalla de firma como no confiable. La interfaz que construye tu transacción se convierte en un objetivo en cuanto tu saldo justifica el esfuerzo. Da por hecho que puede mentirte justo el día en que más importa.
2. Verifica en una segunda superficie independiente. Decodifica la transacción en bruto —destino, valor, calldata, tipo de operación— en un dispositivo que no comparta nada con la máquina que la construyó. Que dos pantallas mientan de forma idéntica es un ataque mucho más difícil que una sola pantalla mintiendo por su cuenta.
3. Rechaza los payloads opacos. Si un firmante no puede ver, parámetro a parámetro, qué hace una transacción, el número correcto de firmas para ella es cero. «Probablemente es la transferencia de siempre» es como se mueven 1.500 millones de dólares.
4. Acota el radio de impacto. Las listas blancas de direcciones, los límites diarios y mensuales y la separación de roles convierten una mala aprobación en una pérdida acotada en lugar de una total. La pérdida de Bybit fue total para esa bóveda porque nada limitaba lo que una sola transacción aprobada podía hacer.
5. Frena la rutina. El ataque se disfrazó de la operación más ordinaria que realizaba el equipo, porque las operaciones ordinarias reciben el menor escrutinio. La rutina no es motivo para relajarse; es el disfraz que elegirá un atacante.

Cómo esto moldea la firma en Ownbit

De las lecciones del hackeo a Bybit anteriores, la duradera es estructural: la verificación final tiene que vivir en algún lugar que la máquina comprometida no pueda alcanzar. El flujo de billetera fría de Ownbit está construido en torno a esa idea. Un teléfono de repuesto se convierte en un firmante aislado por air gap; el teléfono en línea ejecuta una billetera de observación (Watch Wallet) que no guarda ninguna clave, construye la transacción sin firmar y la pasa en forma de código QR. El teléfono sin conexión muestra qué se le está pidiendo firmar en realidad antes de que exista ninguna firma, y después devuelve la firma de la misma manera. El salto por QR es deliberadamente estrecho: cada transacción se ve forzada a pasar por una segunda superficie independiente, y el dispositivo que guarda las claves nunca carga la página web que podría haber sido envenenada.

Para los equipos, MultiSig empresarial aplica directamente las lecciones sobre el radio de impacto: listas blancas de direcciones para que los fondos no puedan llegar a un destino no listado sin importar quién firme, límites de gasto diarios y mensuales, roles de Owner, Signer y Security Admin, y una pausa de emergencia. Estos controles no hacen imposible el engaño —nada lo hace por completo—, pero acotan lo que puede costar una sola aprobación manipulada.

Y una nota honesta sobre nosotros mismos. Los servidores de Ownbit coordinan la firma, pero nunca guardan las claves de los usuarios; cada clave en una MultiSig de Ownbit es una seed phrase BIP39 estándar, y la recuperación funciona sin nuestra infraestructura. La confianza minimizada corta por ambos lados: el mismo diseño que limita lo que un coordinador comprometido podría hacerte es la razón por la que podemos escribir sobre la peor semana de Bybit sin fingir que somos inmunes a los ataques dirigidos. El daño acotado, no la invulnerabilidad proclamada, es el estándar al que vale la pena exigir a los proveedores.

Preguntas frecuentes