Introducción
El sector blockchain se ha obsesionado singularmente con descubrir vulnerabilidades en el código de los contratos inteligentes. La inversión de los equipos de desarrollo se destina a auditorías, concursos de recompensa por errores, herramientas de fuzzing y técnicas de verificación formal, con la convicción de que, al encontrar todos esos errores finales en el código, se lograría la seguridad.
Este método es importante, pero no tiene en cuenta uno de los hechos más aterradores que salieron a la luz en 2024. La vía de ataque más catastrófica que actualmente acecha a los protocolos de criptomonedas no son las complejas cadenas de exploits ni las vulnerabilidades ocultas en el código. Se trata, más bien, de una amenaza mucho más profunda y menos discutida que ha dominado el panorama de las amenazas en los últimos años.
El compromiso de las claves privadas se apodera del panorama de amenazas
Un estudio de 2024 ofrece una estadística alarmante que obligará a redefinir tu enfoque de la seguridad de las cadenas de bloques. La proporción de todos los fondos en criptomonedas robados a lo largo del año que se vieron comprometidos a través de una clave privada es del 43,8 %, lo que lo convierte, con diferencia, en el tipo de ataque más exitoso.
Las debilidades en el control de acceso arquitectónico no suelen ser comunicadas por las empresas de auditoría de cadenas de bloques tradicionales como hallazgos formales, y las plataformas de auditoría competitivas desincentivan explícitamente las presentaciones que se centran en este tipo de problemas sistémicos.
Este enfoque tan específico contrasta radicalmente con las mejores prácticas de auditorías de seguridad en otros sectores, donde la escalada de privilegios y el diseño del control de acceso son cuestiones fundamentales que deben tenerse en cuenta en una fase más temprana del ciclo de desarrollo, cuando a menudo ya es demasiado tarde para cambiar la naturaleza general de los problemas de control de acceso del sistema.
Para conceptualizar los efectos de las decisiones de diseño sobre la vulnerabilidad a los ataques contra claves privadas, considera el siguiente protocolo teórico de préstamos sobrecolateralizados. Sin embargo, se requiere acceso privilegiado a dichos sistemas para realizar varias operaciones importantes:
- Inclusión y exclusión de activos compatibles
- Configuración de los parámetros de riesgo y los tipos de interés
- Cobro de tasas de protocolo
- Pausas de emergencia y actualizaciones desarrollo de contratos inteligentes.
Estos definen la resiliencia general de dicho protocolo ante el compromiso de la clave privada.
Nivel 1: Exposición total con control de un solo punto
El nivel más bajo es aquel en el que el desarrollador tiene una única cuenta controlada externamente con derechos administrativos completos sobre todas las funciones del protocolo. Esta arquitectura es la configuración más vulnerable, en la que la violación de una clave privada proporcionará a los atacantes acceso instantáneo y completo al sistema, posiblemente en forma de carteras de software conectadas a Internet.
La amenaza de traición es inmensa y el efecto devastador y directo.
Nivel 2: Gestión sencilla de riesgos mediante claves distribuidas
El siguiente nivel de madurez consiste en transferir los poderes administrativos a la cartera multifirma, que necesitará la garantía de varios titulares de claves para ejecutar la actualización. Esto solo puede reducir las posibilidades de compromiso y no restringe el alcance del daño que puede sufrir el protocolo, pero sigue siendo una mejora.
Esto es mucho mejor que tener un control de clave única en términos de seguridad, ya que la apropiación del protocolo ya no requiere suficiente acceso con el compromiso de una clave de firmante. No obstante, sigue habiendo riesgos elevados a pesar de la mejora:
- La rapidez de ejecución es una cuestión importante, ya que pueden llevarse a cabo acciones maliciosas antes de que se produzca la respuesta de seguridad.
- Aunque los puntos de fallo se distribuyen entre las claves, la estructura de control sigue estando centralizada.
- Incluso los sistemas multifirma bien protegidos pueden verse comprometidos mediante técnicas avanzadas de ingeniería social
Nivel 3: Protección mejorada mediante la separación por tiempo y función
Las drásticas mejoras en la madurez requieren la aplicación de dos mecanismos de control críticos: los bloqueos temporales y el principio del mínimo privilegio.
Los bloqueos temporales imponen un retraso entre la aprobación y la ejecución de la transacción, lo que da tiempo para examinarla y responder a cualquier incidente. El principio del privilegio mínimo consiste en separar las funciones y responsabilidades, de modo que a cada función se le conceda solo el mínimo de permisos necesarios para desempeñar una función concreta.
Este nivel aborda los fallos fundamentales de los métodos más simples:
- No permite la ejecución inmediata
- Comparte el control entre múltiples especializaciones.
- Da tiempo a los equipos de seguridad para verificar transacciones inesperadas
- Permite una intervención proactiva en lugar de un control reactivo de los daños
Nivel 4: Nivel de seguridad máximo
El nivel más alto de madurez se basa en la eliminación total de las acciones administrativas, y es la forma más radical de compromiso con la idea de descentralización y minimización de la confianza. Tal estrategia excluye categóricamente el control de acceso como parte del modelo de amenazas del protocolo.
Para alcanzar este nivel, se requieren enfoques completamente diferentes a los de todos los demás niveles:
- Se debe eliminar la posibilidad de actualizar los contratos: los contratos inteligentes pasan a ser totalmente inmutables.
- La lista de activos pasa a ser libre: los mercados autónomos se implementan de forma independiente
- Los parámetros de riesgo están consagrados de forma permanente: no es posible la gestión administrativa.
- No es posible realizar intervenciones de emergencia: los sistemas no se pueden ajustar después de su implementación
En el caso de los sistemas de préstamos sobrecolateralizados, hay que tener en cuenta varios elementos críticos:
- Nuevas funciones implementadas en despliegues totalmente diferentes con migración manual de usuarios
- Mercados formados como instancias de protocolo independientes para activos concretos.
- Los parámetros de riesgo siguen directrices algorítmicas o ajustes de implementación permanentes.
Esta cifra es cinco veces mayor que cualquier otro tipo de ataque confirmado, pero el ecosistema de seguridad de la cadena de bloques no está preparado en gran medida para hacer frente a una amenaza de este tipo.
Asegura tu protocolo hoy mismo
No esperes a llegar a un compromiso. Implementa controles de acceso adecuados ahora mismo.
Marco de separación de funciones
| Tipo de función | Responsabilidades | Requisitos de seguridad | Duración del bloqueo temporal |
|---|---|---|---|
| Sistema central | Actualizaciones de contratos | Uso de umbrales de multifirma elevados | Grandes retrasos |
| Operaciones | Configuración del protocolo diario | Necesidades de seguridad moderadas. | Retrasos medios |
| Pausa Guardian | Suspensión del protocolo de emergencia. | Capacidad de acción inmediata. | Sin retrasos. |
| Cancelar Guardian | Revoca las aprobaciones maliciosas | Autoridad de respuesta rápida. | Sin retrasos. |
Los equipos de seguridad ahora pueden intervenir de manera positiva en los casos, en lugar de limitarse a responder al daño una vez que se ha producido, pero esto conlleva nuevos riesgos, como posibles errores en los sistemas de gestión de roles.
Aunque este paradigma de diseño no presenta ningún riesgo de control de acceso, conlleva importantes inconvenientes, como la imposibilidad de intervenir en caso de emergencia y los enormes costes iniciales de verificación.
Creación de sistemas resilientes desde el primer día
La vulnerabilidad de la clave privada en casi la mitad de todos los robos de criptomonedas en 2024 es un problema que no se puede ignorar debido a las decisiones de control de acceso arquitectónico tomadas al inicio del proceso de diseño. Aunque la identificación convencional de vulnerabilidades sigue siendo necesaria, las decisiones de diseño fundamentales deberán tenerse en cuenta mucho antes en el ciclo de desarrollo.
Las medidas reales que se pueden tomar para mejorar la seguridad incluyen:
- Análisis sincero del estado actual de madurez del protocolo.
- Implementación de contratos con bloqueo temporal en funciones administrativas
- Sistemas de supervisión adecuados para modos administrativos de alto riesgo
- Asignación de funciones privilegiadas y separación en roles lógicos
- Aplicación de los principios de privilegio mínimo
- Identificación de elementos de diseño adecuados para patrones inmutables
La forma en que los desarrolladores pueden crear protocolos que sean innovadores y robustos es comprendiendo los marcos de madurez y eligiendo conscientemente patrones de diseño que eviten la dependencia de la confianza o permitan que se extienda el compromiso.
Esto requiere invertir en resiliencia operativa en las primeras fases del desarrollo, asegurándose de que los protocolos sean resistentes no solo a las intrusiones técnicas, sino también a los factores humanos que hacen que el compromiso de las claves privadas sea una fuente de amenazas tan exitosa.
