Finanzas descentralizadas comunes vulnerabilidades de seguridad y medidas de prevención
Recientemente, un experto en seguridad compartió una clase de seguridad en Finanzas descentralizadas con los miembros de la comunidad. El experto revisó los importantes incidentes de seguridad que ha enfrentado la industria Web3 en el último año, exploró las causas de estos incidentes de seguridad y cómo evitarlos, resumió las vulnerabilidades de seguridad comunes en los contratos inteligentes y las medidas de prevención, y también ofreció algunos consejos de seguridad tanto para los desarrolladores de proyectos como para los usuarios comunes.
Los tipos comunes de vulnerabilidades en Finanzas descentralizadas generalmente incluyen préstamos relámpago, manipulación de precios, problemas de permisos de funciones, llamadas externas arbitrarias, problemas con funciones de fallback, vulnerabilidades en la lógica de negocios, filtración de claves privadas, reentrada, entre otros. A continuación, se presentan en detalle los préstamos relámpago, la manipulación de precios y los ataques de reentrada.
Préstamo relámpago
El préstamo relámpago es en sí mismo una innovación de las Finanzas descentralizadas, pero cuando es utilizado por hackers, pueden obtener grandes sumas de dinero sin ningún costo, ejecutar todo el proceso de arbitraje y devolverlo, solo pagando una pequeña tarifa de Gas para obtener enormes ganancias.
En los últimos dos años, los préstamos relámpago han presentado muchos problemas. Algunos proyectos de Finanzas descentralizadas parecen tener altos rendimientos, pero en realidad, el nivel de los equipos detrás de los proyectos varía. Algunos códigos de proyectos pueden haber sido comprados; incluso si el código en sí no tiene vulnerabilidades, aún pueden existir problemas lógicos. Por ejemplo, hubo un proyecto que emitía recompensas en momentos fijos según la cantidad de tokens que poseían los tenedores, pero fue aprovechado por atacantes que utilizaron préstamos relámpago para comprar una gran cantidad de tokens, y en el momento de la emisión de recompensas, la mayor parte de estas se dirigió a los atacantes. Además, hay algunos proyectos que calculan precios a través de Tokens, los cuales pueden verse afectados por préstamos relámpago. Como equipo del proyecto, se debe tener mayor vigilancia sobre estos problemas.
Manipulación de precios
El problema del manipulación de precios está estrechamente relacionado con los préstamos relámpago. Este problema se debe principalmente a que algunos parámetros en el cálculo de precios pueden ser controlados por los usuarios, y los tipos de problemas que suelen aparecer son dos.
Al calcular el precio se utilizan datos de terceros, pero el uso incorrecto o la falta de verificación permiten que el precio sea manipulado maliciosamente.
Se utilizó la cantidad de tokens de algunas direcciones como variable de cálculo, y el saldo de tokens de estas direcciones puede ser temporalmente aumentado o disminuido.
Ataque de reentrada
Uno de los principales riesgos de llamar a contratos externos es que pueden tomar el control del flujo de control y realizar cambios inesperados en tus datos al llamar a funciones.
Debido a que el saldo del usuario se establece en 0 solo al final de la función, la segunda llamada a ( y las posteriores ) seguirán teniendo éxito y extraerán el saldo una y otra vez.
Para diferentes contratos, existen muchas formas de reentrada, que pueden combinar las diferentes funciones del contrato o las funciones de varios contratos diferentes para llevar a cabo un ataque de reentrada. Por lo tanto, al abordar el problema de la reentrada, debemos prestar atención a los siguientes puntos:
No solo previene el problema de reentrada de una única función;
Seguir el patrón de Checks-Effects-Interactions para codificar;
Utilizar un modificador de no reentrada comprobado con el tiempo.
En realidad, lo que más tememos es reinventar la rueda, escribiendo todo nosotros mismos. En este ámbito, hay muchas mejores prácticas de seguridad que podemos utilizar, no hay necesidad de reinventar la rueda. Cuando creas una rueda, no ha pasado por una validación adecuada, y en ese momento, la probabilidad de que surjan problemas es, evidentemente, mucho mayor que la de utilizar algo muy maduro y probado.
Sugerencias de seguridad
Consejos de seguridad para el proyecto
El desarrollo de contratos sigue las mejores prácticas de seguridad.
Contratos actualizables y pausables: Muchos ataques no son de una sola vez donde se transfieren todas las monedas, sino que se ejecutan en múltiples transacciones. Si hay un mecanismo de monitoreo relativamente sólido, se pueden detectar. Una vez detectado, si el contrato puede ser pausado, se pueden reducir efectivamente las pérdidas.
Uso de un bloqueo temporal: Si hay un bloqueo temporal, supongamos que debe completarse en 48 horas, en este momento muchas personas con el bloqueo temporal pueden descubrir que el creador ha actualizado un método de mint, y cualquiera puede usarlo, las personas que monitorean sabrán que el proyecto probablemente ha sido hackeado, y podrán notificar al equipo del proyecto para que haga cambios, incluso si asumimos que se notificó y nadie se ocupa, al menos pueden retirar su parte del dinero y asegurar que sus ganancias no se vean afectadas. Por lo tanto, se dice que si un proyecto no tiene un bloqueo temporal, teóricamente aumenta la probabilidad de que surjan problemas.
Aumentar la inversión en seguridad y establecer un sistema de seguridad completo: la seguridad no es un punto, ni una línea, la seguridad es un sistema. No piense que como parte del proyecto, si el contrato ha sido auditado por varias empresas, no hay problema. Se debe intentar realizar modelado de riesgos y luego ir eliminando gradualmente la mayor parte de los riesgos, el riesgo restante también es un riesgo aceptable, dentro de un rango tolerable. Seguridad y eficiencia no se pueden lograr al mismo tiempo, es necesario hacer ciertos sacrificios. Pero si no se presta atención a la seguridad y no se invierte en ella, es muy normal ser atacado.
Aumentar la conciencia de seguridad de todos los empleados: aumentar la conciencia de seguridad no requiere mucha tecnología. En este gran entorno, solo hay que preguntar un poco más sobre el porqué y pensar un poco más para evitar muchos problemas.
Prevenir el mal actuar interno, aumentando el control de riesgos mientras se mejora la eficiencia.
Seguridad de la introducción de terceros: como parte del ecosistema, los proyectos tienen sus propios proveedores y clientes. Existe un principio de "default que tanto el proveedor como el cliente son inseguros". Se deben realizar verificaciones tanto para los proveedores como para los clientes. Es muy difícil controlar a los terceros, el riesgo de seguridad es en realidad muy alto, por lo que hay que tener mucho cuidado con la introducción de terceros. El contrato es de código abierto, se puede introducir y llamar; si el contrato no es de código abierto, no se puede citar bajo ninguna circunstancia.
¿Cómo pueden los usuarios/LP determinar si un contrato inteligente es seguro?
Para los usuarios comunes, juzgamos si un proyecto es seguro principalmente observando los siguientes seis puntos:
¿El contrato es de código abierto?: Cualquier proyecto cuyo contrato no sea de código abierto, no debe ser tocado, porque no tenemos manera de saber qué se ha escrito en el contrato.
Si el propietario utiliza múltiples firmas, y si estas firmas son descentralizadas: si no se utilizan múltiples firmas, no podemos juzgar la lógica y el contenido del negocio del proyecto, y una vez que ocurra un evento de seguridad, no podremos determinar si fue causado por un hacker. Incluso si se utilizan múltiples firmas, también es necesario evaluar si estas firmas son descentralizadas.
Situación de las transacciones del contrato: especialmente hay muchos proyectos en el mercado que realizan estafas de phishing, que pueden crear un contrato bastante similar. En este momento, debemos observar el tiempo de despliegue del contrato, el número de interacciones, etc. Estos son criterios de evaluación para determinar si el contrato es seguro.
¿Es el contrato un contrato de agencia, es actualizable, tiene un bloqueo temporal?: Si el contrato no se puede actualizar en absoluto, sería demasiado rígido, todavía se recomienda que el contrato del proyecto sea actualizable. Pero la actualización debe hacerse de manera adecuada, cuando la actualización tenga contenido de actualización y cambios en parámetros importantes, debe haber un bloqueo temporal, debe haber una ventana de tiempo para que todos evalúen si la verdadera actualización es perjudicial o beneficiosa para los usuarios, esta también es una forma de ser público y transparente.
¿El contrato ha sido auditado por varias instituciones ( no confíes ciegamente en las empresas de auditoría ), ¿los permisos del Owner son demasiado grandes?: Primero, no confíes solo en una empresa de auditoría, porque diferentes empresas de auditoría y diferentes auditores tienen diferentes perspectivas al ver los problemas. En segundo lugar, hay que ver si los permisos del Owner son demasiado grandes. Los permisos de un Owner de un proyecto normal deben ser controlables, de esta manera no habrá demasiadas operaciones de alto riesgo, y las operaciones también se realizarán de manera temporal, permitiendo a los usuarios saber qué se está operando.
Atención a los oráculos: si el proyecto utiliza un oráculo líder en el mercado, no debería haber grandes problemas, pero si utiliza un oráculo propio, o uno que permita alimentar precios con solo colateralizar algunos tokens de manera arbitraria, entonces hay que tener cuidado. Cuando se detecta que el oráculo puede tener algunos problemas, o que existe la posibilidad de manipulación, no se debe participar, incluso si los rendimientos del proyecto son muy altos.
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.
16 me gusta
Recompensa
16
4
Compartir
Comentar
0/400
MetaverseHobo
· hace13h
Debe tener cuidado, haga su propia investigación (DYOR)
Curso de seguridad en Finanzas descentralizadas: Análisis de vulnerabilidades comunes y medidas de prevención
Finanzas descentralizadas comunes vulnerabilidades de seguridad y medidas de prevención
Recientemente, un experto en seguridad compartió una clase de seguridad en Finanzas descentralizadas con los miembros de la comunidad. El experto revisó los importantes incidentes de seguridad que ha enfrentado la industria Web3 en el último año, exploró las causas de estos incidentes de seguridad y cómo evitarlos, resumió las vulnerabilidades de seguridad comunes en los contratos inteligentes y las medidas de prevención, y también ofreció algunos consejos de seguridad tanto para los desarrolladores de proyectos como para los usuarios comunes.
Los tipos comunes de vulnerabilidades en Finanzas descentralizadas generalmente incluyen préstamos relámpago, manipulación de precios, problemas de permisos de funciones, llamadas externas arbitrarias, problemas con funciones de fallback, vulnerabilidades en la lógica de negocios, filtración de claves privadas, reentrada, entre otros. A continuación, se presentan en detalle los préstamos relámpago, la manipulación de precios y los ataques de reentrada.
Préstamo relámpago
El préstamo relámpago es en sí mismo una innovación de las Finanzas descentralizadas, pero cuando es utilizado por hackers, pueden obtener grandes sumas de dinero sin ningún costo, ejecutar todo el proceso de arbitraje y devolverlo, solo pagando una pequeña tarifa de Gas para obtener enormes ganancias.
En los últimos dos años, los préstamos relámpago han presentado muchos problemas. Algunos proyectos de Finanzas descentralizadas parecen tener altos rendimientos, pero en realidad, el nivel de los equipos detrás de los proyectos varía. Algunos códigos de proyectos pueden haber sido comprados; incluso si el código en sí no tiene vulnerabilidades, aún pueden existir problemas lógicos. Por ejemplo, hubo un proyecto que emitía recompensas en momentos fijos según la cantidad de tokens que poseían los tenedores, pero fue aprovechado por atacantes que utilizaron préstamos relámpago para comprar una gran cantidad de tokens, y en el momento de la emisión de recompensas, la mayor parte de estas se dirigió a los atacantes. Además, hay algunos proyectos que calculan precios a través de Tokens, los cuales pueden verse afectados por préstamos relámpago. Como equipo del proyecto, se debe tener mayor vigilancia sobre estos problemas.
Manipulación de precios
El problema del manipulación de precios está estrechamente relacionado con los préstamos relámpago. Este problema se debe principalmente a que algunos parámetros en el cálculo de precios pueden ser controlados por los usuarios, y los tipos de problemas que suelen aparecer son dos.
Al calcular el precio se utilizan datos de terceros, pero el uso incorrecto o la falta de verificación permiten que el precio sea manipulado maliciosamente.
Se utilizó la cantidad de tokens de algunas direcciones como variable de cálculo, y el saldo de tokens de estas direcciones puede ser temporalmente aumentado o disminuido.
Ataque de reentrada
Uno de los principales riesgos de llamar a contratos externos es que pueden tomar el control del flujo de control y realizar cambios inesperados en tus datos al llamar a funciones.
Debido a que el saldo del usuario se establece en 0 solo al final de la función, la segunda llamada a ( y las posteriores ) seguirán teniendo éxito y extraerán el saldo una y otra vez.
Para diferentes contratos, existen muchas formas de reentrada, que pueden combinar las diferentes funciones del contrato o las funciones de varios contratos diferentes para llevar a cabo un ataque de reentrada. Por lo tanto, al abordar el problema de la reentrada, debemos prestar atención a los siguientes puntos:
No solo previene el problema de reentrada de una única función;
Seguir el patrón de Checks-Effects-Interactions para codificar;
Utilizar un modificador de no reentrada comprobado con el tiempo.
En realidad, lo que más tememos es reinventar la rueda, escribiendo todo nosotros mismos. En este ámbito, hay muchas mejores prácticas de seguridad que podemos utilizar, no hay necesidad de reinventar la rueda. Cuando creas una rueda, no ha pasado por una validación adecuada, y en ese momento, la probabilidad de que surjan problemas es, evidentemente, mucho mayor que la de utilizar algo muy maduro y probado.
Sugerencias de seguridad
Consejos de seguridad para el proyecto
El desarrollo de contratos sigue las mejores prácticas de seguridad.
Contratos actualizables y pausables: Muchos ataques no son de una sola vez donde se transfieren todas las monedas, sino que se ejecutan en múltiples transacciones. Si hay un mecanismo de monitoreo relativamente sólido, se pueden detectar. Una vez detectado, si el contrato puede ser pausado, se pueden reducir efectivamente las pérdidas.
Uso de un bloqueo temporal: Si hay un bloqueo temporal, supongamos que debe completarse en 48 horas, en este momento muchas personas con el bloqueo temporal pueden descubrir que el creador ha actualizado un método de mint, y cualquiera puede usarlo, las personas que monitorean sabrán que el proyecto probablemente ha sido hackeado, y podrán notificar al equipo del proyecto para que haga cambios, incluso si asumimos que se notificó y nadie se ocupa, al menos pueden retirar su parte del dinero y asegurar que sus ganancias no se vean afectadas. Por lo tanto, se dice que si un proyecto no tiene un bloqueo temporal, teóricamente aumenta la probabilidad de que surjan problemas.
Aumentar la inversión en seguridad y establecer un sistema de seguridad completo: la seguridad no es un punto, ni una línea, la seguridad es un sistema. No piense que como parte del proyecto, si el contrato ha sido auditado por varias empresas, no hay problema. Se debe intentar realizar modelado de riesgos y luego ir eliminando gradualmente la mayor parte de los riesgos, el riesgo restante también es un riesgo aceptable, dentro de un rango tolerable. Seguridad y eficiencia no se pueden lograr al mismo tiempo, es necesario hacer ciertos sacrificios. Pero si no se presta atención a la seguridad y no se invierte en ella, es muy normal ser atacado.
Aumentar la conciencia de seguridad de todos los empleados: aumentar la conciencia de seguridad no requiere mucha tecnología. En este gran entorno, solo hay que preguntar un poco más sobre el porqué y pensar un poco más para evitar muchos problemas.
Prevenir el mal actuar interno, aumentando el control de riesgos mientras se mejora la eficiencia.
Seguridad de la introducción de terceros: como parte del ecosistema, los proyectos tienen sus propios proveedores y clientes. Existe un principio de "default que tanto el proveedor como el cliente son inseguros". Se deben realizar verificaciones tanto para los proveedores como para los clientes. Es muy difícil controlar a los terceros, el riesgo de seguridad es en realidad muy alto, por lo que hay que tener mucho cuidado con la introducción de terceros. El contrato es de código abierto, se puede introducir y llamar; si el contrato no es de código abierto, no se puede citar bajo ninguna circunstancia.
¿Cómo pueden los usuarios/LP determinar si un contrato inteligente es seguro?
Para los usuarios comunes, juzgamos si un proyecto es seguro principalmente observando los siguientes seis puntos:
¿El contrato es de código abierto?: Cualquier proyecto cuyo contrato no sea de código abierto, no debe ser tocado, porque no tenemos manera de saber qué se ha escrito en el contrato.
Si el propietario utiliza múltiples firmas, y si estas firmas son descentralizadas: si no se utilizan múltiples firmas, no podemos juzgar la lógica y el contenido del negocio del proyecto, y una vez que ocurra un evento de seguridad, no podremos determinar si fue causado por un hacker. Incluso si se utilizan múltiples firmas, también es necesario evaluar si estas firmas son descentralizadas.
Situación de las transacciones del contrato: especialmente hay muchos proyectos en el mercado que realizan estafas de phishing, que pueden crear un contrato bastante similar. En este momento, debemos observar el tiempo de despliegue del contrato, el número de interacciones, etc. Estos son criterios de evaluación para determinar si el contrato es seguro.
¿Es el contrato un contrato de agencia, es actualizable, tiene un bloqueo temporal?: Si el contrato no se puede actualizar en absoluto, sería demasiado rígido, todavía se recomienda que el contrato del proyecto sea actualizable. Pero la actualización debe hacerse de manera adecuada, cuando la actualización tenga contenido de actualización y cambios en parámetros importantes, debe haber un bloqueo temporal, debe haber una ventana de tiempo para que todos evalúen si la verdadera actualización es perjudicial o beneficiosa para los usuarios, esta también es una forma de ser público y transparente.
¿El contrato ha sido auditado por varias instituciones ( no confíes ciegamente en las empresas de auditoría ), ¿los permisos del Owner son demasiado grandes?: Primero, no confíes solo en una empresa de auditoría, porque diferentes empresas de auditoría y diferentes auditores tienen diferentes perspectivas al ver los problemas. En segundo lugar, hay que ver si los permisos del Owner son demasiado grandes. Los permisos de un Owner de un proyecto normal deben ser controlables, de esta manera no habrá demasiadas operaciones de alto riesgo, y las operaciones también se realizarán de manera temporal, permitiendo a los usuarios saber qué se está operando.
Atención a los oráculos: si el proyecto utiliza un oráculo líder en el mercado, no debería haber grandes problemas, pero si utiliza un oráculo propio, o uno que permita alimentar precios con solo colateralizar algunos tokens de manera arbitraria, entonces hay que tener cuidado. Cuando se detecta que el oráculo puede tener algunos problemas, o que existe la posibilidad de manipulación, no se debe participar, incluso si los rendimientos del proyecto son muy altos.