¿Qué es el pentesting de blockchain? Definiciones y límites

El artículo anterior, From Incidents to Regulation: Why Crypto Institutions Need Blockchain Penetration Testing, explicaba por qué las pruebas de penetración en blockchain son necesarias. Este artículo se centra en qué son, examinando con más detalle las definiciones y los límites de las pruebas de penetración en blockchain.

No existe una definición formal ampliamente aceptada de las pruebas de penetración en blockchain, y muchas de las definiciones propuestas las mezclan con otras mitigaciones, por lo que términos como auditoría, escaneo y bug bounty a veces se incluyen como parte de las pruebas de penetración, aunque cada uno tiene un objetivo diferente. Esto dificulta saber qué validó realmente un encargo determinado. Nuestro punto de partida, extraído de la práctica tanto académica como de la industria, es deliberadamente sencillo: las pruebas de penetración en blockchain son, como su nombre indica, pruebas de penetración —una disciplina definida desde hace décadas— aplicadas al ecosistema web3, llevadas a cabo como una evaluación adversarial y de sistema completo contra un entorno web3 en funcionamiento. Se parte de esa disciplina conocida, y luego se pregunta qué añade web3 al modelo de amenazas y al criterio requerido por los evaluadores.

Las pruebas de penetración en blockchain son una evaluación adversarial y práctica de un sistema en funcionamiento, realizada dentro de un entorno y unas reglas de compromiso acordados, para validar rutas explotables y cadenas de control. Complementan las auditorías de seguridad a nivel de código y también pueden encargarse de forma independiente [1].

Buscan rutas en lugar de debilidades aisladas y operan bajo autorización explícita, alcance definido, supuestos de acceso y restricciones de seguridad. Este artículo responde a tres preguntas: qué son las pruebas de penetración en blockchain, qué pueden validar —especialmente más allá de la evidencia que suele proporcionar una auditoría— y cómo puede una institución comenzar a un nivel general.

Qué añade web3: el modelo de amenazas de la gestión de fondos

Web3 conserva las superficies tradicionales de las pruebas de penetración: infraestructura en la nube, sitios web, APIs, identidades, accesos privilegiados, proveedores y herramientas operativas. En lugar de sustituir ese modelo de amenazas por uno exclusivo de blockchain, lo extiende a sistemas donde los mismos puntos de apoyo pueden llevar directamente a acciones que autorizan, contabilizan o mueven valor.

Tres características determinan esa extensión.

• Primero, los activos digitales son directamente transferibles. Un atacante que alcance la ruta correcta de transacción o retiro puede llegar a mover valor sin pasar por los mismos mecanismos de reversión y conciliación que se usan en los pagos tradicionales.

• Segundo, la firma es a menudo una acción que mueve dinero. Una firma criptográficamente válida demuestra que una clave autorizó una carga útil; por sí sola, no demuestra que un operador viera el destino correcto, entendiera la transacción o siguiera la política de aprobación prevista.

• Tercero, cuando una institución despliega sus propios contratos —algo cada vez más común a medida que los productos añaden funcionalidad on-chain más rica—, esos contratos son públicamente invocables y componibles. Usuarios externos y otros contratos pueden invocarlos en secuencias que la institución no controla. Por lo tanto, la seguridad no depende solo de cada componente, sino también de cómo interactúan las identidades, las aplicaciones, las políticas, los sistemas de firma, la lógica contable y los contratos.

Modelamos la exposición resultante como una cadena de gestión de fondos: los controles off-chain de intención de firma, aprobación y lógica de fondos que conducen a las transacciones on-chain (y, cada vez más, a los propios contratos desplegados por la institución), junto con las capas de nube, web, API e identidad que respaldan esos pasos [1]. Un atacante puede comenzar con un punto de apoyo ordinario y avanzar a través de varios controles: manipular lo que se presenta para la firma, alcanzar un flujo de trabajo privilegiado, explotar una brecha de autorización o hacer que la lógica de fondos acepte una transición de estado no prevista.

La brecha de composición definitoria es el traspaso entre off-chain y on-chain: si los controles de identidad, interfaz, aprobación, firma y lógica de fondos preservan la acción prevista cuando esta se convierte en una transacción on-chain. No todos los ataques recorren toda la cadena. La cuestión es que el objetivo de la garantía abarca varias capas: los controles que parecen sólidos de forma aislada pueden combinarse en una ruta explotable a través del sistema de gestión de fondos en funcionamiento.

Qué hacen las pruebas de penetración en blockchain

Las pruebas de penetración en blockchain convierten esa brecha de composición en evidencia. Dentro del alcance autorizado y las reglas acordadas, los evaluadores traducen los supuestos entre capas en escenarios de ataque, ejecutan esos escenarios contra el entorno en funcionamiento y determinan si producen una ruta reproducible y un impacto concreto. El resultado conecta la ruta con evidencia de respaldo, gravedad, orientación para la remediación y una nueva prueba de las correcciones acordadas, en lugar de detenerse en una lista de debilidades inconexas.

