Finanzas descentralizadas Seguridad: Vulnerabilidades de seguridad comunes y medidas de prevención

Recientemente, un experto en seguridad compartió contenido relacionado con la seguridad de las Finanzas descentralizadas, revisó los importantes incidentes de seguridad en la industria Web3 durante el último año, exploró las razones detrás de estos eventos y cómo evitarlos, resumió las vulnerabilidades de seguridad comunes en los contratos inteligentes y las medidas preventivas, y ofreció algunos consejos de seguridad a los proyectos y usuarios.

Los tipos comunes de vulnerabilidades en DeFi generalmente incluyen préstamos relámpago, manipulación de precios, problemas de permisos de funciones, llamadas externas arbitrarias, problemas con la función fallback, vulnerabilidades en la lógica de negocio, filtración de claves privadas, reentradas, entre otros. Este artículo se centra en los préstamos relámpago, la manipulación de precios y los ataques de reentrada.

Préstamo relámpago

El préstamo relámpago en sí mismo es una innovación de las Finanzas descentralizadas, pero cuando es utilizado por hackers, no necesitan gastar ningún costo para pedir prestado, devuelven el dinero después de ejecutar todo el proceso de arbitraje, y lo que queda es las ganancias del arbitraje, solo necesitan pagar una pequeña cantidad de tarifas de Gas para obtener enormes beneficios.

Los ataques comunes a menudo están acompañados de préstamos relámpago, los atacantes prefieren tomar prestados grandes montos de dinero a través de préstamos relámpago para manipular precios, atacar la lógica del negocio, etc. Los desarrolladores deben considerar si las funciones del contrato se verán afectadas por grandes sumas de dinero que causen anomalías en las funciones, o si a través de grandes sumas de dinero se interactúa en una sola transacción con múltiples funciones en el contrato para obtener recompensas en estos escenarios.

A menudo se puede ver que algunos valores de cantidad de Token en el contrato se utilizan para calcular recompensas, o se utiliza la cantidad de Token en los pares de intercambio DEX para participar en varios cálculos. Dado que los desarrolladores no consideraron que los atacantes podrían manipular estas variables utilizando préstamos relámpago al diseñar estas funciones, los fondos del contrato fueron robados.

En los últimos dos años, los préstamos relámpago han presentado muchos problemas. Muchos proyectos de Finanzas descentralizadas parecen tener altos rendimientos, pero en realidad, el nivel de los equipos detrás de los proyectos es desigual. Por ejemplo, el código podría haber sido comprado; incluso si el código en sí no tiene vulnerabilidades, aún pueden existir problemas lógicos. Por ejemplo, hubo un proyecto que otorgaba recompensas en momentos fijos según la cantidad de tokens que poseían los tenedores, pero fue explotado por atacantes que utilizaron préstamos relámpago para comprar grandes cantidades de tokens, y cuando se otorgaron las recompensas, la mayor parte de estas fluyó hacia los atacantes. Además, hay algunos proyectos que calculan precios a través de tokens, que pueden ser influenciados por préstamos relámpago, como equipo del proyecto, deberían estar alerta ante estos problemas.

Manipulación de precios

El problema del control de precios está estrechamente relacionado con los préstamos relámpago; este problema se debe principalmente a que algunos parámetros pueden ser controlados por los usuarios al calcular el precio, y los tipos de problemas que suelen aparecer son dos.

• Una forma es utilizar datos de terceros para calcular el precio, pero un uso incorrecto o la falta de verificación pueden llevar a que el precio sea manipulado maliciosamente.
• Otra forma es debido a que se utiliza 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 peligros de llamar a contratos externos es que pueden tomar el control del flujo de ejecución y realizar cambios inesperados en tus datos al invocar 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 siguientes ) aún tendrán éxito y se extraerá el saldo una y otra vez.

Existen muchas formas de reentrada en función de los diferentes contratos; se pueden combinar diferentes funciones de contratos o funciones de múltiples contratos distintos para llevar a cabo un ataque de reentrada. Por lo tanto, al abordar el problema de reentrada, debemos prestar atención a los siguientes puntos:

1. No solo previene el problema de reentrada de una única función;
2. Seguir el patrón Checks-Effects-Interactions para codificar;
3. Utilizar un modificador anti-reentrada probado con el tiempo.

En realidad, lo que más tememos es reinventar la rueda, necesitar escribir todo nosotros mismos. En este ámbito hay muchas mejores prácticas de seguridad, solo tenemos que utilizarlas, no hay necesidad de reinventar la rueda. Cuando creas una rueda, no ha sido validada adecuadamente, y en ese momento, la probabilidad de que surjan problemas es, evidentemente, mucho mayor que la de usar algo que ya ha sido probado y es muy maduro.

