Compromiso de la Ruta de Firma Bybit-Safe: Colapso del Límite de Confianza de Custodia

Incident Overview (Without Journalism)

Superficie institucional primaria: Mission-Critical DevSecOps.

Líneas de capacidad:

Reproducible and signed build pipelines
Policy-as-code enforcement
Immutable rollout and rollback control

Tier A (confirmed): Bybit reportó actividad no autorizada el 21 de febrero de 2025 durante una transferencia rutinaria desde una cold wallet multisig de ETH hacia una warm wallet, y afirmó que la presentación de la transacción fue manipulada mientras cambiaba la lógica subyacente del smart contract.

Tier A (confirmed): declaraciones públicas de actores del ecosistema Safe describieron una ruta de ataque dirigida que involucró el compromiso de una máquina de desarrollador de Safe y la propuesta disfrazada de una transacción maliciosa orientada al flujo de firma de Bybit.

Tier A (confirmed): el FBI publicó la Alerta I-022625-PSA el 26 de febrero de 2025, atribuyendo el robo de aproximadamente USD 1.5B en activos virtuales de Bybit a actividad TraderTraitor vinculada a la RPDC.

Tier B (inferred): la falla decisiva no fue extracción de clave privada dentro de un límite HSM; fue desincronización de intención del firmante en la capa de construcción de transacciones de custodia, donde la interfaz confiada y el payload firmado divergieron.

Tier C (unknown): la línea temporal completa pre-compromiso, todos los nodos de persistencia dentro de infraestructura web upstream y toda la telemetría de endpoints del lado operador no han sido divulgados públicamente.

Declaración de supuesto acotado: el análisis asume que los comunicados oficiales son materialmente correctos sobre ruta de ataque y alcance; detalles no públicos pueden ajustar la precisión del secuenciamiento, pero difícilmente cambian la lección arquitectónica central sobre verificabilidad de la ruta de firma.

Failure Surface Mapping

Definir S = {C, N, K, I, O}:

C: plano de control de custodia (propuesta de transacción, validaciones de política, coordinación de firmantes)
N: ruta de red para entrega de artefactos de interfaz de firma y llamadas API
K: ciclo de vida de claves (custodia de claves frías, restricciones de ceremonia de firma)
I: límite de identidad entre intención del operador y semántica de la transacción renderizada
O: orquestación operacional (flujo de aprobación, controles de release, respuesta a incidentes)

Capas fallidas dominantes y clase de falla:

I: falla Bizantina, porque la intención mostrada y el payload ejecutable divergieron.
C: falla de omisión más temporización, porque las compuertas de política no rechazaron la transición malformada antes de completar el quórum.
O: falla de omisión, porque controles de integridad de despliegue para artefactos orientados a firmantes no impidieron manipulación dirigida.

Tier A (confirmed): el incidente se activó durante una ruta operacional legítima de transferencia. Tier B (inferred): el colapso del límite de confianza ocurrió en la traducción interfaz-a-payload, no en la integridad de la primitiva criptográfica de firma.

Formal Failure Modeling

Sea el estado de custodia en tiempo t:

S_t = (Q_t, M_t, P_t, V_t, L_t)

Donde:

Q_t: conjunto de firmantes de quórum y estado de umbral
M_t: bytes de mensaje presentados para aprobación
P_t: contexto de política (restricciones de destino, allowlist de métodos, límites de valor)
V_t: resultados de verificación independiente
L_t: nivel de riesgo en vivo y estado del kill-switch

Transición:

T(S_t): \text{approve} \iff \big(\text{sig}(M_t, Q_t) = 1\big) \land \big(V_t = 1\big) \land \big(P_t = 1\big)

Invariante requerido:

I:\; \text{Semantics}(M_t) = \text{HumanIntent}_t \land V_t=1 \land P_t=1

Condición de violación:

