Mejores Prácticas de Ciberseguridad para Proyectos de Cripto

En esta entrevista, Galo Tocagni explica los principales riesgos de código que corren los proyectos de Web3 y una serie de estrategias para mitigarlos…

Galo Tocagni es VP of Services en OpenZeppelin, una de las empresas líderes en ciberseguridad para cripto a nivel mundial.

¿Cuáles son los principales riesgos de código que afectan a los proyectos de blockchain?

En 2022, unos 3.900 millones de dólares fueron robados a través de hackeos y scams, un aumento del 45% respecto de 2021.

Esto se debe a tres factores:

Primero, los protocolos se están volviendo más complejos, aumentando la superficie y la exposición a nuevos vectores de ataque. Hoy en día, los proyectos tienen más casos de uso y más integraciones con otros protocolos a través de oráculos (que conectan información del mundo real con la blockchain) e implementaciones multichain…

Segundo, cada vez hay más dinero en juego. Sólo en Ethereum hay unos 30.000 millones de dólares de Total Value Locked (TVL), la cantidad de criptoactivos dentro de esta blockchain. Proyectos como Uniswap crecieron de 50 millones de dólares de TVL a más de 4.000 millones en sólo dos años. Más dinero en juego significa que hay más incentivo para los hackers.

Tercero, están surgiendo nuevas organizaciones de hackers con más recursos y mejor coordinación. Estamos viendo el nacimiento del cibercrimen organizado.

Como los riesgos son cada vez mayores, los procedimientos de seguridad se vuelven más importantes. La seguridad debe incorporarse a lo largo de todo el ciclo de desarrollo de una aplicación, y no sólo como algo aislado y puntual como es el caso de una auditoría.

Galo Tocagni, VP of Services en OpenZeppelin.

¿Cuáles son los tipos de ataques más comunes?

Primero, están los ataques a los bridges. Estos son “puentes” que mandan mensajes de una blockchain a otra. Para agregar funcionalidades multichain, los protocolos deben conectarse a través de un bridge colateralizando activos en un contrato. Esto es un factor de riesgo, dado el nivel de centralización de los sistemas.

Segundo, los ataques de gobernanza buscan explotar vulnerabilidades en los sistemas de votación. Por ejemplo, alguien puede pedir prestados tokens de un proyecto para obtener poder de voto y utilizarlo para hacer aprobar una propuesta que le permita apropiarse de fondos.

Tercero, los ataques de access control tratan de obtener el control sobre un smart contract que le dé al atacante control sobre un protocolo para realizar una acción maliciosa.

Por último, los flash loan attacks buscan manipular los precios reportados por un oráculo a través de un préstamo de muy corto plazo conocido como flash loan. Esto hace que el protocolo erróneamente crea que los valores de los activos sean diferentes de los reales y ejecuten alguna acción que beneficia al atacante.

En el Leaderboard de Rekt News podemos ver los tipos de ataques más comunes. Esto es muy útil para aprender de los errores de otros mientras estamos desarrollando nuestro protocolo.

¿Cómo puede un equipo incorporar mejores prácticas en seguridad a lo largo de todo el ciclo de desarrollo?

Es importante tener un mindset de seguridad desde el comienzo. Esto es, entender cuál es el threat model: ¿cuáles son las principales amenazas sobre nuestro proyecto? ¿Cuáles son los “bad actors” que van a intentar atacar nuestro código?

Si estamos desarrollando un proyecto de NFTs, por ejemplo, podríamos pensar que un punto de vulnerabilidad es la función de mint que se utiliza para crear los NFTs. Entonces, deberíamos tener muy claro quién tendrá derecho a autorizar el uso de la función, quiénes son los firmantes del smart contract y cómo se hará el manejo de las llaves privadas.

A partir de las amenazas identificadas en el threat model, podemos pensar en cuáles deben ser las mejores prácticas a incorporar.

Una buena práctica es utilizar librerías públicas de código que ya hayan sido utilizadas y probadas en otros proyectos. En este aspecto, las librerías de OpenZeppelin se han convertido en un estándar de la industria. Más del 90% de los proyectos desplegados en Ethereum las utilizan.

A lo largo de todo el proceso de desarrollo, es muy importante escribir documentación completa.

Si un proyecto tiene mala documentación, para los auditores muchas veces esto es un indicio de que los desarrolladores no saben muy bien lo que hacen sus smart contracts. La falta de documentación genera inconvenientes para la comunidad y los auditores a la hora de entender cómo se comporta el sistema.

Hay un gran número de recursos y herramientas públicas que pueden ayudar a incorporar mejores prácticas en seguridad antes de empezar una auditoría. En esta línea, OpenZeppelin lanzó el Smart Contract Audit Readiness Guide.

Otro ejemplo es la Ethereum Enterprise Alliance que desarrolló una serie de especificaciones que los proyectos deben seguir para asegurar un código de calidad que cumpla con todas las mejores prácticas y estándares.

¿Cual es el objetivo de una auditoría de seguridad?

Una auditoría de seguridad de smart contracts proporciona un análisis detallado del sistema y su infraestructura, con el objetivo de verificar que el código sea correcto, completo y seguro.

