Al leer el informe de "análisis" de la seguridad del ataque de Hacker de @CetusProtocol, descubrirás un fenómeno "interesante": los detalles técnicos se revelan con bastante transparencia, la respuesta de emergencia es casi de nivel académico, pero en la pregunta más crucial de "¿por qué fueron hackeados?", parece evitar lo más importante:
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 de uso amplio, ¿cómo es posible que se haya producido un error absurdo en el que se puede obtener una participación de liquidez extremadamente alta con solo 1 token?
Al analizar la ruta de ataque de un Hacker, se puede descubrir que para lograr un ataque perfecto, debe cumplirse simultáneamente cuatro condiciones: verificación de desbordamiento incorrecta, operaciones de desplazamiento significativo, regla de redondeo hacia arriba y falta de verificación de viabilidad 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 de gran magnitud extremadamente peligrosas, confiar completamente en el mecanismo de verificación de bibliotecas externas, lo más mortal es que, cuando el sistema calculó un resultado absurdo como "1 token por una fortuna", se ejecutó directamente sin ninguna verificación de sentido económico.
Por lo tanto, los puntos que Cetus realmente debería reflexionar son los siguientes:
1）¿Por qué no se realizaron pruebas de seguridad adecuadas al adoptar 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 cientos de millones de dólares sin comprender adecuadamente cuáles son los límites de seguridad de esta biblioteca, si hay alternativas adecuadas en caso de que la función de la biblioteca falle, 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 el atacante, el equipo claramente no ha pensado en si una demanda de liquidez así es razonable. Ni siquiera el fondo de cobertura más grande del mundo podría necesitar una participación de liquidez tan exagerada. Evidentemente, el equipo de Cetus carece de personal de 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 previamente? Esta frase expone inadvertidamente un error de percepción fatal: el equipo del proyecto externaliza la responsabilidad de seguridad a la empresa de seguridad, convirtiendo la auditoría en una especie de medalla de exención de responsabilidad. Pero la realidad es cruel: los ingenieros de auditoría de seguridad son expertos en detectar errores en el código, ¿quién pensaría en probar que el cálculo de la proporción de intercambio, que suena como una fantasía, podría estar mal?
Esta validación que cruza las fronteras de las matemáticas, la criptografía y la economía, es precisamente el mayor punto ciego de la seguridad moderna en 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"; el equipo del proyecto se queja "la auditoría no encontró problemas"; ¡y los usuarios solo saben que su dinero se ha ido!
Mira, esto expone en última instancia la debilidad sistémica de seguridad en la industria DeFi: los equipos con un trasfondo puramente técnico carecen seriamente de un sentido básico de "risco financiero".
Y desde 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 de hackers, creo que a partir de Cetus, todos los equipos de DeFi deberían dejar de lado las limitaciones 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 y revisión múltiple, que no solo examine la auditoría del código, sino que también incluya la auditoría del modelo económico cuando sea necesario; cultivar un "olfato financiero", simular diversos escenarios de ataque y las correspondientes medidas de respuesta, y mantener la sensibilidad ante operaciones anómalas en todo momento, etc.
Esto me recuerda a la experiencia previa en la industria de las empresas de seguridad, incluyendo el consenso que se ha establecido en las conversaciones con los grandes de la seguridad de la industria @evilcos, @chiachih_wu, @yajinzhou, @mikelee205:
A medida que la industria madura, los problemas técnicos de errores en el código disminuirán, mientras que la "conciencia de errores" en la lógica empresarial, que es difusa y con responsabilidades poco claras, 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» se necesita que el equipo del proyecto tenga una comprensión más profunda de la esencia del negocio y la capacidad de controlar los límites. (La raíz de muchos «incidentes de culpa» después de auditorías de seguridad que aún fueron atacados por hackers radica en esto.)
¡El futuro de DeFi pertenece a aquellos equipos que tienen habilidades técnicas sólidas en codificación y una comprensión profunda de la lógica comercial!
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.
Recompensa
Me gusta
1
Compartir
Comentar
0/400
Insistant
· 05-28 04:13
Este tipo de cosas es un noventa y nueve por ciento un robo interno.
¿Qué lecciones nos deja el incidente de seguridad de Cetus, que resultó en el robo de más de 200 millones de dólares?
Al leer el informe de "análisis" de la seguridad del ataque de Hacker de @CetusProtocol, descubrirás un fenómeno "interesante": los detalles técnicos se revelan con bastante transparencia, la respuesta de emergencia es casi de nivel académico, pero en la pregunta más crucial de "¿por qué fueron hackeados?", parece evitar lo más importante:
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 de uso amplio, ¿cómo es posible que se haya producido un error absurdo en el que se puede obtener una participación de liquidez extremadamente alta con solo 1 token?Al analizar la ruta de ataque de un Hacker, se puede descubrir que para lograr un ataque perfecto, debe cumplirse simultáneamente cuatro condiciones: verificación de desbordamiento incorrecta, operaciones de desplazamiento significativo, regla de redondeo hacia arriba y falta de verificación de viabilidad 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 de gran magnitud extremadamente peligrosas, confiar completamente en el mecanismo de verificación de bibliotecas externas, lo más mortal es que, cuando el sistema calculó un resultado absurdo como "1 token por una fortuna", se ejecutó directamente sin ninguna verificación de sentido económico.
Por lo tanto, los puntos que Cetus realmente debería reflexionar son los siguientes:
1）¿Por qué no se realizaron pruebas de seguridad adecuadas al adoptar 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 cientos de millones de dólares sin comprender adecuadamente cuáles son los límites de seguridad de esta biblioteca, si hay alternativas adecuadas en caso de que la función de la biblioteca falle, etc. Es evidente que Cetus carece de la conciencia más básica sobre la seguridad de la cadena de suministro;Cuando el sistema permite la entrada de números astronómicos cuidadosamente elaborados por el atacante, el equipo claramente no ha pensado en si una demanda de liquidez así es razonable. Ni siquiera el fondo de cobertura más grande del mundo podría necesitar una participación de liquidez tan exagerada. Evidentemente, el equipo de Cetus carece de personal de gestión de riesgos con intuición financiera;
Esta validación que cruza las fronteras de las matemáticas, la criptografía y la economía, es precisamente el mayor punto ciego de la seguridad moderna en 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"; el equipo del proyecto se queja "la auditoría no encontró problemas"; ¡y los usuarios solo saben que su dinero se ha ido!
Mira, esto expone en última instancia la debilidad sistémica de seguridad en la industria DeFi: los equipos con un trasfondo puramente técnico carecen seriamente de un sentido básico de "risco financiero".
Y desde 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 de hackers, creo que a partir de Cetus, todos los equipos de DeFi deberían dejar de lado las limitaciones 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 y revisión múltiple, que no solo examine la auditoría del código, sino que también incluya la auditoría del modelo económico cuando sea necesario; cultivar un "olfato financiero", simular diversos escenarios de ataque y las correspondientes medidas de respuesta, y mantener la sensibilidad ante operaciones anómalas en todo momento, etc.
Esto me recuerda a la experiencia previa en la industria de las empresas de seguridad, incluyendo el consenso que se ha establecido en las conversaciones con los grandes de la seguridad de la industria @evilcos, @chiachih_wu, @yajinzhou, @mikelee205:
A medida que la industria madura, los problemas técnicos de errores en el código disminuirán, mientras que la "conciencia de errores" en la lógica empresarial, que es difusa y con responsabilidades poco claras, 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» se necesita que el equipo del proyecto tenga una comprensión más profunda de la esencia del negocio y la capacidad de controlar los límites. (La raíz de muchos «incidentes de culpa» después de auditorías de seguridad que aún fueron atacados por hackers radica en esto.)
¡El futuro de DeFi pertenece a aquellos equipos que tienen habilidades técnicas sólidas en codificación y una comprensión profunda de la lógica comercial!