Auditoria de seguridad externa de Lisk SDK 5.0.0 y Lisk Core 3.0.0

febrero 26, 2021 VICTOR HUGO LAZARTE 0 Comments

 


Como ya se anunció a fines del año pasado, Lisk SDK 5.0.0 y Lisk Core 3.0.0 se han sometido con éxito a una auditoría de seguridad externa por parte de Least Authority , una empresa de auditoría de seguridad de renombre con mucha experiencia en la industria blockchain. En esta  queremos compartir la motivación de la auditoría de seguridad, brindar más detalles sobre el proceso general de auditoría y explicar los resultados que se dan en el Informe de auditoría de seguridad de la autoridad mínima.

Motivación para una auditoría de seguridad

Lisk SDK 5.0.0 y la próxima versión de mainnet Lisk Core 3.0.0 marcan un hito importante para el proyecto Lisk. Aparte de una gran cantidad de mejoras no relacionadas con el protocolo, se han implementado 28 propuestas de mejora de Lisk (LIP) como parte de Lisk Core 3.0.0. Cubrimos la mayoría de estos en detalle en la serie de publicaciones del blog de investigación el año pasado y también los resumimos aquí . Debido a la gran cantidad de cambios y nuestro compromiso con los más altos estándares de seguridad, era importante para nosotros que el nuevo protocolo Lisk, Lisk SDK 5.0.0 y la próxima versión de mainnet Lisk Core 3.0.0 se revisaran adicionalmente como parte de un auditoría de seguridad.

Una auditoría de seguridad de software es una revisión de una implementación con el fin de verificar si se adhiere a los estándares de seguridad, las mejores prácticas y si satisface las especificaciones y declaraciones de seguridad correspondientes. En particular, esto incluye buscar vulnerabilidades o errores en el software. Para las cadenas de bloques públicas como Lisk, la seguridad del software es de suma importancia, ya que cualquiera puede interactuar con la cadena de bloques enviando transacciones o forjando bloques y, por lo tanto, cualquier vulnerabilidad existente en el software puede explotarse fácilmente. Los grandes valores monetarios involucrados en las cadenas de bloques también brindan un gran incentivo para que los atacantes estén constantemente buscando vulnerabilidades. Por estas razones, las auditorías de seguridad independientes de los principales lanzamientos se han convertido en una práctica común en la industria blockchain.

Con esto en mente, ya comenzamos a prepararnos para una auditoría de seguridad mucho antes de completar Lisk SDK 5.0.0 y Lisk Core 3.0.0. Después de haber evaluado y hablado con varias empresas especializadas en auditorías de seguridad de blockchain, la Fundación Lisk finalmente decidió contratar a la Autoridad Mínima debido a su experiencia y un equipo sólido con conocimientos diversos. Sus comentarios positivos y el resultado de la auditoría dan confianza en nuestros estándares de seguridad, nuestros procesos de investigación y desarrollo y los próximos pasos para lanzar Lisk Core 3.0.0 a la red principal.

Proceso de auditoría

La primera parte importante del proceso de auditoría fue definir claramente el alcance de la auditoría. Para la auditoría de seguridad de Least Authority, este fue el diseño e implementación del protocolo Lisk:

Por lo tanto, la auditoría cubrió el protocolo completo y, por lo tanto, todas las partes críticas para la seguridad del software del nodo. Esto incluye, por ejemplo, la capa de igual a igual, el grupo de transacciones, el algoritmo de consenso Lisk-BFT, el algoritmo de firma, así como la codificación y el procesamiento de transacciones y bloques. Puede encontrar la descripción detallada del alcance en la sección Cobertura del Informe de auditoría de seguridad .

Poco después de completar el desarrollo de Lisk SDK 5.0.0 y Lisk Core 3.0.0, tuvimos una reunión con Least Authority para iniciar la auditoría, discutir el alcance y aclarar el proceso general de auditoría. A partir de entonces, los especialistas en seguridad de Least Authority revisaron nuestra documentación, especificaciones y código utilizando una variedad de herramientas y técnicas de seguridad como análisis de código estático , pruebas de fuzz , controles de seguridad contra dependencias o revisiones manuales. Puede encontrar más detalles sobre su enfoque y metodología en el informe de auditoría. Durante toda la revisión, nos comunicamos con regularidad, respondimos cualquier pregunta que surgiera y ya tuvimos la oportunidad de abordar directamente los hallazgos que compartieron con nosotros.

Después de cinco semanas de revisión del código y el protocolo, recibimos una versión inicial del informe de auditoría. Luego analizamos a fondo los hallazgos documentados y los discutimos con la Autoridad mínima. Para algunos de los hallazgos, preparamos una solución antes de recibir el informe de auditoría inicial. Con respecto a otros hallazgos, finalmente decidimos no cambiar la implementación, ya que no los veíamos como un problema de seguridad y un cambio de implementación hubiera implicado otras desventajas. Para todos los hallazgos del informe de auditoría inicial, también redactamos una respuesta detallada que también se incorporó parcialmente en el informe de auditoría final publicado. En la siguiente sección, resumimos la retroalimentación general en el informe y también explicamos los diferentes hallazgos. En particular,