Su factor diferenciador es el criterio especializado en seguridad web3, no un conjunto de herramientas único. Los evaluadores deben interpretar la custodia, la intención de las transacciones, la política de aprobación, los flujos de retiro, la contabilidad de fondos y el comportamiento de las transacciones on-chain (incluidos los contratos desplegados), conectando a la vez la evidencia de las superficies convencionales de nube, web, API, identidad y acceso privilegiado. Las herramientas pueden apoyar el descubrimiento o la validación, pero es el criterio experto el que determina si las condiciones observadas forman una ruta creíble de movimiento de fondos.

La evaluación es metódica, basada en evidencia y puntual en el tiempo. Sus conclusiones se aplican a los sistemas, versiones, configuraciones, supuestos de acceso y condiciones evaluados. Se examinan las rutas potenciales; las rutas explotables confirmadas se documentan con evidencia reproducible.

Tenga en cuenta que un trabajo sistemático a través de la superficie acordada no puede garantizar que se descubran todas las debilidades o rutas de ataque, y un encargo responsable no garantiza que los evaluadores logren una brecha.

Dentro de un entorno institucional web3, ese proceso de escenario a evidencia se ejecuta a través de cinco capacidades conectadas: las superficies evaluables de esa misma cadena de gestión de fondos. Abarcan la infraestructura que sustenta la cadena, sus tres controles off-chain y las transacciones on-chain a las que se traspasan; están conectadas porque una sola ruta puede atravesar varias de ellas:

• Entorno de producción y operaciones de automatización: los evaluadores validan si el acceso, el despliegue, los secretos o los controles operativos pueden encadenarse hacia una acción de gestión de fondos, generando evidencia que vincula el punto de apoyo operativo con su impacto alcanzable.

• Frontends web y de dApps, autorización e intención de firma: los evaluadores validan si la transacción presentada a un usuario u operador puede divergir de la acción finalmente autorizada, registrando el flujo manipulado y el comportamiento firmado o enviado resultante.

• Cadenas de autorización de firma, aprobación y retiro: los evaluadores validan si las identidades, roles, verificaciones de política o pasos de aprobación pueden eludirse o combinarse, documentando la secuencia y la acción no autorizada que esto permite.

• Lógica de negocio de fondos: los evaluadores validan si los saldos, límites, conciliaciones, reglas de retiro o transiciones de estado aceptan condiciones no previstas, capturando una ruta de impacto de negocio reproducible en lugar de solo un defecto técnico.

• Transacciones on-chain y contratos desplegados: los evaluadores validan cómo se comportan las interacciones on-chain de la institución bajo condiciones de ejecución adversarial; cuando la institución ha desplegado sus propios contratos, examinan el comportamiento en tiempo de ejecución de esos contratos y conservan evidencia a nivel de transacción del resultado observado. La garantía a nivel de código sigue siendo función del Code Audit correspondiente.

Part 4: Web3 Attack Surfaces: A Penetration Testing Overview mapea estas superficies y sus conexiones sin cambiar el objetivo central: determinar si las condiciones a través del entorno acordado en funcionamiento se encadenan en un impacto reproducible.

Cómo encaja junto a otras garantías

La comparación más clara es por objetivo de garantía: la decisión que el trabajo pretende respaldar y la evidencia que se espera que produzca. Como se muestra en la figura siguiente, los métodos pueden superponerse, las disciplinas pueden colaborar, y ningún límite útil depende de fingir que un equipo es exclusivamente estático mientras que otro es exclusivamente dinámico. El mismo objetivo —un contrato desplegado, una superficie de nube o RPC, un sistema de firma— puede corresponder a más de una de estas disciplinas; lo que difiere es el objetivo de garantía que cada una enfatiza, no una reivindicación exclusiva sobre el sistema.

Pruebas de penetración y auditoría a nivel de código

Un Code Audit —la forma con nombre propio de la auditoría a nivel de código— genera garantía principalmente en el código (incluyendo también el diseño, la arquitectura y los supuestos del protocolo). Combina revisión experta con herramientas de detección, puede incluir técnicas dinámicas, y produce un informe firmado según el alcance de auditoría acordado. Para contratos, cadenas, puentes, rollups, wallets u otras implementaciones, la auditoría pregunta si el diseño y el código satisfacen las propiedades de seguridad previstas.

Las pruebas de penetración establecen principalmente si condiciones reales a través de un entorno institucional acordado y en funcionamiento pueden encadenarse en un impacto reproducible. Siguen la interacción entre las aplicaciones desplegadas, las identidades, las configuraciones, los flujos de trabajo, la lógica de negocio, los sistemas de firma y las llamadas a contratos, y luego registran la evidencia necesaria para reproducir y remediar la ruta.

Esto es una diferencia de objetivo y evidencia, no una prohibición de capacidades. Los auditores pueden ejecutar pruebas, realizar fuzzing de componentes e investigar el comportamiento en tiempo de ejecución; los evaluadores de penetración pueden revisar configuraciones, lógica de aplicaciones y detalles de implementación para entender una ruta. Los métodos pueden superponerse y los equipos pueden trabajar juntos. Los servicios son complementarios, no sustitutos: la auditoría por sí sola normalmente no proporciona esta evidencia de explotabilidad en tiempo de ejecución a nivel institucional, mientras que las pruebas de penetración no sustituyen la garantía a nivel de código en las propiedades de implementación y protocolo que cubre una auditoría.

