El 25 de diciembre de 2023, nuestro sistema de monitoreo detectó una serie de actividades maliciosas dirigidas a Telcoin. Asistimos al equipo de Telcoin en la identificación de la causa raíz como la inicialización incorrecta de los contratos de billetera, que surgió de inconsistencias entre la implementación real de la billetera y su proxy correspondiente. Este informe tiene como objetivo proporcionar un análisis exhaustivo para comprender completamente el incidente.
0x0: Diseño Básico
Antes de examinar la vulnerabilidad, es importante comprender primero las relaciones entre los contratos inteligentes involucrados. En esencia, estos pueden abstraerse en una combinación de tres patrones de diseño: CloneFactory, Cloneable Proxy y Beacon Proxy, que se ilustran en el siguiente diagrama.
0x1: Análisis de Vulnerabilidad
La vulnerabilidad surge de la inicialización incorrecta de los contratos de billetera, que se debe a una discrepancia entre la implementación real de la billetera y su proxy correspondiente. Específicamente, durante el proceso de inicialización, el proxy inicializó el slot de almacenamiento 0 a un estado distinto de cero al escribir en los bits menos significativos de la ubicación de almacenamiento. Posteriormente, el código de la billetera también escribió en el slot de almacenamiento 0, sobrescribiendo así el valor inicial del proxy en los bits menos significativos. Este problema no es el resultado de una vulnerabilidad inherente en ninguno de los contratos inteligentes, sino más bien de la interacción entre los dos.
A continuación, ilustraremos los detalles basándonos en el rastreo de transacción proporcionado a continuación:
Específicamente, dentro de la función CloneableProxy:Proxy.initialize(), hay una llamada delegatecall que invoca la función Wallet.initialize(). Esta invocación ocurre a través de una delegatecall a la función CloneableProxy:Implementation.initialize(). Como resultado, cualquier modificación al almacenamiento realizada por la función Wallet.initialize() se reflejará en el almacenamiento del contrato CloneableProxy:Proxy.
Para comprender completamente las implicaciones, es necesario examinar el diseño de almacenamiento del contrato CloneableProxy:Proxy. La definición de este contrato se describe a continuación:
Dado que ni el contrato Proxy ni el contrato ERC1967Upgrade tienen variables de almacenamiento, el slot 0 es utilizado en su lugar por dos variables de almacenamiento — _initialized e _initializing — ambas heredadas del contrato Initializable.
Ahora, examinemos el contrato Wallet. Dentro de la función Wallet.initialize(), es evidente que el slot 0xaa sirve como bandera de inicialización. Esto se subraya con el siguiente fragmento de código en las líneas 3–4 y 11–12:
Nótese que el slot 0 está asignado para _state, que almacena los siguientes 32 bytes del calldata después del selector de función, como se indica en la línea 21. Para información adicional detallada, consulte el comentario al inicio del contrato Wallet:
Existe una discrepancia perceptible en el uso del slot 0: el contrato CloneableProxy:Proxy lo interpreta como la bandera de inicialización, mientras que la función Wallet:initialize() lo trata como el estado de la billetera.
En consecuencia, después del proceso de inicialización, los dos bytes menos significativos del slot 0 se restablecerán a cero. Esto efectivamente establece tanto _initialized como _initializing en cero. Como resultado, el contrato CloneableProxy:Proxy se vuelve vulnerable a la re-inicialización a través de la función initialize(), ya que la protección del modificador initializer puede ser eludida.
Obviamente, el potencial de explotación depende del estado de la billetera. Una vez actualizado a un valor distinto de cero, el estado de la billetera impide cualquier re-inicialización adicional de este contrato. Después de la inicialización, a medida que el estado de la billetera se actualiza con cada transacción, aumenta la probabilidad de que los dos bytes menos significativos del slot 0 sean distintos de cero, lo que efectivamente inmuniza la billetera contra la re-inicialización. Esto explica por qué la mayoría de las billeteras vulnerables tenían poco o ningún historial de transacciones, dejándolas expuestas al ataque.
0x2: Análisis del Ataque
El atacante comenzó re-inicializando el contrato vulnerable CloneableProxy:Proxy para alterar la dirección del contrato Beacon. Posteriormente, el atacante procedió a transferir los activos contenidos dentro del contrato CloneableProxy:Proxy, como se detalla a continuación:
Es destacable que varios contratos vulnerables fueron comprometidos en una sola transacción, con el atacante ejecutando esta estrategia repetidamente.
0x3: Resumen de Ataques
Observamos 4,958 ataques en total, ejecutados por seis cuentas distintas, como se muestra a continuación:
0x4: Corrección y Recomendaciones
Nuestra investigación ha revelado que el problema central surge del uso inconsistente del slot de almacenamiento 0, lo que lleva a la posibilidad de re-inicializar contratos vulnerables. Obviamente, la solución implica una gestión cuidadosa de las asignaciones de almacenamiento.
De este incidente, hemos obtenido varias perspectivas críticas:
-
Ejercer extrema precaución al manipular slots de almacenamiento con ensamblador en línea, ya que los errores pueden generar vulnerabilidades significativas.
-
Mantener un monitoreo vigilante de los estados de los contratos. La capacidad de respuesta rápida depende de recibir alertas oportunas.
-
Implementar un mecanismo de pausa dentro de los contratos para permitir la suspensión inmediata de actividades si se detecta una vulneración.
Además, el hecho de que este incidente involucrara múltiples transacciones de ataque dirigidas a diferentes contratos de billetera destaca la apremiante necesidad de soluciones de monitoreo de amenazas y bloqueo de ataques, como Phalcon. Dichas herramientas son esenciales para mitigar riesgos futuros y proteger contra pérdidas potenciales.
0x5: Cronología de Eventos
09:23 AM PST, 25 de diciembre: Nuestro sistema detectó la primera transacción maliciosa en la red Polygon:
10:28 AM PST, 25 de diciembre: El equipo de soporte de Telcoin reportó el incidente en el canal de comunicación interno.
10:32 AM — 10:37 AM PST, 25 de diciembre: Los miembros del equipo de Telcoin notificaron a la comunidad de Discord de Telcoin y crearon una llamada de emergencia con todos los miembros clave del equipo relevantes.
10:45 AM PST, 25 de diciembre: Se implementó una regla de Firewall de Aplicaciones Web para restringir todo el acceso a la Infraestructura de Telcoin.
11:02 AM PST, 25 de diciembre: El equipo de Telcoin inició conversaciones con Seal 911
11:11 AM PST, 25 de diciembre: El equipo de Telcoin y otros miembros de seguridad establecieron una sala de guerra para descubrir la causa raíz del problema y discutir posibles soluciones para bloquear el ataque.
01:14 PM PST, 25 de diciembre: El equipo de Telcoin emitió públicamente una alerta a los usuarios a través de X (Twitter):
03:39 PM PST, 25 de diciembre: Telcoin contactó a Chainalysis y Slowmist para ayudar a investigar los fondos robados mediante una investigación en la que etiquetaron las billeteras y direcciones robadas y compartieron esta información con los exchanges.
10:35 PM PST, 25 de diciembre: Por invitación del equipo de Telcoin, nos unimos a la sala de guerra y compartimos nuestro análisis para determinar la causa raíz.
11:00 PM PST 25 de diciembre a 02:06 AM PST 26 de diciembre: Tras identificar la causa raíz, el equipo de Telcoin logró diseñar una estrategia de mitigación replicando el exploit de manera segura y controlada. Este proceso involucró la re-inicialización de los proxies de billetera para alinearse con un nuevo beacon implementado de forma segura. Dado que este exploit era una oportunidad única, Telcoin puede actualizar preventivamente las configuraciones de las billeteras, deshabilitando así la capacidad del atacante para explotar estas vulnerabilidades.
02:07 AM PST 26 de diciembre a 02:14 AM PST 26 de diciembre: El equipo de Telcoin implementó el proceso de mitigación en todas las billeteras no comprometidas previamente para garantizar una cobertura integral. Para una implementación rápida y eficiente, el proceso se ejecutó en lotes dentro de una ventana de tiempo estrictamente definida. Telcoin luego comenzó el proceso de preparar y luego probar internamente el plan de remediación para una restauración completa de todas las billeteras afectadas y una solución permanente para todas las billeteras.
04:52 PM PST 26 de diciembre: Telcoin y nuestro equipo iniciaron discusiones sobre los siguientes temas:
-
Resumen del Incidente
-
Cronología de Eventos: Un recuento cronológico de cómo se desarrolló el incidente.
-
Análisis de Causa Raíz: Un análisis en profundidad de las causas subyacentes del incidente.
-
Recomendaciones para Mejoras
-
Auditoría de Código
12:27 PM PST 29 de diciembre: Después de varias rondas de discusión, comenzamos a colaborar con el equipo de Telcoin para redactar el informe post-mortem y auditar las remediaciones.
03 de enero de 2024: Se proporcionó el borrador del post-mortem.
04 de enero de 2024: Se presentaron nuestros hallazgos de auditoría, incluyendo problemas identificados y recomendaciones.
04 al 10 de enero de 2024: Colaboramos con el equipo de Telcoin para finalizar el post-mortem y revisar las correcciones.
Además, vale la pena destacar que desde el 25 de diciembre hasta la fecha actual, Telcoin ha estado trabajando activamente en estrecha colaboración con empresas de investigación blockchain y las fuerzas del orden en relación con el incidente.
Acerca de BlockSec
BlockSec es una empresa pionera en seguridad blockchain establecida en 2021 por un grupo de expertos en seguridad de renombre mundial. La empresa está comprometida con mejorar la seguridad y la usabilidad para el emergente mundo Web3 con el fin de facilitar su adopción masiva. Con este fin, BlockSec proporciona servicios de auditoría de seguridad para contratos inteligentes y cadenas EVM, la plataforma Phalcon para el desarrollo de seguridad y el bloqueo proactivo de amenazas, la plataforma MetaSleuth para el rastreo e investigación de fondos, y la extensión MetaDock para que los constructores de web3 naveguen eficientemente en el mundo cripto.
Hasta la fecha, la empresa ha atendido a más de 300 clientes distinguidos como MetaMask, Uniswap Foundation, Compound, Forta y PancakeSwap, y ha recibido decenas de millones de dólares en dos rondas de financiamiento de inversores prominentes, incluyendo Matrix Partners, Vitalbridge Capital y Fenbushi Capital.
Sitio web: https://blocksec.com/
