Superficies de Ataque en Web3: Una Descripción General de las Pruebas de Penetración

Los primeros tres artículos de esta serie establecieron por qué las instituciones cripto necesitan pruebas de penetración blockchain (Parte 1), qué valida esta disciplina (Parte 2), y cómo se puede preparar y ejecutar de forma segura un compromiso institucional (Parte 3).

Este artículo ofrece una visión general de las superficies de ataque relevantes para las pruebas de penetración en una institución web3, con especial atención a cómo la cobertura requerida se extiende más allá de las superficies tradicionales de pruebas de penetración [1]. Específicamente, primero define un modelo de cuatro componentes para las instituciones web3, junto con la responsabilidad, los representantes y las principales superficies de ataque de cada componente. Sobre esa base, luego examina cinco áreas de superficie de ataque que conectan las exposiciones heredadas de aplicaciones e infraestructura con puntos de validación específicos de web3 en la intención de firma, los flujos de trabajo de aprobación y firma, la lógica de fondos y el comportamiento en tiempo de ejecución en cadena.

Los componentes de las instituciones web3

Las instituciones web3, incluyendo los exchanges centralizados, los proveedores de pagos y los proyectos DeFi, conectan los entornos tradicionales de aplicaciones e infraestructura con una cadena de manejo de dinero que va de fuera de la cadena a dentro de la cadena [2]. Conservan las superficies tradicionales de pruebas de penetración a la vez que introducen puntos de validación adicionales en torno a la intención de la transacción, la autoridad de firma, la contabilidad de fondos y la ejecución en cadena. Identificar cómo interactúan estas superficies y qué condiciones pueden formar un camino hacia el valor requiere un criterio especializado de seguridad web3.

Para examinar sistemáticamente esta superficie de ataque ampliada, esta sección define un modelo de cuatro componentes: Aplicación, Autorización y Firma, Interacción con Blockchain e Infraestructura. Para cada componente, se describe la responsabilidad del componente, se identifican implementaciones representativas y se resumen sus principales superficies de ataque. Tenga en cuenta que distintas instituciones web3 pueden combinar o externalizar estos componentes de diferentes maneras.

Componente 1: Aplicación

El componente Aplicación procesa las solicitudes de usuarios u operadores internos bajo una lógica de negocio y autorización definida, traduciendo la intención autorizada en la acción de negocio prevista, como una transferencia de activos o una operación de recuperación. Los representantes comunes en las instituciones web3 incluyen aplicaciones web y móviles, extensiones de navegador y APIs de backend.

Tipos de pruebas comunes.

• Pruebas de Penetración de Aplicaciones Web

• Pruebas de Penetración de Aplicaciones Móviles

• Pruebas de Penetración de Extensiones de Navegador

• Pruebas de Penetración de APIs

El componente Aplicación hereda superficies de ataque tradicionales como la gestión de identidad y sesión, la autorización y aislamiento, y la integridad del flujo de trabajo de negocio y de las transiciones de estado. En una institución web3, la acción de negocio o la intención de transacción preparada en esta etapa puede ser posteriormente autorizada por el componente Autorización y Firma y ejecutada mediante el componente Interacción con Blockchain. Por lo tanto, los fallos en estos controles pueden interrumpir el servicio o propagarse hasta convertirse en pérdida directa de activos.

Componente 2: Autorización y Firma

El componente Autorización y Firma recibe las solicitudes de transacción preparadas por el componente Aplicación y produce las firmas criptográficas necesarias para el envío en cadena. Algunas implementaciones pueden además realizar comprobaciones de política o aprobación dentro del sistema de firma antes de producir una firma. Los representantes comunes en las instituciones web3 incluyen sistemas o servicios de billetera y firma.

Tipos de pruebas comunes.

• Pruebas de Identidad y Acceso Privilegiado

• Pruebas de Flujo de Trabajo de Firma y Aprobación

Las superficies de ataque tradicionales heredadas por el componente Autorización y Firma incluyen la gestión de identidad y acceso privilegiado, la autorización de API y separación de funciones, y la integridad de los flujos de trabajo de aprobación, recuperación y administración. En las instituciones web3, los fallos en este componente pueden tener consecuencias especialmente graves porque una firma válida puede autorizar directamente un cambio de estado irreversible o una transferencia de activos. Como el paso final de autorización criptográfica antes del envío en cadena, el componente Autorización y Firma debe tratarse como una prioridad de aseguramiento crítica dondequiera que se utilice.