Resultado de la auditoria

Retroalimentación general

La auditoría informó la alta calidad general del código base de Lisk y felicitó al proyecto Lisk por seguir las mejores prácticas en cuanto a seguridad, diseño de software y escritura de código. El equipo de Lisk siempre ha tenido como objetivo seguir los más altos estándares en esas áreas y utiliza múltiples herramientas para garantizar una alta calidad del código.

"El código está bien escrito y sigue constantemente las mejores prácticas de la industria para TypeScript".

Una parte muy importante de cualquier proyecto de software es la documentación. Como Blockchain es un campo relativamente nuevo, esto es especialmente cierto. Tener una documentación bien redactada nos permite dar la bienvenida a nuevos miembros a nuestra comunidad, ya sea como operadores de nodos o desarrolladores de cadenas laterales. En ese sentido, la auditoría encontró que nuestra documentación estaba bien redactada y cubría todos los aspectos importantes de nuestro proyecto.

"La documentación es completa, útil y precisa. Felicitamos al equipo de Lisk por brindar una cobertura completa de las opciones de diseño del sistema y el razonamiento de las decisiones de diseño".

La sencillez y la transparencia son valores fundamentales en el desarrollo del proyecto Lisk. Nuestro objetivo es ser abiertos y comunicar las decisiones de la manera más clara y objetiva. El equipo de auditoría felicitó la documentación y los LIP al proporcionar información sobre las opciones de diseño. Por último, y quizás lo más importante, la auditoría destacó el sólido enfoque de seguridad que seguimos. El equipo de investigación está trabajando arduamente para proponer actualizaciones de protocolo que sean seguras y garanticen la seguridad de la cadena de bloques Lisk.

"Descubrimos que el trabajo del equipo de Lisk es muy consciente de la seguridad: ya habían anticipado varios ataques potenciales y aplicaron mitigaciones".

Problemas y sugerencias específicos

En este apartado explicamos las tres cuestiones y dos sugerencias señaladas en el informe de auditoría y nuestro punto de vista para cada una de ellas.

Problema A: Error inesperado de Lisk-codec

El primer problema que se encontró fue un problema con el códec Lisk. La codificación predeterminada asignaría un objeto vacío a las matrices cuando no se proporcionó ningún elemento válido para la matriz, lo que resultaría en un valor de retorno no válido que no fue manejado por el códec Lisk. Por lo tanto, si la función que llama al códec Lisk no manejó correctamente el error, es posible que se hayan producido efectos secundarios no deseados. No hubo una amenaza de seguridad directa como resultado de este problema en el SDK, y ya se solucionó al final de la auditoría de seguridad.

Problema B: Cifrado mnemónico de CLI Lisk-core

El segundo problema se centró en la función de derivación de claves basada en contraseñas utilizada para crear la clave de cifrado para la frase de contraseña mnemotécnica en el lado del cliente. Para forjar bloques, los nodos delegados necesitan acceso a la frase de contraseña del delegado para firmar el bloque. Por razones de seguridad, la frase de contraseña no se almacena en el disco duro como texto sin formato, ya que, de lo contrario, cualquier persona con acceso al disco duro podría robarla fácilmente. En cambio, la frase de contraseña está encriptada con una contraseña que debe ingresar el operador del nodo para falsificarla. Es por eso que Lisk Elements implementa una función para cifrar la contraseña basada en PBKDF2 y AES. PBKDF2 es un esquema bien conocido para la derivación de claves basada en contraseñas debido a sus propiedades de estiramiento de claves . 

Como señala acertadamente el informe de auditoría, hoy en día existen algoritmos más nuevos para este propósito que tienen mejores propiedades que PBKDF2. En particular, Argon2 , que fue el ganador del Concurso de hash de contraseñas hace unos años, tiene propiedades superiores de resistencia a ASIC y agotadoras de memoria que PBKDF2. Sin embargo, PBKDF2 se usa ampliamente en muchos software críticos para la seguridad, como por ejemplo 1Password . Además, para que el ataque descrito en el informe sea posible, se asume que el atacante tiene acceso a la frase de contraseña encriptada, e incluso en este caso, no sería factible forzarla si el nodo delegado usa una contraseña segura.. Por lo tanto, después de considerar los pros y los contras del esquema actual, decidimos continuar apoyando el algoritmo PBKDF2 como el esquema predeterminado para derivar una clave de cifrado en Lisk Elements. 