La historia detrás de la vulnerabilidad del Protocolo Omni --- La lucha entre cuatro hackers

El mempool de Ethereum ha estado bajo la vigilancia de numerosos hackers, quienes analizan constantemente las transacciones y realizan front-running en las transacciones rentables para obtener ganancias. Las transacciones de ataque enviadas por el descubridor de la vulnerabilidad del Omni Protocol fueron capturadas por dos hackers, quienes utilizaron bots de front-running para aprovechar las transacciones de front-running en flashbot y robaron 1200 ETH del protocolo Omni, mientras que el atacante que descubrió la vulnerabilidad solo obtuvo 480 ETH. Durante este tiempo, otro hacker descubrió las transacciones de ataque enviadas por los hackers de front-running en flashbot y, aprovechando que las transacciones de ataque requerían comprar el token Doodle ERC20, realizó un ataque sandwich, obteniendo una ganancia de 151 ETH.

Las personas que descubren vulnerabilidades no son las que más ganan; las que más ganan son otros cazadores en el bosque oscuro. En este ecosistema hay cazadores por todas partes, y los cazadores pueden ser presa unos de otros. Incluso el iniciador de un ataque, si es un novato, puede no llevarse la mayor parte del dinero del proyecto, a menos que lo recoja de una sola vez. Además, muchas personas utilizarán tarifas de Gas más altas para ejecutar las transacciones primero, y si la compra y venta de tokens en DEX está involucrada en el proceso de adelantarse, esto puede resultar en un ataque de sándwich, lo que es muy confuso.

Sugerencias de seguridad

Por último, se presentan recomendaciones de seguridad para los proyectos y los usuarios participantes comunes.

Consejos de seguridad para el proyecto

Uno, el desarrollo de contratos sigue las mejores prácticas de seguridad.

2. Contratos actualizables y pausables: Muchos ataques no son de una sola vez que transfieren todas las monedas, sino que se ejecutan en múltiples transacciones. Si hay un mecanismo de monitoreo relativamente sólido, se puede detectar. Después de detectarlo, suponiendo que el contrato puede ser pausado, se puede reducir eficazmente la pérdida.

Tres, uso de bloqueo temporal: Como en algunos casos, si hay un bloqueo temporal, supongamos que debe completarse dentro de 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 saben que el proyecto debería haber sido hackeado, por lo que pueden notificar al equipo del proyecto para que lo cambie, incluso si se supone que se notificó y nadie se ocupa, al menos pueden retirar su parte del dinero primero, asegurando que sus ganancias no se vean afectadas. Por lo tanto, si un proyecto no tiene bloqueo temporal, teóricamente aumenta la probabilidad de que surjan problemas.

Cuatro, 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 pienses que como parte del proyecto, si el contrato ha sido auditado por varias empresas, está libre de problemas; como resultado, un hacker puede robar la clave privada, incluso si es con múltiples firmas, pueden robar todas las claves privadas. O puede ser que el modelo económico tenga problemas, que el modelo de negocio tenga problemas... hay miles de maneras en las que se puede perder dinero, depende de si se pueden evitar todos los riesgos de seguridad de antemano. Se debe intentar hacer modelado de riesgos y luego ir evitando gradualmente la mayor parte de los riesgos; los riesgos restantes también deben ser aceptables y estar dentro de un rango tolerable. La seguridad y la eficiencia no pueden coexistir de manera óptima, debe haber cierta concesión. Pero si no se presta atención a la seguridad y no se invierte en ella, ser atacado es algo muy normal.

Cinco, aumentar la conciencia de seguridad de todos los empleados: Aumentar la conciencia de seguridad no requiere mucha técnica. En Twitter, a menudo vemos a muchas personas perder NFT por phishing; de hecho, la forma de phishing utiliza las debilidades humanas. Si prestáramos un poco más de atención, podríamos evitar caer en la trampa. En este gran entorno de Web3, solo con preguntar un poco más el porqué y pensar un poco más, se pueden evitar muchos problemas.

Seis, prevenir el daño interno, mejorando la eficiencia mientras se refuerza el control de riesgos: Tomemos algunos ejemplos. Primero, el propietario del contrato es una firma única en lugar de una firma múltiple, si se pierde la clave privada, todo el proyecto queda bajo control; segundo, no se utilizó un bloqueo temporal, algunas actualizaciones de operaciones clave se realizaron de inmediato, sin que nadie lo supiera, lo cual es muy injusto para todos los participantes del protocolo; además, el daño interno, el mecanismo de seguridad interno no ha tenido ningún efecto.

