Lo Que Hemos Cambiado Desde el Ataque a OUSD

Moisés Sosa
Origin Protocol Spanish
6 min readJan 6, 2021

Lo siguiente es un post-mortem completo sobre el reciente hackeo de Origin Dollar (OUSD) que tuvo lugar el 16 de noviembre de 2020. Desde el ataque, pasamos un tiempo considerable aprendiendo de las fallas técnicas, actualizando nuestros contratos inteligentes de OUSD e introduciendo medidas de seguridad mejoradas y procesos en la empresa. Mientras nos preparamos para nuestro relanzamiento de OUSD, queríamos compartir algunas de nuestras últimas actualizaciones de ingeniería con la comunidad. En el futuro, estamos comprometidos a hacer de la seguridad nuestra prioridad número uno mientras ofrecemos retornos competitivos a nuestros holders de OUSD.

¿Qué pasó?

OUSD sufrió una pérdida de 7 millones de dólares el 16 de noviembre debido a un control de validación faltante que permitió un error de reentrada. Este error de validación se introdujo durante una refactorización de ahorro de gas que copió algunas funciones pero no copió la validación. Poco después del incidente, publicamos un plan detallado para proporcionar una compensación equivalente al 100% del valor depositado en OUSD en el momento del ataque. Estamos más motivados que nunca a hacer de OUSD todo un éxito para las masas, una moneda estable generadora de rendimiento.

Casi no sucedió…

Existe la teoría de los desastres de Swiss Cheese: en un sistema complejo, deben alinearse múltiples agujeros en las defensas para que ocurra un desastre. Casi no tuvimos esta pérdida de fondos…

  • Si no hubiéramos eliminado accidentalmente la validación, no habría pérdida de fondos.
  • Si hubiéramos detectado la validación eliminada durante la revisión del cambio de código, no hay pérdida de fondos.
  • Si hubiéramos agregado protección de reentrada, aunque no creíamos que la necesitáramos, no habría pérdida de fondos.
  • Si hubiéramos revisado el hack de Akropolis finance tan a fondo como lo hicimos con los otros hacks de DeFi, podríamos haber visto que éramos vulnerables.
  • Si no hubiéramos asumido que los insumos fueron validados al verificar nuestro contrato en busca de vulnerabilidades de reentrada, no hay pérdida de fondos.
  • Si hubiéramos puesto un límite de minting (acuñación) o un límite de rebase, podríamos haber reducido el impacto a < $200,000.
  • Si tuviéramos un suministro total limitado antes de tener una auditoría completa, habríamos tenido una pérdida correspondientemente menor.
  • Si hubiéramos detectado el ataque y hubiéramos detenido el contrato durante la ventana de seis minutos entre el primer ataque fallido del atacante y el segundo ataque exitoso, no hay pérdida de fondos.

La mala noticia fue que tuvimos una falla, en casi todos los niveles, con la excepción del diseño y la respuesta a incidentes. La buena noticia es que ahora tenemos una lista mucho más sólida y más larga de medidas y protocolos de seguridad para evitar que esto vuelva a suceder. Nos acercamos a donde necesitábamos antes.

Lo que hemos cambiado desde entonces

La solución real al error que causó la pérdida de fondos fue una sola línea de código.

Sin embargo, en lugar de simplemente hacer esa corrección y relanzar, nos hemos tomado un mes y medio para analizar detenidamente nuestros procesos y código, ¡con el objetivo de no volver a hacer eso nunca más!

Primero que nada, arreglamos la validación faltante.

También agregamos verificaciones de reentrada a la Bóveda de OUSD que evitarían que un error similar en el futuro pudiera ser aprovechado.

Más auditorías

Ahora tenemos dos auditorías de código completadas, junto con nuestras correcciones a los problemas menores restantes que se encontraron durante ellas. Trail of Bits estaba auditando nuestros contratos cuando ocurrió el ataque. Completaron su auditoría que identificó varios problemas menores además del error catastrófico. Desde entonces, hemos resuelto cada uno de los problemas que destacaron.

Dada la gravedad de la situación, decidimos contratar una segunda firma auditora para darle otra mirada a los contratos. Trabajamos con Solidified, quien revisó todo el sistema, así como nuestros nuevos contratos de staking y compensación que Trail of Bits no tuvo la oportunidad de revisar.

