Al leer el informe de "revisión" sobre la seguridad de los hackeos de @CetusProtocol, te darás cuenta de un fenómeno "interesante": los detalles técnicos se divulgan de manera bastante transparente, la respuesta de emergencia es ejemplar, pero en la pregunta más crucial de "¿por qué se fue hackeado?" parece que evitan profundizar en el asunto.
El informe dedica mucho espacio a explicar el error de comprobación de la función 'checked_shlw' de la biblioteca 'integer-mate' (que debería ≤ 2^192, pero en realidad ≤2^256) y lo caracteriza como un "malentendido semántico". Esta narrativa, aunque técnicamente válida, dirige hábilmente el enfoque a la responsabilidad externa, como si Cetus también fuera una víctima inocente de esta falla tecnológica.
La pregunta es, dado que integer-mate es una biblioteca matemática de código abierto y ampliamente utilizada, ¿por qué ocurre un error absurdo en el que se puede obtener una cantidad exorbitante de participación en la liquidez con solo 1 token?
Al analizar la trayectoria de los ataques de hackers, se puede descubrir que para lograr un ataque perfecto, el hacker debe cumplir simultáneamente con cuatro condiciones: verificación de desbordamiento incorrecta, operaciones de desplazamiento de gran magnitud, reglas de redondeo hacia arriba y falta de verificación de razonabilidad económica.
Cetus descuidó en cada una de las condiciones de "activación", por ejemplo: aceptar entradas de usuario como 2^200, realizar operaciones de desplazamiento extremadamente peligrosas, confiar completamente en el mecanismo de verificación de bibliotecas externas, y lo más mortal es que, cuando el sistema calcula un resultado tan absurdo como "1 token por una parte del precio astronómico", se ejecutó directamente sin ninguna verificación de sentido común económico.
Por lo tanto, los puntos que Cetus realmente debería reflexionar son los siguientes:
¿Por qué no se realizaron pruebas de seguridad adecuadas al utilizar bibliotecas externas generales? Aunque la biblioteca integer-mate tiene características como ser de código abierto, popular y ampliamente utilizada, Cetus la utiliza para gestionar activos por valor de cientos de millones de dólares sin comprender completamente cuáles son los límites de seguridad de esta biblioteca, si hay alternativas adecuadas si la biblioteca falla, etc. Es evidente que Cetus carece de una conciencia básica sobre la seguridad de la cadena de suministro.
¿Por qué se permite ingresar números astronómicos sin establecer límites? Aunque se dice que los protocolos DeFi deben buscar la descentralización, un sistema financiero maduro, cuanto más abierto es, más necesita límites claros.
Cuando el sistema permitió una cantidad astronómica cuidadosamente construida por un atacante, el equipo aparentemente no pensó si tal requisito de liquidez era razonable. Incluso el fondo de cobertura más grande del mundo es poco probable que necesite una porción tan exagerada de liquidez. Claramente, el equipo de Cetus carecía de talento en gestión de riesgos con intuición financiera;
¿Por qué todavía no se encuentra ningún problema de antemano después de múltiples rondas de auditorías de seguridad? Esta frase expone inadvertidamente un malentendido cognitivo fatal: el equipo del proyecto externaliza la responsabilidad de la seguridad a la empresa de seguridad, y considera la auditoría como una medalla de oro para la exención. Pero la realidad es dura: los ingenieros de auditoría de seguridad son buenos para encontrar errores de código, y ¿quién hubiera pensado que podría ser un error probar el sistema para calcular la fantástica relación de intercambio?
Esta verificación que cruza los límites de las matemáticas, la criptografía y la economía es la mayor zona ciega de la seguridad moderna de DeFi. Las empresas de auditoría dirán "esto es un defecto de diseño del modelo económico, no un problema de lógica del código"; los desarrolladores del proyecto se quejan de que "la auditoría no encontró problemas"; ¡y los usuarios solo saben que su dinero ha desaparecido!
Mira, esto expone en última instancia la deficiencia sistémica de seguridad en la industria DeFi: los equipos con un trasfondo puramente técnico carecen gravemente de un "olfato para el riesgo financiero" básico.
Y según el informe de Cetus, el equipo claramente no ha reflexionado adecuadamente.
En lugar de centrarse únicamente en las deficiencias técnicas relacionadas con el ataque hacker, creo que a partir de Cetus, todos los equipos de DeFi deberían abandonar la limitación del pensamiento puramente técnico y realmente cultivar la conciencia de riesgo de seguridad de los "ingenieros financieros".
Por ejemplo: introducir expertos en gestión de riesgos financieros para cubrir las lagunas de conocimiento del equipo técnico; implementar un mecanismo de auditoría multi-faceta que no solo revise la auditoría de código, sino que también incluya auditorías del modelo económico cuando sea necesario; cultivar un "olfato financiero", simular varios escenarios de ataque y las correspondientes medidas de respuesta, y mantener una sensibilidad constante ante operaciones anómalas, entre otros.
Esto me recuerda a la experiencia previa en empresas de seguridad, incluyendo el consenso entre los grandes de la industria @evilcos, @chiachih_wu, @yajinzhou, @mikelee205 en sus intercambios.
A medida que la industria madura, los problemas de errores técnicos a nivel de código serán cada vez menos, mientras que la "conciencia de errores" en la lógica de negocio con fronteras poco claras y responsabilidades difusas será el mayor desafío.
Las empresas de auditoría solo pueden garantizar que el código no tiene errores, pero para lograr que la «lógica tenga límites», el equipo del proyecto necesita una comprensión más profunda de la esencia del negocio y la capacidad de controlar esos límites. (La causa fundamental de muchos «incidentes de culpa» tras auditorías de seguridad que aún sufrieron ataques de hackers radica precisamente en esto.)
¡El futuro de DeFi pertenece a aquellos equipos que dominan la tecnología de código y comprenden profundamente la lógica de negocio!
El contenido es solo de referencia, no una solicitud u oferta. No se proporciona asesoramiento fiscal, legal ni de inversión. Consulte el Descargo de responsabilidad para obtener más información sobre los riesgos.
Cetus problemas de seguridad: ¿qué debe tener en cuenta el equipo de Finanzas descentralizadas?
Autor: Haotian
Al leer el informe de "revisión" sobre la seguridad de los hackeos de @CetusProtocol, te darás cuenta de un fenómeno "interesante": los detalles técnicos se divulgan de manera bastante transparente, la respuesta de emergencia es ejemplar, pero en la pregunta más crucial de "¿por qué se fue hackeado?" parece que evitan profundizar en el asunto.
El informe dedica mucho espacio a explicar el error de comprobación de la función 'checked_shlw' de la biblioteca 'integer-mate' (que debería ≤ 2^192, pero en realidad ≤2^256) y lo caracteriza como un "malentendido semántico". Esta narrativa, aunque técnicamente válida, dirige hábilmente el enfoque a la responsabilidad externa, como si Cetus también fuera una víctima inocente de esta falla tecnológica.
La pregunta es, dado que
integer-matees una biblioteca matemática de código abierto y ampliamente utilizada, ¿por qué ocurre un error absurdo en el que se puede obtener una cantidad exorbitante de participación en la liquidez con solo 1 token?Al analizar la trayectoria de los ataques de hackers, se puede descubrir que para lograr un ataque perfecto, el hacker debe cumplir simultáneamente con cuatro condiciones: verificación de desbordamiento incorrecta, operaciones de desplazamiento de gran magnitud, reglas de redondeo hacia arriba y falta de verificación de razonabilidad económica.
Cetus descuidó en cada una de las condiciones de "activación", por ejemplo: aceptar entradas de usuario como 2^200, realizar operaciones de desplazamiento extremadamente peligrosas, confiar completamente en el mecanismo de verificación de bibliotecas externas, y lo más mortal es que, cuando el sistema calcula un resultado tan absurdo como "1 token por una parte del precio astronómico", se ejecutó directamente sin ninguna verificación de sentido común económico.
Por lo tanto, los puntos que Cetus realmente debería reflexionar son los siguientes:
¿Por qué no se realizaron pruebas de seguridad adecuadas al utilizar bibliotecas externas generales? Aunque la biblioteca
integer-matetiene características como ser de código abierto, popular y ampliamente utilizada, Cetus la utiliza para gestionar activos por valor de cientos de millones de dólares sin comprender completamente cuáles son los límites de seguridad de esta biblioteca, si hay alternativas adecuadas si la biblioteca falla, etc. Es evidente que Cetus carece de una conciencia básica sobre la seguridad de la cadena de suministro.¿Por qué se permite ingresar números astronómicos sin establecer límites? Aunque se dice que los protocolos DeFi deben buscar la descentralización, un sistema financiero maduro, cuanto más abierto es, más necesita límites claros.
Cuando el sistema permitió una cantidad astronómica cuidadosamente construida por un atacante, el equipo aparentemente no pensó si tal requisito de liquidez era razonable. Incluso el fondo de cobertura más grande del mundo es poco probable que necesite una porción tan exagerada de liquidez. Claramente, el equipo de Cetus carecía de talento en gestión de riesgos con intuición financiera;
Esta verificación que cruza los límites de las matemáticas, la criptografía y la economía es la mayor zona ciega de la seguridad moderna de DeFi. Las empresas de auditoría dirán "esto es un defecto de diseño del modelo económico, no un problema de lógica del código"; los desarrolladores del proyecto se quejan de que "la auditoría no encontró problemas"; ¡y los usuarios solo saben que su dinero ha desaparecido!
Mira, esto expone en última instancia la deficiencia sistémica de seguridad en la industria DeFi: los equipos con un trasfondo puramente técnico carecen gravemente de un "olfato para el riesgo financiero" básico.
Y según el informe de Cetus, el equipo claramente no ha reflexionado adecuadamente.
En lugar de centrarse únicamente en las deficiencias técnicas relacionadas con el ataque hacker, creo que a partir de Cetus, todos los equipos de DeFi deberían abandonar la limitación del pensamiento puramente técnico y realmente cultivar la conciencia de riesgo de seguridad de los "ingenieros financieros".
Por ejemplo: introducir expertos en gestión de riesgos financieros para cubrir las lagunas de conocimiento del equipo técnico; implementar un mecanismo de auditoría multi-faceta que no solo revise la auditoría de código, sino que también incluya auditorías del modelo económico cuando sea necesario; cultivar un "olfato financiero", simular varios escenarios de ataque y las correspondientes medidas de respuesta, y mantener una sensibilidad constante ante operaciones anómalas, entre otros.
Esto me recuerda a la experiencia previa en empresas de seguridad, incluyendo el consenso entre los grandes de la industria @evilcos, @chiachih_wu, @yajinzhou, @mikelee205 en sus intercambios.
A medida que la industria madura, los problemas de errores técnicos a nivel de código serán cada vez menos, mientras que la "conciencia de errores" en la lógica de negocio con fronteras poco claras y responsabilidades difusas será el mayor desafío.
Las empresas de auditoría solo pueden garantizar que el código no tiene errores, pero para lograr que la «lógica tenga límites», el equipo del proyecto necesita una comprensión más profunda de la esencia del negocio y la capacidad de controlar esos límites. (La causa fundamental de muchos «incidentes de culpa» tras auditorías de seguridad que aún sufrieron ataques de hackers radica precisamente en esto.)
¡El futuro de DeFi pertenece a aquellos equipos que dominan la tecnología de código y comprenden profundamente la lógica de negocio!