¿Cómo pueden los protocolos en la cadena garantizar eficiencia al mismo tiempo que también mejoran la seguridad? Algunas herramientas de seguridad pueden designar a una persona para ejecutar una operación, como por ejemplo un multisig de tres de cinco; se puede designar una dirección específica para realizar una operación, como permitir que un nodo de confianza realice la supervisión de riesgos de seguridad. Supongamos que se detecta que el protocolo está siendo atacado y que los fondos están siendo transferidos gradualmente a la dirección del hacker. Si este contrato tiene una función de pausa, y hemos otorgado esa función de pausa a una persona, entonces él podrá realizar esta operación.

Por ejemplo, en el caso de los creadores de mercado para DEX, si no se limitan los derechos del propietario, el propietario puede transferir dinero a otra dirección, puede restringir las direcciones a las que se pueden transferir monedas, limitar qué pares de monedas se pueden operar y establecer que solo se puede retirar dinero a una dirección específica. Esto mejora la eficiencia al mismo tiempo que garantiza un cierto nivel de seguridad.

Siete, Seguridad en la introducción de terceros: Como parte del ecosistema, cada proyecto tiene su propia cadena de suministro. En términos de seguridad, existe un principio de "los upstream y downstream son inseguros por defecto". Es necesario realizar verificaciones tanto para upstream como para downstream. En cuanto a los terceros, es muy difícil de controlar, y la exposición al riesgo de seguridad es especialmente grande, por lo que se debe 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 debe referenciar en absoluto. Porque no sabemos cuál es la lógica interna, o si la introducción de este contrato es en sí mismo un contrato actualizable, su uso normal puede no tener problemas, pero no podemos prever si de repente un día se actualizará y se convertirá en un contrato malintencionado, lo cual es incontrolable.

¿Cómo pueden los usuarios/LP determinar si un contrato inteligente es seguro?

Para los usuarios comunes, evaluamos la seguridad de un proyecto principalmente en base a los siguientes seis puntos:

1. ¿El contrato es de código abierto? Cualquier proyecto cuyo contrato no sea de código abierto, no lo tocamos, porque no tenemos forma de saber qué está escrito en el contrato.

Dos, si el propietario utiliza múltiples firmas, si las múltiples firmas son descentralizadas: Si no se utilizan múltiples firmas, no podemos evaluar la lógica de negocio y el contenido del proyecto; en caso de un evento de seguridad, no podemos determinar si fue obra de un hacker. Incluso si se utilizan múltiples firmas, también es necesario evaluar si las múltiples firmas son descentralizadas.

Tres, situación de las transacciones del contrato existente: Especialmente hay muchos proyectos de phishing en el mercado que pueden crear un contrato bastante similar, en este momento debemos observar el tiempo de implementación del contrato, el número de interacciones, etc., estos son estándares de medida para juzgar si el contrato es seguro.

Cuatro, ¿el contrato es un contrato de agencia, se puede actualizar, hay un bloqueo de tiempo: Si el contrato no se puede actualizar en absoluto, sería demasiado rígido, aún se recomienda que el contrato del proyecto sea actualizable. Pero la actualización debe hacerse de manera cuidadosa, cuando la actualización tenga contenido de actualización o cambios en parámetros importantes, debe haber un bloqueo de tiempo, debe haber una ventana de tiempo para que todos puedan juzgar si la actualización real es perjudicial o beneficiosa para los usuarios, esta también es una forma de ser público y transparente.

Cinco, ¿ha sido auditado el contrato por varias instituciones? ( No confíes ciegamente en las empresas de auditoría ), ¿los permisos del propietario son demasiado amplios? 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. Si un proyecto tiene resultados de auditoría de varias instituciones y se han encontrado diferentes problemas, y el equipo del proyecto ha realizado las correcciones, es más seguro en comparación con tener solo una auditoría de una sola empresa. Un equipo de proyecto responsable buscará realizar auditorías cruzadas con varias instituciones.

En segundo lugar, es importante ver si los permisos del Owner son excesivos. Por ejemplo, en algunos proyectos de貔恘盘, el Owner puede controlar completamente los fondos de los usuarios. Si se compran pocos tokens, se puede comerciar normalmente, pero si la cantidad de tokens comprados es enorme, el Owner puede bloquear de inmediato la posibilidad de transacciones. Algunos proyectos de NFT son iguales. En un proyecto normal, los permisos del Owner deben ser controlables, de modo que no haya demasiadas operaciones de alto riesgo, y las operaciones también se realizarán de forma programada, para que los usuarios sepan qué se está haciendo. Especialmente en tiempos de mercado difíciles, hay todo tipo de esquemas Ponzi, por lo que todos deben prestar atención a los permisos del Owner.

Seis, atención a los oráculos: Si el proyecto utiliza un oráculo líder en el mercado, en general no habrá grandes problemas, pero si utiliza un oráculo propio, o si se pueden agregar tokens de manera aleatoria como colateral,