Tenemos la intención de seguir trabajando con firmas de auditoría de seguridad respetadas para revisar nuestro trabajo. Hemos programado una futura auditoría con OpenZeppelin para revisar actualizaciones adicionales. Si bien las auditorías aún no pueden garantizar la corrección, han demostrado ser útiles para identificar problemas potenciales.

Verificación formal

También hemos contratado a Certora para comenzar a verificar formalmente las diversas propiedades de seguridad de nuestros contratos. Nos ayudarán a definir un conjunto de reglas automatizadas para garantizar que nuestros contratos satisfagan sus especificaciones. Estas comprobaciones de verificación se ejecutarán como parte de nuestro proceso de CI para detectar errores futuros que rompan las especificaciones de nuestro contrato.

Herramientas automatizadas

Ahora tenemos una verificación automática de errores comunes en cada cambio de código utilizando acciones de GitHub para ejecutar Slither, en lugar de hacerlo de forma ad-hoc. Además, estamos ejecutando manualmente un conjunto básico de pruebas de fuzzing de Echidna en cada solicitud de extracción de contrato. Estas pruebas pueden detectar y advertir a nuestro equipo automáticamente sobre problemas de seguridad comunes. También ampliamos enormemente nuestro conjunto de pruebas para obtener una cobertura de código adicional.

Medidas y procesos de seguridad mejorados

Las revisiones de relaciones públicas que tocan contratos son ahora mucho más serias. Necesitamos dos ingenieros para cada RP de contrato, y lo estamos ralentizando para asegurarnos de que se hayan realizado las revisiones, además de agregar una lista de verificación a cada RP.

Nos tomamos una semana de seguridad para enfocarnos en la seguridad de los contratos y realizamos nuestra propia auditoría interna, además de tener una segunda auditoría externa. Tomaremos otra semana de seguridad más adelante en el año.

Nos hemos asegurado de que las funciones no afecten a la seguridad en nuestro proceso de planificación.

Anteriormente, dos ingenieros estaban revisando informalmente cada hack de DeFi. Sin embargo, el único hack que nos habría alertado de un problema con nuestros contratos, Akropolis, solo obtuvo una lectura rápida, en lugar de las revisiones exhaustivas que habían estado sucediendo después de otros ataques. Como resultado, no vimos la validación faltante que permitió el ataque.

Hemos formalizado una rotación de ingeniería para revisar otros ataques, así como también nos aseguramos de profundizar en cada una de estas revisiones hasta trabajar en el código fuente del contrato afectado nosotros mismos.

También estamos llevando a cabo retrospectivas internas sobre los “casi accidentes”, problemas que no afectaron a los usuarios pero llegaron más lejos de lo que deberían.

Aunque respondimos al ataque de OUSD a los pocos minutos de que ocurriera, queremos ser más rápidos la próxima vez. Ahora tenemos un monitoreo automatizado de Discord para transacciones grandes y transacciones fallidas.

Agregamos una función de pausa rápida que permite a dos holders de múltiples firmas (multi-sig) pausar la acuñación y el canje. Esto nos dará la capacidad de responder más rápido a los incidentes y, con suerte, reducir su tamaño.

Seguimos teniendo un programa de recompensas por errores con hasta $ 250,000 OUSD para las principales vulnerabilidades.

Seguro DeFi

Estamos explorando trabajar con Nexus Mutual, Cover Protocol y otros proveedores de seguros para que el seguro DeFi esté disponible para los holders de OUSD. Origin tiene la intención de desplegar un capital significativo como proveedor de cobertura inicial. Compartiremos más detalles en un futuro próximo.

Futuro de OUSD

El relanzamiento de OUSD es inminente, y estamos ansiosos por hacer que DeFi sea mucho más simple y que el dinero sea mucho mejor para todos.

Sabemos que logramos una combinación mágica de rendimiento y facilidad de uso con el lanzamiento inicial de OUSD. Se depositaron casi un millón de dólares al día en los dos días previos al hack, y esperamos recuperar ese impulso en un futuro cercano. En el futuro, la seguridad será nuestra prioridad número uno para OUSD.

Aprende más sobre Origin:

--

--