Componente 3: Interacción con Blockchain

El componente Interacción con Blockchain envía las transacciones autorizadas por usuarios u operadores internos, confirma su estado de ejecución y realiza el seguimiento del estado en cadena resultante. Los representantes comunes en las instituciones web3 incluyen puertas de enlace de nodos o RPC, indexadores y relayers.

Tipos de pruebas comunes.

• Pruebas de Penetración de API y RPC

• Pruebas de Abuso de Envío de Transacciones y Relayers

Aunque la Interacción con Blockchain desempeña un papel específico de las operaciones web3, las pruebas de penetración de este componente se centran en la explotabilidad adversarial de sus superficies de ataque heredadas: credenciales de servicio y seguridad de los endpoints, autorización de RPC y API, y integridad del procesamiento de mensajes y eventos; por ejemplo, si el comportamiento de RPC o del relayer puede ser objeto de abuso, si el envío de transacciones puede ser manipulado, o si los eventos de la cadena pueden ser interpretados incorrectamente. Para las instituciones que operan nodos blockchain personalizados o autoalojados, la corrección de los nodos y clústeres y la resiliencia de RPC a gran escala —sincronización, propagación de transacciones, conmutación por error y disponibilidad— son cuestiones complementarias abordadas por Blockchain Security Testing en lugar de por las pruebas de penetración [2].

Componente 4: Infraestructura

El componente Infraestructura abarca la infraestructura específica de la institución y los sistemas operativos que respaldan o influyen en los otros tres componentes. Los representantes comunes en las instituciones web3 incluyen plataformas en la nube, infraestructura de red, sistemas de IAM y gestión de secretos, sistemas de control de código fuente y CI/CD, y plataformas de monitoreo.

Tipos de pruebas comunes.

• Pruebas de Penetración de Red Externa e Interna

• Pruebas de Penetración de Infraestructura en la Nube

• Pruebas de CI/CD y de la Cadena de Suministro de Software

La Infraestructura hereda principalmente superficies de ataque tradicionales, incluyendo la exposición de red y servicios, la gestión de identidad, privilegios y secretos, y la integridad de la entrega de software y de la cadena de suministro. Aunque la Infraestructura normalmente no realiza directamente acciones de manejo de dinero, su fallo o compromiso puede provocar una pérdida sustancial de activos. Los incidentes de Bybit y TrustWallet analizados en la Parte 1 ilustran cómo los compromisos en los canales de entrega y distribución de software pueden propagarse hasta la cadena de manejo de dinero [1].

Superficies de ataque web3

El modelo de cuatro componentes indica que las pruebas de penetración de las instituciones web3 conservan gran parte de la superficie de ataque tradicional de aplicaciones e infraestructura. La distinción radica en el contexto de manejo de dinero: las debilidades pueden propagarse entre componentes y afectar la intención de la transacción, la firma, el estado de los fondos o la ejecución en cadena. Por lo tanto, identificar estos caminos y seleccionar los puntos de validación adecuados requiere un criterio especializado de seguridad web3.

Para estructurar esta cobertura, esta sección agrupa las superficies de ataque web3 en cinco áreas principales de superficie de ataque derivadas de la cadena de manejo de dinero y del alcance de las pruebas presentado en la Parte 2 [2]:

• Entorno de producción y operaciones de automatización

• Frontends web y de dApp, autorización e intención de firma

• Cadenas de firma, aprobación y autorización de retiros

• Lógica de negocio de fondos

• Transacciones en cadena y contratos desplegados

Entorno de producción y operaciones de automatización

El entorno de producción respalda cada etapa de la cadena de manejo de dinero. Un punto de apoyo convencional en infraestructura, identidad o entrega de software puede no mover fondos directamente, pero puede alterar el comportamiento de la Aplicación, alcanzar la Autorización y Firma, o influir en la Interacción con Blockchain. Por lo tanto, las pruebas de penetración blockchain evalúan el impacto alcanzable de ese punto de apoyo sobre la cadena de manejo de dinero, en lugar de tratar el hallazgo de infraestructura como un endpoint aislado [2].