Dicho esto, la opción adicional de Argon2 junto con PBKDF2 definitivamente será algo bueno para los operadores y delegados de nodos. Es por eso que hemos agregado el soporte de este algoritmo a las tareas futuras de nuestro equipo de desarrollo.

Problema C: derivación de claves de cuenta

La tercera cuestión planteada por el informe de auditoría se refería al algoritmo de derivación de claves de cuenta utilizado en Lisk. Este algoritmo calcula la clave privada para firmar bloques y transacciones a partir de la frase de contraseña proporcionada por el usuario. El método actual para derivar la clave privada de una cuenta es hash de la frase de contraseña usando la función hash SHA-256. El informe señaló que otros métodos de derivación de claves como HKDF tienen propiedades mejor probadas y recomendó que los productos Lisk utilicen dicho algoritmo. El equipo de auditoría también recomendó que todos los usuarios cambien su frase de contraseña en caso de que se implemente este cambio de algoritmo.

El informe señala que el método utilizado actualmente no corre el riesgo de ataques conocidos y que modificar este proceso sería un cambio radical. Después de haber examinado la opción propuesta, el equipo de Lisk ha decidido mantener el método de derivación de claves actual. Cambiar la derivación de claves implicaría que cada usuario de Lisk necesitaría generar una nueva contraseña y transferir todos los fondos de la cuenta anterior a la nueva. Para obtener compatibilidad con versiones anteriores, todas las carteras Lisk también deberían admitir ambos métodos de derivación de claves con la opción de cambiar entre ellos. Consideramos que la pérdida de experiencia del usuario y los riesgos de renunciar a esta migración superaban los beneficios de la propuesta.

En una nota técnica, las carteras de terceros podrían implementar un mecanismo de derivación de claves diferente y usar HKDF como lo propone el informe de auditoría. Sin embargo, tal implementación no sería compatible con la billetera oficial de Lisk, ya que generaría una clave privada diferente para la misma frase de contraseña.

Sugerencia 1: corregir errores tipográficos en la documentación

Least Authority encontró algunos errores tipográficos en nuestra documentación que arreglamos de inmediato.

Sugerencia 2: utilice una clave de dirección y una clave de firma independientes

Finalmente, Least Authority sugirió separar el par de claves usado para calcular la dirección de las claves usadas para firmar transacciones o falsificar bloques. Actualmente, no hay distinción en el protocolo Lisk entre estos dos casos de uso, y si las claves están comprometidas, el usuario tiene que crear una nueva cuenta para intentar ahorrar sus fondos. Para mitigar esto, Least Authority sugirió usar un nuevo conjunto de claves, junto con la clave pública original, para firmar transacciones. La clave privada original se utiliza luego para firmar una transacción de revocación de clave, en caso de que las nuevas claves se vean comprometidas.

Consideramos cuidadosamente esta sugerencia y finalmente decidimos no implementarla al momento de responder a la auditoría de seguridad. Creemos que la sugerencia solo aporta una ganancia de seguridad real si no complica mucho la experiencia del usuario. Por ejemplo, si los usuarios normales tuvieran que manejar varias frases de contraseña con diferentes permisos de forma predeterminada, es posible que se sientan abrumados por la complejidad, se bloqueen de sus cuentas o simplemente almacenen todas las frases de contraseña en el mismo lugar. Por lo tanto, preferimos el enfoque simple actual con una frase de contraseña por cuenta como predeterminada y la posibilidad de registrar una cuenta de firma múltiple para mayor seguridad. No obstante, estamos evaluando la posibilidad de introducir una gestión de claves más avanzada como una posible característica del Lisk SDK.

En conclusión, los resultados positivos de la auditoría de seguridad realizada por Least Authority demuestran la alta calidad de nuestra base de código, lo que nos permite lanzar de forma segura el próximo Lisk Core 3.0.0 a la red principal. Ahora que se ha completado la auditoría de seguridad, el desarrollo continúa en Lisk SDK 5.1.0. Uno de los objetivos de esta versión es agregar comandos para generar una plantilla de aplicación blockchain que incluya módulos, activos, complementos, configuración y un bloque de génesis para comenzar a desarrollar una aplicación blockchain. Otro objetivo de esta versión es agregar un complemento de tablero con el objetivo de proporcionar a los desarrolladores un explorador de blockchain integrado, que permite a los usuarios enumerar cuentas, bloques y transacciones. Otro objetivo de esta versión es agregar un marco de prueba de aplicaciones que permitirá a los desarrolladores probar partes críticas de su aplicación. Por lo tanto, como se ve en los objetivos de lanzamiento, el lanzamiento de Lisk SDK 5.1.0 viene con una experiencia de desarrollador mejorada.

Recursos:

  Como ya se anunció a fines del año pasado, Lisk SDK 5.0.0 y Lisk Core 3.0.0 se han sometido con éxito a una auditoría de seguridad externa...