El comportamiento adversarial de un contrato en una ruta institucional en vivo puede, por lo tanto, entrar dentro de las pruebas de penetración, mientras que la garantía sobre el propio código del contrato se dirige al Code Audit correspondiente.

Escaneo, bug bounties y pruebas especializadas

El escaneo de vulnerabilidades proporciona amplitud automatizada frente a firmas conocidas, servicios expuestos, parches faltantes y problemas de configuración comunes. Favorece una visibilidad repetible y puede contribuir al reconocimiento, mientras que las pruebas de penetración aportan profundidad guiada por expertos y determinan si las condiciones pueden encadenarse en una ruta significativa.

Un bug bounty invita a investigadores independientes a reportar hallazgos elegibles bajo reglas publicadas. Su modelo continuo y colaborativo puede sacar a la luz problemas de cola larga, mientras que un encargo de pruebas de penetración asigna un equipo para examinar metódicamente un entorno acordado y entregar evidencia consolidada, gravedad, orientación para la remediación y nuevas pruebas. Ambos modelos son complementarios y ninguno garantiza un descubrimiento completo.

Por ejemplo, Blockchain Security Testing de BlockSec es un programa hermano, no un padre ni un subconjunto de las pruebas de penetración. Utiliza motores especializados —incluyendo pruebas diferenciales, fuzzing, despliegue privado, pruebas de denegación de servicio de RPC a gran escala, y pruebas de infraestructura de nodos o clústeres— para validar la corrección de implementación y la resiliencia de infraestructura personalizada [2]. Las pruebas de penetración en blockchain se centran en rutas a nivel institucional y entre capas a través del sistema de gestión de fondos en funcionamiento. El alojamiento de aplicaciones y el CI/CD de aplicaciones se dirigen a la superficie de pruebas de penetración; la infraestructura de nodos y clústeres y la resiliencia de RPC a gran escala se dirigen a Blockchain Security Testing. Una arquitectura puede necesitar ambos.

Los objetivos cercanos también requieren una derivación precisa. La garantía a nivel de código de los contratos se dirige al Code Audit correspondiente. La corrección criptográfica de las implementaciones de custodia de claves, incluidos los diseños MPC, TSS y TEE, se dirige a Wallet Security Audit. Los sistemas agénticos del lado de los pagos se dirigen a Agentic Payment Security [1]. Las pruebas de penetración aún pueden examinar el flujo de trabajo de firma circundante, los agentes operativos o la ruta de la aplicación cuando forman parte del alcance institucional acordado.

Esto es una guía de derivación, no una secuencia. Un solo sistema puede generar múltiples objetivos de garantía y, por lo tanto, justificar un conjunto coordinado de evaluaciones; las etiquetas no son mutuamente excluyentes.

Dependiendo de la jurisdicción y la clase de institución, las pruebas pueden ser un requisito regulatorio o una expectativa de supervisión, y algunos regímenes exigen un tercero independiente; Part 1 explica esas distinciones [3]. La aplicabilidad regulatoria debe confirmarse con asesoría legal.

Cómo empezar

Antes de tomar la decisión, podemos comenzar con las siguientes tres preguntas: ¿Qué sistemas mueven fondos? ¿Qué evidencia de garantía ya existe? ¿Qué cadena de control aún no se ha validado de forma adversarial? Las respuestas identifican la brecha de garantía sin elegir prematuramente un servicio por su nombre.

Una conversación de alcance puede entonces alinear el objetivo, los supuestos de acceso, las salvaguardas y los entregables esperados. Part 3: Rules of Engagement and Production Safety for Institutional Blockchain Penetration Testing cubre la autorización, la seguridad y la coordinación necesarias para operacionalizar el encargo [4].

Cuando esté listo para actuar en consecuencia, defina el alcance de su brecha de garantía con BlockSec para alinear el objetivo, la evidencia y las salvaguardas antes de que comiencen las pruebas.

Continúe con las guías de superficies de ataque:

• Part 4: Web3 Attack Surfaces: A Penetration Testing Overview

También en esta serie, próximamente:

• Part 5: Authorization and Signing Security: Web, dApps, and Mobile
• Part 6: Cloud and CI/CD Security: Automated Operations Attack Surfaces
• Part 7: Treasury Control-Plane Security: Signing and Withdrawal Approvals
• Part 8: Exchange Ledger Security: Theft Paths and Data-Plane Logic

La Blockchain Penetration Testing pillar page ofrece la visión a nivel de encargo.

Referencias

Numeradas en orden de primera aparición.

1. BlockSec, Blockchain Penetration Testing.
2. BlockSec, [Blockchain Security Testing], próximamente.
3. BlockSec, From Incidents to Regulation: Why Crypto Institutions Need Blockchain Penetration Testing.
4. BlockSec, Rules of Engagement and Production Safety for Institutional Blockchain Penetration Testing.