El equipo con un trasfondo puramente técnico carece gravemente de un sentido básico de "olfato para el riesgo financiero".
Escrito por: Haotian
Al leer el informe de "análisis de seguridad" sobre el hackeo de @CetusProtocol, te encontrarás con un fenómeno "interesante": los detalles técnicos se revelan de manera bastante transparente, y la respuesta de emergencia es digna de un manual, pero en la pregunta más crucial de "¿por qué fue hackeado?" parece eludir lo más importante:
El informe dedica una gran parte a explicar la función checked\_shlw de la biblioteca integer-mate que verifica errores (debería ser ≤2^192, pero en realidad es ≤2^256), y califica esto como un "malentendido semántico". Aunque esta descripción es técnicamente válida, desvía astutamente la atención hacia la responsabilidad externa, como si Cetus también fuera una víctima inocente de este defecto técnico.
Surge la pregunta, dado que integer-mate es una biblioteca matemática de código abierto y de amplio uso, ¿cómo es posible que ocurra un error absurdo donde con 1 token se pueda obtener una participación en la liquidez a un precio exorbitante?
El análisis de las rutas de ataque de los hackers revela que para llevar a cabo un ataque perfecto, deben cumplirse simultáneamente cuatro condiciones: verificación de desbordamiento incorrecta, operaciones de desplazamiento a gran escala, reglas de redondeo hacia arriba y falta de verificación de viabilidad económica.
Cetus descuidó en cada una de las condiciones de "activación", como por ejemplo: aceptar entradas de usuario como 2^200, realizar operaciones de desplazamiento masivo extremadamente peligrosas, confiar completamente en el mecanismo de verificación de bibliotecas externas, y lo más mortal de todo — cuando el sistema calculó un resultado absurdo de "1 token por una participación extremadamente alta", se ejecutó directamente sin ninguna verificación de sentido económico.
Por lo tanto, los verdaderos puntos que Cetus debería reflexionar son los siguientes:
¿Por qué no se realizaron pruebas de seguridad adecuadas al utilizar bibliotecas externas genéricas? 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 más de mil millones de dólares sin comprender adecuadamente cuáles son los límites de seguridad de esta biblioteca, qué alternativas adecuadas hay si la función de la biblioteca falla, etc. Es evidente que Cetus carece de la conciencia más básica sobre la seguridad de la cadena de suministro;
¿Por qué se permite ingresar números astronómicos sin establecer límites? Aunque los protocolos DeFi deben buscar la descentralización, un sistema financiero maduro, cuanto más abierto sea, más necesita límites claros.
Cuando el sistema permite la entrada de números astronómicos cuidadosamente elaborados por un atacante, el equipo claramente no ha pensado si tal demanda de liquidez es razonable. Incluso el fondo de cobertura más grande del mundo no podría necesitar una participación de liquidez tan exagerada. Es evidente que el equipo de Cetus carece de talento en gestión de riesgos con intuición financiera;
¿Por qué, después de múltiples auditorías de seguridad, aún no se detectaron problemas de antemano? Esta frase revela inadvertidamente un error de percepción mortal: el equipo del proyecto externaliza la responsabilidad de seguridad a una empresa de seguridad, considerando la auditoría como un pase libre de responsabilidad. Pero la realidad es dura: los ingenieros de auditoría de seguridad son buenos en detectar errores en el código, ¿quién pensaría en probar que los ratios de intercambio, que suenan a una locura, podrían estar mal?
La validación que cruza las fronteras de las matemáticas, la criptografía y la economía es precisamente la mayor zona ciega de la seguridad DeFi moderna. Las empresas de auditoría dirán: "Este es un defecto de diseño del modelo económico, no un problema de lógica del código"; los proyectos se quejan: "La auditoría no encontró problemas"; ¡y los usuarios solo saben que su dinero ha desaparecido!
Mira, esto expone, en última instancia, la debilidad sistémica en la seguridad de la industria DeFi: los equipos con un fondo puramente técnico carecen gravemente de un sentido básico de "detección de riesgos financieros".
Y según este informe de Cetus, el equipo claramente no ha reflexionado adecuadamente.
En lugar de centrarse únicamente en las deficiencias técnicas relacionadas con el ataque de hackers, 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; establecer un mecanismo de revisión de auditorías múltiples, no solo revisar la auditoría del código, también es necesario incluir la auditoría de modelos económicos; cultivar un "olfato financiero", simular varios escenarios de ataque y las correspondientes medidas de respuesta, mantener una sensibilidad constante hacia las operaciones anómalas, etc.
Esto me recuerda a mi experiencia previa en empresas de seguridad, incluyendo el consenso que tienen grandes figuras de la industria de la seguridad como @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 disminuirán, mientras que la "conciencia de errores" de la lógica empresarial con fronteras difusas y responsabilidades ambiguas será el mayor desafío.
Las empresas de auditoría solo pueden garantizar que el código no tenga 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 razón fundamental de muchos "incidentes de culpa" después de auditorías de seguridad que aún sufrieron ataques de hackers radica en esto)
¡El futuro de DeFi pertenece a aquellos equipos que tienen habilidades sólidas en tecnología de código y una comprensión profunda de la lógica empresarial!
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é deben tener en cuenta los equipos de Finanzas descentralizadas?
Escrito por: Haotian
Al leer el informe de "análisis de seguridad" sobre el hackeo de @CetusProtocol, te encontrarás con un fenómeno "interesante": los detalles técnicos se revelan de manera bastante transparente, y la respuesta de emergencia es digna de un manual, pero en la pregunta más crucial de "¿por qué fue hackeado?" parece eludir lo más importante:
El informe dedica una gran parte a explicar la función
checked\_shlwde la bibliotecainteger-mateque verifica errores (debería ser ≤2^192, pero en realidad es ≤2^256), y califica esto como un "malentendido semántico". Aunque esta descripción es técnicamente válida, desvía astutamente la atención hacia la responsabilidad externa, como si Cetus también fuera una víctima inocente de este defecto técnico.Surge la pregunta, dado que
integer-matees una biblioteca matemática de código abierto y de amplio uso, ¿cómo es posible que ocurra un error absurdo donde con 1 token se pueda obtener una participación en la liquidez a un precio exorbitante?El análisis de las rutas de ataque de los hackers revela que para llevar a cabo un ataque perfecto, deben cumplirse simultáneamente cuatro condiciones: verificación de desbordamiento incorrecta, operaciones de desplazamiento a gran escala, reglas de redondeo hacia arriba y falta de verificación de viabilidad económica.
Cetus descuidó en cada una de las condiciones de "activación", como por ejemplo: aceptar entradas de usuario como 2^200, realizar operaciones de desplazamiento masivo extremadamente peligrosas, confiar completamente en el mecanismo de verificación de bibliotecas externas, y lo más mortal de todo — cuando el sistema calculó un resultado absurdo de "1 token por una participación extremadamente alta", se ejecutó directamente sin ninguna verificación de sentido económico.
Por lo tanto, los verdaderos puntos que Cetus debería reflexionar son los siguientes:
¿Por qué no se realizaron pruebas de seguridad adecuadas al utilizar bibliotecas externas genéricas? 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 más de mil millones de dólares sin comprender adecuadamente cuáles son los límites de seguridad de esta biblioteca, qué alternativas adecuadas hay si la función de la biblioteca falla, etc. Es evidente que Cetus carece de la conciencia más básica sobre la seguridad de la cadena de suministro;¿Por qué se permite ingresar números astronómicos sin establecer límites? Aunque los protocolos DeFi deben buscar la descentralización, un sistema financiero maduro, cuanto más abierto sea, más necesita límites claros.
Cuando el sistema permite la entrada de números astronómicos cuidadosamente elaborados por un atacante, el equipo claramente no ha pensado si tal demanda de liquidez es razonable. Incluso el fondo de cobertura más grande del mundo no podría necesitar una participación de liquidez tan exagerada. Es evidente que el equipo de Cetus carece de talento en gestión de riesgos con intuición financiera;
La validación que cruza las fronteras de las matemáticas, la criptografía y la economía es precisamente la mayor zona ciega de la seguridad DeFi moderna. Las empresas de auditoría dirán: "Este es un defecto de diseño del modelo económico, no un problema de lógica del código"; los proyectos se quejan: "La auditoría no encontró problemas"; ¡y los usuarios solo saben que su dinero ha desaparecido!
Mira, esto expone, en última instancia, la debilidad sistémica en la seguridad de la industria DeFi: los equipos con un fondo puramente técnico carecen gravemente de un sentido básico de "detección de riesgos financieros".
Y según este informe de Cetus, el equipo claramente no ha reflexionado adecuadamente.
En lugar de centrarse únicamente en las deficiencias técnicas relacionadas con el ataque de hackers, 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; establecer un mecanismo de revisión de auditorías múltiples, no solo revisar la auditoría del código, también es necesario incluir la auditoría de modelos económicos; cultivar un "olfato financiero", simular varios escenarios de ataque y las correspondientes medidas de respuesta, mantener una sensibilidad constante hacia las operaciones anómalas, etc.
Esto me recuerda a mi experiencia previa en empresas de seguridad, incluyendo el consenso que tienen grandes figuras de la industria de la seguridad como @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 disminuirán, mientras que la "conciencia de errores" de la lógica empresarial con fronteras difusas y responsabilidades ambiguas será el mayor desafío.
Las empresas de auditoría solo pueden garantizar que el código no tenga 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 razón fundamental de muchos "incidentes de culpa" después de auditorías de seguridad que aún sufrieron ataques de hackers radica en esto)
¡El futuro de DeFi pertenece a aquellos equipos que tienen habilidades sólidas en tecnología de código y una comprensión profunda de la lógica empresarial!