\text{sig}(M_t, Q_t)=1 \land \text{Semantics}(M_t) \ne \text{HumanIntent}_t \Rightarrow I=0

Implicación de decisión: el umbral multisig por sí solo es insuficiente; la admisibilidad requiere validaciones de equivalencia semántica independientes de la ruta primaria de renderizado de UI.

Adversarial Exploitation Model

Clases de atacante:

A_passive: observa flujo de firma y ventanas temporales
A_active: inyecta lógica de manipulación de transacción en la ruta de propuesta/renderizado
A_internal: abusa privilegios de despliegue dentro de infraestructura de interfaz wallet
A_supply_chain: compromete estación de trabajo de desarrollador y credenciales de release
A_economic: monetiza lavado rápido mediante rutas fragmentadas de salida cross-chain

Variables de presión de explotación:

latencia de detección Δt
ancho del límite de confianza W (conteo de componentes mutables entre intención y payload firmado)
alcance de privilegio P_s (autoridad efectiva de la cuenta comprometida)

Función de presión de riesgo:

\Pi = \alpha \cdot \Delta t + \beta \cdot W + \gamma \cdot P_s

Tier B (inferred): el éxito del ataque requiere maximizar W y P_s mientras se mantiene Δt por debajo del umbral de activación de respuesta a incidentes.

Vínculo operativo: la arquitectura de custodia debe minimizar W con clientes de firma deterministas y cadenas de artefactos inmutables y atestables.

Root Architectural Fragility

La fragilidad estructural es compresión de confianza: la custodia institucional trató el significado de la transacción renderizada en UI y el calldata canónico como equivalentes bajo condiciones normales. Esto acopla autorización humana a una superficie de software mutable. El evento también expone riesgo de fuga de privilegios de CI/CD en servicios adyacentes al firmante; el compromiso de un único contexto de desarrollador upstream puede expandirse hacia influencia sobre aprobación de transacciones. La debilidad de rollback aparece cuando no existe un fail-safe rígido que bloquee flujos de custodia ante deriva de verificación. Por tanto, la fragilidad central no es falla de criptografía ECDSA/threshold; es falla de gobernanza en la ruta de control que mapea intención a bytes.

Code-Level Reconstruction

# Production guard: signer path must verify canonical transaction bytes
# from an independent decoder before quorum signature is accepted.

def approve_cold_transfer(tx_payload, ui_summary, signer_set, policy, verifier):
    canonical = verifier.decode(tx_payload)  # independent parser, separate trust domain

    if canonical.destination not in policy.allowed_destinations:
        raise Reject("destination_not_allowed")
    if canonical.method not in policy.allowed_methods:
        raise Reject("method_not_allowed")
    if canonical.value_wei > policy.max_value_wei:
        raise Reject("value_limit_exceeded")

    # critical invariant: rendered intent must match canonical decoded semantics
    if canonical.summary_hash() != ui_summary.summary_hash():
        policy.raise_kill_switch("intent_payload_mismatch")
        raise Reject("semantic_mismatch")

    for signer in signer_set.required_quorum():
        signer.sign(canonical.hash())

    return "approved"

Reconstrucción de falla: si ui_summary se confía sin decodificación canónica independiente y sin hash-match, una propuesta maliciosa puede satisfacer el quórum mientras viola la intención de transferencia.

Operational Impact Analysis

Tier A (confirmed): la escala de pérdida de activos fue reportada en aproximadamente USD 1.5B.

Tier B (inferred): el radio de impacto está acotado por topología de custodia y controles de emergencia, pero el shock de confianza a nivel de mercado se propaga más allá de las wallets directamente afectadas.

Para operaciones de custodia distribuida, definir:

B = \frac{\text{affected\_nodes}}{\text{total\_nodes}}

Si una sola vía de custodia es comprometida en una arquitectura segregada de n vías, B \approx 1/n; si las vías comparten dependencias de ruta de firma, el B efectivo se aproxima a 1 bajo explotación coordinada.