Enfoque de las pruebas. Los evaluadores validan si el acceso, la implementación, los secretos o los controles operativos pueden encadenarse hacia una acción de manejo de dinero. Un escenario puede comenzar con un servicio expuesto, una identidad comprometida, una credencial de carga de trabajo, un token de compilación, una dependencia o una integración de proveedor, y luego evaluar si el IAM, la segmentación, el manejo de secretos, el control de cambios y la autorización de servicios impiden un mayor alcance. La evidencia resultante debe vincular el punto de apoyo operativo con los componentes y las acciones que mueven valor sobre los que puede influir.

El análisis detallado [3] examina cómo el compromiso del entorno de producción puede propagarse a través de los controles de implementación y operativos hasta los componentes de manejo de dinero.

Frontends web y de dApp, autorización e intención de firma

Los frontends web y de dApp son la capa de interacción principal donde los usuarios y operadores inician y revisan las acciones de manejo de dinero, y participan en los flujos de autorización y firma mediante los cuales se aprueban dichas acciones. Esta posición los convierte en objetivos atractivos para el phishing y el secuestro de frontend, ya que el control de la interfaz puede manipular el contexto o el contenido de una solicitud de transacción antes de que llegue a una billetera o sistema de firma [1].

Enfoque de las pruebas. Los evaluadores validan si la transacción presentada a un usuario u operador puede divergir de la acción finalmente autorizada. La evaluación sigue la solicitud desde la autenticación y autorización de la aplicación, pasando por la construcción de la transacción, la presentación en la billetera, la firma y el envío, considerando si el estado de la sesión, los permisos de la billetera, la simulación, el contexto de la cadena, el contexto del contrato o la lógica de visualización pueden alterar su significado. La evidencia debe conservar la acción presentada, la carga útil real, la firma resultante y el comportamiento enviado.

El análisis detallado [4] sigue la intención de la transacción desde la presentación en la aplicación, pasando por la autorización en la billetera, hasta el resultado firmado o enviado, centrándose en dónde puede divergir el significado de la acción.

Cadenas de firma, aprobación y autorización de retiros

La firma suele ser una acción que mueve dinero, pero la validez criptográfica por sí sola no establece la autoridad de negocio correcta. El resultado en materia de seguridad también depende de quién inició la solicitud, qué política se aplicó, qué revisaron los aprobadores y si la carga útil permaneció sin cambios. Una debilidad en esta cadena de control puede hacer que un firmante legítimo autorice una acción no prevista [2].

Enfoque de las pruebas. Los evaluadores validan si las identidades, los roles, las comprobaciones de política o los pasos de aprobación pueden eludirse o combinarse. Los escenarios pueden evaluar si una misma identidad puede iniciar y aprobar una acción, si un cambio de destino o de límite se vuelve efectivo sin una revisión independiente, si la política se aplica en el firmante o solo en una interfaz, o si una carga útil puede cambiar después de la aprobación. La evidencia debe documentar la secuencia probada, los controles sorteados y la acción no autorizada que se habilitó.

El análisis detallado [5] examina si los flujos institucionales de aprobación y firma preservan la autoridad de negocio desde la iniciación de la transacción hasta la firma y la ejecución del retiro.

Lógica de negocio de fondos

Las instituciones custodiales dependen de un estado fuera de cadena para determinar los saldos, las obligaciones y si el valor puede liberarse. Por lo tanto, un crédito no previsto o una transición de estado puede convertirse en una pérdida financiera directa incluso cuando no se compromete ninguna clave de firma ni contrato inteligente. Las pruebas deben tener en cuenta el invariante económico y el camino de conciliación, no solo si una API individual se comporta según lo implementado [2].

Enfoque de las pruebas. Los evaluadores validan si los saldos, límites, la conciliación, las reglas de retiro o las transiciones de estado aceptan condiciones no previstas. Los escenarios pueden examinar si un depósito se acredita sin el valor esperado, si un solo evento produce múltiples créditos, si la precisión o la concurrencia altera un saldo, o si un estado inválido se vuelve retirable. La evidencia debe capturar las transiciones de estado resultantes y un camino de impacto de negocio reproducible, y no solo un defecto técnico.

El análisis detallado [6] examina cómo puede crearse, propagarse y convertirse en valor retirable un estado de fondos no previsto fuera de cadena a través de los flujos de trabajo institucionales.

