Cetus Protocol recientemente publicó un informe de retrospectiva de seguridad sobre un incidente de ataque Hacker. Este informe es bastante transparente en la divulgación de detalles técnicos y la respuesta de emergencia, siendo un ejemplo digno de un libro de texto. Sin embargo, al explicar "por qué fueron hackeados", la actitud del informe parece esquivar un poco la cuestión central.
El informe destaca la explicación del error de verificación en la función checked_shlw de la biblioteca integer-mate, calificándolo como "malentendido semántico". Aunque esta descripción es técnicamente correcta, parece desviar el enfoque hacia la responsabilidad externa, como si Cetus también fuera una víctima de este defecto técnico.
Sin embargo, vale la pena reflexionar sobre por qué, dado que integer-mate es una biblioteca matemática de código abierto de uso generalizado, ha surgido una vulnerabilidad tan grave aquí en Cetus. Al analizar la ruta de ataque, se puede observar que para que un hacker lleve a cabo un ataque perfecto, debe cumplir simultáneamente con cuatro condiciones: verificación de desbordamiento incorrecta, operación de desplazamiento significativo, regla de redondeo hacia arriba y falta de verificación de razonabilidad económica.
Sorprendentemente, Cetus mostró negligencia en cada una de las condiciones de "activación". Por ejemplo, el sistema aceptó números astronómicos ingresados por los usuarios, utilizó cálculos de desplazamiento extremadamente peligrosos y confió completamente en el mecanismo de verificación de bibliotecas externas. Lo más mortal es que, cuando el sistema calculó un resultado tan absurdo como "1 token por una participación a precio de oro", se ejecutó directamente sin ninguna verificación de sentido económico.
Por lo tanto, las verdaderas cuestiones que Cetus debería reflexionar incluyen:
¿Por qué se utiliza una biblioteca externa genérica sin realizar pruebas de seguridad adecuadas? Aunque la biblioteca integer-mate tiene características como ser de código abierto, popular y ampliamente utilizada, parece que Cetus no ha comprendido completamente los límites de seguridad de esta biblioteca al gestionar activos tan enormes, ni ha considerado alternativas en caso de que la biblioteca falle. Esto refleja una falta de conciencia en la protección de la seguridad de la cadena de suministro por parte de Cetus.
¿Por qué se permite la entrada de números astronómicos sin establecer límites? A pesar de que los protocolos DeFi persiguen la descentralización, los sistemas financieros maduros también necesitan límites claros al mismo tiempo que son abiertos. Permitir la entrada de números tan exagerados indica que el equipo puede carecer de talento en gestión de riesgos con intuición financiera.
¿Por qué, después de múltiples auditorías de seguridad, todavía no se detectaron problemas de antemano? Esto expone un error cognitivo fatal: el equipo del proyecto externaliza completamente la responsabilidad de seguridad a la empresa de seguridad, considerando la auditoría como un pase de exención de responsabilidad. Sin embargo, los ingenieros de auditoría de seguridad son expertos en detectar errores en el código, pero pueden no pensar en probar el rendimiento del sistema en situaciones extremas.
Esta verificación que cruza las fronteras de las matemáticas, la criptografía y la economía es precisamente el mayor vacío de seguridad en el DeFi moderno. Las empresas de auditoría pueden considerar que se trata de un defecto en el diseño del modelo económico y no de un problema de lógica del código, mientras que los proyectos pueden quejarse de que la auditoría no detectó problemas, y los usuarios son quienes finalmente asumen las pérdidas.
Este evento expuso las deficiencias de seguridad sistémica en la industria DeFi: los equipos con un trasfondo puramente técnico a menudo carecen de un "olfato para el riesgo financiero" básico. Según el informe de Cetus, el equipo parece no haber reconocido completamente este hecho.
Para Cetus y toda la industria DeFi, es importante salir de las limitaciones del pensamiento puramente técnico y cultivar una verdadera conciencia de riesgos de seguridad entre los "ingenieros financieros". Se podría considerar la incorporación de expertos en control de riesgos financieros para cubrir las lagunas de conocimiento del equipo técnico; establecer un mecanismo de auditoría y revisión de múltiples partes, que no solo se enfoque en la auditoría del código, sino que también preste atención a la auditoría del modelo económico; cultivar un "olfato financiero", simular varios escenarios de ataque y formular medidas de respuesta correspondientes, manteniendo una alta vigilancia sobre operaciones anómalas.
Con el desarrollo de la industria, los errores técnicos a nivel de código pueden ir disminuyendo gradualmente, pero la lógica empresarial con "conciencia de error" que tiene fronteras difusas y responsabilidades poco claras se convertirá en el mayor desafío. Las empresas de auditoría pueden asegurar que el código no tenga errores, pero cómo lograr que la "lógica tenga límites" requiere que el equipo del proyecto tenga una comprensión más profunda de la naturaleza del negocio y la capacidad de controlar los límites.
El futuro de DeFi pertenece a aquellos equipos que no solo tienen habilidades técnicas sólidas en código, sino que también comprenden profundamente la lógica empresarial. Solo los equipos que posean estas dos capacidades simultáneamente podrán establecerse realmente y tener éxito en esta industria llena de desafíos.
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
20 me gusta
Recompensa
20
6
Compartir
Comentar
0/400
GasWhisperer
· 07-17 18:44
los patrones del mempool nunca mienten... integer-mate fue solo la puerta de entrada, no la vulnerabilidad central para ser honesto
Ver originalesResponder0
DataOnlooker
· 07-17 15:56
¡Maestro en echar la culpa, este Cetus!
Ver originalesResponder0
ImpermanentLossEnjoyer
· 07-15 05:30
Las pérdidas aún se pueden analizar. 香嗷
Ver originalesResponder0
DegenApeSurfer
· 07-15 05:30
Quien viva, que asuma la responsabilidad.
Ver originalesResponder0
SatoshiLegend
· 07-15 05:30
¿Por qué los proyectos de Finanzas descentralizadas presentan con frecuencia este tipo de errores de desbordamiento de enteros? Antes de profundizar en la raíz del problema, es necesario entender el algoritmo pow.
Ver originalesResponder0
GasOptimizer
· 07-15 05:28
Echar la culpa es una buena crítica, definitivamente es un error por no haber revisado.
Reflexiones sobre el incidente del hacker de Cetus: la seguridad en DeFi necesita salir del pensamiento puramente técnico
Cetus Protocol recientemente publicó un informe de retrospectiva de seguridad sobre un incidente de ataque Hacker. Este informe es bastante transparente en la divulgación de detalles técnicos y la respuesta de emergencia, siendo un ejemplo digno de un libro de texto. Sin embargo, al explicar "por qué fueron hackeados", la actitud del informe parece esquivar un poco la cuestión central.
El informe destaca la explicación del error de verificación en la función checked_shlw de la biblioteca integer-mate, calificándolo como "malentendido semántico". Aunque esta descripción es técnicamente correcta, parece desviar el enfoque hacia la responsabilidad externa, como si Cetus también fuera una víctima de este defecto técnico.
Sin embargo, vale la pena reflexionar sobre por qué, dado que integer-mate es una biblioteca matemática de código abierto de uso generalizado, ha surgido una vulnerabilidad tan grave aquí en Cetus. Al analizar la ruta de ataque, se puede observar que para que un hacker lleve a cabo un ataque perfecto, debe cumplir simultáneamente con cuatro condiciones: verificación de desbordamiento incorrecta, operación de desplazamiento significativo, regla de redondeo hacia arriba y falta de verificación de razonabilidad económica.
Sorprendentemente, Cetus mostró negligencia en cada una de las condiciones de "activación". Por ejemplo, el sistema aceptó números astronómicos ingresados por los usuarios, utilizó cálculos de desplazamiento extremadamente peligrosos y confió completamente en el mecanismo de verificación de bibliotecas externas. Lo más mortal es que, cuando el sistema calculó un resultado tan absurdo como "1 token por una participación a precio de oro", se ejecutó directamente sin ninguna verificación de sentido económico.
Por lo tanto, las verdaderas cuestiones que Cetus debería reflexionar incluyen:
¿Por qué se utiliza una biblioteca externa genérica sin realizar pruebas de seguridad adecuadas? Aunque la biblioteca integer-mate tiene características como ser de código abierto, popular y ampliamente utilizada, parece que Cetus no ha comprendido completamente los límites de seguridad de esta biblioteca al gestionar activos tan enormes, ni ha considerado alternativas en caso de que la biblioteca falle. Esto refleja una falta de conciencia en la protección de la seguridad de la cadena de suministro por parte de Cetus.
¿Por qué se permite la entrada de números astronómicos sin establecer límites? A pesar de que los protocolos DeFi persiguen la descentralización, los sistemas financieros maduros también necesitan límites claros al mismo tiempo que son abiertos. Permitir la entrada de números tan exagerados indica que el equipo puede carecer de talento en gestión de riesgos con intuición financiera.
¿Por qué, después de múltiples auditorías de seguridad, todavía no se detectaron problemas de antemano? Esto expone un error cognitivo fatal: el equipo del proyecto externaliza completamente la responsabilidad de seguridad a la empresa de seguridad, considerando la auditoría como un pase de exención de responsabilidad. Sin embargo, los ingenieros de auditoría de seguridad son expertos en detectar errores en el código, pero pueden no pensar en probar el rendimiento del sistema en situaciones extremas.
Esta verificación que cruza las fronteras de las matemáticas, la criptografía y la economía es precisamente el mayor vacío de seguridad en el DeFi moderno. Las empresas de auditoría pueden considerar que se trata de un defecto en el diseño del modelo económico y no de un problema de lógica del código, mientras que los proyectos pueden quejarse de que la auditoría no detectó problemas, y los usuarios son quienes finalmente asumen las pérdidas.
Este evento expuso las deficiencias de seguridad sistémica en la industria DeFi: los equipos con un trasfondo puramente técnico a menudo carecen de un "olfato para el riesgo financiero" básico. Según el informe de Cetus, el equipo parece no haber reconocido completamente este hecho.
Para Cetus y toda la industria DeFi, es importante salir de las limitaciones del pensamiento puramente técnico y cultivar una verdadera conciencia de riesgos de seguridad entre los "ingenieros financieros". Se podría considerar la incorporación de expertos en control de riesgos financieros para cubrir las lagunas de conocimiento del equipo técnico; establecer un mecanismo de auditoría y revisión de múltiples partes, que no solo se enfoque en la auditoría del código, sino que también preste atención a la auditoría del modelo económico; cultivar un "olfato financiero", simular varios escenarios de ataque y formular medidas de respuesta correspondientes, manteniendo una alta vigilancia sobre operaciones anómalas.
Con el desarrollo de la industria, los errores técnicos a nivel de código pueden ir disminuyendo gradualmente, pero la lógica empresarial con "conciencia de error" que tiene fronteras difusas y responsabilidades poco claras se convertirá en el mayor desafío. Las empresas de auditoría pueden asegurar que el código no tenga errores, pero cómo lograr que la "lógica tenga límites" requiere que el equipo del proyecto tenga una comprensión más profunda de la naturaleza del negocio y la capacidad de controlar los límites.
El futuro de DeFi pertenece a aquellos equipos que no solo tienen habilidades técnicas sólidas en código, sino que también comprenden profundamente la lógica empresarial. Solo los equipos que posean estas dos capacidades simultáneamente podrán establecerse realmente y tener éxito en esta industria llena de desafíos.