Un código correcto significa que el sistema efectivamente hace aquello que está diseñado para hacer.

Un código completo significa que el código está escrito de manera rigurosa, incorporando las mejores prácticas de desarrollo.

Un código seguro significa que el sistema está protegido contra todos los tipos posibles de ataque. Un protocolo no es un sistema aislado. Cuantas más integraciones tenga, más expuesto se encuentra a distintos vectores de ataque.

Una auditoría es la oportunidad de contar con un equipo de expertos en seguridad de smart contracts que conozcan en profundidad tus sistemas, muchas veces más que los mismos desarrolladores que crearon el código.

La diferencia es que los auditores lo miran con un mindset de ataque ofensivo. Buscan poner al sistema bajo estrés para identificar todos aquellos casos en los que puede fallar y encontrar todas las situaciones que permitan a un atacante generar daño. Esto no es sólo robar fondos sino que también puede ser bloquear o quemar dinero, obstruir el uso de las interfaces o romper el sistema.

Imaginemos que soy un emprendedor de Web3 y ya desarrollé mi primera aplicación. ¿En qué momento debería hacer una auditoría de mi código?

El momento perfecto para una auditoría es justo antes del deployment. Cuando uno cree que el código ya está lo suficientemente maduro como para ser lanzado. Mientras más maduro esté el código, más jugo se le puede sacar a un auditor para encontrar vulnerabilidades.

Si el código está inmaduro, quizá el auditor gaste tiempo en identificar una vulnerabilidad que uno mismo podría haber encontrado en el proceso de desarrollo.

¿Cuánto demora en promedio la auditoría de una aplicación?

Esto varía mucho en función de ciertos parámetros.

Primero, la extensión del código. La auditoría de una aplicación con más líneas de código, por supuesto, tendrá una mayor duración.

Segundo, la complejidad del código. El tipo de código utilizado y el hecho de tener integraciones con otros protocolos afecta la dificultad y la duración de la auditoría.

Tercero, las librerías. Si el código reutiliza librerías preexistentes, los auditores no necesitan revisarlo por completo porque conocen las librerías y dan por sentado que son seguras.

El alcance de la auditoría se define en función de estas tres variables. En promedio, un proyecto simple demora dos semanas y trabajan dos auditores.

¿Cuáles son las etapas de una auditoría?

Un proceso de auditoría consiste en tres etapas: estimación, auditoría y publicación.

1. Estimación. El cliente comparte el código y la documentación relevante. En base a esto, se realiza una estimación de la duración y el presupuesto. Se define una fecha para el comienzo de la auditoría. En base a la calidad del código, se definen acciones para que el código llegue en mejores condiciones a la auditoría.
2. Auditoría. Esta fase empieza con un call inicial en el que se pone en marcha el proceso. Desde ese momento, hay una constante comunicación entre el cliente y los auditores. La fase de auditoría se subdivide en tres etapas.

El primer paso es entender qué se espera del código. Para esto, se lee el white paper, la documentación, las especificaciones y cualquier otro material disponible. Mientras mejor sea la documentación que pueda proveer el equipo, más eficiente será el proceso de auditoría.

El segundo paso es correr los tests y herramientas de seguridad. Esto nos permite identificar vulnerabilidades comunes y da indicio a los auditores de dónde deben enfocar su atención. Luego, se hace una revisión manual del código. Según nuestra política, cada línea de código tiene que ser revisada por al menos dos pares de ojos. Aquí nos preguntamos: ¿el código es correcto? ¿Hace lo que debería estar haciendo?

En el tercer paso, confeccionamos un reporte inicial con una descripción de cómo funciona el sistema, una descripción de los problemas encontrados y sugerencias de cómo deberían resolverse.

3. Publicación. En esta fase el proyecto debe resolver las vulnerabilidades encontradas. Luego los auditores revisan que las correcciones hayan sido bien hechas, y se cierra el reporte final. Siempre sugerimos que el reporte se haga público como una muestra a la comunidad de que el equipo está comprometido con la seguridad.

¿Qué variables debería tener en cuenta un equipo a la hora de decidir qué auditor elegir?

Es importante evaluar el tipo de expertise de la firma a contratar. Algunas empresas están más especializadas en cierto tipo de proyectos. Así que es bueno ver cuál tiene mayor expertise en lo que se está desarrollando.

También vale la pena ir a alguna conferencia y acercarse al stand de las empresas de auditoría para sentir la “química” con los distintos equipos de seguridad. Los auditores tienen que verse como una parte extendida del equipo y no sólo como el proveedor de un servicio.

Finalmente, una buena práctica es dedicar una semana a revisar los reportes de auditoría de diferentes empresas y ver con cuál uno se siente más cómodo.

¿Qué consejo final podrías dar a un equipo que está empezando a emprender en el mundo del blockchain?

El mensaje más importante es que, en un proyecto de blockchain, el código siempre está expuesto y hay actores anónimos constantemente buscando oportunidades para explotar vulnerabilidades.

Existe una falsa creencia de que un equipo puede dejar la seguridad en manos de los auditores. La realidad es que el equipo de desarrollo es el principal responsable de la seguridad. La seguridad debe ser parte de la cultura de una organización.