Transacciones en cadena y contratos desplegados

La transferencia en cadena es el punto donde la intención fuera de cadena se convierte en comportamiento público en tiempo de ejecución. Las transacciones pueden ser irreversibles, y los contratos desplegados son públicamente invocables y componibles con sistemas fuera del control directo de la institución. Por lo tanto, la evaluación debe preservar la relación entre la acción prevista, la transacción enviada, la ejecución observada y el estado interpretado por la institución [2].

Enfoque de las pruebas. Los evaluadores validan cómo se comportan las interacciones en cadena de la institución bajo condiciones adversas en tiempo de ejecución. Los escenarios pueden examinar si los campos de la transacción pueden cambiar entre la construcción, la firma y el envío. También pueden evaluar si el comportamiento de RPC o del relayer afecta la acción, si los eventos de la cadena se interpretan correctamente, y si los permisos desplegados, las actualizaciones o la composición del protocolo alteran el resultado esperado. La evidencia debe conservar la transacción enviada, el contexto relevante de la cadena y el resultado observado en tiempo de ejecución.

Para esta área, las pruebas de penetración siguen centradas en la interacción adversarial en tiempo de ejecución y en la evidencia a nivel de transacción. El aseguramiento de contratos a nivel de código permanece dentro de Code Audit, mientras que la corrección de los nodos o clústeres y la resiliencia de RPC a gran escala permanecen dentro de Blockchain Security Testing [2].

Conclusión

Las pruebas de penetración blockchain conservan las superficies de ataque tradicionales de aplicaciones e infraestructura examinadas en las evaluaciones convencionales. Lo que las distingue es la necesidad de rastrear las debilidades más allá de esos puntos de entrada a través de la cadena de manejo de dinero de la institución, donde los fallos en el procesamiento de solicitudes, la autorización, la entrega de software o la infraestructura pueden afectar la firma criptográfica, el estado de los fondos o la ejecución en cadena.

Para hacer explícitas estas relaciones, este artículo utiliza un modelo de cuatro componentes: Aplicación prepara las acciones de negocio, Autorización y Firma produce las firmas, Interacción con Blockchain envía las transacciones e interpreta los resultados, e Infraestructura respalda o influye en los otros componentes. Además, cinco áreas de superficie de ataque identifican dónde es más importante el criterio especializado de seguridad web3, particularmente en los límites entre la intención de la transacción, la autoridad de firma, la lógica de fondos y el comportamiento en tiempo de ejecución en cadena.

Cuatro guías complementarias amplían esta visión general con análisis dedicados a la autorización de aplicaciones y la intención de firma, la seguridad en la nube y CI/CD, el control de tesorería y la lógica del libro mayor de exchanges. Las transacciones en cadena y los contratos desplegados siguen cubiertos en esta visión general.

BlockSec ayuda a las instituciones a convertir el modelo de cuatro componentes y las cinco áreas de superficie de ataque en un alcance evaluable, mapeando los componentes, los responsables, los flujos de fondos y los límites de confianza, seleccionando perspectivas de atacante, definiendo evidencia segura y validando los posibles caminos que importan. Para definir el alcance de la superficie de ataque de su próximo compromiso, solicite una conversación de alcance. Hay más información disponible bajo solicitud.

También en esta serie, próximamente:

• Parte 5: Seguridad de Autorización y Firma: Web, dApps y
• Parte 6: Seguridad en la Nube y CI/CD: Superficies de Ataque en Operaciones Automatizadas
• Parte 7: Seguridad del Plano de Control de Tesorería: Aprobaciones de Firma y Retiro
• Parte 8: Seguridad del Libro Mayor de Exchanges: Vías de Robo y Lógica del Plano de Datos

La página pilar de Blockchain Penetration Testing ofrece la visión a nivel de compromiso.

Referencias

Numeradas en orden de primera aparición.

1. BlockSec, From Incidents to Regulation: Why Crypto Institutions Need Blockchain Penetration Testing.
2. BlockSec, What Is Blockchain Penetration Testing? Definitions and Boundaries.
3. BlockSec, publicación próxima.
4. BlockSec, publicación próxima.
5. BlockSec, publicación próxima.
6. BlockSec, publicación próxima.