Implicación de decisión: la segregación debe ser segregación por dependencias, no solo por clave.

Enterprise Translation Layer

CTO: construcción y firma de transacciones de custodia deben tratarse como software crítico de producción con build determinista, atestación y detección de deriva, no como tooling de UI wallet.

CISO: el threat model debe priorizar spoofing de intención del firmante y entrada de supply chain en sistemas de propuesta de transacciones; los controles requieren verificación semántica independiente de transacciones y contención just-in-time de credenciales.

DevSecOps: artefactos orientados a firmantes requieren procedencia firmada, autorización de release de dos partes, logs inmutables de despliegue y compuertas policy-as-code que bloqueen mutación no verificada de frontend/recurso.

Board: las afirmaciones de solvencia no sustituyen madurez de controles; la exposición de riesgo institucional está determinada por arquitectura de gobernanza de custodia y latencia de detección medible.

STIGNING Hardening Model

Prescripciones de control:

Aislar el plano de control de custodia de superficies de build mutables expuestas a internet.
Segmentar ciclo de vida de claves por clase de transacción, envolvente de valor y dominios de aprobación con time-lock.
Aplicar hardening de quórum con verificación fuera de banda a nivel de bytes de la transacción.
Reforzar observabilidad con trazas de eventos firmadas para creación de propuesta, hash de artefacto de renderizado, decisión de firmante y broadcast.
Aplicar envolvente de rate limiting sobre rutas de transferencia de alto valor y activar políticas deterministas de pausa ante mismatch semántico.
Exigir rollback seguro para migración: sistemas de aprobación de custodia solo deben avanzar a artefactos atestados; rollback debe preservar procedencia reproducible.

Modelo estructural ASCII:

[Policy Engine]----attested rules---->[Tx Constructor]
      |                                   |
      |                          canonical bytes + hash
      v                                   v
[Independent Decoder] <---compare---> [Signer UI Renderer]
      |                                   |
      +------ mismatch => kill switch ----+
                      |
                 [Quorum Signers]
                      |
                 [Broadcast Gate]

Strategic Implication

Clasificación primaria: governance failure.

Implicación a cinco-diez años: la custodia institucional de activos digitales convergerá hacia autorización centrada en verificadores, donde la aprobación humana queda criptográficamente ligada a semántica de transacción decodificada independientemente. La separación competitiva estará definida por integridad medible de ruta de firma, pruebas formales de admisibilidad de políticas y contención de baja latencia bajo compromiso de supply chain.

References

Bybit Announcement, Incident Update: Unauthorized Activity Involving ETH Cold Wallet (21 feb 2025): https://announcements.bybit.com/en/article/incident-update-unauthorized-activity-involving-eth-cold-wallet-blt292c0454d26e9140/
Actualización oficial de Bybit vía PRNewswire, resumen forense (26 feb 2025): https://www.prnewswire.com/news-releases/bybit-confirms-security-integrity-amid-safe-wallet-incident--no-compromise-in-infrastructure-302386274.html
Comunicado de Safe Ecosystem Foundation y hallazgos preliminares del equipo Safe Wallet (28 feb 2025): https://safefoundation.org/blog/safe-ecosystem-foundation-statement
FBI Cyber PSA I-022625-PSA (26 feb 2025): https://www.fbi.gov/investigate/cyber/alerts/2025/north-korea-responsible-for-1-5-billion-bybit-hack

Conclusion

El incidente demuestra que el compromiso de custodia puede emerger desde la gobernanza de construcción de transacciones, incluso cuando las primitivas de firma permanecen íntegras. La resiliencia institucional depende de reducir el ancho del límite de confianza, imponer invariantes de equivalencia semántica antes de completar el quórum y operar controles deterministas de contención para anomalías en la ruta de firma.

STIGNING Infrastructure Risk Commentary Series
Engineering Under Adversarial Conditions